Why does bottleneck constraint shift theory of constraints inertia fail?

The most common reason bottleneck constraint shift theory of constraints inertia fails: Inertia — continuing to optimize a constraint that is no longer binding. You built systems, habits, routines, and mental models around the old bottleneck. You invested effort. You are proud of the improvement. And now you keep tuning, refining, and protecting those systems even though the constraint has moved elsewhere. The policies you created to subordinate non-constraint work to the old bottleneck are still in place, now actively harming throughput by forcing the system to serve a stage that no longer needs special treatment. Goldratt called this the most dangerous failure of all: letting inertia become the system constraint. The thing that saved you becomes the thing that traps you.

The fix: Return to the bottleneck you have been working on throughout this phase. Assume, hypothetically, that you have fully resolved it — that the constraint is gone, throughput at that stage is unlimited. Now ask: where does the queue build up next? What stage of your personal system would become the new slowest point? Write a one-paragraph description of this predicted next bottleneck. Then look at your current system honestly: is there any evidence the constraint has already begun to shift? Are you seeing improvement at the old bottleneck but stagnation in overall output? If so, you may already be optimizing a former constraint while the new one goes unaddressed. Name the new constraint explicitly and prepare to run the full measurement protocol from L-0945 on it.

The underlying principle is straightforward: The constraint shifts — return to step one and find the new bottleneck.