The Five Whys, With Evidence: Root-Cause Analysis Without Storytelling
Branch each why into evidence-backed causal hypotheses, test interventions, and stop before a neat single-root story replaces a complex system.
State the observable problem, ask why it occurred, and branch whenever more than one contributor is plausible. For every arrow, record evidence for and against, a rival explanation, and a test or intervention whose result should differ if the link is causal. Stop when the next why becomes speculation, falls outside scope, or reaches a condition you cannot usefully change.
Use this for a bounded recurring mismatch
Use this method for a well-described operational problem: missed handoffs, recurring data errors, avoidable rework, or a performance measure that repeatedly departs from its target. Begin with a timeline and evidence, not “Why are people careless?”
Do not use Five Whys alone for serious safety events, alleged misconduct, legal attribution, trauma, or complex failures spanning many institutions. Do not interrogate a person with repeated “why” questions. The object of inquiry is the event system, not a suspect.
CMS quality-improvement guidance presents Five Whys as one root-cause-analysis tool and notes that the inquiry may require fewer or more than five questions. cms, card Critical analysis warns that the method can oversimplify complex causality and fixate on a single chain. card
What survives the comparison: the Evidence-Branching Why Graph
The evidence-branching graph
Each node contains a condition, not a blame label. Each arrow contains:
- evidence supporting the connection;
- evidence against or missing;
- plausible alternative;
- predicted observation if the connection is real;
- countermeasure and owner;
- residual risk after the countermeasure.
Use the number five only as a reminder to continue inquiry. Depth is earned by evidence, not by reaching the fifth box.
Build and test the why graph
Step 1 — Write the event. Include actor-neutral observation, place, time, expected state, actual state, and consequence.
Step 2 — Reconstruct the timeline. Use logs, artifacts, interviews, and environmental conditions. Mark conflict rather than forcing one version.
Step 3 — Ask the first why. Generate at least two plausible contributors independently.
Step 4 — Branch. For each contributor, ask what conditions made it possible. Include task design, information, tools, workload, incentives, supervision, and environment.
Step 5 — Test arrows. Seek comparative cases, records, counterexamples, and temporal order. Label unsupported links as hypotheses.
Step 6 — Select an intervention point. Prefer a change that alters the system and creates a measurable prediction.
Step 7 — Run a bounded countermeasure. Preserve baseline, measure intended effect and side effects, and assign an owner.
Step 8 — Reopen the graph. If the event persists, update the relevant link rather than adding another convenient why.
Worked graph: missing citations
Event: seven of fifty draft claims lack traceable source IDs. One branch is “authors forgot”; evidence shows the same author succeeded in another template. Another is “source fields were optional during drafting”; repository history supports it. A third is “citations were lost during export”; round-trip comparison shows two losses.
Different causes require different countermeasures: schema validation, template defaults, and export integrity checks. “Train writers to be careful” would act on the least-supported branch. The branching graph prevents a single human-error ending.
Adaptations by complexity
- Quick operational issue: cap the graph at one page and run one reversible test.
- Data-rich process: quantify branch frequency across an error taxonomy.
- Socio-technical system: add feedback loops, delays, interactions, and stakeholder effects.
- Sensitive event: use a trained independent facilitator and protect participants.
- Solo analysis: build the graph once, then return later to generate rivals without seeing the first ranking.
When branches proliferate beyond useful action, move to system mapping or formal investigation.
Match the countermeasure to the contributor
Use a strength hierarchy. A reminder or retraining depends on memory and attention; a checklist adds a visible cue; an interface constraint changes the opportunity for error; removing a hazardous dependency changes the system. Prefer the strongest feasible intervention that addresses the supported link, but analyze new burdens and workarounds.
Define a process measure and an outcome measure before the change. If a required field prevents omission but causes fabricated entries, the process measure improved while the underlying evidence problem worsened. Monitor displacement and negative findings. A countermeasure that cannot fail an explicit test has not validated the causal branch; it has only changed the workflow.
Failure modes that manufacture a root
- Starting with a judgmental problem statement.
- Treating the fifth answer as “the root.”
- Following only the first plausible chain.
- Accepting “human error,” “communication,” or “culture” as a terminal node.
- Confusing temporal order with causation.
- Ignoring why safeguards failed to contain the event.
- Selecting a countermeasure before testing the link.
- Closing the review after writing a report.
The method should make uncertainty more visible, not hide it behind depth-shaped language.
Where the Evidence-Branching Why Graph travels—and where it does not
Give a different incident record to the analyst. Without the template, they must write an observable event, build at least two branches, test a causal arrow with evidence and counterevidence, reject a blame label, propose a bounded intervention, and specify the result that would weaken the hypothesis.
Begin from The After-Action Review, widen interactions with Systems Thinking, and test recurrence through The Error Taxonomy Method.
A causal story is not a causal estimate
Retrospective records are incomplete and outcome knowledge changes interpretation. Interventions can be unethical or impractical, and observed improvement may have rival causes. Complex safety and regulatory events require formal methods and qualified investigators. This protocol cannot allocate liability or prove a unique root cause.
The Five Whys becomes useful when every why opens an evidence question and every selected cause survives a test.
Named sources
Evidence and further reading
Published July 29, 2026. No substantive revision has been recorded. Evidence last verified July 28, 2026.