When an issue arises, it’s important to take quick action. Whether that means a software patch is launched, a batch is pulled, or the use of a reagent is halted, it’s critical to tackle the immediate problem.
But just as critical as “how do we fix this?” is “How do we make sure this doesn’t happen again?”
That’s where the Root Cause Analysis comes in. This guide will walk you through how to conduct an effective Root Cause Analysis that takes you from “problem fixed” to “process improved.”
The term “Root Cause Analysis” might sound daunting, but at its core, it’s just a fancier way to say “find out why this issue really happened.”
Instead of just treating the symptoms, a Root Cause Analysis aims to identify the ultimate reason a problem occurred so that you can take steps to prevent the issue from arising again.
For example, maybe you discover a sample was stored at the wrong temperature. Did the storage machine malfunction? Did someone adjust the temperature to the wrong setting? Is the temperature gauge accurate?
You can discard the sample so it doesn’t impact future tests, but until you find the reason – or the root cause – of the issue, you won’t know what preventative actions need to be taken.
For any event you officially define as an issue, you must perform a root cause analysis.
That doesn’t mean every Root Cause Analysis needs to be a massive undertaking. The key is to match the scale of your investigation to the severity and risk of the problem.
If a technician makes a minor clerical error in a batch record, a quick investigation might show it was just a one-off mistake caused by typing a little too fast. You log it, identify the root cause as human error, confirm it’s an isolated incident, and move on.
But what if that same technician makes the same error every month? That's a pattern worth investigating further. “Human error” is no longer a sufficient root cause and your Root Cause Analysis needs to dig deeper. Is the batch record template confusing? Is the technician’s training incomplete? Is their workload too high, leading to rushed work? The investigation becomes lengthier and more comprehensive because the risk of a recurring issue is higher.
The length of your investigation may vary based on the severity of the problem, but all Root Cause Analyses tend to follow the same steps:
Your first move is to pull in the right people. When it comes to your investigative team structure, you have some options. It could be:
Regardless of the structure, your team must include two key groups:
Subject Matter Experts (SMEs): These are the people who understand the process, equipment, or material involved inside and out. If there’s an issue within the lab assay, you need the lab analyst. If a piece of manufacturing equipment fails, you need an engineer. It’s not the investigator’s job to automatically know the answers. They have to find the answers, and for that, you need the SMEs.
The person(s) involved: You need a first-hand account of what happened, so talk directly to the person who was performing the task when the issue occurred and/or the person who noticed and reported the issue.
Before you can uncover the “why” you have to clearly articulate the “what.” This is the issue description that must be included in your Root Cause Analysis documentation. The goal is to write the issue description so that a total stranger (like an auditor) can read it and understand the situation inside and out. A strong issue description captures the who, what, when, and where.
Be careful: These questions are deceptively simple.
A broken gauge might have been reported on August 3, but how long has it been that way? How do you know it wasn’t noticed earlier but not reported? Has it impacted other samples? What checks are in place to confirm your other temperature gauges are working properly? Take your time and think with a wide lens to make sure you capture the problem completely.
This is the core of the investigation. The most common technique is the "5 Whys" method, a problem-solving technique used to find the real root cause of an issue by repeatedly asking the question "Why?" (“5 Whys” is a bit of a misnomer. Regardless of how many times it takes, you’ll keep asking “why” until you hit the core of the problem).
Here’s an example for a product sample that yielded an out-of-specification test result:
1. Why was the test result out-of-specification?
2. Why was the sample contaminated?
3. Why did the glassware contain residue?
4. Why was the glassware not properly rinsed?
5. Why was the technician unaware of this requirement?
At this point, you may think the outdated SOP is the root cause of the issue, but this is still a symptom or contributing factor. Even if we replace the SOP with the updated version, how do we know there aren’t more outdated SOPs floating around the premises? A similar problem could easily arise again. There’s still another “why” we can ask.
6. Why was the outdated SOP still in the lab?
It’s now easier to see the preventative action that’s necessary: the organization needs a formalized document control process, and likely an eQMS or eDMS.
Categorizing your root causes can help you identify trends or weak spots in your processes. It’s common for life sciences organizations to use frameworks like the 6 Ms to explore potential causes related to:
Once you’ve gotten to the heart of the issue, it’s time for a Corrective and Preventive Action (CAPA), which should be directly derived from your root cause analysis. If the root cause was an unclear SOP (Method), your CAPA will be to revise that SOP and retrain the team.
And don’t forget, your quality system must include a process for checking that your changes were effective. That could mean monitoring the process for three months or performing an audit a year later to ensure the problem hasn't returned.
A thorough Root Cause Analysis involves coordinating people, gathering evidence, documenting findings, and tracking actions. It can be a lot to manage, and doing it all with paper, email, and spreadsheets is a recipe for chaos and missed steps.
This is where an electronic Quality Management System (eQMS) becomes a game-changer.
Ultimately, an eQMS transforms your RCA process from a reactive, paper-shuffling exercise into a proactive, data-driven engine for continuous improvement.