Written and maintained by CASRAI Editorial Board
Last updated
A CAPA investigation that names “operator error” as the root cause and “retrain the operator” as the corrective action is not finished — it has stopped at the symptom. The operator did something, but an operator working under an ambiguous procedure, an unlabeled reagent, or a form that makes the wrong entry easy to make will produce the same deviation again regardless of how much retraining happens in between. Retraining a person against a system that sets them up to fail is a corrective action with nothing underneath it, and it is one of the most common reasons a closed CAPA reopens at the next audit.
The fix is not a better investigation template. It is picking the right analysis technique for the kind of problem in front of you, and understanding specifically what failure mode each technique exists to catch. This guide covers three techniques — 5 Whys, fishbone/Ishikawa diagrams, and fault tree analysis — how to choose between them, and the human-error taxonomy that keeps “operator error” from being treated as an answer instead of a starting point.
Why “operator error” and “retraining” fail as a root cause and a corrective action
“Operator error” describes what happened, not why it happened. Every deviation involves a person doing, or not doing, something — that observation is the starting point of an investigation, not its conclusion. A root cause has to explain why a capable, trained person made that specific error at that specific point: an SOP step written ambiguously enough that two trained operators read it two different ways, a verification step that’s easy to skip because nothing forces it, a label format that makes two different reagents look alike under the lighting on the bench, a queue of competing priorities that made the shortcut rational in the moment. Each of those is fixable at the system level. “The operator wasn’t careful enough” is not.
Retraining fails as a corrective action for the same reason: it treats a system problem as a knowledge problem. If the operator already knew the correct procedure and made the error anyway, more instruction on the same procedure doesn’t change the conditions that produced the error the first time. Retraining is sometimes a legitimate part of a corrective action — if the investigation genuinely finds a training gap, not just a training record gap — but on its own, with no accompanying system change, it is the corrective-action equivalent of the problem statement that already contains its conclusion: a box that gets checked without addressing the condition that produced the deviation.
A quick taxonomy: symptom, proximate cause, and true root cause
It helps to keep three levels distinct while investigating:
- Symptom — what was observed: a missing signature, an out-of-range result, a contaminated sample, a batch record discrepancy.
- Proximate cause — the immediate action or condition that produced the symptom: the operator skipped a step, a sensor drifted out of calibration, the wrong reagent was pulled from a shared shelf.
- Root cause — the system-level condition that made the proximate cause likely or possible: an SOP that doesn’t specify a tolerance, a calibration schedule with no escalation when a check is missed, a storage layout with no physical separation between look-alike reagents.
An investigation that stops at the proximate cause produces a corrective action aimed at the wrong layer — discipline or retrain the person, recalibrate the one sensor, relabel the one shelf — without addressing why the system allowed that proximate cause to occur at all, which is exactly the gap an extent-of-condition review is meant to catch on the record side. The three techniques below exist to force the investigation down to that third level instead of stopping at the second.
5 Whys: for a single, linear causal chain
5 Whys is the simplest of the three: state the problem, ask “why did that happen,” take the answer, and ask “why” again, repeating until further “why” questions stop producing new information — conventionally around five iterations, though the real stopping point is when you reach a cause the organization can actually act on, not a fixed count.
What it’s for: deviations with one dominant, linear chain of causation — A happened because of B, B happened because of C. A missed second-operator verification signature is a good 5 Whys candidate: why was it missed → the reviewer was rushing → why was the reviewer rushing → the review queue had built up past end of shift → why did the queue build up → there’s no dedicated review slot before shift change → why is there no dedicated slot → the SOP doesn’t allocate one. That last answer is a system-level, actionable root cause: add a scheduled review checkpoint before shift end, not “remind reviewers to slow down.”
The failure mode it’s meant to prevent: stopping the investigation at the first plausible-sounding answer (usually the proximate cause) instead of continuing until the chain reaches a genuinely systemic condition. 5 Whys done badly looks like a single “why” followed by a corrective action — which is functionally identical to never asking why at all.
Where it breaks down: 5 Whys assumes one cause leads to the next in a straight line. Real deviations often have two or three factors that combined to produce the outcome — a training gap and a system that didn’t catch the resulting error and a review step that was skipped under time pressure. Forcing a genuinely multi-factor problem through a single linear chain produces an investigation that picks one branch and calls it the root cause, missing the others. That’s the signal to move to fishbone instead.
Fishbone / Ishikawa diagrams: for a problem with several independent contributing categories
A fishbone (Ishikawa) diagram organizes potential causes into standard categories — commonly Method, Machine, Material, Man (personnel), Measurement, and Environment in a manufacturing or lab context — branching off a spine that points to the stated problem. Each category gets populated with candidate causes, typically generated by the investigation team asking “why” within that category, so it’s often used alongside 5 Whys rather than instead of it: fishbone structures where to look, 5 Whys drills down once you’re looking in the right place.
What it’s for: deviations where the cause plausibly sits in more than one category and a single linear chain would prematurely narrow the search — an out-of-specification assay result, for example, could trace to the method (an ambiguous protocol step), the equipment (an uncalibrated instrument), the material (a reagent lot with a stability issue), the person (an undertrained analyst), the measurement system itself (an imprecise assay), or the environment (a temperature excursion in the room). Fishbone forces the team to check all six before converging on one.
The failure mode it’s meant to prevent: anchoring on the first explanation that comes to mind — usually the human factor, because “someone made a mistake” is the easiest story to tell — without systematically checking whether the equipment, materials, method, or environment contributed. A fishbone session that only fills in the Man branch and leaves the other five empty hasn’t actually used the tool; it’s used the diagram as a formality around a conclusion the team already reached.
Where it breaks down: a fishbone diagram is good at generating a wide candidate list but doesn’t, by itself, tell you which branch is the actual cause or how multiple contributing factors combined causally to produce the failure — it’s a brainstorming and categorization structure, not a causal logic model. For that, and especially for failures where the deviation only occurs when several conditions align at once, fault tree analysis is the more rigorous tool.
Fault tree analysis: for a failure that depends on a combination of conditions
Fault tree analysis works top-down and deductively: start from the undesired top event (the deviation, the failure, the out-of-spec result) and work backward, mapping the specific combinations of contributing conditions that could produce it, connected with formal AND/OR logic gates. An AND gate means every condition beneath it has to occur together for the fault to propagate up; an OR gate means any one of them is sufficient on its own. This makes fault tree analysis the right tool when a failure is genuinely conditional — it doesn’t happen every time condition X occurs, only when X and Y occur together, or when X occurs and the control that would normally catch it (Z) has also failed.
What it’s for: deviations involving a control failure, not just a process failure — a contamination event that only occurs when an aseptic technique lapse (condition X) coincides with an environmental monitoring result that should have flagged it but didn’t (condition Z), or an equipment failure that only produces a bad result when it happens between scheduled calibration checks. Fault tree analysis makes explicit which combinations of conditions are sufficient to produce the failure, which is exactly the structure a 5 Whys chain or a fishbone category list doesn’t capture on its own.
The failure mode it’s meant to prevent: treating a conditional, multi-cause failure as if it had a single cause, which produces a corrective action that only closes one branch of the tree and leaves every other combination that reaches the same top event still live. If the investigation fixes the aseptic-technique lapse but never asks why the environmental monitoring control also failed to catch it, the same top event can still occur next time through the other branch.
Where it breaks down: fault tree analysis is more effort than most deviations warrant, and it depends on the team actually knowing the control structure well enough to map it correctly — a fault tree built without genuine knowledge of the system’s controls just reproduces the team’s assumptions in diagram form. Reserve it for higher-severity or recurring failures where a control, not just a step, is implicated; it’s disproportionate for a single missed signature or a straightforward calibration miss.
Choosing by problem type: a quick reference
| Problem shape | Technique | Failure mode it prevents |
|---|---|---|
| One dominant, linear chain of causation | 5 Whys | Stopping at the first plausible-sounding proximate cause instead of the systemic condition beneath it |
| Cause could plausibly sit in several independent categories (method, equipment, material, person, measurement, environment) | Fishbone / Ishikawa | Anchoring on the human factor and never systematically checking the other categories |
| Failure only occurs when multiple conditions or control failures combine | Fault tree analysis | Fixing one contributing branch while leaving other sufficient combinations that reach the same failure still open |
These aren’t mutually exclusive. A common, defensible sequence is: fishbone to generate and categorize the candidate causes broadly, 5 Whys within the most promising category to drill down to a systemic cause, and fault tree analysis reserved for the subset of failures where the investigation reveals the deviation depended on a control also failing, not just a process step going wrong.
Substantiating the root cause, whichever technique you use
Regardless of technique, the CAPA record has to show the evidence behind the stated root cause — interview notes, training records, equipment calibration logs, prior deviation history, document revision history — not just the conclusion the technique produced. A root cause section that states “inadequate procedure clarity” with no cited evidence of what in the procedure was actually ambiguous, checked against what operators reported, is a conclusion without a trail, and it’s one of the more common findings auditors cite against otherwise well-run CAPA systems. This is one section within the larger CAPA record structure; see the full breakdown of what a defensible CAPA report and action plan needs in every section in the CAPA report and plan structure guide.
From root cause to corrective action
The point of correctly identifying the root cause is that the corrective action should follow directly from it, not from a generic template. A root cause of “ambiguous SOP wording” points to a document revision with the ambiguity specifically resolved and re-verified against how operators actually read the new wording — not to a training session on the old wording. A root cause that traces to “no physical separation between look-alike reagents” points to a storage or labeling change, not a reminder to read labels more carefully. When a proposed corrective action would materially change a process, system, specification, or facility layout, that change itself needs to go through change control as its own assessed and documented step, even when the CAPA is what generated the proposal — the CAPA record documents the investigation and the decision to change something; change control governs and documents the change itself.
Frequently asked questions
Is 5 Whys or fishbone the better default for a GxP deviation?
Neither is a universal default. 5 Whys fits a deviation where the investigation team already has good reason to believe the cause sits on one linear chain. Fishbone fits when the cause could plausibly be in more than one category and a single chain would narrow the search too early. Many teams run a short fishbone first to make sure they’re looking in the right category, then use 5 Whys within that category to drill down — which avoids committing to a single chain before checking whether the assumption is even right.
When is fault tree analysis actually necessary, versus 5 Whys or fishbone being enough?
Fault tree analysis earns its extra effort when the failure is conditional — it doesn’t happen every time one thing goes wrong, only when that thing coincides with a control also failing to catch it. If a single proximate cause reliably explains the deviation on its own, fault tree analysis is more structure than the problem needs; 5 Whys or fishbone will get to a defensible root cause faster.
Why isn’t “operator error” acceptable as a stated root cause even when a person genuinely made a mistake?
Because it doesn’t answer why a trained, capable person made that specific mistake at that specific point, which is the question a root cause has to answer. The person’s action is real, but treating it as the endpoint of the investigation, rather than the entry point into asking what about the procedure, the equipment, the label, or the workload made that action likely, produces a corrective action (usually retraining) that doesn’t change the conditions that produced the error and doesn’t prevent recurrence.
Does the root cause technique used need to be documented in the CAPA record itself?
Yes — the record should name the method used (5 Whys, fishbone/Ishikawa, fault tree, or a comparable structured technique) and show the evidence trail behind the conclusion, not just state a root cause as an assertion. See the root cause analysis section of the CAPA report and plan structure guide for what auditors specifically check for in that section.
