5 Whys Root Cause Analysis: Dig Past the Symptom Without Blaming People

The same problem keeps coming back, and someone already has the explanation: "the new hire made a mistake," "the team was careless," "the coordinator dropped the handoff again." The sentence ends with a person. That person gets retrained or warned. A few weeks later, the problem returns.

5 Whys is built for exactly this moment. When a specific, recent problem keeps recurring and the first explanation points at someone, it gives you a way to dig past that story, with every step resting on a fact that can be checked.

What is 5 Whys?

5 Whys is a structured questioning routine that moves from a visible problem to a root cause: a cause you can act on that, once removed, stops the problem from coming back. The method is associated with Sakichi Toyoda and was described by Taiichi Ohno as part of the Toyota Production System.

The mechanics are simple. Ask why the problem happened. Take the answer and ask why that happened. Repeat until you reach a process, a policy or a system condition rather than a person.

Where other tools widen the picture (issue trees, fishbones, process maps), 5 Whys goes deep on one specific failure.

"Five" is a guideline, not a rule

Sometimes three questions are enough; sometimes you need seven. What matters is the discipline between the questions: each answer must be a fact someone can verify. Calling the team careless gives nobody anything to check. "The error log shows the wrong template was used on every affected invoice" is. Evidence is what stops the session from becoming a round of theories.

Two more ideas make the method work:

• Chains can branch. If two separate things had to fail for the customer to feel the problem, follow two chains, each with its own evidence.
• Read it backward with "therefore." Start at the root cause and walk up to the symptom. If any step needs the word "somehow," a link is missing.

A 5 Whys example

A fictional accounting firm keeps sending some clients invoices with the wrong rate.

Problem statement: Since the billing system was upgraded, a growing share of invoices to retainer clients have gone out at the standard rate instead of the agreed retainer rate.

• Why 1: The invoices were generated with the standard rate. Evidence: every incorrect invoice reviewed carries the default rate code.
• Why 2: Those clients have no retainer rate stored in the new system. Evidence: a check of client records shows the field is empty for the affected accounts.
• Why 3: Retainer rates were not included in the data migration. Evidence: the migration scope document lists contacts and open balances, not rate agreements.
• Why 4: The migration plan had no sign-off from the billing team on which fields mattered. Evidence: the approval page carries only IT signatures.

Root cause: system changes can go live without the operational owner confirming the data they depend on.

Read backward: there was no billing sign-off, therefore rate agreements were left out of the migration, therefore retainer clients have no stored rate, therefore invoices fall back to the standard rate. Every "therefore" holds.

A second branch surfaced in the same session: clients who complained were not told a corrected invoice was on its way, because nobody owned that message after the upgrade. It gets its own chain and its own fix.

Countermeasure, owner, check date: restore the missing rates and add a billing sign-off step to every future system change. Owner: the billing lead, with IT. The check date is set for a few weeks out, against the original problem measure.

Retraining the person who sent the invoices would have been cheap and would have looked decisive. It would also have left the real gap open.

How to run it in eight steps

1. Write the problem as a measured, time-bound statement: the symptom, where, when and the before-and-after change.
2. Get the people closest to the work into the room, not only the supervisor. Their job is to correct assumptions, not to defend themselves.
3. Ask the first why and record the answer with its evidence. If the answer names a person, push further: where, when, and how do we know?
4. Verify each answer before asking the next why. Look at the log, the record or the plan. "Everyone knows" is not evidence.
5. Branch whenever there is more than one causal path.
6. Stop at a cause a process or policy change can fix. If you reach "the economy" or "human nature," you went too far.
7. Read the chain backward with "therefore."
8. Set a countermeasure, one owner and a check date, and agree on them before the session ends.

Common mistakes

• Stopping at a person. Ask the next question anyway: what allowed the mistake, and why did nothing catch it?
• Accepting guesses. A confident participant offers a plausible theory and it gets written down unchecked. Require evidence in the same session.
• One chain for a problem with two causes. A clean single story produces a half solution. A branch is the method working.
• Stopping too early, or too far. Too early: "the data was missing." Too far: "the labor market is tight." The right depth is a process gap that a named owner can close.

When 5 Whys is not enough

It works best on specific, recent, bounded problems with one or two dominant chains. For broad problems with many interacting causes, start with a MECE breakdown or an issue tree to map the territory first, and then use 5 Whys on the branch that matters. It also depends on who is in the room, and it can get political when the chain points at a leader's decision. Agree upfront that the chain may point anywhere, but the countermeasure must be a process change.

Go further

Five Whys is Chapter 9 of The Problem-Solving Toolkit, in Part II, Find the Facts, and comes with a printable Five Whys Worksheet with fields for evidence, branches and the "therefore" read-back. Read Chapter 1 for free, or see how it fits into the whole Frame, Find, Decide, Deliver method.