Theory of Constraints

Concentrate improvement effort where it can change the performance of the whole system, not where activity is merely visible or easy to automate.

In one minute

The Theory of Constraints (TOC) treats an organisation as a connected system working towards a defined goal. At any moment, a small number of factors limit how much of that goal the system can achieve.

The Five Focusing Steps are:

1. Identify the current system constraint.
2. Exploit it: use its existing capacity effectively.
3. Subordinate other work to the needs of the constraint.
4. Elevate it when low-cost changes are insufficient.
5. Repeat when the constraint moves; do not let old rules become the new constraint.

Best for: queues, missed delivery promises, overloaded specialist teams, slow decisions and automation portfolios.
Avoid when: the goal is undefined, performance is not measured end to end or an urgent safety issue requires immediate containment.

The problem it addresses

Organisations distribute effort across many local improvements. Each team becomes busier or faster, but total throughput, customer lead time or mission performance barely changes.

TOC asks a harder question: what single factor currently prevents the system from achieving more of its goal? Once that factor is identified, policies, priorities and investments can be aligned around it.

When to use it

Use TOC when:

• work accumulates before one role, decision or system;
• several teams report high utilisation while delivery remains poor;
• new automation increases output but not completed customer outcomes;
• scarce expert judgement determines overall capacity;
• priorities change constantly and urgent work displaces important work;
• a transformation programme has more candidate projects than capacity.

A constraint may be physical, informational, behavioural, policy-based or external. A market with insufficient demand can also constrain the goal.

When not to use it

Do not use TOC:

• to excuse known safety, legal or quality defects;
• by declaring the busiest person the constraint without flow evidence;
• to maximise utilisation at every step;
• when demand categories with different goals are mixed together;
• as a one-off bottleneck workshop with no review after conditions change;
• to remove human judgement solely because it appears slow.

Use Value Stream Mapping when the flow itself is not yet visible. Use FMEA before changing a constraint in a safety- or quality-sensitive process.

Inputs required

• an explicit system goal and unit of useful output;
• the boundary of the system being managed;
• demand, throughput, queue, lead-time and quality evidence;
• capacity and availability at candidate constraints;
• rules governing priority, batch size, release and escalation;
• examples of blocked and completed work;
• stakeholder knowledge about external or policy constraints.

Step-by-step process

1. Define the goal and useful throughput

State the outcome the system exists to create and how a completed unit contributes to it. Include quality and safety conditions: work that later requires correction or causes harm is not useful throughput.

2. Identify the current constraint

Look for persistent queues, starvation downstream, long recovery times, scarce decisions and the factor whose additional effective capacity would increase total goal achievement. Distinguish a constraint from a temporary incident.

Test the hypothesis: if this factor gained usable capacity, could the rest of the system convert it into more completed value?

3. Exploit existing capacity

Protect the constraint from avoidable loss before buying technology or adding people. Examples:

• send complete work to it;
• remove tasks that do not require its scarce capability;
• reduce changeovers and interruptions;
• route clear priorities to one visible queue;
• resolve obvious defects before they arrive;
• schedule maintenance or review around the constraint.

4. Subordinate the rest of the system

Align upstream release and downstream support with constraint capacity. More input is not helpful when it only creates work in progress. Non-constraints should protect flow, prepare high-quality inputs and absorb variation rather than optimise their own utilisation.

5. Elevate the constraint

If exploitation and subordination are insufficient, invest in additional capacity or change the operating model. Options include cross-training, policy change, demand shaping, redesign, suppliers, deterministic automation or carefully bounded AI support.

6. Verify system effects

Measure completed throughput, end-to-end lead time, quality, operating effort and queue age. A local speed increase that does not affect these measures has not elevated the system.

7. Repeat and challenge inertia

Once performance improves, the constraint may move. Return to identification and retire policies that were useful only for the previous constraint.

AI automation lens

AI is most useful when it protects or extends scarce capability without weakening quality. Examples include preparing evidence for an expert, routing complete cases, summarising standard material or detecting items that need early attention.

Before automating the constraint, ask:

• Is the limiting factor capacity, input quality, priority policy or demand?
• Can a deterministic rule handle the task more reliably?
• What decisions must remain with an accountable human?
• Will the automation create more review work than it removes?
• How are low-confidence, novel or high-impact cases routed?
• What downstream constraint may appear after improvement?

Do not measure success by model calls, drafts generated or minutes saved at one task. Measure additional correct outcomes through the full system.

Visual model

Text alternative: demand passes through a process whose output is limited by one constraint. A repeating identify–exploit–subordinate–elevate loop improves that constraint, while AI observes and assists without controlling release on its own.

Text alternative: five connected stages identify, exploit, subordinate, elevate and repeat around a highlighted system constraint. An AI-support path prepares complete work for the constraint, while an exception path preserves accountable human judgement. System throughput, lead time and quality are measured after each cycle.

Interactive example

Scenario

BrightBid prepares 80 complex sales proposals per month. AI drafting reduces initial writing from four hours to forty minutes, but signed proposals remain at 42 per month.

Evidence:

• solution consultants can review 60 proposals monthly;
• the security specialist can review 45;
• 30% of submissions reach security review without required architecture evidence;
• sales teams release work in an end-of-month batch;
• security review averages 50 minutes, but incomplete cases consume another 35 minutes;
• legal and pricing have spare capacity.

Your move

Identify the most plausible constraint and define exploit, subordinate and elevate actions.

Worked answer

Security review is the current constraint, but the first response should not be “buy an AI reviewer.”

Exploit: reserve the specialist for security judgement, create a complete-evidence gate and prevent interruptions by routing questions through scheduled review windows.

Subordinate: release proposals steadily, require architecture evidence upstream and limit work in progress before security review.

Elevate: after measuring the first changes, use a retrieval-bounded assistant to assemble cited evidence for standard controls; the specialist retains approval. Cross-train one reviewer for low-risk proposal types.

Success is more correctly completed proposals without longer downstream lead time or weaker security findings. Draft volume is not the goal measure.

Facilitation notes

• Define one system and goal before discussing bottlenecks.
• Ask which factor limits completed value, not which team feels busiest.
• Examine policies such as batching, priority escalation and approval rights.
• Keep quality and harm in the definition of throughput.
• Separate exploitation from elevation; low-cost operating changes come first.
• Tell non-constraint teams why lower local utilisation may improve the whole.
• Review the constraint after every material change in demand or capacity.

Expected output

A sound application produces:

• a defined system goal and throughput measure;
• an evidence-backed constraint hypothesis;
• current loss and queue evidence at the constraint;
• exploit, subordinate and elevation actions;
• an explicit release and priority policy;
• AI or automation boundaries where relevant;
• system-level measures and a date to reassess the constraint.

Common mistakes

1. Choosing the busiest resource. Busyness may reflect poor release policy rather than the system constraint.
2. Automating before exploiting. Waste and incomplete inputs become faster.
3. Maximising every resource. Excess upstream output increases queues.
4. Ignoring policy constraints. A rule can limit flow more than physical capacity.
5. Counting defective output. Rework is not useful throughput.
6. Stopping after improvement. The constraint moves and the old plan becomes stale.
7. Using TOC as a layoff argument. The method aligns capacity to the goal; it does not make automatic staffing decisions.

Quality checklist

• The system goal and boundary are explicit.
• Throughput represents completed, acceptable value.
• The constraint is supported by queue and capacity evidence.
• The team tested whether added constraint capacity would improve the whole.
• Exploitation precedes major investment.
• Upstream release is aligned with the constraint.
• Automation preserves quality, accountability and exception handling.
• Measures cover the whole system.
• A repeat date is set because the constraint can move.

Template

Knowledge check

An AI tool triples the number of cases prepared for a specialist whose queue is already growing. What is the most TOC-consistent response?

A. Reward the preparation team for higher output.
B. Release all generated cases immediately.
C. Align release to the constraint and improve input completeness before adding more volume.
D. Measure only model latency.

Answer: C. Non-constraint output should support the constraint and total throughput, not create more work in progress.

Related tools

• Preceded by: Value Stream Mapping
• Often combined with: Pareto Analysis, Root Cause Analysis
• Risk-checked with: FMEA
• Improved through: PDCA/PDSA Cycle
• Not to be confused with: capacity planning, cost cutting or finding any temporary bottleneck

References

1. Goldratt, E. M., and Cox, J. The Goal: A Process of Ongoing Improvement. North River Press, first published 1984; 30th anniversary edition, 2014. Primary source for the constraint-focused management approach.
2. Goldratt, E. M. What Is This Thing Called Theory of Constraints and How Should It Be Implemented? North River Press, 1990. Primary practitioner source for the focusing process.
3. Theory of Constraints International Certification Organization. “The Five Focusing Steps.” Official conference resource (opens in a new tab). Confirms the focusing sequence and the warning against inertia.
4. Lean Enterprise Institute. “Theory of Constraints.” Authoritative overview (opens in a new tab). Useful comparison of system constraint and flow perspectives.
5. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. Official publication (opens in a new tab).

Sources reviewed 3 August 2026.