Constraints and bottlenecks

Follow the work, not the noise

Start with the result that matters to the customer or service user. Follow real work from request to completion, with the people doing it. Include handovers and other organisations—not just your own team.

• Where does work wait, return or get stuck? Look at queues, waiting times, rework and incomplete information over time.
• What is limiting progress there? Check demand, available capacity, variation, priorities, rules and dependencies. A large queue is a clue, not proof of the constraint.
• What would happen if we relieved it? Predict the effect on completed work, total waiting time and quality. What evidence would challenge your explanation?

You are forming a testable explanation, not looking for someone to blame.

One simple example

Imagine a service team that prepares orders quickly, but every order needs approval from one specialist. Orders wait for approval; speeding up preparation adds to the queue without increasing deliveries.

Check why approval is needed and how the specialist’s time is used. Could routine orders follow an agreed standard, leaving specialist review for exceptions? Test the arrangement without weakening quality or safety.

If completed orders increase, another limit may become important. The constraint is not necessarily in the same place forever.

Check four traps

• The loudest symptom. Visible delays may arise downstream of the condition causing them. Trace the work rather than assuming the most complained-about step is the cause.
• The wrong boundary. A dependency may sit with another team or organisation. Involve them; a local change alone may not be enough.
• Yesterday’s constraint. Recheck after changes and as demand shifts. Do not keep expanding a step that no longer limits the result.
• A missing condition. Progress may depend on information, skills, authority or a shared arrangement that does not yet exist—not simply on making an existing step faster.

Test a change at the suspected constraint

First make better use of what is available and organise surrounding work to support it. Add capacity where needed—not automatically everywhere. The Theory of Constraints’ five focusing steps provide a short sequence.

If two legitimate needs seem to conflict, use TRIZ separation questions to explore alternatives. Not every constraint is a contradiction, and no particular tool is compulsory.

State what will change, what result you expect and when. Check implementation, completed work, end-to-end waiting and possible harm elsewhere. A local gain is not automatically a system gain—but it may still improve safety, quality or working conditions.

Charts can help identify performance changes. A change point alone does not prove you found the constraint or establish causation; no detected change is a reason to investigate the explanation, implementation, data and timing—not a verdict by itself.

What’s your next useful question?

What is limiting the result now—and what would we expect to see if we relieved it?