The Five Whys Method Without Oversimplifying the Problem
The method is a prompt for causal depth, not a rule that every failure has one cause or exactly five layers.
How to use the Five Whys method
Start with one observable event, ask why the event occurred, and require evidence for every answer. Branch when several conditions were necessary. Stop when the team reaches a controllable system mechanism, not a personality label or a vague lack of care.
Start with one event and ask why it happened. Support every answer with evidence, and branch when more than one condition was needed.
Key relationships
- The first why examines the direct mechanism behind the event.
- Evidence supports each link in the why chain.
- A useful stopping point identifies a system condition the team can change.
Start from an observable event
Begin with a measured event rather than a judgement. 'The release failed its accessibility check' is observable. 'The team was careless' is an interpretation that prematurely closes the inquiry.
Branch when the evidence branches
An event can require several conditions. A check may have been missing, a deadline may have compressed review, and ownership may have been unclear. Record parallel causes rather than forcing them into one neat chain.
Stop at a controllable mechanism
Stop when you reach a mechanism the organization can change and evidence supports. 'Human error' is rarely useful because it neither predicts recurrence nor identifies a control. A missing automated contrast test is specific and changeable.
Ask how the problem escaped
Use two tracks: how the defect was created and how it passed through detection. A calculation error may originate in a copied formula and escape because the review checks totals but not formulas. The two tracks lead to different controls and should not be collapsed into one chain.
Also ask how recovery was delayed. Detection and recovery often explain more of the impact than the initiating mistake.
Challenge each why answer
For every link, ask what observation supports it and what else could produce the same event. If the answer is based only on recollection, mark confidence as low and seek a record, reproduction, or comparison case.
Avoid changing levels without noticing. Moving from a failed component to budget policy may be valid, but the intermediate mechanism should be stated so the chain remains testable.
Turn the chain into controls
Match the control to the mechanism. Knowledge gaps may need a job aid and a competency check. Error-prone entry may need validation. Conflicting priorities may need an explicit decision rule. Every action should have an owner, due date, and verification measure.
Repeat the scenario after implementation when practical. A policy that exists only in a document is not yet evidence that the failure path has changed.
Facilitate the discussion without blame
Invite the people closest to the work and begin with the shared event record. Ask about the conditions that made an action reasonable at the time, including information, workload, tools, incentives, and competing goals. This produces more useful controls than asking why a person failed to be more careful.
Give participants a way to add evidence after the session and distinguish disagreement from uncertainty. If the group cannot support a link, record a question and owner rather than forcing consensus. The chain is a working hypothesis until its important links are verified. Review the final actions with the people who must use the changed process, and record their operational concerns.
Branch the analysis when one chain hides the system
Suppose an accessibility defect reached production. A single chain may end with a developer omission. Two linked branches reveal both how the defect was created and how it escaped detection.
| Layer | Creation branch | Escape branch |
|---|---|---|
| Observed event | A control had insufficient contrast | The release included the defect |
| Direct mechanism | A token outside the approved palette was used | The review did not flag the rendered contrast |
| System condition | The component library allowed an unrestricted color value | The automated check did not cover that state |
| Controllable change | Restrict the component to approved tokens | Add the missing state to automated and manual review |
Both branches can be true. Restricting the token reduces creation risk, while broader checking improves detection. Ending at someone chose the wrong color supplies neither control. Every link still needs evidence from the component history, test configuration, and release record.
Stop the questioning when
- The mechanism is specific enough to predict recurrence.
- The team has evidence for the important links.
- A named owner can change the condition.
- The proposed action can be checked after implementation.
Keep the why chain testable
For incidents with several interacting mechanisms, move from a single chain to the broader root cause analysis process.
Before the first why, use the problem framing worksheet to state the observed event, boundary, and evidence.