How to Run a 5 Whys That Actually Finds the Root Cause

5 Whys is the most misused tool in lean. Here is how to use it correctly so you fix the system, not the symptom.

Why 5 Whys fails most of the time

The most common failure mode: the team stops at a symptom and calls it a root cause. The machine broke down. Why? Because it wasn't maintained. Why wasn't it maintained? Because the maintenance team was busy. Why were they busy? Because there are too many breakdowns. That last answer is circular. It is not a root cause.

A root cause is a system-level condition that, if changed, would prevent the problem from recurring. If your fifth why is still a behaviour, a person, or a surface condition, you have not found the root cause yet.

The validation test for each why

At each level, test the logic: "If we fix this why, does it prevent the problem above it?" Work backwards from the bottom up. If you fix the root cause and the problem above it is not prevented, you have a wrong why. The chain must hold in both directions.

The most common traps

Stopping at human error. "The operator made a mistake" is never a root cause. Why did the system allow the mistake? Why was there no error-proofing? Why was the standard work unclear? The operator is not the cause. The system that allowed the error is.

Branching without discipline. Real problems often have multiple causes. If two different whys are both true at the same level, document both branches. Do not arbitrarily pick one.

Running it alone. 5 Whys is a team exercise. A facilitator asks the questions. Subject matter experts answer them. The person closest to the problem is not the same as the person who understands the system.

The Sakichi Toyoda rule

Toyota's founder said: "By repeating why five times, the nature of the problem as well as its solution becomes clear." The number five is not the point. The point is to keep asking until the answer is something the system can actually change. Sometimes that takes three whys. Sometimes it takes seven.

What a good 5 Whys output looks like

The output is a chain of whys that is logically defensible at every link, ends at a system-level condition that can be changed, and produces a specific countermeasure that addresses the root cause rather than the symptom. If the countermeasure only addresses the most recent why, you stopped too early.