How to Identify Process Bottlenecks: Measuring Lead Time and Tracking KPIs

A purchase request has been submitted and passed its initial review, but the order still has not been placed. Procurement is waiting for finance. Finance says the documents are incomplete. The person who submitted the request simply wants to know when it will be finished.

A few calls eventually get the request moving. The following week, another request gets stuck in exactly the same place.

This pattern is familiar in many organizations. Work gets done, but only through personal follow-ups, repeated reminders, and management intervention. The deeper problem is that nobody can clearly explain where the delay began or what needs to change to prevent it from happening again.

Identifying process bottlenecks means turning “everything takes too long” into questions that can be answered with evidence. Which stage creates a queue? How much time is spent doing the work, and how much is spent waiting? Is the problem limited capacity, incomplete information, or the way the process itself has been designed?

What Is a Process Bottleneck?

A process bottleneck is a stage or constraint that limits the rate at which work can move through the overall process. It might be a person, a management approval, a software system, or an organizational rule. When incoming work exceeds a stage’s capacity to handle it, a queue builds up and waiting time increases.

However, not every delay is a bottleneck. An absent colleague or a brief system outage may hold up one case without being the process’s main constraint. Even the longest task is not necessarily the bottleneck: several people may perform it in parallel, providing enough capacity to meet demand.

To identify a bottleneck, examine incoming demand, processing capacity, queue size, waiting time, and the stage’s effect on the final outcome. A delayed case is a useful starting point, but it is not enough to diagnose the entire process.

Should the Duration of Every Task Be Measured?

If you want to make informed decisions about process performance, you need a reliable way to measure the time spent in its activities. Without that information, it is difficult to distinguish work that genuinely takes a long time from work that spends most of its life waiting.

This does not mean introducing a separate timer for every minor action on day one. The level of measurement should reflect the importance of the activity, the risk of delay, and the effort required to collect the data. Repeated activities, handoffs between departments, and stages that directly affect completion time are sensible places to start.

Processing Time, Waiting Time, and Lead Time

Before measuring anything, agree on what each time metric means:

• Active processing time: The time actually spent working on a request, such as 20 minutes reviewing its documents.
• Waiting time: The time a request spends in a queue or waiting for information, approval, or another dependency.
• Lead time: The total elapsed time between a defined starting point and a defined endpoint, including waiting within that interval.
• Completion deadline: The point by which a task is expected or required to be completed, such as within eight working hours of receiving a complete request.

A document review may require only 20 minutes of active work, while two days pass between the request entering the review stage and leaving it. From the requester’s perspective, those two days matter: the result is still unavailable throughout that period.

Should Every Task Have a Maximum Allowed Duration?

For important activities, a clear and trackable completion target is useful. But the target should not be confused with lead time itself. A more accurate statement is: “The lead time target for this activity is no more than eight working hours.”

If the time commitment is agreed between a service provider and a service recipient, it may form part of a service-level agreement, or SLA. Internal departments can also establish operational agreements to coordinate their responsibilities. Simply adding a number beside a task does not create a service-level agreement.

The target should not be based on guesswork. First, measure current performance over a period that reflects the usual volume and variety of requests. Then set a target based on service needs, task complexity, team capacity, and realistic improvement opportunities. A routine purchase and an emergency purchase do not necessarily need the same deadline.

Define the Rules Behind the Clock

“Four hours” is ambiguous unless the working calendar is defined. If a complete request arrives at 3 p.m. and the working day ends at 4 p.m., four working hours and four calendar hours produce different deadlines.

Specify when measurement starts, which holidays apply, when the clock may pause, and how incomplete submissions are handled. If an agreed service clock pauses while documents are being completed, record the reason and duration. That waiting period remains part of the requester’s experience and should remain visible in the overall case timeline.

How to Identify Process Bottlenecks Using Workflow Data

A process diagram shows how work is supposed to move. Execution data shows what actually happened. To compare the two, each case needs a unique identifier and a record of its key events:

• When it entered and completed each stage.
• Who was responsible and when responsibility changed.
• Its deadline and current status.
• The reasons for pauses and their duration.
• Any returns for correction and their causes.
• The request type, complexity, and priority.

If active processing time is also measured, its recording method must be credible. A form left open on a screen does not prove that someone is working on it. A system that records only stage entry and completion measures elapsed time in that stage. That number should not automatically be presented as active working time.

Example: How Much Work Does a Purchase Request Actually Require?

The following hypothetical example separates active work from waiting. The stages run sequentially, there is no rework, and all durations use the same working calendar.

Active processing and waiting time in a hypothetical purchase request Stage Active processing time Waiting time Elapsed time Initial review 20 minutes 4 hours 4 hours 20 minutes Manager approval 10 minutes 12 hours 12 hours 10 minutes Finance review 30 minutes 16 hours 16 hours 30 minutes Order placement 40 minutes 2 hours 2 hours 40 minutes Total 1 hour 40 minutes 34 hours 35 hours 40 minutes

Most of the time in this example is spent waiting. Reducing the initial review from 20 minutes to 10 minutes would make only a small difference to the overall result.

The more useful question is why the request waited 16 hours for finance. Was the team overloaded? Were documents missing? Were reviews handled in batches? Was responsibility unclear? Each explanation points to a different intervention.

Finance review deserves further investigation in this case, but identifying it as the process bottleneck requires evidence from other requests, queue trends, and available capacity.

For processes with parallel activities, do not add every activity’s duration together and call the result lead time. Overall lead time is the interval between the case’s defined start and finish. Adding overlapping activity durations can produce a figure larger than the time the case actually took.

Systems Thinking: Why Following Up on One Case Does Not Fix the Process

Calling the person responsible for a delayed task may resolve the immediate problem. But if the same call is needed every week, the situation is no longer an exception. The way work flows needs to be reviewed.

Systems thinking means evaluating each department’s performance in relation to the outcome of the whole process. Procurement might be rewarded for forwarding requests quickly while sending more incomplete files to finance. Its local metric improves, but rework and total completion time increase.

A useful review asks whether information is complete at the point of submission, decision rights are clear, approvals are necessary, and deputies are available. It also checks whether routine decisions depend on someone whose schedule makes timely approval unlikely.

Removing the Symptom Can Hide the Problem

Hiding a problem does not always look deliberate. Closing overdue requests to improve a report, opening new cases instead of continuing existing ones, or moving work outside the system can make the numbers look better without improving the underlying process.

Process redesign should not mean removing controls without examining their purpose, either. An approval may be necessary, but its requirements could vary according to the value or risk of a request. A delay might be resolved by assigning a deputy, improving the submission form, or allowing independent checks to run in parallel.

Review several delayed cases from beginning to end with the people involved. Move beyond “Who was late?” and examine the conditions that make the delay repeat. This does not remove individual accountability. It helps distinguish personal mistakes from design weaknesses and capacity constraints.

The Role of BPMN and BPMS in Reducing Process Delays

BPMN is a modeling notation used to clarify activities, responsibilities, decisions, and exception paths. A BPMS is a system used to execute processes and record their events. A BPMN diagram alone does not generate performance data: event recording and measurement rules must also be built into execution.

For further discussion of implementation, see my article on designing and implementing organizational processes with BPMS, in Persian.

The implementation should define what happens when a deadline approaches, is missed, or has no available task owner. Who receives the reminder? When is the issue escalated? Who has the authority to remove the obstacle? Alerts without clear ownership eventually become messages people ignore.

BPMN timer events can model these behaviors, but their configuration matters. A reminder may need to run without interrupting the activity. Not every timer should cancel ongoing work when a deadline is reached. The intended behavior must match the event type and the capabilities of the BPMS engine.

How to Derive Meaningful KPIs from a Business Process

Start with the purpose of the process. If procurement exists to meet organizational needs accurately and on time, the number of submitted forms is not enough to assess success. Fulfillment time, on-time completion, order accuracy, and rework provide a more useful picture.

The relationship between process design, risk, and evaluation is also discussed in my article on BPMS, risk control, and performance evaluation, in Persian.

Examples of process performance indicators Indicator Calculation Purpose Median lead time The middle completion-time value for a defined group of completed cases. Understand typical completion time. 90th-percentile lead time The duration within which 90% of the defined group of completed cases finished. Reveal longer delays that an average may obscure. On-time completion rate Cases completed by their deadline ÷ all cases with deadlines falling in the reporting period × 100. Assess adherence to time commitments. Correction return rate Completed cases returned for correction at least once ÷ all completed cases in the same group × 100. Identify weaknesses in inputs or review requirements. Overdue work in progress The number of open cases past their deadline at the reporting snapshot. Make the current backlog visible and actionable.

For the on-time completion rate, open cases whose deadlines have passed must remain in the denominator. Excluding unfinished work can create an overly positive picture. Canceled cases and permitted pauses also need explicit reporting rules.

Every KPI Needs a Clear Definition

A metric name is not enough. Define its formula, data source, reporting period, case population, target, and owner. Two people should not produce different figures from the same indicator because they interpreted it differently.

Segment results by request type and complexity. Someone handling difficult cases may reasonably take longer than someone handling routine requests. Comparing their completion times without accounting for that difference is a weak basis for evaluating performance.

Process metrics should not automatically become individual scores, either. Waiting for a budget allocation or a manager’s approval may be outside an employee’s control. Measure quality and repeat work alongside speed so that people are not encouraged to close cases before the work is actually complete.

Performance Monitoring Should Lead to Process Improvement

A daily dashboard should show which tasks are approaching their deadlines, which cases are overdue, and where queues are growing. Periodic reviews should turn those observations into decisions: what is causing the repeated delay, what needs to change, and who will implement the change by when?

If most returns are caused by incomplete information, extending the review deadline is unlikely to solve the problem. Improving the form, validating submissions, or clarifying required documents may be more effective. If inputs are complete but the queue keeps growing, investigate capacity, work allocation, and prioritization rules.

After a change, measure the same indicators across comparable groups of cases. If completion time falls but errors increase, the improvement is incomplete. If the queue simply moves from finance to procurement, the overall constraint has not been resolved.

Start with one recurring process. Document how it actually works, separate processing time from waiting time, set clear deadlines for important stages, and address the main cause of delay. Then evaluate the result using the same measures.

The value of process management becomes visible when “we are following up” is replaced with specific information: where the work is, why it is waiting, when it should be completed, and what has changed to prevent the delay from recurring.

Frequently Asked Questions

Is lead time the same as the maximum allowed task duration?

No. Lead time is the elapsed duration between defined start and end points. The maximum allowed duration is a target or commitment against which actual performance is assessed.

Does setting a deadline automatically reduce delays?

No. A deadline needs to be supported by sufficient capacity, complete inputs, clear ownership, and a response to missed commitments. Otherwise, it may simply generate more alerts.

Do you need a BPMS to start measuring process performance?

No. A structured spreadsheet can support a limited initial effort. As request volumes, roles, and exception paths grow, a BPMS can make rule enforcement and event recording more consistent.

Does making every task faster always improve the process?

Not necessarily. Improvement must be evaluated across the whole process. Saving time in one stage is valuable when it improves the final outcome without undermining quality, necessary controls, or performance elsewhere.