Most of us have used the 5 Whys during deviation investigations, but have we been using it correctly? It appears on every deviation investigation form, every deviation report, every post-incident review. Five questions. Five answers. Signed and filed as a CAPA starting point. But is this the right approach?
The Linear Trap
Consider the example shown below with a problem statement and associated 5Why analysis :
Problem Statement: An older version of an SOP was found on the shopfloor that triggered a deviation.
| Level | Question | Answer |
| Why 1 | Why was the older version of SOP-xxxx found on the shopfloor? | Operator used a printed copy not updated after the revision. |
| Why 2 | Why was the printed copy not replaced after the new version was approved? | No one informed the shopfloor supervisor that SOP-XXXX had been revised. |
| Why 3 | Why was the shopfloor supervisor not notified of the revision? | System notifies only the document owner, not active-use areas. |
| Why 4 | Why does the notification process exclude active-use areas? | The distribution matrix was not updated when the shopfloor was added as a user area. |
| Why 5 | Why was the distribution matrix not updated? | No requirement in change control to review the distribution matrix when adding a user area. |
The above 5 Whys analysis runs as a single straight line — one problem, one Why, one answer, repeated five times. That works when a failure has a single, clear cause. But real deviations rarely behave in this manner.
When you look at the problem statement — older version of SOP-XXXX found on the shopfloor — can we attribute it to just one reason? There may be three distinct causes, each having its own branches. Not all will reach Why 5, and that is fine. The goal is to find the branches that lead to a true systemic cause.
The Branching Model
The same analysis done differently reveals three independent causal branches:
Problem Statement: An older version of an SOP was found on the shopfloor that triggered a deviation.
Branch B is important for a different reason: it closes early and clears Document Control of a failure. This is equally valuable — the 5 Whys is not only a tool to find blame, but to eliminate false leads and confirm where controls did hold
Why This Matters in Pharma QMS
When the 5 Whys analysis is forced into a single linear chain, investigations routinely stop at the first plausible answer rather than the true systemic cause. This leads to CAPAs that address symptoms rather than eliminating the underlying system gaps. Examples include retraining the operator, reminding Document Control, etc. The branching model exposes multiple independent failure pathways. In this example, even if Branch A’s CAPA (an HR–Document Control notification procedure) is fully implemented, the deviation could recur via Branch C if the configuration baseline register gap remains unaddressed.
The branching model depends heavily on the knowledge of the team conducting the analysis. A fishbone (Ishikawa) diagram can help identify potential causes before drilling down. For high-risk deviations with patient safety implications, FMEA or fault tree analysis provides a more defensible, data-driven structure.
5Why – The Right Way – Step by Step
Using 5 Whys correctly in a pharmaceutical QMS context means:
- Start with a well-defined problem statement — observable, specific, and bounded. Vague statements generate vague chains.
- Identify all Why 1 possibilities before drilling — brainstorm independently, then build separate branches for each distinct causal pathway.
- Allow branches to close early when appropriate — a branch that leads to “this control worked correctly” is a valid and useful finding.
- Do not force five levels — the goal is the systemic root cause, not a count of five. Three Whys that reach a procedural gap are better than five Whys that circle back to a symptom.
- Validate each root cause with the reverse test — ask: “If this root cause were eliminated, would the deviation have been prevented?” If the answer is no, keep drilling.
- Link each confirmed root cause to a discrete CAPA action — one root cause, one CAPA. Multiple root causes from multiple branches each require their own corrective action plan.
The Real Goal
The 5 Whys was never intended to be a form-filler. Sakichi Toyoda introduced it into Toyota’s production system as a discipline of genuine inquiry, not documentation compliance. In a QMS environment where the pressure is to close deviations quickly and move on, it is easy to treat it as a checkbox. The result is a CAPA system full of retraining records and SOP updates that address the same recurring deviations, investigation after investigation.
The branching 5 Whys is time-consuming, there is no doubt about that, but it is the version that actually protects product quality and patient safety. The illusion of root cause is easy to create. The root cause itself takes work to find.