INTRODUCTION
If you lead a team or internal projects, you probably know the feeling: everyone is busy, meetings are full, tasks "spin", but progress is not always visible. In such situations, companies often try to introduce stricter monitoring of people.
The problem is that KPIs "for people" often sound like control, create resistance and encourage the wrong behavior (for example, closing tasks without actual delivery). A much better approach is to measure the process: workflow, handover, downtime and delivery quality.
In this text you get a simple frame and 6 KPI metrics which you can introduce without complications — so that the team works more calmly, clearly and predictably.
Why KPIs for People Often Don't Work (and Create Resistance)
When you measure people instead of processes, you usually get one of these three consequences:
- People optimize the "numbers", not the result (they close the tasks, but the work is not done)
- The quality drops because speed is rewarded, and the finishing is not visible
- The team hides problems instead of bringing them up (because "it looks bad")
In projects, the biggest waste of time is usually not because someone is "not working", but because the work system is not clear: too many parallel tasks, unclear handovers, waiting for approvals, bad input (unclear request) and too many communication channels.
What does "Process KPI" mean (simple definition)
KPIs for internal projects are the fastest way to get clarity on where the work is realistically stuck — without pressuring the team and without micromanaging. If you lead a team or internal projects, you probably know the feeling: everyone is busy, and progress is not always visible.
The goal is not to "catch" people, but to discover:
- where do the delays occur?
- where the work is returned for finishing
- how many jobs are open at the same time
- how predictable is the delivery
6 KPI metrics that bring immediate clarity
1) Cycle time (time from the start to the end of the task)
What does it measure: how long it realistically takes to complete a task from the moment the team starts working on it.
How to measure (simple): date "In progress" → date "Done".
What does it tell you: whether the problem is capacity, interruptions or too much parallel work.
First move if it's bad: reduce WIP (see metric #3) and introduce clear criteria for what "In progress" means.
2) Lead time (time from request to delivery)
What does it measure: how long it takes from the moment the request is made to the moment it is delivered.
How to measure: task creation date → “Done” date.
What does it tell you: how predictable the system is for internal "clients" (other team, management, partners).
First move if it's bad: check where tasks are waiting (approvals, information, submissions).
3) WIP (Work in Progress) – number of parallel open tasks
What does it measure: how many tasks are active at the same time.
Why it is critical: too much parallel work extends all deadlines.
How to measure: number of tasks in "In progress" status per person or per team.
First move if it's bad: introduce a WIP limit (for example, a maximum of 2 active tasks per person) and the rule: "we don't start a new one until we finish what we started".
4) Handover delay (handover delays between people/teams)
What does it measure: koliko vremena posao stoji između dva koraka (na primer, “spremno za review” → “review urađen”).
How to measure: track the time in the statuses "Waiting", "Review", "Approval".
What does it tell you: where are the bottlenecks (often reviews/approvals).
First move if it's bad: agree on an SLA for the review (for example, 24–48h) and clearly define who owns the approval.
5) Rework rate
What does it measure: how often the task is returned for revision.
How to measure: the number of tasks that went past "Done" and returned, or the number of comments/iterations before "Done".
What does it tell you: whether the problem is in the quality of input (unclear requirement), standard or expectations.
First move if it's bad: introduce "Definition of Ready" (what must exist for the task to start at all).
6) On-time delivery (predictability of delivery)
What does it measure: percentage of tasks/projects delivered within the agreed time frame.
Important: the goal is not 100% — the goal is realistic planning and a stable system.
First move if it's bad: shorten planning (smaller batch), introduce a weekly review of priorities and reduce the number of "urgent" interventions.
The most common mistakes (and how to avoid them)
- Too many metrics at once: start with 2–3 (Cycle time, WIP, Handover delay)
- Measurement without action: A KPI is only useful if it leads to a decision (what do we change next week)
- KPI without owner: determine who monitors and who suggests corrections
- Measuring in the wrong tool: chat and email are not a system; KPI seeks "one source of truth"
Mini case study: "Everything is urgent, but nothing arrives"
One team had the feeling that they were "working all the time", but the deadlines kept slipping. When we looked at the workflow, it turned out that the biggest problem was WIP: too many parallel tasks and constant interruptions.
What we did:
- we have introduced a WIP limit
- defined what "In progress" means
- agreed on a rhythm of reviewing priorities once a week
Result after 3–4 weeks:
- shorter cycle time
- less switching between tasks
- clearer focus and less "firefighting"
How to introduce KPIs in 7 days (mini plan)
- Select 1 process (eg internal projects and tasks) and 1 tool as a source of truth
- Start with 3 metrics: Cycle time, WIP, Handover delay
- Status definition agreements (what does "To do", "In progress", "Review", "Done" mean)
- Introduce a weekly review (30 minutes): what slowed us down and what we're changing next week
- Only then add other metrics. (rework, on-time delivery)
Related blogs
Frequently asked questions about process KPIs (FAQ)
How many KPIs are enough?
2-3 KPIs are enough to start with. If you introduce too much, the team will lose focus and measurement will become a burden.
