Highveld Fine Foods closed seven complaints of hard blue plastic in 500 g sliced polony the same way every time: “Fragment from damaged crate. Crates inspected. Operators reminded.” Nobody tested that story. When a lab ran FTIR on two retained fragments, the material was blue acetal (POM), but the crates are HDPE. The real source was a non-OEM plastic slicer guide, fitted five weeks earlier, chipping under load at every changeover. The team had reached for a conclusion, not a tool.
Conducting a Root Cause Analysis is ASC’s 2-day, 16-hour online course that teaches the five tools below on one running case study, R2 350, no VAT charged, self-paced, with a Certificate of Completion.
Root cause analysis tools: the key facts
| What this compares | 5 Whys / why-tree, fishbone (Ishikawa) diagram, fault tree analysis, 8D and FMEA |
|---|---|
| What each kind does | Fishbone and the why-tree organise hypotheses; the fault tree tests how failures combine; 8D and FMEA are frameworks, not cause-finding methods alone |
| Fishbone origin | Kaoru Ishikawa, Kawasaki shipyards, 1943; formalised in Guide to Quality Control, 1968 |
| 5 Whys origin | Sakichi Toyoda on the Toyoda looms; formalised by Taiichi Ohno for the Toyota Production System |
| Fault tree origin | H. A. Watson, Bell Labs, 1962, for the Minuteman missile programme; standardised in IEC 61025 |
| 8D origin | Ford’s Team Oriented Problem Solving manual, 1987, influenced by MIL-STD-1520C |
| FMEA origin | US military procedure MIL-P-1629, 1949; current reference is the AIAG-VDA handbook, 2019 |
| The rule across all five | None accepts “human error” or a named person as an ending: forbidden end-points, not root causes |
Which RCA tool, and when?
| Tool | Best for | Fails when | Time needed | Output |
|---|---|---|---|---|
| 5 Whys / why-tree | One verified fact pushed to a controllable cause, split into occurrence, escape and management legs | Used before evidence exists, or kept to one linear chain | 30–60 minutes once the trigger is confirmed | A why-tree with evidence at every step |
| Fishbone (Ishikawa) | Sorting a wide brainstorm into testable categories | The head is vague, items are opinions, or nothing gets tested | 60–90 minutes to build | A V/H/X-tagged map of hypotheses |
| Fault tree analysis | Several defences failing together, a CCP or allergen escape | Used on a single-cause event, or with guessed probabilities | Half a day to build and evidence | An AND/OR diagram showing cut sets and single points of failure |
| 8D | Product already on shelf, cause not yet known | Containment reported as the fix, or D7 skipped | Days for containment; weeks to close | Verified containment, two root causes, systemic prevention |
| FMEA | Proactive review, or updating after an RCA finds a new failure mode | Done once, never revisited; ranked by RPN instead of severity | Days for a full process walk-through | A rated register of failure modes and controls by step |
What is the 5 Whys, and when does it break down?
The 5 Whys is repeated questioning of a single verified fact until you reach a controllable system condition. Five is a guide, not a rule. It breaks down when a team stays on one linear chain for an incident with more than one cause, or accepts an answer that is an opinion, not something you could show an auditor.
Ohno’s example: a fuse blew because a bearing was poorly lubricated, because the pump shaft was worn, because no strainer was fitted. Stop at the fuse and you replace a fuse; only the missing strainer stops recurrence. Alan Card’s 2017 BMJ Quality & Safety critique is fair against the whiteboard version: linear, five is arbitrary, single-cause, and analysts disagree. Build the chain only after the evidence exists, reference every answer, split into a why-tree, occurrence, escape, management-system legs, wherever a question has more than one true answer, and never let it end at human error or “did not follow the SOP”.
What is a fishbone (Ishikawa) diagram, and what is it actually for?
A fishbone sorts brainstormed causes into categories, People, Methods, Machines, Materials, Measurement, Environment, often with Management added, against a specific problem statement, so every item can be tagged Verified, Hypothesis or Excluded. It is a sorting and prioritising tool, not an analysis in itself.
A vague head such as “foreign body complaints” lets every idea fit; a specific head naming material, size, product, line, shift and date does the opposite. Items belong on the bones as checkable conditions, never judgements. What makes it more than sticky notes is tagging: V verified, with evidence; H hypothesis, with a test; X excluded, with the evidence that rules it out. A completed fishbone cannot show timing, or that causes had to happen together; that is what the why-tree and fault tree are for.
What is fault tree analysis, and when do you need one?
Fault tree analysis starts from a precisely defined top event and works top-down through AND and OR logic gates to basic events, showing which failures had to combine and exposing any single point of failure. Use it whenever several independent defences would have had to fail together, such as a CCP or allergen escape.
An AND gate means every input had to occur, like a safe needing two keys. An OR gate means any single input is enough, like a room with two unlocked doors; OR gates near the top event are a warning sign. A minimal cut set is the smallest combination that produces the top event; one with a single member is a single point of failure. Used reactively, mark which branches occurred, on evidence, guessing probabilities is a known weakness of the tool.
What is 8D, and how is it different from a why-tree?
8D is an eight-discipline (plus D0) framework built around containing a problem before the cause is known, requiring two verified root causes, one for occurrence, one for how the defect escaped, while the why-tree is the tool used inside D4 to find them. Reach for 8D when defective product is already with the customer.
D0 protects the customer; D3 verifies interim containment; D4 needs both root causes confirmed by making the problem appear and disappear; D5–D6 validate the action before D3 is removed; D7 updates procedures, the FMEA and HACCP plan; D8 closes once effectiveness data exists. 8Ds fail predictably: containment reported as the root cause, retraining listed as D5, or D7 skipped.
What is FMEA, and why doesn’t RCA use it directly?
FMEA (Failure Mode and Effects Analysis) is a proactive, step-by-step review of how a process can fail, rating Severity, Occurrence and Detection for every failure mode before anything has gone wrong: the reverse direction of an RCA, which starts from an incident that already happened. An RCA’s job is to update it, not replace it.
Teams used to multiply Severity × Occurrence × Detection into a Risk Priority Number, which ranks a frequent cosmetic defect (S3 × O6 × D5 = 90) above a rare undeclared allergen (S10 × O2 × D2 = 40), backwards for food safety. The AIAG-VDA handbook (2019) drops the RPN for an Action Priority table that weights severity first, so a severity 9–10 mode ranks High until controls are demonstrated. After any incident, ask whether the failure mode was already in the PFMEA, the D7 question above.
Which tool should I use?
Start from what you know about the problem, not your favourite tool: a fuzzy problem needs Is/Is Not first; a split team needs a tagged fishbone; one clear fact needs a why-tree; several failures combining needs a fault tree; product on shelf needs 8D; a new failure mode should update the FMEA.
- Don’t know which line, product or time: Is/Is Not first.
- Worked before, recently stopped: change analysis, then a why-tree.
- Team disagrees where to look: a tagged fishbone.
- A single, clear, verified fact: a why-tree, in legs.
- Several failures had to combine: a fault tree, then barrier analysis.
- Product already out, cause unknown: 8D, containment first.
- Before a change, or after a gap is found: update the FMEA.
Worked example: the Highveld case, three tools deep
Highveld Fine Foods received seven complaints of hard blue plastic fragments in 500 g sliced polony, all from Line 2, B shift, production from 24 February 2025. FTIR identified the fragments as acetal (POM). Here is that evidence run through three tools.
Step 1: Fishbone, sort the hypotheses
Head: “Hard blue acetal fragments, 500 g polony, Line 2, B shift, from 24 Feb 2025.” Bones: People, Methods, Machines, Materials, Measurement, Management.
- Machines, V: non-OEM acetal guide, fitted 24 Feb, chipped under the nut.
- Materials, X: crates (HDPE) and gloves (soft; would be metal-detected).
- Methods, V: WI-SL-04 gives no torque value, never reviewed when the part changed.
- Measurement, V: the metal detector can’t detect acetal; the guide is missing from the register.
- Management, V: guide bought from a non-approved supplier; MoC covers capital projects only.
Step 2: Why-tree, push the verified factors down
Occurrence leg: the setter tightens the nut against the guide at every changeover, because WI-SL-04 gives no torque value, because no MoC was raised on the spare, a controllable stopping point.
Escape leg: acetal isn’t metal-detectable and no X-ray is installed, a technology decision.
Management leg: the complaint KPI rewards closing within ten days, with no trending by line or shift, so it took seven complaints to trigger an investigation.
Each leg passes the therefore test and explains why Line 2 B shift specifically, not a person.
Step 3: Fault tree, show how the failures combined
The why-tree explains each leg alone; the fault tree shows all three had to be true together.
Every marked box is a place the chain could have been broken: not one root cause, but a short list of solution points to rank on cost, time and effectiveness. Conducting a Root Cause Analysis walks you through fishbone, why-tree and fault tree exercises on this exact case, with model answers for each one.
What does an auditor actually ask for?
Under ISO 22000, an auditor tests clause 8.9.3 directly: who evaluated the non-conformity, what cause was determined, and how effectiveness was verified. SQF Code Edition 9 (clause 2.5.3) expects documented corrective action methods, and recommends structured tools by name, the 5 Whys and the fishbone, over guesswork.
BRCGS Global Standard Food Safety Issue 9 tests RCA through its non-conformity clauses (3.7, 3.10, 3.11) at every close-out. ISO 22000:2018 separates operational (clause 8.9, corrective actions at 8.9.3) from system-level non-conformities (clause 10.1); an FSSC 22000 auditor tests both to the depth of a CCP deviation. Every scheme challenges the same causes: human error, “did not follow procedure” with no reason given, and “isolated incident”. A close-out that survives names a verified cause at each layer, with an action stronger than a memo.
Frequently asked questions
Is the 5 Whys enough on its own for a food safety RCA?
Rarely, for anything serious. The whiteboard version stops where the team already suspects. Built properly, after the evidence is gathered, with a reference on every answer, split into occurrence, escape and management legs, and it becomes a why-tree, strong enough for most incidents. Where several failures combined, move to a fault tree.
How is a fault tree different from a fishbone diagram?
A fishbone sorts hypotheses into categories from a brainstorm. A fault tree starts from a defined top event and works down through AND/OR logic to show which failures had to combine, and whether any single one could cause the event alone. The fishbone comes first; the fault tree is for when several verified factors turn out to be necessary together.
Do I need FMEA if I already do RCA?
Yes. They run in opposite directions and both are needed. RCA works backwards from an incident that already happened; FMEA works forwards from a process step to failure modes that haven’t happened yet. A new failure mode found by an RCA should feed back into the PFMEA, D7 in the 8D framework.
What tool do auditors expect to see for a major non-conformity?
No single tool is mandated, but SQF guidance names the 5 Whys and the fishbone diagram specifically, and every scheme expects analysis depth to match risk, a full investigation for a major, proportionate effort for a minor. What gets rejected is the absence of any structured tool: a root cause that is really just the symptom, restated.
How many “whys” are actually needed?
Whatever it takes to reach a controllable system condition, a procedure, specification, design or resource you can change. Some chains reach it in three steps, others need eight. Five is Ohno’s illustration, not a target; stopping at the fifth why while the answer is still a person or an opinion defeats the method.
Learn to run all five, on one case, in two days
Reading about these tools is not the same as running them under time pressure. Conducting a Root Cause Analysis teaches fishbone, why-tree, fault tree, barrier analysis, change analysis, 8D, A3, FMEA, PDCA and DMAIC across 12 modules, on the Highveld case used throughout this article.
- R2 350, no VAT charged, about 16 hours, self-paced, Advanced level
- 12 modules on one running case study, with a practical exercise and model answers in every module
- Online final assessment: 50 questions, 70% to pass, three attempts
- Certificate of Completion on passing
- ASC is a FoodBev SETA accredited training provider (587/00337/1900)
Enrol in Conducting a Root Cause Analysis →
Not ready for two days? Start with the RCA Overview (R649) or the 1-Day RCA course (R1 250). See our RCA hub, or turning audit findings into corrective action. Investigating a people-related failure? Read Human Error Is Not a Root Cause. See all courses or contact us. Teams of five or more: contact ASC.