The 5 Whys is simple, popular and easy to misuse. How to use it properly, when to combine it with fishbone diagrams, data and fault trees, and how to prove a root cause before acting on it.
Why did the line stop? The machine overheated. Why? The coolant pump failed. Why? It was not maintained. Why? Maintenance was behind schedule. Why? Not enough technicians. Five whys, a neat answer: hire a technician. A deeper investigation found something else. The pump had failed because it was the wrong specification for the duty, installed during a rushed upgrade, and three other pumps on the site had the same problem. Hiring another technician would not have helped.
The 5 Whys is a valuable tool. It is also easy to use badly.
Using 5 Whys well
- Start with a clear, specific problem statement, based on facts.
- Go to the gemba: look at the actual process, part or equipment.
- Answer each "why" with facts, not assumptions. If you do not know, find out before continuing.
- Follow multiple branches. Most problems have more than one cause.
- Stop when you reach a cause you can act on that would prevent recurrence, not necessarily after exactly five steps.
- Check the logic backwards: "this cause, therefore that effect". If it does not hold, the chain is wrong.
- Ask two sets of whys: why did it happen, and why was it not detected?
Where 5 Whys falls short
- Complex problems with several interacting causes.
- Problems where the cause is not visible and needs data to find.
- Investigations led by people who already "know" the answer.
- Chains that drift towards blaming people or management.
Other tools to combine with it
- Fishbone (Ishikawa) diagrams: organise possible causes by category, such as methods, machines, materials, measurement, people and environment, so nothing is overlooked.
- "Is / is not" analysis: compare where, when and on what the problem occurs with where it does not. Differences point to causes.
- Data analysis: Pareto charts, run charts, stratification and comparisons to test which causes are real.
- Designed experiments, where several factors interact, as described in DOE for injection moulders.
- Fault tree analysis for safety-critical or complex system failures.
- Change analysis: what changed just before the problem appeared?
Proving the root cause
Before implementing a fix, confirm the cause:
- Can you turn the problem on and off by changing the suspected cause?
- Does the cause explain all the facts, including where and when the problem does not occur?
- Is there data showing the relationship?
A root cause that has not been proven is a hypothesis.
Building capability
Root cause analysis is a skill that improves with practice and coaching. Leaders who ask good questions, "how do we know?", "what does the data say?", "why was it not detected?", build teams that find real causes, which is the heart of a problem-solving culture.
The 5 Whys is a good start. Real root cause analysis uses it as one tool among several, always backed by evidence.
