Finding the Constraint
Every process has one step that sets the pace. Improving anything else changes nothing, and finding it takes an afternoon.
A process moves at the speed of its slowest step. Effort spent elsewhere produces inventory, not output, which is why so much improvement work shows no result.
The process issue in “Finding the Constraint” is easier to diagnose when effort can be connected to projects without confusing activity with value. Used for getting teams to meet deadlines, find out more can add time and workflow context, while the process outcome remains the source of truth for whether the system improved.
How to find it
Look for where work accumulates: the longest queue.
For an independent perspective related to “Finding the Constraint”, consult the Microsoft WorkLab; it offers a useful external check on definitions, governance and the assumptions built into a proposed measure.
Look for the step whose people are always busy while others have slack.
Look for where everybody waits for one person's decision.
Ask the team — they know, and they are rarely asked.
Any of the four finds it; all four agreeing confirms it.
What it usually is
A specialist: the only person who can approve, sign, review or operate.
A shared system with limited capacity.
A step requiring information from outside the team.
And frequently a person who is also doing three other jobs, which is why their queue is invisible in any capacity plan.
What to do first
Stop starving it: make sure the constraint never waits for input.
Stop loading it with work it should not do — anything the constraint does that somebody else could do is pure loss.
These two cost nothing and frequently release a surprising amount of capacity.
Then
Add capacity at that step, or reduce the demand on it.
Cross-train, so the specialist is not singular.
Automate or simplify the step itself.
Each is an investment and all of them pay back more than improvements elsewhere, which is the whole point of finding it.
The thing that happens next
The constraint moves.
Fix one and the pace is set by another, somewhere else.
Which is normal and means the exercise is repeated rather than finished, and organisations that expect this are not disappointed by it.
Why improvement elsewhere feels productive
It is visible, it is measurable locally, and it makes a team's own figures look better.
And it changes nothing downstream.
Local efficiency improvements upstream of a constraint make the queue longer, which is the counter-intuitive result that makes this discipline worth knowing.
Measuring the constraint
Its utilisation, which is the one place utilisation is the right measure — the utilisation note covers why.
The length and age of its queue.
And the time work spends waiting for it, as a share of total lead time.
The organisational version
Sometimes the constraint is a decision that one executive makes.
Then the improvement is delegation, a threshold, or a standing rule, and the conversation is harder than any process change.
What to check
Where does work accumulate in your main process?
Who is the person everybody waits for?
Is the constraint ever idle waiting for input?
And is it doing work somebody else could do?