Early in my career I read a CAPA whose corrective action, in full, was: “Operator counseled to be more careful.”
Reader, they were not more careful. The same nonconformity showed up eleven months later, on a different shift, with a different operator, and the second CAPA said “Operator retrained.” By the third one, somebody had at least started writing “human error” in the root cause box, which I suppose counts as progress.
Here is the thing nobody says out loud: “the operator made a mistake” is almost always true. That’s what makes it so seductive. It’s accurate, it’s verifiable, it explains the event, and it’s completely useless.
What the requirement actually asks for
ISO 13485:2016 §8.5.2 says the organization shall take action to eliminate the cause of nonconformities in order to prevent recurrence, and that your documented procedure has to cover “determining the causes of nonconformities.” Note the plural. The standard does not assume there’s one villain.
It also says corrective action shall be “proportionate to the effects of the nonconformities encountered” — which is your permission slip to not run a full fishbone on a typo, and your obligation to run something real on the thing that reached a patient.
And since the QMSR incorporates ISO 13485 by reference, this is now the federal expectation too, not just the certification one. It shows: inadequate investigation and CAPA remains one of the most-cited problem areas FDA writes up. The recurring sentence in warning letters is some version of “you failed to identify the root cause.” Not “you failed to fix it.” Failed to find it.
Why 5 Whys keeps landing on a person
Five Whys is a genuinely good tool that fails in a specific, predictable way: it walks backward through a causal chain, and a human being is usually the last thing that touched the process. So the chain terminates at whoever was standing there.
Watch it happen. The label on lot 4412 was wrong. Why? The operator loaded the wrong label roll. Why? She didn’t verify the part number. Why? She didn’t follow the SOP.
Four whys and we’ve arrived at a named employee and a training record. It has the shape of an answer. Everyone in the room is relieved, because the alternative is admitting something about how the line is set up.
So here’s the discipline I’d offer, and it’s the only RCA rule I’d tattoo on anybody: when a “why” lands on a human, the next “why” has to be about the system that let them. Keep going.
Why didn’t she verify the part number? Because two label rolls for two different catalog numbers are stored in the same bin, the part numbers differ by one digit, the printed text is 6-point, and the SOP’s verification step is a checkbox at the end of the run rather than a gate at the start.
Now you have something to fix. Segregate the bins. Change the label stock so the two are visually distinguishable at arm’s length. Move verification upstream so it’s a stop point, not a signature. None of those corrective actions require anyone to be more careful, which is excellent, because “be more careful” is not a control — it’s a wish.
When one line isn’t enough
Five Whys is linear, and plenty of real failures aren’t. When several conditions only caused trouble together, use a fishbone (Ishikawa) and work the categories: people, process, equipment, materials, environment, measurement. You’re not hunting the one true cause; you’re mapping the set of conditions that made the failure possible, then deciding which you can actually remove.
A quick tell that you’ve found a systemic cause rather than a proximate one: could this same failure have happened to a competent, well-rested, well-intentioned person on a good day? If yes, you’re looking at the system. If your fix only works when everyone is paying unusual attention, you haven’t fixed anything — you’ve written an inspirational poster.
But sometimes it really is training
I want to be fair here, because the pendulum swings too far the other way and people start treating “training” as a forbidden word. Sometimes it genuinely is a contributing cause. Someone was qualified on revision C and the process moved to revision E. Someone was signed off after shadowing a shift, which is not the same as being competent.
The distinction is this: if training is part of the answer, the finding is about your training system, not about that individual. The corrective action isn’t “retrain Maria.” It’s “our qualification method for this operation doesn’t demonstrate competence, and here’s how we’re changing it” — which is exactly the bar ISO 13485 Clause 6 sets when it asks you to evaluate the effectiveness of training rather than just record attendance. Retraining one person is a correction, not a corrective action. It fixes the thing. It does not fix the cause.
Do this today
- Pull your last ten closed CAPAs and read only the root cause field. Count how many end at a person or at “training.” If it’s more than a couple, that’s your real finding.
- Add a stop rule to your investigation form: if the stated cause is human error, the record must also state what about the process, tooling, layout, or documentation permitted it.
- Check for repeats. The same nonconformity recurring under a different CAPA number is the single loudest signal that the first root cause was wrong. Trend by cause, not just by count.
- Write the cause so a stranger could act on it. If your root cause statement doesn’t tell someone what to change, it’s a description of the event wearing a hat.
That third one is where a real system of record earns its keep. When findings, causes, and CAPAs live in one place across quarters instead of in a folder per audit, “we’ve solved this before” stops being a hallway conversation and starts being a chart. It’s also the difference between an audit program and a stack of audit reports.
Root cause analysis isn’t about assigning blame, and it isn’t about heroically refusing to assign blame either. It’s about answering one question honestly: what would have had to be different for this to be impossible? If the answer is “a person would have had to try harder,” keep asking.
Next in the series: effectiveness verification — proving the fix actually worked, which is the step everyone fumbles, usually by declaring victory the day the SOP is signed.