5 Whys

5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem. Starting from the observed problem statement, the investigator asks 'why did this happen?' and writes a one-sentence answer. The answer becomes the new problem statement, and the question is asked again. The cycle repeats — typically five times, but the count is not prescriptive — until further iterations no longer yield useful causal explanation or until a cause is reached that the organisation can actually act on (a process change, a design change, a training change, a system change) rather than a symptom that would only suppress the next occurrence.

It was developed by Sakichi Toyoda, founder of Toyota Industries, and was used extensively in Toyota's manufacturing operations. Taiichi Ohno described it as the basis for Toyota's scientific approach to problem-solving — 'by repeating why five times, the nature of the problem as well as its solution becomes clear'. The technique was codified in the Toyota Production System and inherited by Lean Manufacturing, Six Sigma, ISO 9001:2015 corrective-action expectations, ICH Q10 pharmaceutical-quality-system root-cause guidance and the major device CAPA expectations under 21 CFR 820.100, MDSAP and ISO 13485.

The CAPA system is the single most-cited area in FDA Form 483 inspections of medical-device manufacturers — year after year, decade after decade. The substantive criticism is almost never that the manufacturer failed to open CAPAs; it is that the CAPAs that were opened did not reach a root cause sufficient to prevent recurrence. The corrective action attacked a symptom, the preventive action covered a too-narrow scope, and the effectiveness check therefore confirmed that the symptom went away in that one place — only for the same root cause to surface in another product, another shift, another line, another quarter.

5 Whys is in the dock when this happens because 5 Whys is the most commonly applied root-cause technique. The technique itself is not the problem — it is the way it is applied: jumping levels, attributing to operator error at the second 'why' and stopping there, working from anecdote rather than from audit-trail evidence, single-thread reasoning where multiple causal chains co-exist, and 'training the operator' as the answer to almost every chain. Used with rigour, 5 Whys is fully sufficient for the majority of moderate-complexity investigations. Used as a form-fill exercise, it is an audit liability.

1. Define the problem statement precisely — what happened, when, where, on what product, to what specification, observed by whom, with what immediate impact. A vague problem statement guarantees a vague root cause. Quantify everything (lot, line, time, sample size, deviation magnitude, frequency).
2. Assemble the people who can speak to the evidence — the operator who observed it, the supervisor on shift, the engineer who owns the process, the QA reviewer who flagged it. Excluding the operator from the investigation is the most common structural failure.
3. Pull the evidence before asking the first why — audit trail, batch record, equipment logs, environmental data, training records, change-control history, prior CAPAs on the same product / process / equipment, supplier-quality data, complaints data. The first why should be answerable from data, not from memory.
4. Ask the first why and answer with a single sentence. The answer must be a factual statement of the immediate cause, not a category label ('human error', 'training gap', 'procedure not followed').
5. Validate the answer against the evidence — does the audit trail confirm the sequence? Is the time-stamp consistent? Is the operator's recollection corroborated by the equipment log? An unvalidated answer means the next why is built on sand.
6. If multiple causal chains are credible, branch — 5 Whys is allowed to fork. The single-thread tree is one of the most common rigour failures. Fishbone (Ishikawa) is the tool to enumerate categories of cause; 5 Whys then iterates down each branch.
7. Continue iterating. At each level, the answer becomes the new question. Stop when the next 'why' would be metaphysical ('why is the supplier prone to drift?' — at some point the answer is 'they are; treat the symptom') or when the cause is at a level the organisation can act on.
8. Cross-check the final root cause against an independent technique — fishbone, FMEA, FTA, Apollo, or a peer review by someone not in the investigation team. If the technique alone gives the answer, that is a red flag.
9. Translate the root cause into a corrective action (eliminate the cause for the affected event), a preventive action (eliminate the cause from recurring elsewhere), and an effectiveness-verification plan (the measurable observation that confirms the cause is gone, with a defined post-implementation window).
10. Lock the investigation — every node, every piece of supporting evidence, every signature; immutable once approved, with full audit trail for any later amendment.

Problem statement: HPLC assay for Product X, lot 2024-118, sample 3 returned a result of 92.4% of label claim against a specification of 95.0%-105.0%. Observed by analyst J during routine release testing on 14 May 2024 at 09:42. No prior OOS for this product in the previous 24 months.

• Why 1 — Why was the assay 92.4%? Because the API concentration in the dosage units sampled was below specification.
• Evidence: re-test from the same lot, performed on a different HPLC column by a second analyst per the OOS Phase II protocol, returned 92.1%, 92.6%, 92.3%. Original result confirmed; not an analytical artifact.
• Why 2 — Why was the API concentration low? Because the dispense for that batch under-delivered API against the formula target.
• Evidence: BMR shows dispense recorded 14.78 kg of API against a target of 15.00 kg ± 0.5%. Reconciliation at the end of batch flagged a yield 1.5% below historical mean.
• Why 3 — Why did the dispense under-deliver? Because the dispense scale was within its calibration tolerance for the full-range check but had drifted at the working-weight end.
• Evidence: post-event calibration check at 15 kg working weight showed -1.6% bias; the most recent monthly calibration record (3 weeks prior) showed pass at the full-range check only (50 kg).
• Why 4 — Why did the scale drift go undetected? Because the calibration SOP requires only a single-point check at full-range monthly; mid-range and working-weight points are checked annually only.
• Evidence: SOP-MET-014 v6, §5.3; calibration records for the prior 12 months confirm the single-point monthly cadence; the annual multi-point check is overdue by 11 months for that scale due to a missed schedule trigger.
• Why 5 — Why is the calibration SOP a single-point monthly cadence? Because the SOP was authored against the manufacturer's recommendation for the older scale; the current scale (model upgraded 18 months ago) has a different drift profile and the manufacturer recommends quarterly multi-point checks at working-weight. The SOP was not updated as part of the equipment changeover.
• Evidence: equipment change-control record CC-2022-091; SOP version history; manufacturer documentation for both scale models.

Root cause: SOP calibration cadence not updated to match the current equipment, allowing working-weight drift to go undetected. Corrective action: re-calibrate the scale per manufacturer's recommended cadence; re-test all batches dispensed on this scale in the past 12 months for impact assessment. Preventive action: revise SOP-MET-014 to require quarterly multi-point checks at working-weights for this scale model and any future replacement; add equipment-changeover to the SOP-impact-assessment checklist in the change-control procedure to prevent recurrence on any other equipment class. Effectiveness verification: 6-month post-implementation review of all scale calibration records; OOS rate for products dispensed on this scale class trended against pre-implementation baseline; impact-assessment closure for the 12-month retrospective lot review.

• Stopping at operator error — '...because the operator did not follow the procedure'. The investigation has stopped at a symptom; the next why is 'why did the operator not follow the procedure?' — was the procedure unclear, was it impractical, was the operator trained, was the operator supervised, was the procedure even on the line?
• Pattern-matching against a template — investigators learn that 'training gap' is a quick-to-close finding and steer the chain there. The 483 themed pattern is repeated 'inadequate training' findings across unrelated CAPAs.
• Single-thread reasoning — only one causal chain is explored when multiple are credible. The fishbone is supposed to enumerate the categories (Man / Machine / Method / Material / Measurement / Environment) before 5 Whys runs down each that applies.
• Vague problem statement — without a quantified problem statement, 'why' loses meaning. 'Batch failed' is not a problem statement; 'Lot 2024-118 of Product X had assay 92.4% against spec 95.0%-105.0% on the release HPLC' is.
• Working from memory not from evidence — investigations dominated by interview rather than by audit-trail / batch-record / equipment-log evidence inherit the participants' biases.
• Excluding the operator — investigations that the operator on shift never sees miss the on-floor reality that determined the actual sequence.
• Stopping too early — three whys with three category labels ('training gap', 'documentation issue', 'procedure ambiguity') and a corrective action of 'retrain operator on revised procedure'. Almost always insufficient.
• Going too far — six or seven whys into philosophical territory ('why does the supplier exist?'). The stopping rule is actionability, not iteration count.
• Confusing immediate cause with root cause — the immediate cause is the proximate event; the root cause is the systemic failure that allowed the proximate event. Both are needed; the corrective action addresses the immediate cause, the preventive action addresses the root cause.
• Not validating each answer against evidence — the chain becomes a story.
• No cross-check — 5 Whys as the sole technique with no fishbone, no FMEA, no peer review.
• Corrective action that does not address the cause identified — the investigation reaches a systemic cause, then proposes a local action 'because the systemic action is too expensive'. The CAPA effectiveness check will fail.
• Preventive action scope too narrow — the cause is generalisable across products / lines / sites but the preventive action is implemented only on the affected product / line / site.
• Effectiveness verification deferred to 'we'll see' rather than a defined observation with a defined criterion and a defined window.

• High-complexity, multi-causal failures with safety implications — use Fault Tree Analysis (FTA) or Apollo Root Cause Analysis to handle multiple AND/OR-combined causes rigorously.
• Recurrent failures that have already had 5 Whys done — escalate to a more rigorous technique (FTA, Apollo, cause-mapping). Repeating the same technique that missed the root cause the first time is unlikely to find it the second.
• Process capability problems (Cpk drift, multi-variable interaction) — use SPC / DOE / multi-variate analysis to characterise the process before iterating on causation.
• Latent design failures — use FMEA (or the AIAG / VDA 2019 PFMEA / DFMEA / FMEA-MSR methodology) to enumerate the failure modes and their causes a priori; 5 Whys then refines for a specific observed failure.
• Cross-functional failures where causation spans multiple departments — use Cause-and-Effect (Ishikawa) first to enumerate the categories, then 5 Whys down each branch with each department represented.
• Cultural / organisational failures (repeat findings across many products / lines) — use a Cultural Maturity Assessment or a Human Performance Improvement (HPI) framework; 5 Whys will keep hitting 'training' and miss the system.

Inspectors sampling a CAPA in 2026 will expect to see: (a) a problem statement that is specific and quantified; (b) an investigation team that includes the people who saw the event, not just QA; (c) evidence references at every step — audit trail, batch record, equipment log, training record, change-control history; (d) a stated root-cause technique (5 Whys / fishbone / FTA / Apollo / FMEA) — not 'judgement' or 'experience'; (e) a chain that is internally consistent and externally validated; (f) corrective action that addresses the immediate cause + preventive action that addresses the root cause + scope assessment to other products / lines / sites; (g) effectiveness-verification plan with measurable criterion and defined window; (h) signature, date and audit trail for every step.

FDA Form 483 patterns published year after year cite the same root-cause failures: 'corrective action does not adequately address the underlying cause', 'root-cause analysis is inadequate', 'preventive action is not extended to other products that share the same cause', 'effectiveness verification does not confirm the underlying cause has been addressed'. MDSAP findings catalogue similar patterns under Chapter 4 (CAPA). Notified Bodies cite the same under EU MDR Annex IX QMS audits.

5 Whys and the Ishikawa fishbone (also called cause-and-effect diagram) are the standard pairing for routine investigations. The fishbone enumerates categories of potential cause — typically Man / Machine / Method / Material / Measurement / Environment for manufacturing (the 6 Ms), or People / Process / Equipment / Materials / Environment / Management for service contexts. Each category surfaces candidate contributing factors; 5 Whys then iterates down each applicable factor to a root cause.

Fishbone forces enumeration before convergence. The single biggest cause of weak 5 Whys is jumping to a chain without enumerating alternatives. The fishbone, run as a structured team session with the operator present, takes 30 minutes for a routine deviation and prevents the single-thread trap. The output is a fishbone + a set of 5 Whys chains (one per active branch) + a converged root-cause statement.

• Problem statement (quantified)
• Investigation team (names, roles, including the operator on shift)
• Evidence pulled (audit trail / batch record / equipment log / training record / change-control history / prior CAPAs)
• Technique used (5 Whys, fishbone, FMEA, FTA, Apollo, etc.) and why that technique was chosen
• Fishbone (if applicable) with categories enumerated and active branches identified
• 5 Whys tree per active branch — each node with the answer, the evidence reference and the validator
• Convergence to root cause(s)
• Cross-check method (peer review, second technique, independent reviewer)
• Corrective action (immediate cause)
• Preventive action (systemic cause), scope assessment to other products / lines / sites
• Effectiveness verification plan — observable, measurable, time-bound
• Signature, date, audit trail
• Linkage to the CAPA record (CAPA number, status, owner, due date)

• Investigation cycle time (problem detection → root cause approved)
• % of investigations using a structured technique (5 Whys / fishbone / FTA / FMEA / Apollo) vs free-text
• % of root causes attributing to 'operator error' alone (target: low — high signals stopping-too-early bias)
• % of investigations with operator on the team
• % of investigations with multi-branch fishbone vs single-thread
• Repeat-after-CAPA rate (closed CAPAs that re-open within 12 / 24 months on the same product / process)
• Effectiveness verification closure rate within plan
• Preventive-action scope-assessment completeness (% of CAPAs where scope was extended to other products / lines)
• External finding rate citing inadequate root-cause analysis (483 / Notified Body finding / MDSAP grade)

V5 Ultimate models the 5 Whys as a branching tree inside the investigation record — every node has an answer field, an evidence-reference field (pulling directly from the audit trail, batch record, equipment log, training record, prior CAPAs or change-control history), a validator field and an actionability flag. Branching is first-class — fishbone categories drive the tree structure, multiple active branches converge to one or more root causes, and the tree is rendered visually for the investigator and the reviewer.

The fishbone is a structured workspace before the 5 Whys opens — categories (configurable per industry) enumerate candidate contributing factors with the operator present; only active factors propagate into the 5 Whys tree. The system surfaces prior CAPAs on the same product / process / equipment / supplier with one click — preventing the 'no prior history' assumption that drives repeat findings.

Operator-on-team is enforced — investigations cannot be approved without at least one operator signature alongside the QA reviewer. Stop-at-operator-error is flagged for review — when the chain converges on 'operator did not follow the procedure', the system requires either evidence that the procedure was followable, present, current and trained, or an explicit next-why exploring why it was not. The corrective + preventive actions and the effectiveness-verification plan are required fields with the scope assessment to other products / lines / sites called out separately. Once approved, the investigation is locked with audit trail; any amendment requires a controlled change with two-person e-signature per 21 CFR 11.200.