Theory of constraints

Goal

The theory of constraints directs improvement effort to the factor that limits a system's throughput. The PMBOK Guide lists its five focusing steps among continuous improvement methods such as PDCA, Lean and Six Sigma.

It addresses a common problem: every team improves and the system delivers no more. A chain delivers at the pace of its slowest stage. The theory says where to put the effort and which stages there is no point in speeding up.

The deliverable fits on one page. It names the constraint and its type, the decisions that exploit it and the rules that subordinate the rest of the system to it. If throughput must grow further, the deliverable costs out an elevation proposal. Throughput, inventory and operating expense measure the effect of each decision.

Usage

When to use it

• Low throughput while everyone is busy: look for the stage that limits the system before adding resources.
• A queue growing in front of one stage: cases or tickets piling up signal a physical constraint.
• A capacity investment to decide on: check that the hire, the licence or the equipment targets the constraint.
• A resource shared by a continuous stream of requests: a test environment or a specialist; set its priorities and the entry rate.
• Utilisation metrics per station: replace them with the system's throughput, inventory and expense.
• A rule that slows the whole flow: a monthly release window or a double signature; treat it as a policy constraint.
• An organisation that already practises TOC or Lean: the PMBOK Guide asks the project manager to adapt the project's resource management to it.

When not to use it

• No measured flow: the named constraint remains an opinion; first measure queues and waiting times with value stream mapping.
• Scheduling a project under resource contention: apply the critical chain method, which carries the theory over to projects.

Description

What the theory means by a constraint

A constraint is "any element or factor that prevents a system from achieving a higher level of performance with respect to its goal". Watson, Blackstone and Gardiner take this definition from the APICS Dictionary. The PMBOK Guide speaks of the most important limiting factor on the way to an objective.

In the theory, the word does not mean what it means in the triple constraint. Scope, schedule and cost bound a project and trade off against one another. The theory's constraint is the point in the system that sets its throughput.

The theory holds that a system has few constraints and that they determine its performance. Watson and his co-authors sort constraints by type. The type decides the treatment.

Measuring the system rather than the stations

Goldratt judges a decision by its effect on three system measures. ACCA defines them as follows:

• throughput: the rate at which the system generates money through sales;
• inventory: the money invested in what the system intends to sell;
• operating expense: the money spent turning inventory into throughput.

A team that does not sell what it delivers measures by proxy. Throughput becomes items delivered and accepted per week. Inventory becomes work started and not yet delivered. Operating expense becomes the team's weekly cost.

These measures contradict efficiency per station. Goldratt and Fox set this opposition down as rules (1986). Watson and his co-authors cite two of them: "An hour lost at a bottleneck is an hour lost for the total system"; "An hour saved at a non-bottleneck is just a mirage". A non-constraint station working at 100% does not raise throughput. It builds inventory in front of the constraint. ACCA therefore accepts idle time at non-constraint stations.

The five focusing steps

Goldratt and Jeff Cox set out the steps in The Goal. They later evolved into the process of ongoing improvement (POOGI). The POOGI adds prerequisites: the team defines the system and its purpose, then chooses the measures that align the system with that purpose. For Goldratt, the goal of a company is to make money now and in the future. A public service or a project team names its own goal before looking for what limits it.

1. Identify the constraint. The team compares the load and the capacity of each stage using data: ticket timestamps, entry and exit dates of cases. The longest queue often sits in front of the constraint. The team also names the constraint's type.
2. Decide how to exploit the constraint. The team gets the highest possible throughput from the constraint with the current resources. A stand-in covers the constraint during breaks and meetings. The constraint handles only work that will leave the system. Quality control therefore comes before it. Another station takes over any task it can do in the constraint's place.
3. Subordinate everything else to that decision. Every other stage sets its pace by the constraint. Upstream stages start no more work than the constraint absorbs. Downstream stages process what leaves the constraint without delay. Non-constraint stations therefore keep unused capacity. That reserve shields the constraint from disruptions.
4. Elevate the constraint. The team adds capacity to the constraint through a hire, a purchase, outsourcing or a second piece of equipment. It does so only if throughput must still grow after steps 2 and 3. Watson and his co-authors set this order: exploit before elevating.
5. If a previous step has broken the constraint, go back to step 1. Goldratt adds an instruction: do not let inertia set in. The team then reviews the rules set for the old constraint: the entry rate, the priorities, the stand-in's hours. A rule left in place after the constraint has moved can become a policy constraint.

Breaking one constraint makes another appear elsewhere. The steps therefore form a loop.

Drum, buffer, rope

Drum-buffer-rope (DBR) puts steps 1 to 3 into practice for a physical or market constraint. The drum is the constraint that step 1 identifies. Its pace sets the pace of the system. The buffer serves exploitation: it is a time margin in front of the constraint. Work reaches it a little before the constraint needs it. An upstream incident therefore does not leave the constraint without work. The rope serves subordination: it ties the entry of work to the drum. The system starts an item only when the constraint has consumed one.

In a team that tracks its work on a kanban board, one work-in-progress limit shared by all columns up to the constraint does the rope's job: a card enters only when another leaves the constraint. The PMBOK Guide lists the theory of constraints and the Kanban method among the approaches that maximise flow.

For a policy constraint, the team changes the rule. Goldratt proposed the thinking processes for this purpose. These logic trees link undesirable effects to the rule that causes them.

The theory of constraints and neighbouring techniques

Pitfalls

Elevating before exploiting. Buying capacity is the most visible answer and the most expensive one. A constraint that loses time to breaks, rework or tasks another station could do keeps that waste after the purchase. The team exhausts steps 2 and 3 before costing step 4.

Keeping everyone busy. Management that measures the utilisation of each station or the tickets closed per person gets busy stations and inventory in front of the constraint. Throughput stays at the constraint's level.

Naming the constraint by guesswork. Neither the team that complains most nor the person with the most hours is necessarily the constraint. A team can be overloaded with work that will never leave the system. The team identifies the constraint from measured queues and throughput.

Staying on the old constraint. After an elevation, the team keeps working on the stage it knows. The constraint may have moved. Every hour saved on the old one is then a mirage. The team goes back through step 1 after every change in capacity.

Declaring an external constraint untreatable. GPM notes that a constraint can lie outside the organisation's control: a single supplier or a regulatory approval. The team exploits the constraint and subordinates the rest of the system to it. Elevation then goes through a contract or a negotiation.

Limitations

Watson, Blackstone and Gardiner list the theory's weaknesses. Its solutions are feasible without always being optimal. Its procedures are poorly defined and the literature names no preferred method. The literature defines throughput in several ways. Goldratt defines it as sales minus totally variable costs. Throughput accounting serves the short term and provides no product cost for setting a price. The authors find no clear evidence of a performance gap with just-in-time.

GPM adds that a fixed focus on the constraint can hide other paths to improvement. According to Watson and his co-authors, the thinking processes rest on subjective interpretation. Their validity and reliability remain to be shown. These tools are also hard to teach to company management. Watson and his co-authors noted in 2007 that Goldratt seemed to be moving away from these tools: he had launched a programme for consultants called Viable Vision.

Watson and his co-authors cite a 2003 IndustryWeek survey: fewer than 5% of US manufacturing plants then used the theory to drive improvement.

AI considerations

From an export of tickets or cases, an AI assistant that runs code computes the queue, the waiting time and the weekly throughput for each stage. It produces the load and capacity table for step 1 and flags the stage where work piles up. In internal directives and minutes, it picks out the rules that limit flow: release windows, signatures, approval thresholds. The team gets a first list of policy constraints to check. From the undesirable effects the team has noted, the model drafts the thinking-process trees.

The team chooses the constraint itself. A language model names the most plausible stage from the words in the documents; only flow data identify the constraint. Elevation commits budget and people. Management decides on it. An export that shows the throughput or the queue of named employees contains personal data under the Federal Act on Data Protection (FADP). The team anonymises it or obtains the data protection advisor's agreement before sending it to an online service.

Examples

The constraint sets throughput and moves when it is elevated. The team that builds the online portal of an AHV/AVS compensation office measures its stages in backlog items per week.

The second environment adds 4 items of capacity to testing and only 1 item to throughput. Deployment caps at 9 and becomes the constraint. The team goes back to step 1 on deployment.

Visualisations

After exploitation and subordination, testing sets the pace of the portal chain. The other stages keep unused capacity.

Cost

Tooling

A whiteboard is enough to draw the chain, note each stage's capacity and queue and mark the constraint. A spreadsheet calculates load, capacity and throughput per stage and tracks the measures week by week.

Jira and Azure DevOps record every move from one stage to the next. Their cumulative flow diagram shows the band that widens in front of the constraint. A process mining tool such as Celonis reconstructs the waiting times of a process from ERP logs. A simulation tests the effect of an elevation before the purchase.

Sources

• Project Management Institute (2025), A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th edition: §2.6.2.5 Monitor and Control Resourcing, which names the theory of constraints in its list of tools (figure 2-45); §2.6.3 Tailoring Considerations (Industry context) for adapting resource management to the organisation's methods; §4.2.2 Adaptive Approaches for the description of the constraint and the theory among the approaches that maximise flow; Section 5, entry "Theory of constraints (TOC)" for the definition and the link with CCPM; entry "Continuous improvement" for the five focusing steps among continuous improvement methods. The PMBOK Guide does not describe the steps.
• Goldratt, Eliyahu M. and Cox, Jeff (1984), The Goal: A Process of Ongoing Improvement, North River Press: the business novel in which Goldratt sets out the five focusing steps.
• Watson, K. J., Blackstone, J. H. and Gardiner, S. C. (2007), "The evolution of a management philosophy: The theory of constraints", Journal of Operations Management 25(2), pp. 387-402: the definition of the constraint from the APICS Dictionary and its types; the rules of Goldratt and Fox (1986); the five focusing steps and the POOGI prerequisites; drum-buffer-rope; throughput, inventory and operating expense; the thinking processes; the weaknesses of the theory.
• ACCA, "Throughput accounting": the definitions of throughput, inventory and operating expense; the hour lost at the bottleneck; idle time accepted at non-constraint stations.
• GPM Deutsche Gesellschaft für Projektmanagement (2024), "Theory of Constraints (TOC): Definition, Prinzipien & Anwendungsbereiche": the constraint outside the organisation's control; the risk of a focus fixed on the constraint alone.