Learning guide and study notes
Why does the problem recur? Use it when fixing symptoms is not enough.
Root-cause thinking investigates why an issue recurs beneath surface symptoms, tracing evidence across process, design, and systemic branches until you find a controllable cause whose removal prevents recurrence.
A root-cause inquiry tests contributing factors and asks whether removing a candidate cause would prevent recurrence.
Work through these steps in order, applying the tools above. Write down the answer to each step before moving on.
Write a specific problem statement and involve people who know the process. [1] Source: CMS — Five Whys for Root Cause Analysis (opens in a new tab)
Follow evidence through successive why questions; branch when multiple factors are involved. [1] Source: CMS — Five Whys for Root Cause Analysis (opens in a new tab)
Ask whether removing the candidate would prevent recurrence; assign a corrective action and verify its effect. [1] Source: CMS — Five Whys for Root Cause Analysis (opens in a new tab)
Pick a recurring incident, ask why until a testable process cause appears, then ask whether removing it would prevent recurrence.
Situation: Deployments repeatedly roll back.
How to apply: Trace incompatible dependencies to missing dependency checks rather than blaming the last operator.
Outcome: Add an automated check and monitor whether the same failure mode returns.
Situation: An internal gateway fails because a TLS certificate expired over a holiday weekend.
How to apply: Look past “nobody renewed the cert” to ask why renewal relied on a shared calendar reminder and manual upload.
Outcome: Automate certificate lifecycle rotation and alert on renewal failure 14 days before expiry.
Situation: A standby environment fails during a failover drill because firewall rules did not match primary.
How to apply: Trace both branches: why emergency primary edits bypassed version control, and why drift went undetected for months.
Outcome: Reconcile network rules from a single source of truth and run daily automated drift checks.
Illustrative examples showing how the lens changes decisions; not measured outcomes.
Watch out: Five is a mnemonic, not a mandatory stopping point; a single linear chain can hide multiple causes.
Combine this lens with others rather than relying on it alone. Browse all thinkings
A useful cause explains the failure mechanism and leads to a prevention test, rather than merely naming the last person or event.
Use a problem of your own. Write a short answer to each prompt, then return after trying the method.
Answer from memory before opening the suggested answer.
It stops before examining conditions such as unclear interfaces, missing safeguards, workload, or incentives that made the error possible and consequential.
Record evidence for each link, consider competing explanations, and mark unverified links as hypotheses. A neat story is not a validated mechanism.
These sources support the method; the examples and exercises are original teaching illustrations.