Lean teams use it because it is quick and needs little training or software. It pushes teams to fix the process instead of blaming people or patching symptoms.
Where it comes from
The technique is credited to Sakichi Toyoda and was promoted by Taiichi Ohno within the Toyota Production System.
At a glance
Asking why until the cause is fixable
Swipe sideways to see the whole diagram.
How to apply 5 Whys
- 1
Define the problem precisely
Write a specific, factual problem statement. Include what happened, where and when.
- 2
Gather the right people
Include people who do the work and saw the problem. Go to the gemba if you can.
- 3
Ask why and record the answer
Answer with facts you can verify. Each answer becomes the subject of the next why.
- 4
Keep going until it is actionable
Five is a guide, not a rule. Stop when you reach a process cause you can control and fix.
- 5
Verify the chain
Read the chain backward using "therefore" to check the logic. If a link fails, revisit it.
- 6
Act and follow up
Put a countermeasure on the root cause and confirm the problem does not return.
Worked example (illustrative)
A machine stopped because a fuse blew. The fuse blew because the motor overloaded, which happened because a bearing lacked lubrication. The lube pump intake had no strainer and clogged, so the fix is adding a strainer and a check to the PM schedule. The press had stopped 3 times that month for the same fuse. After the strainer went in, it ran the next quarter with no repeat.
Common mistakes
- Stopping at human error, such as "the operator forgot", instead of asking why the process allowed it.
- Following a single chain when the problem has several contributing causes.
- Accepting guesses as answers without checking them against data or the gemba.
When 5 Whys is not the right tool
Five whys follows one chain of cause. Problems with several interacting causes need a fishbone diagram or a fuller investigation.
The answers also depend on who is in the room. Check each answer with data or at the gemba before you act on it.
Branching whys
When an answer has more than one cause, split the chain. Each branch gets its own series of whys, which turns the list into a small tree.
Stop when you reach a cause you can act on that would prevent the problem returning. The number five is a guide, not a rule.
A five whys example outside the factory
This example is illustrative. Problem: 14 of last month's 120 customer invoices were paid more than 30 days late.
Why 1: the customers received those invoices late. Why 2: the invoices went out about 10 days after delivery. Why 3: they waited for a signed delivery note. Why 4: drivers hand in notes only at the end of the week. Why 5: there is no way to send a note on the day of delivery.
Root cause: delivery notes reach accounts once a week. Countermeasure: drivers photograph the signed note in the delivery app, and accounts invoice the same day. The next month, 3 of 118 invoices are paid late.
A five whys template
Problem statement: what happened, where, when and how often, in one sentence.
Then up to five rows, each with the why, the answer and the evidence that the answer is true, such as a log, a count or an observation at the gemba.
Finish with the root cause, the countermeasure, its owner and date, and how you will check that the problem has not returned.
Rewriting a chain that blames a person
A weak chain reads: the order was shipped to the wrong address, because the clerk typed it wrong. It stops at a person, so the only fix is to tell people to be careful.
Ask why the process allowed it instead. The clerk retyped the address from an email, because the order form does not feed the shipping system. The countermeasure is to link the two, so nobody retypes the address. That fixes the process, not the person.
Guides on this topic
- Root cause analysis example: 6 worked samples and a templateA root cause analysis example for six settings, from a machine stoppage to warehouse picking errors, plus root cause statement wording and common mistakes.Read the guide
- How to write an A3 report: step by step, with an exampleHow to write an A3 report section by section, with a worked A3 example and the coaching questions that turn A3 problem solving into learning.Read the guide
- Kaizen event: meaning, steps and a 3-5 day agendaA kaizen event is a focused workshop that improves one process in 3-5 days. Learn the meaning, roles, agenda, steps, measures and common mistakes.Read the guide
- Process improvement methodologies: 9 methods comparedProcess improvement methodologies compared: PDCA, lean, kaizen, Six Sigma, TQM, theory of constraints, BPR and retrospectives, with how to choose and combine.Read the guide
Sources
Books and papers show their publication year. Web pages show the month we last checked them.
- 1.Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988)
- 2.Durward K. Sobek II and Art Smalley, Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System (Productivity Press, 2008)