2.2The 5 whys method
The essentials in 30 seconds
- 5 whys = dig layer by layer: each « why » goes past the symptom up to the actionable root cause.
- The « 5 » is indicative: stop when you hold a cause whose treatment prevents the return of the problem.
- Reflex: on verified facts, as a team — and switch to Ishikawa if the problem has several causes.
Running mini-case — Sara traces a delay's chain
A deliverable from Sara's workshop ships late. Instead of blaming the late person, she unrolls the « whys »: late validation… because the validator was absent… because there is no backup… because the role isn't planned… because the process was never formalized. The root cause is no person, it is the missing backup process.
Sequel to case 2.1 — Sara moves from the symptom (the delay) to the root cause.
1. A deceptively simple tool
The 5 whys method traces back to the root cause of a problem. Facing a problem, you ask « why? », then question the answer with a new « why? », usually five times (the number is indicative).
Each « why » digs one layer further, going past surface symptoms to find the real origin.
2. A classic example
Problem: « the machine stopped ». Why? A fuse blew. Why? The bearing lacked lubrication. Why? The pump worked poorly. Why? Its shaft was worn. Why? No filter, letting impurities in.
→ Root cause: the missing filter. Fixing the fuse (symptom) would have solved nothing; installing a filter (root cause) fixes it durably.
3. Strengths and limits
The strength: forcing you not to stop at the first explanation (often a symptom). Born in industry (Toyota system), it applies to any problem (technical, organizational, personal).
Its limits: it assumes correct answers (an error diverts the whole chain), and a problem may have several causes (there, an Ishikawa diagram complements better). Use it on facts, as a team.
🔎 Concrete example — Five whys on a delay
A deliverable handed in late.
Late. Why? Late validation. Why? The validator was absent. Why? No backup. Why? Role not planned. Why? Process never formalized.
→ Root cause: no backup process.Result: you act on the process, not the person.
Reflex: base each « why » on a verified fact.
Section vocabulary
- 5 whys
- Method of asking « why? » several times in a row to trace to the root cause.
Simple example: Sara unrolls five « whys » on her delay up to the missing process.
What it is not: asking one question then stopping at the first explanation.
Reflex: never stop at the first « because ».
- Root cause
- Deep origin of a problem, whose resolution prevents its return.
Simple example: the missing filter (machine) or backup (Sara's workshop).
What it is not: the blown fuse or visible delay, taken for the origin.
Reflex: test: does treating it prevent return?
- Causal chain
- A series of linked causes (each « why » reveals the previous one's cause) leading to the origin.
Simple example: late validation → absent → no backup → unplanned role → missing process.
What it is not: a list of unrelated excuses with no logical link.
Reflex: verify each link before digging the next.
- Surface symptom
- First visible explanation of a problem, to go past to reach the real cause.
Simple example: « the fuse blew » or « the deliverable is late ».
What it is not: the deep, actionable origin of the problem.
Reflex: treat the first answer as a starting point, not a conclusion.
- Toyota system
- Industrial origin of the 5 whys (Toyota production problem-solving method).
Simple example: the fuse-to-filter chain, born in industry.
What it is not: a trick reserved for technical problems only.
Reflex: also apply it to organization and coordination problems.
In practice — Tracing the cause with the 5 whys
- State the problem clearly, then ask « why does this happen? ».
- Question each answer with a new « why? », digging layer by layer.
- Continue (about 5 times) until you reach a root cause you can act on.
- Check the logic (each answer must be true); if the problem has several causes, complete with an Ishikawa.
Ready-to-say script — run the 5 whys (1 min)
« We're late. Rather than find who: why was validation late? And why was there no backup? We dig until we hold something actionable — a verified fact at each step. »
Say as a team facing a board: one column per « why », advance only on verified facts.
Copy-paste template — 5-whys chain
PROBLEM (symptom): _______________
WHY 1: _______________ (verified fact? yes/no)
WHY 2: _______________ (verified fact? yes/no)
WHY 3: _______________ (verified fact? yes/no)
WHY 4-5: _______________
ACTIONABLE ROOT CAUSE: _______________Small business / tight budget
Two people, ten minutes in a notebook: three well-verified « whys » beat five guesses.
Algerian SME
Delays tied to outages, travel or suppliers: verify each link (call, order, date) before concluding.
Team / workshop
Run with several: everyone challenges the answer (« proven or assumed? ») to avoid a biased chain.
Multi-cause problem
If two branches appear, stop and switch to Ishikawa (2.3), then dig each branch.
✓ Best practices
- Base each answer on a verified fact, not a supposition.
- Aim for an actionable cause whose resolution prevents the problem's return.
- Seek systemic causes, not a culprit (« why did the system allow this? »).
✗ Common pitfalls
- Stopping at the first explanation (often a symptom).
- Building the chain on false suppositions that divert everything.
- Ignoring that a problem may have several causes (prefer Ishikawa).
Key takeaways
- The 5 whys trace to the root cause by asking « why? » several times.
- Each « why » digs one layer further, going past surface symptoms.
- Solving the root cause fixes it durably; treating the symptom lets the problem return.
- Limits: assumes correct answers; a multi-cause problem is better handled with Ishikawa.
48h Challenge — apply tomorrow
Take 1 real problem and unroll the 5-whys chain (template above), each link backed by a fact. End with 1 action on the root cause.
- I unroll a « why » chain to the actionable.
- I back each link with a verified fact.
- I did the 48h challenge or planned its date.
Frequently asked questions
Why exactly five times?
The « five » is indicative: it often takes about five iterations to go past surface explanations, but the key is to dig to the root cause, whatever the number. Sometimes three suffice, sometimes seven are needed. You know you're there when you reach an actionable cause whose resolution prevents the problem's return. The real trap isn't doing too many or too few whys, but stopping at the first explanation out of impatience — which the method fights by forcing you to continue.
What are the limits of the 5 whys?
It assumes correct answers: an error along the way diverts the whole chain, so rely on facts. It follows a single linear chain, whereas a problem often has several causes — for those, the Ishikawa diagram (2.3), which maps all cause families, is better suited. It depends on who runs it (hence the value of a team) and may tempt you to blame a person instead of digging systemic causes. These limits invite using it on facts, as a team, and completing it with other tools.
What do the 5 whys look for?