Operations & process
Five Whys
A root-cause questioning discipline from the Toyota Production System: state the problem where it occurred, ask why of each verified answer in turn, work down from symptom through process causes to the system cause, and fix the deepest point where a countermeasure will hold.
Also known as 5 Whys, Why-why analysis, Five-why root cause analysis. First set out by Sakichi Toyoda (attributed); formalised by Taiichi Ohno at Toyota in 1988.
Where this is contested
Toyota tradition credits Sakichi Toyoda with the practice, but the attribution rests on company lore rather than documents: no primary source from Toyoda describes the method, and the earliest substantive written account is Ohno's, published in Japanese in 1978 and in English in 1988.
- Format
- Process / loop
- Level
- Team
- Best for
- Plan execution · Assess risk
- Decision stage
- Diagnose · Review
- Difficulty
- Introductory
- Time to apply
- Thirty to sixty minutes at the place the problem occurred; longer where answers need verifying with data.
Plate · The model
The components
Why 1: behind the symptom
The first why converts the visible failure into its immediate cause, a technical or physical fact observable at the scene. It establishes the discipline for the whole chain: facts, verified where the work happens.
Signals of strength
The answer is observable and checkable at the scene · It names a thing or an event rather than a person · The problem statement it explains has a magnitude attached
Why 2: the immediate cause
The second why asks what produced that technical fact. The answer usually still lives close to the equipment or the task, and it is the last point at which the chain can honestly stay technical.
Signals of strength
The answer explains the mechanism, how the fault physically arose · Evidence, a measurement or an inspection backs it · It would satisfy an engineer but not yet prevent recurrence
Why 3: the process cause
The third why typically crosses from the technical into the way the work is organised: a procedure, a schedule, a maintenance routine or a method that allowed the immediate cause to occur.
Signals of strength
The answer describes how work is set up rather than what broke · Variation between people or shifts appears in the evidence · A written standard exists and was unclear, wrong or unfollowed, or no standard exists at all
Why 4: the system cause
The fourth why reaches the management system behind the process gap: how standards are set, how training happens, how maintenance is planned, how changes are introduced. This is usually where responsibility becomes organisational rather than individual.
Signals of strength
The answer implicates a decision, policy or omission above the team · Fixing it would prevent a family of problems, this one included · The room goes quieter, because the cause now belongs to management
Why 5: the root cause
The final why lands on the missing or broken standard whose correction prevents recurrence. A sound root cause is actionable, at process level, and passes the backwards 'therefore' test all the way up to the original symptom.
Signals of strength
The countermeasure is a changed process, never a reminder to be careful · Read backwards, every link follows with 'therefore' · Correcting it would have prevented this occurrence and will prevent the next
When it earns its keep
- An operational problem keeps recurring despite being 'fixed', which is the signature of countermeasures applied at symptom level.
- A failure has a plausibly linear causal chain, one thing leading to another through equipment, procedure and management system, as most shop-floor and service-delivery problems do.
- A team defaults to blaming individuals and you need a structure that walks the conversation past the person to the process that set them up to fail.
- You are running kaizen or a PDCA cycle and need the plan stage grounded in a cause rather than a hunch.
And when it doesn't
- The failure is complex and multi-causal, such as a serious safety incident or a systems outage with interacting contributors. Five whys forces a single pathway; use a fishbone diagram, fault tree or a formal investigation method instead.
- The answers cannot be verified by observation or data. A whys chain built on conjecture in a meeting room is a story, and stories converge on whatever the loudest voice already believed.
- The subject is statistical rather than event-based, such as gradual yield drift, where the cause is a distribution to be analysed rather than a chain to be walked.
- The real purpose is allocating blame. The method's output is a process countermeasure, and used as an interrogation technique it produces defensiveness and fiction.
How to run it
Before starting, gather the inputs the analysis depends on:
- A precise, factual problem statement: what happened, where, when and how big, established at the place of work rather than from a report.
- Access to the people who do the work and to the scene of the problem, since each answer should be verified by observation.
- Data or physical evidence to test each proposed cause, so the chain rests on facts rather than plausible guesses.
- Enough organisational honesty to follow the chain into management systems, because that is where it usually ends.
- 1
Go and see, then state the problem
Define the problem at the place it occurred, in observable terms with a magnitude. 'The June issue shipped three days late' can be investigated; 'delivery performance is poor' cannot. Toyota practice starts at the gemba for exactly this reason.
- 2
Ask the first why and verify the answer
Ask why the stated problem happened and accept only an answer that can be checked against evidence at the scene. The first answer names the immediate cause, and it is nearly always a fact about equipment, materials or a task, never about a person's character.
- 3
Ask why of each verified answer in turn
Treat each answer as the next question's subject, moving one causal link at a time. The chain should deepen from the technical, through how the work is organised, into the management system that shaped it. Skipping levels is how chains arrive at convenient answers.
- 4
Read the chain backwards with 'therefore'
Test the logic by reversing it: the root cause, therefore the system gap, therefore the process fault, therefore the symptom. If any link does not follow, the chain has a gap or a guess in it, and the questioning resumes there.
- 5
Stop at a cause you can change, at process level
Five is a guide rather than a rule. Stop when the answer is a missing or broken standard whose correction would prevent recurrence, and keep going if the current answer still describes a symptom or a person. 'Operator error' is never a stopping point.
- 6
Countermeasure and confirm
Implement a countermeasure at the root, then watch for recurrence, which is the only test that matters. This closes naturally into a PDCA cycle: the whys chain is the plan stage's hypothesis about cause.
Reading the result
A verified causal chain from symptom to root cause, a countermeasure aimed at the deepest changeable link, and a check for recurrence. The chain itself, written down, is also a teaching document about how the process really works.
- Judge the chain by its last link. If the final answer is a person, the analysis stopped early; if it is a missing or unmaintained standard, it probably reached the right depth.
- The count is a guide. Some chains resolve honestly in three whys and some need seven; what matters is that each link is verified and the chain moves from symptom through process to system.
- One chain is one pathway. If the problem plausibly has several contributing causes, expect to run several chains and prioritise between the roots, rather than pretending the first chain found the only truth.
A worked example
A Leeds commercial printer chases a repeated late delivery
A trade printing firm in Leeds has delivered a monthly magazine contract late two months running, and the client is threatening to retender. The account manager blames the press crew. The production director instead runs a five whys session at the press with the minders, starting from the verified fact: the June issue shipped three days late.
- Why 1: behind the symptom
- Why did the June issue ship late? The main run had to be partly reprinted after 20,000 copies were rejected for colour misregistration. Verified against the job ticket and the waste records; the crew worked the reprint overnight, which sits awkwardly beside the account manager's theory of carelessness.
- Why 2: the immediate cause
- Why did the run misregister? Register drifted mid-run as web tension varied on the second unit. The press log shows tension alarms clustering around reel changes, so the mechanism is established by data rather than recollection.
- Why 3: the process cause
- Why did web tension vary? Reel splices were being prepared differently by each minder; two of the five splices that shift failed the tension check. Observation at the reelstand confirms three distinct splicing techniques in use across the crew.
- Why 4: the system cause
- Why were splices prepared inconsistently? The splice procedure was never updated when the new reelstand was installed in January. The written standard still describes the old equipment, so each minder adapted individually and nobody was wrong to.
- Why 5: the root cause
- Why was the procedure not updated? The firm has no step linking equipment changes to revision of standard work and retraining; commissioning ends at mechanical handover. Read backwards, the chain holds: no update trigger, therefore an obsolete standard, therefore improvised splices, therefore tension variation, therefore misregister, therefore a late issue.
The read. The countermeasure lands at the system: the commissioning checklist gains a standard-work revision and retraining step with a named owner, and the splice procedure is rewritten with the minders at the reelstand. The blamed press crew turn out to be the people the system had abandoned. The director also notes honestly that this was one pathway; a second chain, asking why 20,000 copies ran before quality control caught the fault, deserves its own session, which is precisely the single-path limitation critics raise.
Pitfalls
- Stopping at human error. 'The operator made a mistake' is where the analysis should accelerate, by asking why the process allowed the mistake, never where it should stop.
- Answering from a meeting room. Chains built on recollection and plausibility drift towards whatever the group already believed; each link needs verifying where the work happens.
- Forcing one chain through a multi-causal problem. When several factors contribute, run several chains and prioritise between the roots, or switch to a method built for complexity.
- Treating five as a rule. Stopping early leaves a symptom dressed as a root; grinding on past the actionable cause produces philosophy ('why does the company exist?') rather than a countermeasure.
- Skipping the confirmation. A whys chain is a hypothesis until the countermeasure is in place and the problem has stayed gone; recurrence is the only verdict that counts.
What the critics say
The method's structure is its weakness in complex systems. Card argues it forces investigators down a single analytical pathway, insists on a single root cause, and assumes the most distal link in the chain is the best place to intervene, none of which holds for multi-causal failures, and he recommends retiring it for serious incident investigation.
Card, A. J. (2017) 'The problem with 5 whys', BMJ Quality and Safety, 26(8), pp. 671-677.
Criticism comes from inside Toyota's own tradition. Teruyuki Minoura, formerly head of global purchasing, warned that the technique is too basic on its own and that practitioners tend to reason by off-the-cuff deduction rather than by observation at the workplace, producing chains that reflect assumption rather than fact.
Minoura, T. (2003) 'The "Thinking" Production System: TPS as a winning strategy for developing people in the global manufacturing environment', Toyota Motor Corporation, October 2003.
The method is bounded by the questioner's knowledge and is not repeatable: investigators cannot surface causes they do not already understand, and different teams analysing the same problem routinely produce different chains and different roots, which sits uneasily with the method's claim to find the cause.
Sources and further reading
- Ohno, T. (1988) Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press. First published in Japanese, 1978.
- Liker, J. K. (2004) The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. New York: McGraw-Hill.
- Minoura, T. (2003) 'The "Thinking" Production System: TPS as a winning strategy for developing people in the global manufacturing environment', Toyota Motor Corporation, October 2003.
- Card, A. J. (2017) 'The problem with 5 whys', BMJ Quality and Safety, 26(8), pp. 671-677. ↗