Theory of Constraints for Project Managers: Find the One Step That Limits Everything

Imagine a highway where two lanes narrow into one. Before the merge, the road is full, the drivers are impatient and a certain amount of honking is going on. After the merge, the road is almost empty. Now imagine that a very enthusiastic city council decides to improve the situation by widening the road after the merge, with a fresh coat of asphalt and a pretty fountain. Does a single additional car per hour reach the other side?

It does not. The merge decides how many cars per hour get through, and every dollar spent anywhere else is a donation to the scenery.

That is the central idea of the Theory of Constraints, and once you see it, you will see merges everywhere: in the kitchen, in the design department, in the approvals office and in your own calendar. This guide explains the idea in plain language, walks through the five steps that turn it into action, shows how it appears in real projects and teams and ends with a small tool that finds the bottleneck in your own process.

Where the idea comes from

Eliyahu Goldratt, an Israeli physicist who turned to business, introduced the Theory of Constraints in the 1980s, and he made it famous with a novel, The Goal (1984), about a factory manager who has ninety days to save his plant. It is a business book that reads like a thriller, and one scene has become a classic: the manager takes a troop of boy scouts on a hike and discovers that the whole line moves at the speed of the slowest hiker. Making the fast scouts faster only stretches the line. The only way to speed up the troop is to help the slowest one: lighten his pack, put him in front, move the heavy things to somebody stronger.

The method started in manufacturing, but the logic applies wherever work flows through steps: construction, software, clinics, kitchens, marketing and the small business owner's own Tuesday. Goldratt later applied it to projects directly, in Critical Chain (1997), and I will come back to that.

The principle: output is set by the weakest step

Every process is a chain of steps. Each step has a capacity, the amount of work it can handle in a day or a week. The output of the whole chain is the capacity of the weakest step, because nothing can leave the process faster than it passes through its narrowest point. That step is the constraint, also called the bottleneck.

Two consequences follow, and both are uncomfortable.

1. An hour lost at the constraint is an hour lost for the whole system. If the constraint stops for an hour, the entire project's output stops for an hour, and nobody can buy it back later.
2. An hour saved anywhere else is, strictly speaking, a mirage. If the design team becomes twice as fast but the review step stays the same, the only thing that grows is the pile of designs waiting for review.

This is why so many improvement efforts disappoint. Teams find a step that is easy to improve, improve it, celebrate and then wonder why the delivery date did not move. They improved a step that was not the constraint.

The five focusing steps

Goldratt turned the idea into a simple loop. It is worth memorizing, because it is one of the few management ideas that fits on a sticky note.

1. Identify the constraint. Find the one step that limits the whole. Look for where work piles up in front of it and where the people after it are waiting.
2. Exploit the constraint. Squeeze the maximum out of what you already have. Make sure it never waits, never works on the wrong thing and never redoes a mistake.
3. Subordinate everything else to the constraint. The other steps exist to serve it: feed it clean work at the pace it can take, and do not drown it with more than it can handle.
4. Elevate the constraint. Only now, if the first three steps are not enough, add capacity: hire, buy, outsource, add a shift.
5. Repeat. When you fix the constraint, a different step becomes the weakest. Go back to step one, and do not let yesterday's solution become tomorrow's habit.

Notice the order. Most of us jump straight to step four, because spending money feels like action. The first three steps are free, and they often solve most of the problem.

Where constraints hide in projects

In a factory, the constraint is often a machine you can point at. In a project, it is rarely so obvious, and it is often not a thing at all. The usual suspects:

• A rare skill. The only structural engineer, the one senior developer who reviews every change, the single person who can sign a drawing. Everything waits for their calendar.
• A decision-maker. The owner, the sponsor or the committee that meets on the second Tuesday of the month. Work stops at their door, and everyone calls it "waiting for approval." See the executive sponsor guide for how to make decisions faster.
• An approval gate. A permit, an inspection, a legal review or a security review with a queue of its own.
• A long-lead item. The steel, the custom equipment, the license with an eight-week turnaround. The critical path usually runs through it.
• A shared resource. One crew across three sites, one test environment for five teams, one kitchen for the whole restaurant.
• A policy. "Everything over $500 needs two signatures." A policy can be a constraint without any person or machine involved. The rule is the bottleneck.
• The owner. In a small business, the constraint is often the person at the top, because every question, quote and choice goes through them. This is one of the reasons the weekly rhythm in Project Focus exists.

Notice that the constraint is not necessarily the busiest or the loudest step. Often the people at the constraint are quiet, overloaded and polite, and the noisy ones are upstream, complaining that their work is stuck.

How to find yours

You do not need software to find the constraint. You need curiosity and a pencil. A few clues:

• Where does work wait? Look for the biggest pile, the longest list, the column on the board that is always full. Work queues up in front of the constraint.
• Who is always busy, and who is sometimes idle? The step after the constraint often has idle time, and the steps before it have too much unfinished work.
• What do people say they are waiting for? "Waiting for review," "waiting for the permit," "waiting for the quote." The same sentence, said by many people, usually points to the constraint.
• What would speed up everything if it doubled? Ask the team that question and watch where the answers converge.
• Measure it. Count how many items each step can finish in a week. The smallest number is your constraint. The tool below does this arithmetic for you.

Step 2: exploit, or stop wasting the constraint

This is the step with the best return, and it costs nothing. The constraint's time is the most valuable time in the system, so protect it.

• Never let it wait. Prepare the work before it arrives, so the constraint always has something ready. If the senior engineer reviews code, a junior colleague should make sure the change is small, tested and well described before it reaches them.
• Never let it work on the wrong thing. Rank the work by value. The constraint should handle the most valuable items first, not the loudest.
• Keep rework away from it. Check quality before the work reaches the constraint, so no capacity is spent on items that will bounce back.
• Remove everything that does not need the constraint. If the sponsor spends two hours a week on tasks that someone else could do, give those tasks away.
• Keep it running at lunch, in the shifts and over holidays. In a factory this means a machine that never stops. In a project it can mean a decision window that is guaranteed: "Every Thursday at ten, the owner decides everything on the list."

Step 3: subordinate, or stop overloading the constraint

Once the constraint is protected, the other steps must stop doing things that make its life harder. This is the counterintuitive step, because it means asking productive people to slow down.

• Do not feed the constraint more than it can handle. A pile in front of it does not make it faster. It makes everything slower, because the work becomes older and harder to sort.
• Limit work in progress. A cap on how many items can be open at once, as in kanban, is the practical form of this idea. It keeps upstream steps from flooding the constraint and exposes the bottleneck honestly.
• Pace the other steps by the constraint. In manufacturing the idea is called drum, buffer, rope: the constraint is the drum that sets the beat, a buffer of work in front of it protects it from interruption and a rope ties the release of new work to the speed of the drum. In a small team it can be as simple as: do not start a new item until one finishes at the constraint.
• Let non-constraints be idle. This is the hardest part. A step that is not the constraint can, and should, have spare time. Keeping everyone one hundred percent busy is the surest way to bury the bottleneck.

Step 4: elevate, but only after steps 2 and 3

If the constraint is still the limit after you have protected it and fed it properly, then add capacity: another reviewer, a second crew, an outside specialist, a better tool, a shorter approval path. This is the moment to spend money, because now you know the spending will move the whole system.

Compare two decisions. A team spends $20,000 on a faster design tool and nothing changes, because review is the bottleneck. Another team spends $4,000 on a part-time reviewer and ships a third more work every month. Same instinct, very different return. The difference was knowing where the constraint was.

Step 5: repeat, because the constraint moves

Fix the constraint and a new one appears. That is not a failure: it is the process getting healthier. The danger is inertia. The reviewer you added in March becomes a habit and the process is still organized around a problem that no longer exists. Put a reminder in your calendar for once a month: where is the pile now?

From critical path to critical chain

Project managers already know one constraint-based tool: the critical path, the longest chain of dependent tasks that sets the finish date. In 1997 Goldratt proposed an evolution called critical chain project management, and its ideas are useful even if you never adopt the whole method.

• Hidden safety. People pad their estimates. Each task has a little extra time in it, and in the end that extra time is gone: workers tend to start late when a deadline feels far away (the "student syndrome"), and work expands to fill the time available (Parkinson's law).
• Shared buffers. Instead of padding every task, the method takes the safety out of the individual tasks and pools it into a few buffers: one at the end of the project and smaller ones where side chains join the main chain. A pooled buffer absorbs surprises more efficiently than many small ones, because not everything goes wrong at once.
• Resources count. A critical chain is the longest chain of tasks when people and equipment are also limits, not only the dependencies between tasks. If one person is needed for two tasks planned at the same time, the plan has a conflict that a standard schedule hides.
• Buffer management. Instead of watching each task's date, you watch how much of the buffer has been used compared with how much of the work is done. Green means ignore, yellow means prepare a plan, red means act.
• Stop multitasking. Switching between tasks makes each one slower. Finishing one before starting the next is faster than juggling three.

The method has fans and critics, and it asks a team to change its habits, so treat it as a set of ideas rather than a religion. Even a light version helps: name the one task or person that controls the finish date, protect it, pool your safety time and watch the buffer instead of the calendar. For the wider question of how people and workload fit together, see our guide to capacity planning and bottlenecks.

Three examples (illustrative)

A clinic opening. A small clinic is building out a space. The construction is on time, the equipment has arrived and the staff is hired. But the health department inspection is booked six weeks out. That inspection is the constraint. Exploiting it means making sure everything is ready the day the inspector arrives, so there is no second visit. Subordinating means not hiring the whole staff early, because the payroll would be burning cash while waiting. Elevating means asking whether an earlier slot or a pre-inspection review is available. Our article on how a clinic opens on time shows the full pattern.

A software team. Features flow from design to build to code review to release. The team grows from four to six developers, and the number of features that ship barely moves, because every change waits for one senior engineer's review. Adding developers makes the pile longer. The fix is to shorten the changes, add a second reviewer and cap the number of changes waiting. The tech teams guide covers this in more detail.

A small restaurant. The cooks are fast, the servers are friendly and the line at the door is long, but the kitchen sends out the same number of plates every night. The constraint is the pass, the single station where the dishes are checked and finished. Hiring another cook changes nothing. A second person at the pass, or simplifying the plating, changes the whole evening. The restaurant article walks through a similar one.

Find your bottleneck

The tool below does the arithmetic. Enter how many items each of your four steps can finish in a week (or any other period). It shows which step is the constraint, what the whole process can deliver and how much spare capacity the other steps have. It also tests two ideas, so you can see why the first three steps matter: what happens if you speed up the constraint by twenty percent, and what happens if you speed up a step that is not the constraint by fifty percent. Replace the sample numbers with yours. Nothing you type leaves your browser.

Interactive tool

Find your bottleneck

Loading the tool…

Common mistakes

• Improving what is easy instead of what limits. The step that is easy to improve is seldom the constraint.
• Measuring busyness. A busy step is not necessarily a constraint. The constraint is where the work waits.
• Keeping everyone one hundred percent utilized. It feels efficient and produces queues, delay and rework.
• Skipping to step four. Buying capacity before protecting what you have wastes money.
• Fixing the constraint with overtime. Short sprints work. A permanent state of heroics does not.
• Declaring victory. The constraint moves. Check again.
• Confusing the constraint with a person's performance. A person at the constraint is not the problem. The system around them usually is.

What to do this week

Pick one project or one process that feels slow. Draw its steps on a sheet of paper, left to right. Under each step, write how many items it can finish in a week. Circle the smallest number. Then answer three questions: when does the circled step wait or work on the wrong thing, what is flowing into it that could be cleaner and what is it doing that someone else could do? If you can make one of those better by Friday, you have just improved the whole system, probably for free. If you would like help finding the constraint in a business or a project, that is part of my consulting work, and you can tell me where you are stuck on the contact page.

Where does work wait in your business: for a person, a decision, a delivery or a rule? Tell me in the comments.

More tools. The weekly review, the risk register and the decision log are free in the toolkit.

Also read. How to see work moving and stuck at a glance: kanban for small teams. And how to keep a dashboard from lying to you: dashboards without vanity metrics.

Frequently asked questions

What is the Theory of Constraints in simple terms?

It is the idea that every process has one step that limits its output, and that improving anything else does not increase what gets finished. You find that step, protect it, make everything else support it, add capacity there only if needed and then repeat, because the constraint moves.

What are the five focusing steps?

Identify the constraint, exploit it (make the most of what you have), subordinate everything else to it, elevate it (add capacity) and repeat. The order matters: the first three steps are usually free and often solve most of the problem before you spend any money.

How is the Theory of Constraints used in project management?

Project managers use it to find the task, person, decision or approval that controls the finish date, to cap work in progress, to protect the people who are the limit and, in critical chain project management, to pool safety time into buffers instead of padding every task and to watch the buffer rather than individual dates.

Is the constraint always a person or a machine?

No. It can be a rule, a policy, an approval gate, a long-lead item, a market limit or a decision-maker's calendar. In small businesses it is very often the owner, because every decision goes through one person. The way to find it is to look for where work waits.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Useful Made me smile Go deeper on this

Be the first to react.

Comments

Loading comments…

Leave a comment

NameEmail (required, never shown)

Where does work wait in your business: for a person, a decision, a delivery or a rule? Post comment

Your name and email create a small profile that shows you are a real person. The email is never shown. The first time, I send you a confirmation link, and every comment is reviewed before it appears. Please keep it respectful and leave links out.