The 5 Whys: a practical how-to

What conditions lie behind this particular explanation?

The 5 Whys is a simple way to explore a possible causal path: ask why something happened, check the answer, then explore the conditions behind it. Five is a prompt—not a guaranteed route to one root cause. You may need fewer or more questions, several branches, or a different investigation approach.

Use it within an evidence-led investigation, not as an interview technique for finding someone to blame. For the wider process and diagrams, see the root cause analysis guide.

How to run a 5 Whys

Start with a specific problem. State what happened, where and when, and how it differed from what was expected. Do not build an assumed cause into the statement.
Involve people who know the work. Establish the sequence using records, observation and accounts from those involved. Ask what made an action or outcome possible, not “Why did you fail?”
Ask why—and check the answer. Record the proposed explanation, supporting and conflicting evidence, and what remains unknown. A plausible answer is not a fact.
Explore each supported path. Ask what conditions lay behind the answer. Where more than one contributor is plausible, draw separate branches rather than forcing them into a single chain.
Pause when evidence runs out. Assign someone to gather the missing information. “We don’t know yet” is better than an invented answer.
Summarise what you can act on and test. Keep uncertainties visible and connect a proposed change to a supported explanation. Do not stop merely because you have reached five questions—or continue until you can name a senior manager.

Worked example: a late customer order

Problem statement: order A was promised for Tuesday but arrived on Thursday.

This is an invented, non-clinical illustration. The records described below are evidence you would need to obtain in a real investigation, not findings from an actual business.

Question	Illustrative answer	Evidence needed before accepting it
1. Why did the order arrive late?	It missed the planned carrier collection and went on the next available service.	Compare the agreed date, collection booking, dispatch scan and delivery record. Check for carrier delays too.
2. Why did it miss collection?	It was not ready when the carrier arrived.	Check production completion, packing and collection timestamps. Talk with dispatch staff.
3. Why was it not ready?	It needed rework after being made to an outdated specification.	Compare the product, rework record and approved customer specification. Check when the discrepancy was found.
4. Why was the outdated specification used?	An earlier copy was still available at the workstation and was selected.	Inspect the copies available at the time and reconstruct how the job information was selected.
5. Why was the earlier copy still available?	The update process added a new version without withdrawing or clearly superseding the old one.	Review version history and the update workflow with those using it. Check other jobs to see whether this is a wider vulnerability.

Branch rather than force the story: readiness could also have been affected by unavailable material or an equipment interruption. Investigate these as separate paths if evidence makes them plausible. The promised date or collection plan may also have been unrealistic; do not assume either was sound.

Pause if you cannot check an answer. If version history is missing, record the uncertainty and gather other evidence. Do not call the fifth answer “the root cause” just because it completes the chain.

Possible test: if the version-control explanation is supported, trial a controlled source of approved specifications and a reliable way to supersede old copies. Check use of the current version, rework, on-time delivery, access difficulties and extra workload. This may address one pathway without explaining every late order.

Limits and when to stop

One chain is not the whole system. Several interacting conditions can contribute to the same outcome. Use a fishbone, timeline or specialist method when a single chain hides the important relationships.
Different teams can reach different answers. Make the evidence and reasoning visible; do not select an explanation by confidence, seniority or agreement alone.
Have we stopped at the obvious explanation? “Someone made a mistake” or “the procedure wasn’t followed” may describe what happened without explaining the conditions behind it. Would another person face the same difficulty? Explore Joiner’s levels of fix → Follow the evidence—not a prescribed level or a search for someone to blame.
Stop to investigate, not to satisfy a number. Pause when evidence runs out, branches need specialist work, or the next question becomes speculation. You can test a supported contributor while recognising that the explanation remains incomplete.
Respond proportionately to risk. Serious concerns may require immediate protective action and formal investigation after a single event. Do not wait for repetition or rely on a brief 5 Whys exercise where a more rigorous response is required.

Test the response—not just the story

Agree what you expect the change to achieve, how you will know it was implemented, what harm to watch for and when to review it. Include the people affected and use appropriate safety and approval processes.

A suitable chart or Bootstrap CUSUM analysis may help identify a performance change. A change point does not confirm the causal chain or prove that the intervention caused the result. Consider other changes, implementation, data quality and variation. No detected change does not automatically mean the idea had no benefit.

Right intervention? →
Right measures? →

Use the tools for different questions

Systems thinking examines parts and relationships. RCA organises an evidence-led investigation. The 5 Whys explores a particular explanatory path. Feedback loops examine how consequences return to influence what happens next.

These are complementary tools—not mandatory stages.

Return to the practical RCA guide and templates →