When improvement stalls despite effort, the bottleneck…
When throughput improvement stalls despite continued effort at the current constraint location, immediately re-run constraint identification to detect whether the bottleneck has migrated.
Why This Is a Rule
Goldratt's fifth focusing step: "If in a previous step a constraint has been broken, go back to step 1. Do not allow inertia to cause a system's constraint." When you successfully improve a constraint, throughput increases — until it doesn't, because a different step has become the new bottleneck. Continued effort at the old constraint location now produces zero improvement because the system is limited elsewhere.
This is constraint migration, and it's the most common reason improvement efforts stall. You optimized code review throughput, so now the bottleneck is testing. You keep optimizing code review (because that's where your attention and processes are focused), and throughput doesn't budge — because the constraint moved and your effort didn't follow it.
The trigger is specific: stalled improvement despite continued effort. If you're working hard on the constraint and throughput isn't improving, the most likely explanation isn't "try harder" — it's "the constraint is somewhere else now."
When This Fires
- You've been improving a process step for 2+ weeks with no throughput improvement
- Effort at the identified bottleneck feels productive locally but doesn't improve overall output
- After a successful improvement initiative, a new plateau emerges
- Weekly constraint review shows the same constraint for 3+ weeks without improvement
Common Failure Mode
Doubling down on the original constraint because "we've invested so much in improving it." This is sunk-cost thinking applied to process improvement. The old constraint may now be over-optimized while the new constraint receives zero attention. Every week spent on the wrong constraint is a week of lost throughput improvement.
The Protocol
When improvement stalls despite effort: (1) Stop optimizing the current constraint. (2) Re-run constraint identification from scratch: where are queues building? What step has the lowest throughput? What are people waiting for? (3) If the constraint has migrated, redirect all improvement effort to the new location. (4) Establish a weekly constraint review ritual: every week, ask four questions — what's the current bottleneck? Did it shift since last week? What action was taken? How did throughput change? This prevents the inertia that keeps you working on yesterday's constraint.