Theory of Constraints

How to run it

1. Describe the system: what it exists to get through, the stages the work passes through in order, and the number that goes up when more gets through.
2. Name the places the flow might narrow. For each, look for the evidence: what piles up in front of it, and who or what sits idle after it. Commit to one. A wrong constraint worked properly teaches you more than a right one never committed to.
3. Exploit it. List the moves that recover capacity the constraint already has, without spending anything: stop it doing work that isn’t its job, stop feeding it broken input, stop letting it sit idle at handovers.
4. Subordinate everything else. Decide what changes away from the constraint so that it never waits and never drowns, and say whose numbers get worse on purpose. If nobody’s do, nothing has been subordinated. Tell them yourself.
5. Only if squeezing wasn’t enough, elevate: spend on more capacity at the constraint specifically. An empty elevate step is a result, not a gap.
6. Ask where the constraint stands now. If it has moved, name the step it moved to, note which rules from this round must not become policy, and start again from the top on the new one.

Where it falls down. People find a constraint and then try to fix three things at once, or name three constraints and spread the effort across all of them, which is the same failure.