“Someone forgot” ends the investigation too early
At the hypothetical operations team Rowan, a weekly client report goes out late for the third time. The first explanation is that the coordinator forgot to send it. The manager is considering another reminder, but the coordinator says the report was waiting for an approved data extract.
Five Whys uses repeated causal questions to move beyond an initial symptom toward underlying causes. ASQ notes that an investigation may need fewer or more than five questions. Rowan, its timeline, and the proposed actions below are invented.
Start with an event that people can check
Rowan writes: “The Friday client report was sent after the agreed noon deadline.” That is more useful than “The team is unreliable.” The team gathers the request, extract, approval, and sending timestamps and asks people involved to explain the sequence.
A good problem statement includes conditions and boundaries. Did the report miss every week or only during a particular handoff? Was the deadline known? Do not assume the answer while writing the question.
Problem → supported causal questions → corrective action → review
Start with an observable event
Problem
Describe what happened, where, and under which conditions.
Follow a supported explanation
Why?
Ask why the previous condition occurred and record evidence.
Keep other causes visible
Branches
Explore plausible alternatives instead of forcing one chain.
Test the explanation
Action and check
Choose a relevant change and inspect whether recurrence falls.
Follow the chain, with evidence beside it
The fictional review develops this working explanation:
| Question | Candidate explanation | Evidence to inspect |
|---|---|---|
| Why was the report late? | The approved extract arrived after the sending deadline | Extract and approval timestamps |
| Why did approval arrive late? | Review began only after the usual reviewer returned | Review queue and availability record |
| Why did work wait for that reviewer? | The team did not know who could approve in their absence | Handoff notes and role descriptions |
| Why was the backup unclear? | The recurring-report procedure had no backup decision owner | Current procedure and actual practice |
These are hypothetical candidate links. A real team would verify them before treating the explanation as established. The table stops at four questions because an actionable process gap has emerged; a fifth question is useful only if it reveals something important.
Each question should refer to the previous answer. Jumping from a late report to a broad complaint about company culture can produce a compelling story with no inspectable causal link.
Branch when the evidence points in two directions
Suppose the data extract also contained errors requiring rework. The team should explore that branch rather than force every delay into the missing-backup explanation. A backup reviewer might shorten waiting time while leaving poor data quality untouched.
A simple chain is a useful starting representation, but many incidents involve several contributing conditions. Record what remains unexplained. Ask whether the same event could still happen if the proposed cause were removed.
The person closest to the work may reveal constraints that a manager’s first account misses. Include those perspectives and make it possible to disagree with the emerging explanation without being treated as defensive.
Turn a cause into an action you can inspect
Rowan proposes naming an authorized backup reviewer, defining when the coordinator should use that route, and ensuring the backup can access the extract. “Communicate better” would not establish any of those conditions.
The team should also check the original deadline against actual workload. A backup role cannot repair a schedule that never allowed enough time to review the report. An action is stronger when it addresses the mechanism rather than adds another general reminder.
The proposal includes a review of the next four scheduled reports. Rowan would track extract readiness, review waiting time, errors, and sending time. Four reports are an illustrative review window, not proof of effectiveness. Other causes or unusual conditions could remain unseen.
Avoid a tidy story that outruns the facts
Repeated “why” questions can create a plausible narrative even when evidence is missing. Mark assumptions explicitly, seek counterexamples, and distinguish an account from a directly observed event. Agreement in a meeting is not causal verification.
Avoid stopping at a person’s mistake as if it explains the surrounding system. People can make errors, but the investigation should also examine information, authority, workload, tools, and recovery paths. Equally, do not invent an abstract systemic cause just because it sounds more sophisticated.
For complex failures, use a broader investigation that preserves multiple factors and relevant specialist evidence. Five Whys alone is not a complete incident-analysis method.
Use a RACI Matrix if the investigation exposes unclear approval authority. Use PDCA to plan, test, review, and revise a corrective change.
Rowan’s next task is to verify the waiting-time explanation and test a workable backup route. The investigation is useful when it changes a condition that contributes to the problem and leaves a way to check whether that change helped.
Sources and further reading
- ASQ, Five Whys and Five Hows. The repeated-question method and flexible stopping count follow ASQ; Rowan’s investigation is an original hypothetical example.