# 5 Whys

**URL:** https://kaizumi.com/dictionary/5-whys

**Description:** 5 Whys traces a problem down to a cause you can change. Ohno's machine example took 5 rungs. Five is a count, not a stop rule.

**Japanese:** なぜなぜ分析 (naze naze bunseki) — "why-why analysis"

**Category:** lean-tools

**Tags:** problem-solving, foundational

## The chain | How the 5 Whys method works

To use the 5 Whys, you start with a specific problem and ask why it happened. When you get an answer, you ask why that happened too. You repeat this step until you find a root cause that you can actually fix.

Asking the question is easy. Finding the real answer takes honest investigation. When a 5 Whys analysis fails, it is almost always because someone guessed at an answer instead of checking the facts.

Sakichi Toyoda started using this approach at Toyota Industries. Later, Taiichi Ohno built it into the Toyota Production System and described it as the foundation of Toyota's scientific approach to work. The most famous example comes from Ohno, when a piece of equipment broke down on the shop floor:

1. **Why did the machine stop?** An overload blew the fuse. **Go and see:** the blown fuse in the panel, and the overload trip on the drive.
2. **Why was there an overload?** The bearing did not get enough oil. **Go and see:** the bearing itself. Dry metal, heat colour, scoring.
3. **Why did the bearing not get enough oil?** The lubrication pump was too weak. **Go and see:** oil arriving at the delivery point, measured against the pump's rated flow.
4. **Why was the pump too weak?** Its shaft had worn, and it rattled. **Go and see:** the shaft out of its housing, with a gauge on it.
5. **Why had the shaft worn?** Nobody fitted a strainer, so metal scrap got into the pump. **Go and see:** the empty strainer housing, and the scrap in the oil.

If you only read the questions, the process looks simple. But the real work is in the answers. Each step is a statement of fact that someone checked in the place where it happened.

You can use the exact same process in an office or a hospital. For example, suppose a patient waits `40` minutes for a discharge letter. Why? The doctor has not signed it yet. Why? She is currently on her morning ward round. Why? The letter only arrived in her queue after she started her rounds. Why? The pharmacy review only happens once a day at `11am`. That final answer points to a schedule that people chose, which means people can change it.

The most important part of each step is checking the real situation for yourself. Verifying the facts on the ground is what keeps you from making assumptions. That is why [gemba](/dictionary/gemba), going to the actual place where the work happens, is essential to this method. The 5 Whys is one of the most direct tools in [root cause analysis](/dictionary/root-cause-analysis), and the [field guide](/guides/five-whys-root-cause-analysis) walks through a complete example step by step.

## The ladder | What stopping early costs you

You could choose to stop asking questions at any step in the chain. But each stopping point leads to a completely different fix, and each fix gives you a different outcome.

You can look at Ohno's example as a list of questions, or you can look at it as a list of costs:

| The rung you stopped on | The fix it implies | What it buys you |
|---|---|---|
| Why 0 — the machine stopped | Restart it | Nothing. It stops again on the same shift, for the same reason. |
| Why 1 — the fuse blew | Fit a new fuse, or a bigger one | A bigger fuse removes the only guard on the motor. The next failure costs far more than a fuse. |
| Why 2 — the bearing ran dry | Grease it by hand, put it on a checklist | A manual task, forever. The pump still fails, and now somebody is paid to hide it. |
| Why 3 — the pump was weak | Rebuild or replace the pump | A few quiet months. The new pump wears the same way, because the scrap is still in the oil. |
| Why 4 — the shaft was worn | Replace the shaft | A spare shaft carried on a schedule. You have started budgeting for the symptom. |
| Why 5 — no strainer fitted | Fit a strainer | Scrap never reaches the shaft. Every rung above this one stops happening. |

```kz-figure
id: ladder
caption: Five of the six stopping points buy the same thing: a cost that comes back. Only the bottom rung ends the chain.
wide: true
```

Look at the third column. The fixes for steps `1` through `4` all create ongoing work or recurring expenses. You end up having someone grease a part manually every week, or ordering replacement shafts on a regular schedule, or adding another item to a daily inspection sheet. Only the final step actually gets rid of the problem.

At first glance, surface-level fixes look quick and cheap. Replacing a fuse costs very little money. But over a year, temporary fixes become expensive because the issue keeps returning. By contrast, you only have to buy and install a strainer once. Stopping early might feel like you solved the issue quickly, but it usually costs far more in the long run.

The step where you stop shows how permanent your solution really is. Before you decide to finish an investigation, write down how much your proposed fix will cost and how long you will have to keep paying for it. A [maintenance programme](/dictionary/total-productive-maintenance) built out of rung-2 fixes costs money every year and never removes the problem.

It helps to write two numbers next to your solution: what it costs to do right now, and what it will cost each year to maintain. When a team sees both numbers, they rarely settle for an incomplete fix at step `2`.

## Stopping | When to stop a 5 Whys chain

You should stop asking why when you find a root cause you can control and prevent from happening again. You do not stop simply because you reached five questions.

Ohno reached a missing strainer at step five because that specific mechanical failure had five steps. Five is not a universal rule. If a problem only has three causes in its chain, forcing yourself to ask five questions will make you invent two extra steps that are not there. Alan J. Card summarized this issue in BMJ Quality & Safety in 2017:

> "the arbitrary depth of the fifth why is unlikely to correlate with the root cause"

Use these three tests to decide when your chain is complete, rather than counting the number of steps:

1. **The chain works in reverse.** Read your chain backward using the word "therefore." Each step should make logical sense on its own. For example: We fit a strainer, therefore scrap cannot enter the pump, therefore the shaft does not wear down, therefore the pump works properly, therefore the bearing gets oil, therefore the motor does not overload, therefore the fuse does not blow, therefore the machine keeps running. If a step requires an unstated assumption to make sense, that is where your logic breaks down.
2. **You reached a process decision instead of a random event.** Events have causes, but process decisions can be changed directly. A root cause usually comes down to a policy, a standard, a schedule, or an omitted design requirement. Saying that nobody installed a strainer points to a specific choice. Someone either designed the pump without one or skipped the check during assembly.
3. **The cause is something you can actually change.** Sometimes a cause lies outside your control, such as a supplier's internal manufacturing process, a government regulation, or a corporate mandate from several management layers above you. When that happens, stop at the deepest step your team can directly change, and clearly note on your worksheet where the problem leaves your control. An issue that belongs entirely to another organization is a referral, not a root cause you can fix yourself.

The first test is the quickest way to spot weak logic. It is especially useful when a step blames a person. For example: "We retrained the employee, therefore the bearing received oil." That statement skips the actual physical reason the oil stopped flowing, which shows the chain is incomplete.

Run all three tests before closing an investigation. If your chain fails any of these tests, it is not finished, and the problem will likely happen again.

```kz-figure
id: therefore
caption: Read down with "why?". Read back up with "therefore". The amber rung is true and still wrong: three shifts did not wear the shaft.
```

```kz-callout
tone: warn
title: A rung that names a person has left the process.
p: If a rung reads `human error`, `lack of training` or `management`, back up one rung. Ask what made that the reasonable thing to do at the time. The chain has stopped at a verdict, and a verdict has no next question.
```

## Bad rungs | Four ways 5 Whys goes wrong

A step in your analysis can sound completely reasonable while still leading your team in the wrong direction. There are four common mistakes to watch out for, and all four can happen on Ohno's own machine chain.

The [5 Whys builder](/tools/5-whys) helps you spot these four patterns during your analysis. This page, the tool and the field guide all work from one list, not three.

| The bad rung | What it sounds like | Why it ends the chain | The rewrite |
|---|---|---|---|
| It blames a person | "The operator let the bearing run dry." | The only next question is why this person is bad, and that has no useful answer. The chain stops at a name. | "The bearing did not get enough oil." Now ask why the oil was not arriving. |
| It is a fix in disguise | "The pump needs a maintenance checklist." | That is something to do, not something that was wrong. It also arrived before anyone opened the pump. | "The lubrication pump was too weak." Hold every fix until the chain bottoms out. |
| It is too vague to see | "The equipment is getting old." | It explains every failure on site and repairs none of them. You cannot walk over and look at "old". | "The pump shaft had worn." A shaft you can pull and measure. |
| The link does not hold | "The plant runs three shifts." | True, and not what wore the shaft. A correct statement in the wrong place reads fine and quietly ends the chain. | Delete it. Only the backward "therefore" read catches this one. |

The first three mistakes usually happen when people try to solve a problem in a meeting room instead of looking at the actual work area. If you go directly to the work area, blaming a person turns into looking at what physical condition failed, jumping to a solution turns into observing what is actually happening, and vague statements turn into specific measurements.

The fourth mistake is different because you cannot catch it just by looking at the equipment or workspace. You can only catch it by reading the chain backward with "therefore" to see if the logic actually holds up.

Two of these mistakes point toward other practical tools. If a step points to an individual person, the solution is not to demand better behaviour. The solution is to design a process that prevents mistakes from happening, which is the goal of [poka-yoke](/dictionary/poka-yoke), or mistake-proofing. If a step suggests adding a routine checklist, that task usually belongs in your team's documented [standard work](/dictionary/standard-work).

You should apply those tools after you understand the root cause, not instead of doing the analysis. If you are not sure whether a step is a verified fact or just an assumption, do a [gemba walk](/dictionary/gemba-walk) to go and see for yourself.

If you spot a bad step during a meeting, you do not need to discard the whole session. Simply cross that step out, write down the verified fact instead, and continue your questions from there.

## Proof | Why two 5 Whys give different answers

Two different teams can look at the exact same breakdown and reach completely different conclusions. The reason is arithmetic.

A step can follow the correct format and still be factually incorrect. Sounding plausible is not the same as being true, and you cannot verify the truth by sitting at a desk.

Suppose that at each step of your analysis, there are three possible explanations that sound plausible. Three is what the field guide gives you at each step, and a real team usually produces more. Three plausible answers at each of the five steps creates `3 × 3 × 3 × 3 × 3` = `243` possible five-step chains.

Only one of those paths matches what actually happened in the physical workspace. The other `242` paths contain at least one incorrect assumption. If your team relies only on what sounds reasonable in a meeting, your chance of finding the true root cause is `1` in `243`, or roughly `0.4` percent.

You can easily eliminate the wrong paths by checking the facts at each step. At every question, list the two or three most likely answers. Then go to the work area, look at the evidence, and eliminate the answers that do not match reality. One trip removes two of the three answers, and the `243` chains collapse to one.

Treat this calculation as a shape, not a measurement of your own team. Nobody has counted the plausible answers on your whiteboard. What matters is what happens to the two counts as you go deeper. The wrong paths multiply at every step, while the number of right ones stays at one.

Toyota recognised this limitation itself. Teruyuki Minoura, a former Toyota managing director, pointed out that the 5 Whys can produce results that do not repeat. Same problem, different people, different cause. The `243` possible chains are the reason. Nothing in the method pushes two investigators onto the same branch, so plausibility does the choosing, and plausibility is personal.

```kz-callout
tone: note
title: The rule that makes a chain repeatable.
p: Do not write a rung down until you have gone and seen it. A verified rung has one answer, so two people who both go and look end up on the same branch.
```

That single rule makes the method work consistently. It is why going to the [gemba](/dictionary/gemba), the place where the work actually happens, is a practical requirement of the method rather than just a slogan.

You can build your own chain in our online tool. It checks each step as you write it and flags answers that blame people or jump straight to solutions.

<!--TOOL:5-whys-->

## Choosing | When not to use 5 Whys

The 5 Whys method works best when a problem follows a single, clear chain of cause and effect. If a problem has multiple contributing factors, you need a different approach.

A 5 Whys analysis follows a single path from start to finish. But many real-world problems branch off into multiple causes. If an issue has several causes and you only use a single 5 Whys chain, you will naturally overlook all the other branches.

Before you start asking questions, make sure the tool matches the kind of problem you have. Choose the right method for the situation rather than defaulting to the most familiar tool.

A 5 Whys analysis only takes a few minutes and one walk to where the work happens. That low cost is why it should be your first choice for simple, linear problems.

| What the problem looks like | The instrument |
|---|---|
| One break, one visible path | 5 Whys. Run the chain to the bottom, and price each rung before you stop. |
| Several conditions at once | A [fishbone diagram](/dictionary/fishbone-diagram) first. Map the width across categories, then run a why-chain down each bone that carries real evidence. [Build one](/tools/fishbone). |
| A gap you never closed | [A3](/dictionary/a3-problem-solving) and [PDCA](/dictionary/pdca). You are setting a target, not repairing a break. [Start an A3](/tools/a3). |
| A safety event | A structured method with independent review. One chain does not repeat well enough to carry that weight. |
| You do not know where to start | A [Pareto chart](/dictionary/pareto-chart) first. Rank the problems, then dig into the biggest one. [Chart it](/tools/pareto). |

When you understand where the 5 Whys fits, it stops competing with other methods. Root cause analysis is the discipline, and the 5 Whys is one of its simplest tools. It fits inside the analysis section of an [A3](/guides/a3-problem-solving) or the Check step of [PDCA](/guides/pdca).

This approach works the same way whether you are looking at a hospital ward, a warehouse aisle, or an insurance claims queue. The only thing that changes is the specific evidence you go to inspect.

## Answers | 5 Whys questions people ask

```kz-qa
q: Who invented the 5 Whys?
a: Sakichi Toyoda, who founded Toyota Industries, developed it. Taiichi Ohno spread it through the Toyota Production System and called it the basis of Toyota's scientific approach. The example everyone learns is Ohno's: a machine stopped, traced in five rungs to a missing pump strainer.
q: Why five whys and not four or six?
a: Five describes Ohno's machine example, where the causal path happened to be five links long. It is a count, not a stop rule. Stop instead when the chain reads back with "therefore" at every link, when the last rung is a decision somebody made, and when you still hold the lever to change it.
q: What is the difference between 5 Whys and a fishbone diagram?
a: A [fishbone diagram](/dictionary/fishbone-diagram) maps width. It lists every category of cause that could contribute. A 5 Whys goes down one path in depth. Use the fishbone when several conditions had to line up, find the paths that carry real evidence, then run a why-chain down each of those.
q: Can two people run 5 Whys on the same problem and reach different causes?
a: Yes, and it is the method's best-known weakness. Teruyuki Minoura raised it from inside Toyota. If each why has three plausible answers, five rungs allow 243 different chains, and only one matches the evidence. The fix is to verify every rung where the work happens before you write it down.
q: Is 5 Whys the same as root cause analysis?
a: No. [Root cause analysis](/dictionary/root-cause-analysis) is the discipline. 5 Whys is one of its simplest instruments. It sits inside larger methods, such as the analysis box of an A3 or the Check step of PDCA, instead of replacing them.
```

Source: https://kaizumi.com/dictionary/5-whys
Licence: free to quote and cite with attribution to Kaizumi.