Root cause analysis means working back from a symptom to the condition that produced it, so the fix removes the problem rather than the evidence of it. It names a family of methods rather than one.
- 5 Whys — quick and verbal, suits a straightforward causal chain
- Ishikawa diagram — spreads the search across categories so it does not narrow too early
- Fault tree analysis — for failures with several contributing conditions
- Pareto analysis — decides which problem is worth analysing at all
How far back to go has a practical answer: to the last cause inside your control whose removal stops recurrence. Chains extend indefinitely — a defect traces to a setting, to a maintenance schedule, to a budget, to a market — and continuing past the point of action is philosophy rather than analysis.
A cause qualifies as root when removing it prevents the problem returning and it explains the evidence. Both halves are load-bearing; a plausible cause that would not have produced the observed pattern is a hypothesis nobody tested.
Stopping at human error is the standard failure. “Operator did not follow the procedure” describes what happened. The questions after it — why it was not followed, whether it could have been, what let the error through undetected — are where the analysis actually starts.
