The template
Problem statement: what happened, where, when and how much. Example: "Case labels missing on 9 pallets out of 140 shipped from Line 2 on Tuesday."
| Why | Question | Answer | Evidence (how we confirmed it) |
|---|---|---|---|
| Why 1 | Why did the problem happen? | ||
| Why 2 | Why did that happen? | ||
| Why 3 | Why did that happen? | ||
| Why 4 | Why did that happen? | ||
| Why 5 | Why did that happen? |
| Close-out | Entry |
|---|---|
| Root cause | The last answer: a cause in the process, within the team's control |
| Check backwards | Read from the root cause up using "therefore". Does it hold? |
| Countermeasure | What changes so the cause cannot recur |
| Owner and due date | One name, one date |
| Verification | The measure that will show it worked, and when it is reviewed |
Print it, copy it to a whiteboard or use it as the analysis box of an A3 report.
How do you fill in a 5 whys template?
Start with the problem statement and do not move on until it has a number in it. "Labelling problems" cannot be analysed; "9 of 140 pallets with no case label on Tuesday" can.
Ask the first why at the process with the people who run it. Write the answer as a fact, then fill the evidence column: what someone saw, measured or found in a record. If nobody can say how the answer was confirmed, go and check before asking the next why.
Each answer becomes the subject of the next question. Keep to one chain. If an answer splits into two causes, run a second column for the second branch rather than mixing them.
Stop when the answer is a cause in the process that the team can change, and that would stop the problem if fixed. That may be at the third why or the seventh. Five is a guide, not a rule.
How do you know you have found the root cause?
Three tests. First, read the chain backwards with "therefore": the label printer ribbon was not on the changeover checklist, therefore it was not changed, therefore it ran out mid-shift, and so on up to the problem. If any step does not follow, the chain is broken. Second, the root cause sits in a process, a standard or a system, not in a person. Third, removing the cause would have prevented this occurrence and will prevent the next one.
What are the common mistakes?
- Stopping at a person: "operator error" or "forgot" is where the next why starts, not where it ends.
- Guessing in a meeting room instead of confirming each answer at the process.
- Forcing one chain when the problem has several causes. Use a fishbone diagram to spread wide first, then 5 whys on the likely causes.
- Ending on something outside the team's control, such as the supplier or the weather, without asking why the process is exposed to it.
- Writing a countermeasure that is a reminder or a retraining session. If the fix relies on people remembering, the cause is still there.
When should you use 5 whys instead of a fishbone or an A3?
| Situation | Tool |
|---|---|
| One clear chain, small problem, the team can fix it | 5 whys |
| Many possible causes, nobody agrees which | Fishbone, then 5 whys on the likely ones |
| Large, cross-functional or repeating problem | A3, with 5 whys in the analysis section |
| Safety incident or customer complaint needing a formal record | Corrective action (CAPA), with 5 whys as the root cause step |
5 whys and daily management
The 5 whys works best close to the problem. When a measure on the tier board goes red, the team leader runs a short 5 whys at the board with the people on shift, the countermeasure goes on the action list with an owner and date, and the next huddles show whether the measure recovers. Problems that the team cannot solve at its level are escalated to the next tier with the 5 whys attached, so nobody starts again from scratch.
Step by step
- Write the problem statement. What, where, when and how much, with a number in it.
- Go to the process. Run the 5 whys with the people who do the work, where the problem happened.
- Ask why and record evidence. Write each answer as a fact and note how it was confirmed before asking the next why.
- Stop at a process cause. Stop when the answer is a cause in the process that the team can change.
- Check backwards. Read the chain from the root cause up with 'therefore'; fix any step that does not follow.
- Set and verify the countermeasure. One owner, one date and a measure reviewed at the next huddles.
A worked example
A packing line found case labels missing on 9 of 140 pallets. Why? The printer stopped printing for 40 minutes mid-shift; the reject log confirmed it. Why? The ribbon ran out. Why? It was not changed at the start-of-shift changeover. Why? Changing the ribbon is not on the changeover checklist, so it depends on the operator noticing it is low. Root cause: the changeover standard does not include the ribbon. Countermeasure: add a ribbon check with a minimum-length mark to the checklist, owned by the shift lead by Friday. Missing labels were tracked on the tier board for four weeks with no repeat.