5 Whys: Follow the Cause Chain Until You Can Act

A line stops. A ticket reopens. An order ships with the wrong item. The first fix often looks right: replace the part, remind the person, add one more check at the last step.

Then the same failure returns. The last visible break was a symptom. The schedule, the missing plan, or the rule that made the break likely is still in place. If you treat every incident as a one-off, you spend the week on patches and never name what to change.

The 5 Whys is a way to slow that rush. It asks you to write what actually happened, then test each “because” until the answer is something the team can redesign. It does not promise that five questions reveal the only truth in a messy system.

The 5 Whys is a linear root-cause method associated with Sakichi Toyoda and later Toyota Production System teaching. You start with a problem you can observe. You ask why it happened. You treat that answer as a candidate, not as the end. If the answer itself has a cause, you ask why again.

The number five is a mnemonic so people do not stop at the first plausible sentence. Some chains close in three rounds. Some need more. The method still holds: stay on one chain, require an observation for each step, stop when the cause is structural, then convert that cause into an action focus.

The 5 Whys does not map every possible cause category, does not rank causes by volume, and does not run an improvement cycle. It diagnoses one chain.

A useful 5 Whys pass is a written chain plus an action, not a meeting that says “we asked why five times.”

1. Define the observable problem

Write what happened in terms you could show someone: “orders shipped with the wrong item on Tuesday,” not “the warehouse is sloppy.” Mixing several problems in one statement blurs the chain.

2. Ask why and name the immediate cause

Answer with an observation: the machine overheated, the pick list did not match the bin, the check was skipped. If you lack evidence, label the answer as assumed.

3. Test whether the answer is still a symptom

Ask whether this cause would still happen if a deeper condition stayed true. If yes, you do not have a structural cause yet.

4. Continue until the cause is structural

Keep the chain on the same problem. Stop when the answer names a process, schedule, rule, design, or missing plan you can change. Do not force extra rounds that wander into blame or speculation.

5. Convert the cause into an action focus

State what would interrupt the chain: a maintenance schedule, a verification step, a rule change. Without that move, you still have a story.

Review the chain when a new failure class appears. A chain is a snapshot of this incident class, not a permanent law.

When another lens fits better, or when you need a complementary view, these frameworks do different jobs. They are not interchangeable labels for the same question.

The 5 Whys is the lens for one evidenced chain, then an action. Other methods help when the question is a cause map, a ranking, a cycle, or a completeness check.

• Recurring failures after a fix. The part was replaced, the reminder was sent, and the same break came back.
• One incident with a plausible chain. You can name what happened, when, and what was visible, and you need the next cause, not a brainstorm of every category.
• Symptom-to-system translation. The team can see the last break (overheat, wrong pick, missed check) but cannot name the process that made it likely.

Example: The line that keeps stopping

A small factory treats every stop as a machine event. Technicians replace a pump. The line stops again the next month.

They write the problem: the line stopped for two hours on Thursday. Immediate cause: the machine overheated. Why: cooling failed. Why: the pump stopped. Why: the pump was not maintained. Why: there is no scheduled maintenance plan.

Implication: Protect time to create and staff a maintenance schedule. Replacing the pump again is still a patch. The team did not prove a cosmic five-layer truth. They evidenced one chain and named a changeable cause. Blaming the technician would be a different, weaker ending.

Example: Wrong item in the box

A warehouse sees recurring mis-picks. Leadership wants “more care.”

Problem: twelve orders this week shipped with the wrong SKU. Immediate cause: pickers pulled from the adjacent bin. Why: labels on two bins look the same under warehouse lighting. Why: the label spec was never updated after a packaging change.

Implication: Change the label spec and bin contrast before another “be careful” talk. If volume of mis-picks is the first question, 80/20 ranking of error types may come first; 5 Whys then drills the dominant type.

What the 5 Whys can help with

• Writing a problem as an observable outcome
• Following one cause chain without stopping at the first plausible reason
• Separating a symptom from a process, system, or rule
• Naming an action that would interrupt recurrence

What the 5 Whys cannot replace

• Many branches at once. A Fishbone diagram groups possible causes into categories. 5 Whys drills one chain.
• Ranking many causes. The 80/20 Rule asks which few items dominate a counted result. 5 Whys explains one chain.
• Fact completeness. 5W1H scans who, what, when, where, why, and how. It does not force a structural cause.
• An improvement cycle. PDCA tests a change over time. 5 Whys is diagnosis before or beside that cycle.
• A guarantee in a complex system. Several interacting causes may need a map first. A linear chain can still be useful, but it is not a full system model.

Honest scope: 5 Whys structures a cause chain and an action focus. It should not be sold as complete root-cause discovery.