Framework library · Decision making and problem solving
Five whys
Five whys traces a problem back through a chain of causes by asking why, again and again, until the answer is something the organisation controls and can fix. Five is a rule of thumb, not a quota: stop when the next why leads outside what anyone present can change. The method is quick and needs no data to start, which is both its strength and the reason each answer needs checking.
Use it when
- A specific problem keeps recurring and the fixes so far have treated symptoms.
- You need a quick first diagnosis before deciding whether a fuller investigation is worth it.
- A team disagrees about a cause and needs to lay out the chain one step at a time.
Avoid it when
- The problem has several independent causes. A single chain follows one and misses the others. Draw a fishbone diagram first.
- The problem is a pattern across many incidents. Count the causes with a Pareto analysis before chasing one of them.
- The failure is safety-critical. Use a structured investigation with evidence at every step. Five whys alone is not repeatable enough.
How to run it
State the problem precisely
What, where, when and how much: "one in six new customers cancelled within 90 days in the third quarter", not "churn is high".
Ask why and check each answer
Each answer should be a fact you can show, not an opinion. If it cannot be checked in the room, check it before asking the next why.
Keep asking until the cause is yours to change
Stop when the next why leads to something nobody here can change, or back to a cause already listed.
Test the chain backwards
Read it from the root cause up, joining each step with "therefore". If a step does not follow, the chain has jumped.
Fix the root cause and measure the result
Name an action with an owner, and the measure that will show it worked.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Stopping at a person ("the installer made a mistake"). Ask why the process let the mistake through.
- Following one chain when the problem has several causes. An answer can have more than one why; follow the ones the evidence supports.
- Answering from memory in the meeting. Without data at each step, different teams produce different chains for the same problem.
- Taking five as the rule. Some chains end at three; some need seven.
Where it comes from
Associated with Toyota and commonly credited to Sakichi Toyoda. Taiichi Ohno set out the practice of asking why five times in Toyota Production System: Beyond Large-Scale Production (Japanese edition 1978; English edition, Productivity Press, 1988). Source.
Use it with
Further reading
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.