Quick comparison
| Technique | Best used when | Strength | Limitation |
|---|---|---|---|
| 5 Why (Why-Why) | One clear failure with a traceable chain of events | Fast, needs little data, easy to review | Can stop at the first plausible answer; one chain hides parallel causes |
| Fishbone (Ishikawa) | Several plausible contributors, cross-functional team | Makes the team look beyond the obvious suspect | Produces hypotheses, not proof; can become a long list |
| Fault Tree Analysis | Safety-critical or complex system failures | Shows AND/OR logic between events; can be quantified | Time-consuming; needs system knowledge and failure data |
| Pareto analysis | Many recurring events and a history of records | Shows which failure modes deserve attention first | Prioritises problems; does not explain why they occur |
| FMEA | Before a failure: new equipment, process changes | Preventive; ranks failure modes by risk | Not an investigation of an event that has already happened |
Pick by the question you are asking
- "Why did this specific stop, defect or incident happen?" — Fishbone to open up possible causes, then Why-Why on the plausible branches.
- "Which of our many problems should we investigate first?" — Pareto on your downtime, scrap or incident records.
- "How can combinations of failures lead to this hazard?" — Fault Tree Analysis.
- "What could go wrong with this new line or changed process?" — FMEA, before the event.
Why Fishbone and 5 Why work best together
Used alone, 5 Why tends to follow the first explanation someone offers. Used alone, a Fishbone diagram ends as a wall of possibilities without conclusions. Combined, they cover each other's weakness: the Fishbone widens the search, and Why-Why tests the strongest candidates until the team reaches a cause it can act on.
Example (illustrative): a conveyor stops on the night shift. The Fishbone lists a motor overload trip under Equipment, a skipped inspection under Process and a handover gap under People. Two of those become Why-Why branches. One ends in a worn bearing that was outside the inspection plan; the other is ruled out by the alarm log. The team acts on the first and records why the second was rejected.
Common mistakes when choosing a technique
- Running a full Fault Tree for a simple, low-risk stoppage.
- Treating Pareto results as causes rather than priorities.
- Using FMEA after an event instead of investigating what actually happened.
- Forcing exactly five Whys, or stopping at "operator error".
How EasyFixProblem supports this
Each case follows one path: problem definition, Fishbone, branching Why-Why with verdicts at the end of each branch, root causes, actions and effectiveness checks, then a management summary. See how EasyFixProblem works, or use the RCA report template to structure what you present.