Theory of Constraints: Five Focusing Steps in Practice
Key takeaways
- The theory of constraints says total throughput only improves by managing the single limiting resource, using the five focusing steps: identify, exploit, subordinate, elevate, repeat.
- In a five-step client-onboarding workflow, an analyst needing 50 hours against 40 available caps throughput at 8 onboardings per week, making the analyst the constraint.
- Exploit the constraint before spending money: offloading template work and trimming one 30-minute field lifted capacity to roughly 10 onboardings per week at zero cost.
- Subordination means capping released work at what the constraint can absorb, even if upstream stages sit idle, because extra releases only build WIP and lengthen lead time.
- Skip the five focusing steps when demand is unstable, constraints shift constantly, capacity is purely variable cost, or a political blocker can veto change.
The theory of constraints gives you a defensible first-pass capacity model: identify the bottleneck resource, exploit it, subordinate everything else to it, elevate it, and repeat once throughput moves. This walkthrough applies all five steps to a single client-onboarding workflow with named resources, hours, and throughput figures, so you can quote a scoping engagement on evidence rather than a guess.
What is the theory of constraints in project management?
The theory of constraints (TOC) holds that every system has one limiting factor, and total throughput can only improve by managing that factor. Eliyahu Goldratt introduced it in The Goal and formalised it as a repeatable method: identify the constraint, exploit it, subordinate everything else to it, elevate it, and repeat (Theory of Constraints overview).
Applied to project workflows, the constraint is rarely a machine. It is more often a single approver, a scarce specialist, or a review stage where work queues because arrivals outpace cycle time. That queue shows up as WIP and lead time long before anyone measures utilisation directly.
A first-pass capacity model makes the constraint visible: map the workflow, estimate capacity per stage, and compare demand against each. Our workflow bottleneck calculator does exactly this scoping pass before you commit to a deeper engagement.
What are the five focusing steps of the theory of constraints?
Step 1: Identify
Find the step with the least capacity relative to demand. Decision rule: if you cannot point to where WIP piles up and lead time stretches, keep looking. A first-pass model of cycle times against demand makes this defensible rather than a guess (bottleneck software).
Step 2: Exploit
Get full throughput from the constraint before spending money. Decision rule: is the constraint ever idle on billable work, starved by upstream errors, or loaded with tasks that could run elsewhere? Fix that first.
Step 3: Subordinate
Set the pace of every other step to the constraint. Decision rule: if non-constraint steps are running at 100% utilization while the constraint starves, the schedule is wrong.
Step 4: Elevate
Only now add capacity: another reviewer, a second machine, an extra contractor. Decision rule: total cost of the addition against throughput gained.
Step 5: Repeat
Elevation moves the constraint. Re-run the capacity check, find the new bottleneck, start again.
How do you identify the constraint in a project workflow?
Map the flow first: every step, who or what performs it, and where work waits between steps. The constraint is usually visible before you calculate anything, because work piles up in front of it and starves the steps after it.
Signals that point to the constraint
Three signals do most of the work. First, WIP and queues: the longest backlog sits upstream of the constraint. Second, utilisation: the resource that is never idle while others wait is a strong candidate. Third, cycle time variance: steps feeding the constraint get expedited, steps after it starve. Goldratt built the whole method on this idea of the binding constraint in The Goal (Goldratt and Cox, 1984, North River Press, per Wikipedia's summary of the book).
A quick capacity comparison method
Estimate demand per resource in hours per week, then divide by available capacity. The resource closest to 100% is your constraint; the gap for everyone else is slack you can exploit. Improve First's Constraint Impact Calculator runs this comparison and shows where the constraint moves next, under its terms of use. A spreadsheet does the same, just without the "where next" projection.
What is a theory of constraints bottleneck example?
The workflow and the numbers
Take a client-onboarding workflow with five steps, each owned by one resource. The client signs on Monday, and the work must clear all five steps before kickoff. Demand is 10 onboardings per week, and each resource works 40 hours.
| Step | Resource | Hours per onboarding | Weekly capacity used | Utilisation |
|---|---|---|---|---|
| Contract review | Legal | 2 | 20 | 50% |
| Account setup | Ops coordinator | 3 | 30 | 75% |
| Data migration | Analyst | 5 | 50 | 125% |
| Security check | Compliance | 4 | 40 | 100% |
| Kickoff call | Account manager | 1 | 10 | 25% |
Finding the constraint
Data migration needs 50 hours against 40 available, so the analyst is the constraint: throughput for the whole workflow caps at 8 onboardings per week, not 10. Compliance sits at exactly 100% utilisation, which means any sick day or rework pushes backlog into next week. Every other step has slack, so improving them changes nothing about system throughput.
Exploiting it before spending money
Exploit means squeezing more from the analyst without buying anything: move template work to the coordinator (25% utilised), batch migrations, or drop one low-value field that costs 30 minutes per job. Those moves lift capacity to roughly 10 per week at zero cost. Only then decide whether to hire or subcontract. You can run this arithmetic, and the "where does the constraint move next" question, in the Constraint Impact Calculator before you quote the engagement.
How do the five focusing steps play out step by step in that example?
Subordinating the rest of the workflow
Subordination means everything upstream accepts the constraint's pace. If the review stage has 8 hours of daily capacity and work arrives needing 9.5, you stop releasing more than 8 hours of work per day into the pipeline, even though the earlier stages sit idle. That feels wasteful, but releasing 9.5 hours only builds WIP and lengthens lead time without adding throughput. Set a release cadence that matches the constraint, and cap WIP at each upstream station.
Elevating: when to add capacity
Elevate only after exploitation and subordination fail to close the demand gap. The decision criterion is arithmetic: if the gap exceeds what offloading, batching, or trimming handoffs can recover, add capacity at the constraint. Options in the example are a second reviewer, dropping low-value review checkpoints, or extending review hours. Each option changes throughput differently, so model the shift before quoting the fix, and be clear about the limits of any first-pass model (disclaimer).
Where the constraint moves next
Once review capacity rises above demand, re-run the utilisation numbers. The constraint rarely disappears; it moves. In the worked example, expect it to land at the upstream drafting stage, which previously ran below capacity. That is the repeat step: find the new constraint and start the cycle again.
How does TOC differ from lean and critical path?
Pick the lens that matches the engagement. TOC assumes one constraint governs system throughput, so you find it, exploit it, and subordinate everything else to it. Lean assumes waste is distributed throughout the process, so you map value streams and remove muda everywhere. Critical path assumes the schedule itself is the problem: it identifies the longest dependent task chain and manages floats, which is a planning lens rather than a capacity one.
The Critical Path Method and Critical Chain overview from PMI explains how Goldratt's critical chain extended CPM by adding resource constraints and buffers, which is where the two schools overlap. Each lens answers a different question, and misapplying one produces confident nonsense: a critical path analysis will not fix a capacity problem, and a TOC intervention will not fix a schedule that was never resource-levelled. Consultants who can name which lens they are using, and why, tend to scope faster because the client hears a method rather than a preference.
In practice: use CPM when the deadline drives the work, lean when waste is diffuse, and TOC when one station, approval step, or resource is visibly capping throughput.
When should you not apply the five focusing steps?
Skip the five focusing steps when demand is unstable. If orders arrive in bursts rather than as a steady flow, your "constraint" is often just a queue that moves week to week, and elevating it buys nothing.
Skip it when constraints shift constantly across stations. A moving bottleneck means the system is under control in the Goldratt sense; fix scheduling and variability first, then re-check where WIP piles up.
Skip it when costs are purely variable. If you can buy more capacity by the hour with no fixed asset, there is no constraint to exploit, only a purchasing decision.
And skip it when a political blocker can veto any change. No throughput gain survives a manager whose headcount depends on the current process.
How did Goldratt's book The Goal shape TOC?
Eliyahu Goldratt published The Goal in 1984, teaching throughput, inventory, and operating expense through a plant manager's story rather than equations. The novel format still works with clients: a consultant can hand over a narrative that makes the bottleneck concept intuitive before any numbers appear. That matters because practitioners on forums often struggle to even frame a capacity question clearly, let alone pick a tool (CR4 discussion on capacity modelling).
How do you turn a first-pass TOC analysis into a client-ready scoping report?
Run the five focusing steps on the client's workflow, capture the constraint's throughput numbers and the improvement's projected effect, then write up what you tested, what moved, and where the constraint is likely to land next. That document becomes your scoping report: it shows the client you found a real bottleneck with numbers, not opinions, and it justifies the quote for the deeper engagement.
Tool options for a first-pass model
A spreadsheet capacity model works and costs nothing, but it breaks when the client asks "what if demand doubles?" DO.Impact, ProcessModel, and FlowVisual all model constraint behaviour directly. KaiNexus sits adjacent: it manages improvement work rather than modelling capacity.
Running the same criteria on Improve First
Improve First handles the calculator workflow well: constraint identification, improvement testing, and a client-ready report. Where it falls short: no simulation of multi-constraint systems, no scheduling against takt time, and no WIP analytics. If your engagement needs full discrete-event modelling, ProcessModel covers that; Improve First covers the scoping pass that wins the work.
FAQ
Is the theory of constraints only for manufacturing?
No. Goldratt developed it in a factory setting, but the constraint in a service workflow is usually a person or stage: an approver, a specialist, or a review step where demand exceeds cycle time. The five focusing steps apply identically. The client-onboarding example in this article caps throughput at an analyst, not a machine.
What is the difference between a bottleneck and a constraint in TOC?
A bottleneck is any resource with higher demand than capacity; a constraint is the one that limits total system throughput. In the worked example, the analyst at 125% utilisation is the constraint because it caps the workflow at 8 onboardings per week. Other near-capacity steps are bottlenecks in casual usage, but improving them moves nothing.
Can I apply the five focusing steps without special software?
Yes. A spreadsheet capacity model handles the whole first pass: estimate weekly demand per resource in hours, divide by available capacity, and the resource closest to 100% is your constraint. That arithmetic produced every number in the worked example. Software adds value later, mainly for demand-doubling projections and modelling where the constraint moves next.
How long does a first-pass TOC analysis take on a small workflow?
For a five-step workflow with named resources, plan on a few hours: map the flow, collect hours-per-job estimates, and run the utilisation comparison. The larger cost is usually getting honest cycle-time numbers rather than doing the arithmetic. Treat the result as a first-pass model with stated assumptions, not a validated simulation, before quoting a scoping engagement.
What does 'subordinate everything else' actually mean in practice?
It means every non-constraint step runs at the constraint's pace, not its own maximum. Concretely: cap work released into the pipeline at what the constraint can absorb, even if upstream stages sit idle, and cap WIP at each station. Releasing more only builds queues and lengthens lead time. Idle time upstream is expected and acceptable under subordination.