Problem Solving & Quality · Root Causes

5 Whys

Ask “why?” again and again from the verified symptom, checking each answer with facts, until you reach a cause you can act on.

Time30 min
FormatSmall group
StageRoot Causes

5 Whys: what it is and why it works

The 5 Whys method starts from a verified deviation and asks why it happened, then why that answer happened, and so on, until it reaches a cause that can be acted on and whose removal would prevent recurrence. Each answer is written as a checkable statement and verified with a fact before the next why is asked; if it cannot be verified, the team branches or goes to look. The finished chain is read backwards with 'therefore' to test that every link holds.

The method is powerful because it is simple and because it pushes past the first physical explanation, such as a broken pin or a blocked filter, toward the condition that allowed it. Its weakness is that it follows one chain at a time and rewards confident storytelling: without fact checks, two teams can reach two different root causes from the same symptom. That is why verification at each step is not optional. It works best on problems with a fairly linear causal path. For wide, multi-cause problems, start with an Ishikawa diagram and apply 5 Whys to the verified branches; for escapes, run the three-path version, which also asks why the defect was not detected and why the system allowed it.

What you need

A verified deviation statement
Access to records, equipment and people to verify each answer
Facts already gathered: Is / Is-Not table, timeline, preserved evidence
A facilitator who insists on evidence for every link

What you get

A causal chain from symptom to actionable root cause, with evidence for each link
Any branches where more than one cause contributed
A root-cause statement the team can act on
A backward 'therefore' check confirming the logic

When to use it

When the fix treats the symptom and the same failure comes back next month.

How to do it, step by step

Start from the verified deviation, not from an opinion about it.
Ask why it happened and write the answer as a checkable statement.
Verify the answer with a fact before asking the next why; if it is unproven, branch or go and look.
Continue until you reach a cause that, if removed, would prevent recurrence and that you can act on.
Read the chain backwards with “therefore” — every link must hold.

Worked example: Repeated low-flow trips on a cooling-water pump

Illustrative scenario — figures are realistic but not from a real company.

At a specialty chemicals plant, the cooling-water pump serving a reactor jacket trips on low flow twice in one month. Each time, maintenance cleans the suction strainer and restarts the pump. The reliability engineer is asked to find out why it keeps happening.

Why did the pump trip? The low-flow protection acted because the suction strainer was heavily blocked, verified by the strainer differential-pressure trend and photos from the last cleaning.
Why was the strainer blocked? It was packed with biological slime and scale flakes, verified by lab analysis of a sample the technician kept.
Why was there so much biofilm? Biocide dosing to the cooling tower had been cut by half two months earlier, verified in the water-treatment program log.
Why was dosing cut? A cost-reduction review lowered the rate without looking at microbiological monitoring data, verified in the change request, which had no technical sign-off.
Why could the change skip technical review? The plant's management-of-change (MOC) procedure did not cover water-treatment chemical programs. That cause is within the plant's control and can be acted on.

Result. Read backwards (MOC gap, therefore unreviewed dosing cut, therefore biofilm, therefore blocked strainer, therefore trip), every link held. The plant restored dosing under its water-treatment specialist's guidance, cleaned the system and extended the MOC procedure to chemical programs. No further trips occurred over the next six months. A third strainer cleaning would have fixed nothing.

Open it in the FieldKit Problem Solving app → Get the Problem Solving template pack — join the waitlist

Common pitfalls and how to avoid them

Answering from opinion.Verify each answer with data, records or direct observation before asking the next why.
Stopping at 'human error'.Ask why the error was possible or likely (training, design, workload, procedure) until you reach a condition you can change.
Forcing exactly five whys.Stop at an actionable cause whose removal prevents recurrence, whether that takes three whys or seven.
Following one chain when several causes contribute.Branch whenever an answer has more than one verified cause, and follow each branch to its end.

Frequently asked questions

How many whys should you ask?

As many as it takes to reach a cause you can act on and whose removal would prevent recurrence, often three to seven. Five is a rule of thumb, not a quota. Stop when the next why leaves your sphere of influence, becomes speculative or turns into blame. Stopping too early usually means you are still treating a symptom.

What are the limitations of the 5 Whys?

It tends to follow a single causal chain, it can stop at the limit of the team's knowledge, and different teams can reach different answers if the links are not verified. It is less suited to complex problems with several interacting causes. Verifying each answer with facts, allowing branches, and combining the method with a fishbone diagram or fault tree reduce these weaknesses.

Can 5 Whys be used for safety incidents?

Yes, as one tool among several. Safety incidents usually involve multiple contributing causes, failed barriers and organizational factors, and a single chain rarely captures all of that. Combine 5 Whys with a timeline, a fault tree or a structured incident investigation method, and follow your organization's investigation procedure and any regulatory requirements.

Origin

5 Whys — attributed to Sakichi Toyoda; made central to the Toyota Production System by Taiichi Ohno.

Used in these playbooks

Major breakdown investigation 1 week

One week after a trip, a leak or a critical equipment failure: rebuild the sequence, map the failure combinations, dig to the cause, choose strong barriers and record the lesson.

Related methods

More in “Root Causes”

List the possible causes, dig down the chains and prove the real one before acting.