When something goes wrong — an injury, a near miss, a quality escape — the goal of the investigation is simple to state and hard to do: find the cause you can actually fix, so it doesn't happen again. Two techniques dominate this work: the 5 Whys and the Fishbone (Ishikawa) diagram. They're often treated as rivals. They're better understood as complements.
Here's how each one works, where each one fails, and how to decide which to reach for.
The 5 Whys: go deep on one chain
The 5 Whys is a linear technique. You state the problem, ask "why did that happen?", answer it, then ask "why?" of that answer — repeating until you reach a cause that, if corrected, prevents recurrence. A worked example:
- An operator slipped and fell near conveyor line 3.
- There was hydraulic oil on the floor.
- A hose fitting on the press was leaking.
- The fitting wasn't replaced at its scheduled interval.
- The preventive maintenance task wasn't triggered.
- The PM schedule for that press was never migrated when the CMMS was replaced.
Notice the root cause is a system gap (a missed data migration), not "the operator was careless." That's the whole point — keep asking why until you pass the human error and reach the condition that allowed it.
Where 5 Whys works well
- Simple to moderate problems with a clear single chain of causation
- Fast investigations where you need a defensible cause quickly
- Teams new to RCA — it needs no training or templates
Where 5 Whys fails
- Tunnel vision. It follows one path and can miss parallel causes — most real incidents have several contributing factors, not one.
- Stops too early. Teams settle on "human error" and stop, blaming the person instead of the system.
- Answer depends on who's asking. Different investigators can walk different chains from the same problem.
The Fishbone diagram: go wide across categories
The Fishbone (or Ishikawa, or cause-and-effect) diagram is a branching technique. You write the problem at the "head" of the fish, then brainstorm possible causes along "bones," each a category. The classic manufacturing categories are the 6 Ms:
| Category | Prompts |
|---|---|
| Method | Procedures, work instructions, the way the task is designed |
| Machine | Equipment, tools, maintenance, guarding |
| Material | Raw materials, consumables, substitutions |
| Man / People | Training, competence, staffing, fatigue, supervision |
| Measurement | Inspection, calibration, monitoring, data quality |
| Environment | Layout, lighting, noise, weather, housekeeping |
For a service or safety context you can swap categories (People, Process, Policy, Place, etc.). The value is structural: by forcing yourself to consider every category, you surface causes a single "why" chain would never reach.
Where Fishbone works well
- Complex problems with multiple contributing factors
- Group workshops — it's a natural brainstorming canvas
- When you suspect you're missing something and want breadth before depth
Where Fishbone fails
- Breadth without depth. It lists possible causes but doesn't, by itself, tell you which are real or how deep they go.
- Can become a wall of guesses. Without evidence, bones fill with speculation.
- No prioritisation built in. You still need a way to test and rank the candidates.
Side by side
| 5 Whys | Fishbone | |
|---|---|---|
| Shape | Linear — one chain, deep | Branching — many categories, wide |
| Best for | Simple, single-cause problems | Complex, multi-factor problems |
| Team size | Individual or small group | Workshop / group |
| Main risk | Tunnel vision, stops at blame | Speculation, no depth |
| Output | A root cause | A map of candidate causes |
From root cause to corrective action
An RCA is only worth doing if it changes something. Whichever method you use, the output should feed a corrective and preventive action (CAPA) that targets the root cause, not the symptom. Mopping the oil is a fix for "Why 1." Correcting the CMMS migration gap is a fix for the actual root cause — and it prevents every future leak the same gap would have hidden.
Good practice: every confirmed root cause gets at least one action, with an owner and a due date, and the action is verified for effectiveness after it closes. That last step — did the action actually work? — is what separates a paperwork exercise from real improvement, and it's exactly what an ISO 45001 or ISO 9001 auditor checks under corrective action.
Run RCA and close the loop in one place
ENSURE's Incidents module guides 5 Whys and Fishbone investigations, then turns confirmed root causes into tracked CAPAs with owners, due dates, and effectiveness checks — so nothing stops at "mop the floor." See it on a real incident in a 30-minute demo.