Skip to content
Root Cause blog image
Lexi Sharkov09/03/258 min read

How to conduct a Root Cause Analysis: A step-by-step guide [with examples]

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.”

What is a Root Cause Analysis?

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.

Brush up on quality management fundamentals with the eQMS 101 eBook.

Learn how to choose an eQMS, QMS software costs, and how to get leadership approval for the quality management software you need. 

Get Your Copy

101 ebook graphic fanned pages

When do you need to conduct a Root Cause Analysis? 

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.

How to conduct a root cause analysis step-by-step

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:

Step 1: Assemble the right team

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:

  • A formal committee with representatives from different departments (Quality Management, Manufacturing, Regulatory, etc.).
  • The Quality Management team exclusively.
  • One dedicated "investigator" whose job is to interview people and collect information.
  • An ad-hoc team assembled specifically for the issue at hand.

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. 

Step 2: Write a crystal-clear issue description

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

  • Who: Who discovered it? Who reported it? Who was performing the task? Use clear identifiers, whether that’s full names or first initial and last name.
  • What: What exactly happened? Give as much detail as you possibly can. Not just "a reagent failed," but "Reagent Kit Lot #123 failed its quality control check, yielding out-of-spec results for Assay XYZ". Avoid acronyms, abbreviations, or confusing jargon.
  • When: Get the exact date and time, down to the minute if possible, and timezone (e.g., August 27, 2025, 2:37 PM PST).
  • Where: Where did it happen physically (e.g., Lab 3, Cleanroom B, Manufacturing Site A)? And where in the process? Was it during a specific client's batch? Multiple batches? On a specific line? This helps define the scope and impact of the issue, ultimately informing your overall action plan.

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. 

Step 3: Start asking “why”

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?

  • The test equipment detected a large, unexpected peak, indicating the sample was contaminated.

2. Why was the sample contaminated?

  • The glassware used to prepare the sample contained residue from a cleaning solvent.

3. Why did the glassware contain residue?

  • It was not properly rinsed with deionized water after being washed with the solvent.

4. Why was the glassware not properly rinsed?

  • The new lab technician who washed the glassware was not aware that a final rinse with deionized water was required.

5. Why was the technician unaware of this requirement?

  • The technician was trained using a one-page work instruction posted near the sink, but that document is an outdated version of the official SOP and omits the final rinsing step.

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?

  • The organization lacks a formal document control process and document management tool for retrieving and destroying outdated printed materials when a new version becomes effective. 

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.

Step 4: Categorize, fix, and reassess

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:

  • Man: The people involved in the process.
  • Machine: The equipment and tools used.
  • Method: The procedures and SOPs being followed.
  • Material: The raw materials and inputs required.
  • Measurement: Data from product specifications or process monitoring.
  • Mother Nature: The environment (e.g., temperature, storm-caused power outage).

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.

The best tool for conducting root cause analysis

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. 

  • Centralized Collaboration & Documentation: An eQMS makes it easy to rally the troops. Instead of sending documents around for review and signature, everything lives in one electronic record that all assigned team members can access, review, and sign off on.
  • Linked Evidence for Audits: A robust eQMS allows you to directly link your investigation to other critical records. You can link to the SOP that wasn't followed, link to previous recurring issues, and link the newly revised SOP as evidence that you fixed the problem. This creates a clean, easy-to-follow audit trail.
  • Data-Driven Insights: An eQMS with custom fields and reporting dashboards lets you easily track metrics related to your issues. Which root cause category is most prevalent? Are we seeing recurring human errors that point to a training gap? This business intelligence helps you identify your biggest weaknesses and focus your improvement efforts.
  • Accountability and Timeliness: An eQMS keeps you honest about deadlines for your CAPAs. Automated reminders and dashboards show you what tasks are coming due (or are already overdue), helping you actually complete your action plans on time.

Ultimately, an eQMS transforms your RCA process from a reactive, paper-shuffling exercise into a proactive, data-driven engine for continuous improvement.