The fastest way to learn root cause analysis is to watch it done on real problems. Below are five complete examples — manufacturing, healthcare, software, logistics, and customer service — each solved with a different RCA method, with the actual numbers, the full causal chain, and the corrective action that closed it. Notice the pattern that repeats in every case: a measurable problem statement, a cause verified with evidence before anyone acted, and a fix aimed at the process rather than a person.
1. Manufacturing (5 Whys): scrap rate quadruples overnight
Problem statement: Scrap rate on line 2 rose from 1.2% to 4.9% between March 3-10; 100% of defects are under-torqued fasteners at station 4. Cost: ~$3,100/week.
Why 5 Whys: the symptom is specific and localised — one station, one defect type — so a single causal chain is likely. No need for breadth first.
The chain: Why under-torqued? → Torque tool stops early. Why? → Tool was recalibrated on March 2. Why did recalibration produce a wrong setting? → Technician used the spec from the laminated card at the bench. Why was the card wrong? → It shows revision C values; the drawing moved to revision D in January. Why did no one update the card? → The calibration procedure doesn't reference the drawing revision — bench cards are updated from memory.
Verification: tool reset to rev-D spec on one shift → zero defects in 400 units; card left unchanged on the other shift → defects continued.
Corrective action: calibration procedure now requires pulling current spec from the PLM system; bench cards abolished. Scrap back to 1.1% within a week — and note the root cause was a procedure, not the technician.
2. Healthcare (Fishbone → 5 Whys): medication near-miss in the ED
Problem statement: A near-miss: 10× dose of anticoagulant drawn up (caught at bedside check). Second similar near-miss in 6 weeks.
Why Fishbone first: high stakes, many plausible contributors (people, process, equipment, environment) — breadth before depth. The team mapped causes across 6M categories in a 45-minute session using a fishbone worksheet.
What the map showed: three branches dominated the vote — look-alike vials (Material), interruptions during preparation (Environment), and a dose calculator that defaults to adult weight (Machine). A quick 5 Whys on the strongest branch (look-alike vials) landed on: pharmacy switched suppliers in April; the new 10,000-unit vial matches the old 1,000-unit vial's cap colour — and no risk review accompanies supplier switches.
Corrective action: high-alert medications separated by shelf zone + auxiliary labels; supplier-change procedure now includes a look-alike/sound-alike review. The interruption and calculator branches went to a follow-up HFMEA.
3. Software (5 Whys, incident format): checkout outage at peak
Problem statement: Checkout API returned 5xx for 43 minutes during Friday peak; ~$18k revenue impact; triggered by a deploy at 17:02.
The chain: Why 5xx? → Connection pool exhausted. Why? → New feature holds connections 4× longer. Why not caught in review? → The change looked harmless; load behaviour only appears at production traffic. Why no load test? → Load tests exist but run weekly, not per-deploy. Why deploy at Friday peak at all? → No deploy-window policy; release timing is left to each engineer.
Two systemic fixes (note: not "engineer should be more careful"): connection-hold linting + per-deploy smoke load test in CI, and a deploy freeze 16:00–20:00 on peak days. Full post-mortem pattern in the 5 Whys for DevOps guide.
4. Logistics (Pareto → 5 Whys): late deliveries pile up
Problem statement: On-time delivery fell from 96% to 88% in Q1 (target ≥95%); 312 late shipments across 9 recorded reason codes.
Why Pareto first: counted, categorised data already exists — rank before you dig. The Pareto chart showed "carrier pickup missed" = 41% and "customs docs incomplete" = 27% — two codes = 68% of all lates. The other seven codes were ignored, deliberately.
Drill on #1: Why do carriers miss pickups? → Booking goes out after the 14:00 cut-off. Why? → Warehouse confirms pack completion in batches at end of shift. Why? → Scanning happens at the pack bench, but confirmation requires a desktop session the packers don't have — so a supervisor batches it.
Corrective action: pack-complete confirmation moved to the handheld scanners. Missed pickups fell 70% in six weeks; OTD recovered to 94.6%. Customs-docs branch became a second, separate analysis.
5. Customer service (8D-wrapped): B2B client escalates repeated billing errors
Problem statement: Key account received incorrect invoices 3 months running (wrong volume discounts); client demanded a formal corrective action response — which makes this an 8D case, not a memo.
Highlights of the 8D: D3 containment — manual invoice review for this account until the fix validates. D4 dual root cause: occurrence — discount tiers live in a spreadsheet the billing system doesn't read, re-keyed monthly by hand; escape — invoice QA samples 5% randomly, so a systematic error on one account passes unseen. D5-D6: discount table migrated into the billing system + QA sampling stratified by account risk; validated over two cycles with zero errors before D8 closure.
The 8D lesson: the formalism earned its overhead here — the customer needed evidence of containment and validation, and the dual occurrence/escape analysis caught a QA design flaw a plain 5 Whys would have skipped. Full worked reports in 8D examples.
The pattern across all five examples
- Problem statements are measurable. "4.9% scrap", "43 minutes of 5xx", "88% OTD" — never "quality got worse". How to write one.
- The method follows the data situation. Counted data → Pareto first. Wide-open cause field → fishbone first. One suspected chain → 5 Whys. Customer demands formality → 8D wrapper. See the full decision guide.
- Causes were verified before action — the on/off test in case 1, the vote-then-drill in case 2, the data split in case 4.
- Every root cause is a process, not a person. A procedure without revision control, a supplier switch without risk review, a missing deploy policy, a desktop-only confirmation step, a spreadsheet outside the system.
- Follow-up closed the loop — each case re-measured the original number after the fix.
Run your own analysis
Grab the free RCA report template (Excel, Word, PDF) with the same seven-section structure these cases follow — or run a guided session in the browser.
Start a free 5 Whys analysis →Frequently asked questions
What is a good example of root cause analysis?
One that moves from a measurable symptom to a verified systemic cause — like case 1 above: scrap spike → wrong calibration spec → procedure that doesn't reference drawing revisions. The fix changes the procedure, not the operator.
How do I choose which RCA method to use?
Counted data → Pareto first. Wide-open cause field → fishbone. One suspected chain → 5 Whys. Formal customer demand → 8D. Most real cases chain two methods, as cases 2 and 4 show.
What makes a root cause "verified"?
Evidence that the cause produces the effect: toggle it and watch the symptom follow, or show the symptom appears exactly where the cause is present. "Sounds right in the meeting" is not verification.
Should the root cause always be a process, not a person?
Almost always — if you land on "operator error", keep asking why the process let that error happen and escape. All five cases above ended at a process.
Where can I get a template for my own analysis?
The free RCA report template covers the full sequence; method-specific templates (5 Whys, fishbone, 8D, A3, FMEA, Pareto) are linked from it.
Related resources
- Root Cause Analysis: the complete guide — the 6-step process behind every case above
- Free RCA report template — Excel, Word and PDF, same seven-section structure
- 10 more 5 Whys examples — the drill method across ten industries
- 7 fishbone examples — complete diagrams by industry
- 5 full 8D reports — the formal corrective-action format, discipline by discipline