Cycle time and lead time are not the same number

Two teams can report on the same process, quote different numbers, and both be telling the truth. It happens constantly, it wastes entire meetings, and it is almost always the same confusion: one of them is measuring how long the work takes and the other is measuring how long the customer waits.

Worse, the term that causes the trouble has two settled meanings of its own. In shop floor practice, cycle time usually means the interval between one unit coming off a station and the next: an output rate turned inside out. In service and knowledge work it usually means the time spent working on one item from start to finish. Both usages are decades old and neither is going away.

So this piece takes a position rather than adjudicating. Print the definition beside the number. Every report, every dashboard tile, every slide. A metric whose definition has to be recalled from memory is a metric that will be misread by somebody senior enough for it to matter.

The order

Take a purchase requisition. Five steps, and somebody has timed both the working time at each step and the waiting before it. The waits are measured in working hours, on an eight hour day, because a wait that spans a weekend is not a wait anyone can shorten by working harder.

---

	Working time, the five steps added up	55 min
	Waiting time, the four queues added up	82 h
	Lead time, working plus waiting	82 h 55 min
	Lead time on an eight hour working day	10.4 days

Illustrative figures rather than a measurement from a live system, but every one of them is obtainable: four timestamps per requisition, which most approval systems already record and nobody ever reads.

Fifty five minutes of work. Ten and a half days to arrive. The ratio between them has a name, process cycle efficiency, and here it is fifty five minutes against four thousand nine hundred and seventy five, which is 1.1 percent.

That number is the whole argument. For ninety nine percent of its life this requisition is sitting still.

Which is why the usual project fails

Now watch what happens to the two obvious improvement plans.

The first is the one that gets proposed: make the steps faster. Train the finance team, buy a better form, cut every working time in half. That saves twenty seven and a half minutes out of eighty two hours, which is a lead time reduction of 0.55 percent. Ten days becomes ten days. Nobody will be able to tell it happened, and the team that did the work will be told the project failed.

The second is the one nobody puts in a business case, because it does not look like work: get rid of the forty one hour wait before the vendor record is set up. That is 49 percent of the lead time, in one queue.

Ninety times out of a hundred, the forty one hours turns out to be an accumulation rule rather than a capacity problem. The vendor team runs new records on Tuesdays and Thursdays. Or the request needs two approvals and they are gathered in a batch. Or it sits until somebody checks the shared mailbox. None of those are anyone working slowly, and none of them are fixed by making anyone work faster.

Where the third number fits

There is still a legitimate use for cycle time in its shop floor sense, and it is a different question again: how often does an order come out of this process?

If the team issues forty orders in a forty hour week, one order completes every hour. That is the cycle time in the output sense, and it is genuinely useful, because it is what tells you whether the process can keep up with demand. It is also completely unrelated to the ten days any individual order takes, and to the fifty five minutes of work inside one.

Three numbers, all correct, all measuring different things:

• Working time, 55 minutes. What the process costs in effort.
• Cycle time, one an hour. What the process can supply.
• Lead time, 10.4 days. What the requester experiences.

The three are not independent. Little’s Law ties them together: at eight orders a working day and a lead time of 10.4 days, there are about eighty three requisitions somewhere inside this process at any moment. That figure is usually a surprise, and it is usually the first time anyone realizes how much unfinished work the process is carrying.

What to do on Monday

You do not need a project to find out where your own gap is. You need four timestamps per item, which the systems already hold, and a spreadsheet.

1. Pick one item type and one window. Not “purchasing”. One requisition type, one month.
2. Record when each step started and when it finished. The gap between one step finishing and the next starting is a queue, and queues are what you are hunting.
3. Add the working time. Add the waiting time. Divide. If the ratio is above about ten percent you have an unusual process. Most come in under five.
4. Sort the queues by size and look only at the largest one. In this example that is one queue carrying half the total, and every hour spent on the other three is an hour spent on the wrong thing.
5. Ask what rule creates it. Not who. A wait that size is nearly always the output of a policy, a schedule or a batch size, and policies can be changed on a Tuesday afternoon at no cost.

The reason to separate the two measures is not tidiness. It is that they point at different work. Working time is improved by making the steps better, which is slow, expensive and usually worth very little. Lead time is improved by removing the waiting, which is fast, free and worth almost everything. A team that only ever measures the first will spend years being diligent about the wrong half of its own process.