Processing time, waiting time and lead time explained

Lead time is the time from the trigger of a case to its result. It consists of processing time, when someone actually works on the case, and waiting time, when the case lies untouched. You calculate it by adding both along the path the cases take – counting each step as often as cases pass through it on average, and counting only the longest branch where work runs in parallel.

Three times, three questions

Each of the three times answers a different question:

A note on terms

Sources do not use these words consistently. Some call the time from trigger to result cycle time, others throughput time; some use cycle time for the time one step takes. The app uses one set of terms: processing time is the work, waiting time is the lying, and lead time is the whole span from trigger to result. When you compare figures with other sources, check which definition they use.

All times are minutes of working time. A working day is the number of working hours per day set for the process – 8 hours in the examples – so 2,400 minutes are 5 working days. Nights and weekends are not counted.

Worked example: the invoice check

In the worked example, accounts payable enters an invoice, checks it, and posts it; one in five invoices is incomplete and goes back to the supplier, three in ten need an approval. Because of the loop, “Check invoice” runs 1.25 times per case on average, the supplier query 0.25 times and the approval 0.3 times. Each step’s times are multiplied by those visits:

What the result says

The lead time is 17.5 + 1,212 = 1,229.5 minutes, about 20.5 hours or 2.6 working days. The processing share is 1.4%: for every minute of work the invoice waits about 70 minutes. That is typical of office processes and the reason why faster typing rarely shortens a lead time – removing waiting does. Because accounts payable in the example is at 101% utilization, the app marks this lead time “only without backlog”: the waiting times are estimates, and the queue that grows with the backlog comes on top, so the figure is a minimum.

Two shortcuts give wrong answers. Adding up every box in the diagram gives 20 minutes of processing and 4,020 minutes of waiting, 4,040 minutes or 8.4 working days, because it assumes every invoice goes to the supplier and to the approval. Following only the main path gives 195 minutes and ignores the 20% that wait a week for the supplier. Why the correct figure lies in between is explained in branches and loops.

Ranges: best, typical, worst case

Times in an office are estimates, so the app takes each time as a range: best, typical and worst case. The calculation runs three times – once with all best values, once with all typical values and once with all worst values – with the same shares at decisions. The result is a range for the lead time.

In the invoice template, for example, “Enter invoice in ERP” is estimated at 4, 6 or 12 minutes of processing and 120, 480 or 960 minutes of waiting before it. One pass through that step alone takes between 124 and 972 minutes of processing plus waiting, typically 486, before its query rate and the repeat passes after a correction are added. If only a typical value is known, it is used for all three runs. The worked example above has single values only, so its range is a single number. What changes when the mean of a range counts instead of the typical value is shown in simulation and process mining.

Parallel work: the longest branch counts

When a case is split into parallel paths – for example engineering checks feasibility while purchasing requests prices – the case is finished only when both are done. For the lead time, only the longer branch counts: the time-determining path. Both branches are worked on, though. With parallel work the app therefore distinguishes two figures that are equal without it: the processing time per case, summed over all branches, which drives cost and staffing; and the processing time on the time-determining path, which goes into the lead time and the processing share.

An example with assumed figures: branch A takes 2 hours (30 minutes of work, 90 minutes of waiting), branch B 5 hours (60 minutes of work, 240 minutes of waiting). The lead time counts branch B with 300 minutes. The processing time per case over both branches is 30 + 60 = 90 minutes, the processing time on the time-determining path 60 minutes. This is why, with parallel work, the lead time is shorter than processing time per case plus waiting time: 300 minutes instead of 90 + 240 = 330. The processing share is 60 ÷ 300 = 20%. The app identifies the matching join for each parallel split and replaces the region by the duration of its longest branch. Where that cannot be determined unambiguously, it adds up and shows a note.

Reducing lead time

Because waiting dominates, the effective levers usually address waiting rather than work:

• Avoid loops: in the worked example, making the order number mandatory halves the incomplete invoices and cuts the lead time from 1,229.5 to 895.6 minutes. See future process and measures.
• Remove handoffs and approvals that add a day of waiting for a few minutes of work.
• Work in parallel where steps do not depend on each other.
• Check utilization: a role above 100% builds a backlog, and cases wait longer. See bottleneck analysis.

Frequently asked questions

Keep learning