We fixed the bottleneck and the output barely moved

A team spends three months and a capital budget on the step everybody agreed was the bottleneck. It now runs forty percent faster. Output went up by four percent, and the mood in the room afterwards is worse than before the project started.

Nothing went wrong. This is what fixing a constraint looks like, and it is only disappointing if you expected the improvement at the step to be the improvement at the line.

The output was never that step’s to give

Throughput is set by the slowest step. Relieve it and the line speeds up until it hits the next slowest, and stops there.

---

	Cutting, per hour	30
	Forming, per hour	26
	Assembly, was 20, now	28
	Finishing, per hour	25
	Throughput, was 20, now	25

Illustrative figures. Assembly improved by forty percent and the line improved by twenty five, because at twenty eight it is no longer the slowest step. Finishing is, at twenty five, and that was true before the project started.

Twenty five, not twenty eight. The remaining three units an hour of assembly’s new capacity are worth nothing at all, because finishing cannot take them. That capacity was bought and it will never be used until something else changes.

Anyone who had the capacity table before the project started could have predicted the answer exactly, including the fact that the last chunk of the improvement would be wasted. Most projects do not have that table, which is why the result comes as a surprise rather than as a plan.

The three surprises, in order

The improvement is capped by the next number. Always. If assembly at twenty had been improved to twenty two rather than twenty eight, the line would have gone to twenty two and every unit of the improvement would have counted. Improving past the next constraint is spending money on capacity that cannot be used.

The queue moves, and it moves to somewhere new. The pile that used to sit in front of assembly now sits in front of finishing. The people at finishing, who were not part of the project and were doing fine, are now the ones under pressure. This is the point at which the improvement gets blamed for making things worse, so warn them before rather than explaining after.

And the next constraint may not behave like the last one. Assembly was a capacity problem and had a capacity fix. Finishing might be constrained by a shift pattern, a shared resource, an approval, or a supplier. The technique that worked last time may have nothing to do with the next one.

Predicting it costs an afternoon

The capacity table is the whole of the answer, and it is not a modeling exercise. Every step, capacity per hour, on the same clock, with availability measured rather than assumed. The smallest number is today’s constraint and the second smallest is tomorrow’s, and the difference between them is what your project is worth.

Two things make the table wrong in practice, both in the same direction. Availability gets stated rather than measured, so every capacity is optimistic. And shared resources get counted at full capacity when this process only gets a fraction of them. Both inflate the numbers, and both hide how close the second smallest is to the first.

That is the number to look at hardest. If the constraint is at twenty and the next step is at twenty one, the entire available gain is five percent and no amount of work at the constraint will beat it. Know that before the capital request, not after.

What to do with it

Write the target on the business case as the next constraint, not as the step’s new capacity. Assembly going from twenty to twenty eight is not the promise. Twenty five is the promise, because finishing is at twenty five, and a business case that promises twenty eight will be judged a failure for delivering exactly what was predictable.

Improve to just past the next constraint, then stop. The last few units of capacity at a step that is no longer the slowest are dead money. Buying them is the most common way an otherwise sound project overspends.

And plan the second project before finishing the first. The constraint moving is not a setback, it is the mechanism working. A team that expects it runs a program. A team that does not runs one project and concludes that the method does not work.

The only real mistake here is expecting a single fix to change the system permanently. It moves the limit one step along, and then you do it again.