For consultants getting past the first answer
5 Whys Template With Worked Examples
A 5 whys worksheet with a how-do-we-know column on every why, a stop rule, branching for two causes, and three worked client examples.
5 whys · Quotes take six days to go out (example)
Promise: two days · evidence on every why
- 1Quotes wait four of the six days for engineeringHow we know: time stamps on 120 quotes
- 2Every quote goes to engineering, even standard modelsHow we know: the quoting procedure; 70% are standard
- 3Sales can't tell which configurations are standardHow we know: five of six sales reps; the quote screen
- 4Root cause: the standard list is engineering-onlyFix: put the list in the quote screen · sales operations
What you'll get
Five whys with evidence, a stop rule, branching and worked examples
- A problem statement test, so the chain starts from a fact
- Five whys, each with evidence, plus a rule for when to stop
- Three worked client examples and three broken chains fixed
Before and after
Your problem in. A first chain to check out.
Repair visits needing a second trip are up to 18% from 8% last year. Techs say they often don't have the part. Ops manager thinks the new models are the issue. Not sure who updates the van stock.
Problem: 18% of repair visits in [period] needed a second trip, against 8% last year. Why 1: The technician didn't have the part. How we know: what technicians report, per your notes. Checked: not yet. Why 2: Why didn't the technician have the part? Possible answers to check: the van stock list misses parts for the new models (the ops manager's view, per your notes), or used parts aren't restocked. To confirm with the client: who updates the van stock list, and when it last changed.
The chain stops where your evidence stops. Possible answers are marked to check, never written as facts.
Why it works
What is the 5 whys, and when do you stop asking?
A 5 whys template helps you find a problem's root cause by asking why it happens, then why that happens, until you reach a cause you can act on. The Lean Enterprise Institute describes the 5 whys as asking why repeatedly to get beyond the obvious symptoms, with an example from Taiichi Ohno of Toyota. This worksheet starts with the problem stated precisely, then gives each why a "how do we know?" column, so every answer rests on evidence rather than opinion.
The hard part is knowing when to stop. Stop when the answer is something the client can act on and control, and fixing it would stop the problem coming back. Five is a guide, and some chains end at three. When an answer has two causes, the worksheet branches, because, as the IHI notes, there may be multiple root causes of one problem. Each branch gets its own chain and root cause, then a countermeasure with an owner, a date and a measure.
The examples doc works three client problems: slow customer quotes, new hires without working laptops, and repair visits that need a second trip. It also fixes three chains that went wrong. Paste the problem, and River drafts the whys your notes support and marks the rest as answers to check. For a problem with many possible causes, the root cause analysis template adds a fishbone first. To gather evidence from stakeholder interviews, interview synthesis counts who said what.
What lands in your doc
What's inside the 5 whys template
- A precise problem statement
What, where, since when and how big, with a weak and a strong example to check yours against. - Five whys with evidence
Every answer gets a how-do-we-know column and a checked box, then a read-back test from bottom to top. - The stop rule
Three checks that tell you when you've reached a root cause the client can act on and control. - Branching for two causes
Separate chains when one answer has two causes, so neither is dropped for the more convenient one. - Countermeasures
An owner, a date and how you'll know it worked, for every root cause the chain reaches. - Examples and mistakes
Three worked client examples, plus three broken chains fixed: a blamed person, a symptom and a guess.
How it works
How to run a 5 whys analysis
State the problem
Write what happens, where, since when and how big, against a target. Put no cause and no names in it.
Ask why, and prove it
Write each answer and how you know it. Mark beliefs not yet checked, and check them first. Optional: paste the problem for a first chain.
Branch, then stop
Follow each cause in its own chain when an answer has two. Stop when the client can act on the answer and fixing it would stop the problem coming back.
Fix and check
Give each root cause a countermeasure, an owner and a date, then track the number from your problem statement.
Questions consultants ask
Common questions
What is the 5 whys technique?
The 5 whys is a way to find a problem's root cause by asking why it happens, then asking why about each answer in turn. Taiichi Ohno's classic example follows a machine that stopped back to a pump with no strainer, which let metal scraps in. Five is a guide: stop when you reach a cause you can act on.
Do you always ask why exactly five times?
No. Five is a rule of thumb. Stop when the answer is a cause the client can act on and control, and fixing it would stop the problem coming back. Some chains reach that at three whys. If you're at five and the answer is still a symptom, such as late deliveries, keep going.
What are the most common 5 whys mistakes?
Three come up most. Blaming a person: IHI's root cause guidance treats individual performance as a symptom of larger systems-based issues, so ask why the process allowed it. Stopping at a symptom, such as "deliveries are late". And guessing: an answer nobody checked, with four more whys built on top of it.
What if the problem has more than one cause?
Branch. When one answer has two causes, such as laptops that arrived late and accounts that weren't set up, give each its own chain and follow both to a root cause. If the first why turns up many possible causes, widen the search with the fishbone in the root cause analysis template first.
When should I use 5 whys instead of an issue tree?
Use 5 whys for a specific, measurable problem inside a process, such as rework, delays or errors. For a broad business question, such as why profit fell across a whole company, an issue tree splits it into parts first. A 5 whys can then explain the part where the problem sits.
What if we don't know where in the process it goes wrong?
Map the process first. A SIPOC diagram shows the five to seven main steps, what goes in and what comes out, on one page. Then look at the numbers step by step to find where the problem appears, and start your 5 whys there, with that step's data as your first evidence.
Will River fill in the whys for me?
Only as far as your notes go. River writes the problem statement and the whys your notes support, each with where it came from. Where the evidence stops, it lists possible answers marked to check, never as facts. Under River's privacy policy, nothing you paste is used to train AI models.
Your next step
More for your project
Ask why until the client can act
Open the worksheet with three worked examples beside it, or paste the problem for a first chain to check.