Root cause analysis (RCA) is a structured process for tracing a problem back to the underlying cause that produced it, rather than stopping at the closest visible symptom.
The idea
RCA is a family of techniques — 5 Whys, fishbone/Ishikawa diagrams, fault tree analysis — that share the same goal: find the earliest point in a chain of events where an intervention would have prevented the problem, instead of only masking its immediate symptom. It’s typically applied after an incident, defect, or recurring failure, working backward from the observed effect toward its contributing causes.
When to use it
- A problem or defect recurs despite previous fixes
- Post-incident reviews and postmortems
- Manufacturing, software, and process-quality investigations where a repeat failure is costly
How to apply it
- Describe the problem precisely and gather the facts around it.
- Ask “why” repeatedly (5 Whys), or map contributing factors on a fishbone diagram grouped by category (people, process, equipment, and so on).
- Distinguish plausible causes from confirmed ones, testing before committing to a fix.
- Address the root cause, then verify the problem stops recurring.
Watch out for
- Stopping at a proximate cause and mistaking it for the root cause
- Treating “5 Whys” as a single linear chain when real problems often have multiple contributing causes
- Skipping verification, so a plausible-sounding cause is never actually confirmed
Related models
- Root Cause vs Proximate Use — the core distinction root cause analysis depends on.
- Indentify Root Causes — the underlying principle this technique applies.
- Dmaic — uses root cause analysis within its Analyze phase.
- Multiple Causation — a reminder that outcomes often have more than one root cause.
Sources
The “5 Whys” technique, developed within the Toyota Production System; the Ishikawa (fishbone) diagram, developed by Kaoru Ishikawa.