Bottlenecks and the theory of constraints

Goldratt defines a constraint as anything that limits a system from achieving higher performance against its goal. In a chain of dependent steps the slowest step sets the pace of the whole: speeding up a step upstream of it only piles work in front of it, and speeding up a step downstream only makes that step wait more. His five focusing steps follow from that. Identify the constraint. Decide how to exploit it, meaning get the most out of it without major spending. Subordinate everything else to that decision. Elevate the constraint by adding capacity. Then, when it breaks, go back to step one, and do not let inertia from the old constraint become the new one.

It holds because the parts are dependent and variable. In The Goal the hike moves at the pace of the slowest scout, Herbie, no matter how fast the others walk, and the gap in front of him is the inventory of the system. Work waiting in front of a bottleneck is the clearest sign of where it is, and the wait is the queue length divided by the constraint's rate, which Little's law makes exact. In practice this means walking the pipeline and finding where the queue is longest, then asking how much of that stage's time goes to things that are not its job.

The constraint moves once you lift it, so the steps are a loop, not a project, and Goldratt's warning about inertia is the part most often skipped: the rules an organisation built around the old constraint outlive it and become the new one. Constraints are often policies rather than machines: an approval, a batch size, a rule about who may deploy. And exploit comes before elevate for a reason. Teams reach for more capacity when the bottleneck is idle a third of the time because of scheduling, and the cheaper fix is to stop starving it. Finally, the model assumes a chain. In a web of parallel paths there can be several constraints at once, and the method works one at a time.