Root cause
The five whys finds one cause, and most delays do not have one
Asking why five times works when a chain of single causes led to a single failure. It fails quietly on anything where the cause is a distribution rather than an event.
The five whys is the most widely taught root cause technique there is, and it deserves to be. It costs nothing, it needs no software, anyone can run it, and on the class of problem it was built for it works.
The trouble is that nobody is ever taught where it stops working, so it gets applied to problems it cannot answer, and it produces an answer anyway. That is the dangerous part. It does not fail loudly.
Where it works
A machine stopped. Why? A fuse blew. Why? The motor drew too much current. Why? The bearing seized. Why? It was not lubricated. Why? The lubrication schedule was not being followed.
This works because the situation has the shape the technique assumes: one event, one chain, one cause per link. Each answer is a fact somebody can verify, and the chain terminates at something that can be changed. That is a real root cause, and fixing it prevents this failure recurring.
Keep using it for this. It is excellent at it.
Where it stops working
Now try it on the thing operations teams actually spend most of their time on.
Orders are late. Why? They waited at assessment. Why? There was a queue. Why? Work arrives faster than assessment handles it, sometimes. Why? Sometimes there are more orders. Why?
And you are stuck, because there is no fifth answer of the same kind. The honest answer to the last why is that arrivals vary and handling times vary, and when both are true a queue forms even though average capacity exceeds average demand.
That is not a cause in the sense the technique means. Nobody did it. There is no schedule that was not followed. There is nothing at the end of the chain to fix, and yet the delay is completely real and entirely explainable.
What it produces instead
This is the part worth watching for, because the technique does not stop. Faced with a question that has no single cause, a room will supply one, and it is almost always a person or a department.
Assessment is too slow. Assessment needs to be more productive. Assessment should be monitored more closely.
None of those is supported by anything. The queue in the example forms at any utilization level, gets worse as the step fills, and would form with a faster team too, only at a higher volume. The five whys did not find that answer. It found the last noun anybody mentioned, and the noun was a team.
How to tell which problem you have, before you start
One question, asked before the first why.
Did this happen once, or does it happen at a rate?
| The problem | Use |
|---|---|
| A specific failure, on a specific day, with a chain behind it | The five whys. It is the right tool and nothing else is faster |
| Something that happens at a rate, to a proportion, on and off | Measure the spread. There is no single cause to find |
A machine that stopped on Tuesday is the first. Orders being late a quarter of the time is the second. The second one is answered by looking at the distribution rather than the chain, which is what the average was met and a quarter of the orders were late is about.
What to do with it
Ask the once-or-rate question first. It takes ten seconds and it decides whether the next hour is well spent.
Stop at the first why with more than one honest answer. If two answers are both true, the chain has branched, and a technique that follows one branch is now discarding evidence. That is the point to change method rather than to pick a branch.
And treat “the team is too slow” as a failed session rather than a finding. It is what the method produces when it has run past its own limit. The real answer is usually in the arrival pattern or the spread of handling times, and neither of those is anybody’s fault.
The five whys is a good tool. Most process delays are simply not the kind of problem it was built to solve.