I've lost count of how many times I've watched a company fix one bottleneck, celebrate, and treat the job as done — only to be caught out, months later, by a new one nobody saw coming.
Dr. Goldratt put the underlying logic simply: "Not every change is an improvement, but certainly every improvement is a change." Flip that around and the harder truth shows itself: if you're not changing, you're not improving — you're just standing still while everything around you moves.
Whatever your Management Philosophy of choice, you'll have a process for that: PDCA, Kaizen, DMAIC. In TOC, we have the Five Focusing Steps.
The five steps, quickly
- Identify the constraint — the one resource or policy limiting how much the whole system can produce.
- Exploit it — squeeze everything you can out of it without spending money.
- Subordinate everything else to that decision — stop optimising parts that don't matter and start protecting the one that does.
- Elevate the constraint — invest, if you still need to, once exploitation and subordination aren't enough.
- Repeat — go back to step one. Don't let inertia become the new constraint.
Most companies I've worked with are fine with steps one through four. They identify the bottleneck, they fix it, they feel the win. Then they stop. And that's a drawback, as the Five Focusing Steps don't end at step four.
Identify is a decision, not just a diagnosis
Step one gets treated as a purely technical exercise — walk the floor, look at the data, find the bottleneck. Sometimes that's exactly right. But there's a question hiding inside "identify" that's easy to miss the first time round: is this constraint yours to choose, or is it something you have to accept?
When you have more demand than capacity, you often do get real freedom here. Some resource is going to be the constraint — and which one it is can be a decision, not just a discovery. Put it somewhere cheap to protect and easy to keep exploiting, and you've built an advantage into the business. Let it sit wherever history happened to leave it, and you're managing a bottleneck nobody chose for its strategic value.
When capacity outstrips demand, there's nothing to choose. The constraint is the market, full stop — and the honest move is to accept that rather than pretend some internal fix will make it go away.
Goldratt's own caution is worth sitting with here too: in his day, a genuine market constraint was rare. What looked like one was usually a policy constraint wearing a market costume — a purchasing, production, or marketing rule nobody had revisited since the reason for it disappeared.
That's less true now. Several forces make real market constraints far more common today than when Goldratt wrote that warning — globalization not least among them, widening most companies' competitive set well past what a policy story can explain. So the practical move isn't to assume either answer by default: rule out the policy explanation first, since it's still worth checking, then accept the market one if it holds.
That distinction doesn't get settled once. It resets every time you loop back through step five. The second or third time round step one, you're not just hunting for a new bottleneck — you're asking again whether you have a choice this time, or whether circumstances have just handed you one.
Step five is the whole point
That loop back to step one is POOGI — Process Of OnGoing Improvement. It's not a bonus step. It's the mechanism that makes the other four worth doing at all.
Here's why it matters: fixing today's constraint doesn't freeze the system in place. It moves the constraint somewhere else — sometimes to another resource, sometimes to the market, sometimes to a policy nobody questioned because it was never the bottleneck before. If nobody goes looking for it, the company runs for months on an assumption that stopped being true the day the last fix landed.
In one past engagement with a retail business, the constraint turned out to be the team preparing shipments. Once identified, they changed the process — introducing a "full kit" checklist before handing an order off for shipment — and it did the trick: shipments increased by 35%. Then they stopped there.
Nine months later, noticing the bottom line hadn't moved the way it should have, I pushed for another round. It turned out the constraint had moved to the order-handling team — and the 35% gain had quietly eroded away after only a couple of months. Nobody had noticed. For roughly seven months, they'd been running the business as if that improvement were still in place, when it hadn't been for most of that time.
Why this gets skipped
Not because it's hard. Because step four feels like the finish line. There's a project close-out, a review meeting, a "we solved it" moment — and organisationally, that's where attention moves on to the next initiative. Nobody schedules "go find the new constraint" as a task, because it doesn't look like a task. It looks like starting over.
Goldratt had a name for exactly this trap. His own warning on step five reads: "Do Not Allow Inertia to Cause a System Constraint". Step four's finish-line feeling is inertia dressed up as closure — the win becomes the new status quo, and the status quo is the one constraint nobody ever schedules a fix for.
The companies that actually get value from TOC over years, not just in the quarter they applied it, are the ones that treat step five as a standing item — not a one-off project with an end date, but a habit of asking "what's limiting us now, and did we choose it or inherit it?" on a fixed rhythm.
The same loop, two environments
Everything above reads naturally as a manufacturing story — a constraint sitting on a shop floor, moving from one machine to another, eventually landing on the market. But the loop works exactly the same way in a project environment, even though nothing about a project repeats the way a production line does.
In manufacturing, POOGI usually walks a short path: fix one resource, watch for the next, and sooner or later you've fixed enough that the market itself becomes the constraint — at which point, as above, there's nothing left to choose. You accept it and manage delivery instead.
In a project environment, the same walk takes longer and crosses a different kind of ground. It typically moves in three stages. First, the constraint is internal and behavioral — bad multitasking, task estimates padded and then eaten by Parkinson's Law, no relay-race handoffs between tasks. Fix that with CCPM basics and buffer discipline, and the constraint doesn't disappear — it moves to whatever resource every project in the portfolio queues behind: one skill set, one piece of equipment, one approval gate. Fix that too, with portfolio-level buffer management, and you arrive at the same place manufacturing does: capacity to run projects now exceeds the flow of projects worth running. The constraint has walked out of scheduling entirely and into the pipeline — which is just the project-world name for the market.
Same five steps, same loop back to step one, same eventual question of choice versus acceptance. The only difference is what "the floor" looks like while you're walking it — a physical line in one case, a portfolio of buffer reports in the other.
What POOGI looks like in practice
It doesn't need to be elaborate. A short, recurring check — monthly, quarterly, or tied to a review cycle you already run — asking one question: has the constraint moved? Sometimes the answer is no, and that's fine; you've confirmed the current fix is still holding. Sometimes it has, and you're back at step one with a head start, because the organisation is now used to thinking this way.
That's the real payoff of POOGI — not a single improvement, but an organisation that's stopped being surprised by where its limits are.
If you've fixed a bottleneck and aren't sure whether it's moved — that's usually a five-minute conversation worth having. Get in touch.]If you've fixed a bottleneck and aren't sure whether it's moved — that's usually a five-minute conversation worth having. Get in touch.
