Root Cause Analysis Made Simple

I think sometimes we think we have to do things a certain way. At some point you read, or were told, that you should use FMEA, or a fish bone analysis, or a scatter plot, or some such thing as the tool when doing a root cause analysis.

At this point, I bet many of you are nodding along, but secretly thinking, "Oh God, what are those things again? What the heck does FMEA stand for…and mean? It rings a bell but I don't really know what the letters mean or how it applies to a root cause analysis.”

And others are thinking, "What? This chick doesn't know what she's talking about. You should use a Fault Tree Analysis or Pareto Chart". And now some people new to Quality are panicking thinking that they really shouldn't have the job they have because their heart is racing at the term Root Cause Analysis and their head is spinning with all of these terms.

But honestly, let's just get logical and real and use our heads for a second. It doesn't matter which tool you use (unless your procedure dictates a certain tool and then you need to have a think about that procedure, possibly, and see if it makes any assumptions about people's understanding of why and how to use the tool it's named).

The tools, and the names of the tools, sometimes make a mountain out of a molehill. They take a root cause analysis and make it into a big deal. Or a bigger deal than it needs to be.

When you take your car to the mechanic he usually does a root cause analysis. But all he says is, "Hmm, let's get to the bottom of this." Right?

We're just talking about problem solving. That's all a root cause analysis is. Somebody just decided to put a fancy word on it and make it a "thing", but it's just good old problem solving. Relax.

So let's take the edge off of the fear and/or weight of these things. First of all, remember the point. The point is something's not working and so your customer isn't getting what they should be getting. You're just trying to fix it so it doesn't happen again.

No matter what fancy tool you're using, you're basically trying to find out what went wrong (or could have gone wrong), why it went wrong, and how you can make sure it doesn't happen again.

You can be systematic and logical without pulling out a fancy intimidating tool that not everyone on the team really understands. Or you can use the tool if you want to, but then just make sure you use very straightforward ways to explain how and why the tool is being used.

Start with some basic questions:

1. What happened? Or what could have happened? What's the problem?

When you're answering this, of course you'll need to gather up some info ("evidence"). You'll need to talk to people. Maybe there'll be photos. Maybe there'll be some data. Maybe there'll be some details about the impact of the problem. (E.g. three people were injured; or 50 mLs were pumped out instead of 5 mLs; or here's the error code from the instrument; or here's the stability data)

2. Why? What could have caused this??

You might have to talk to a pile of people here - the people who used it, sold it, wrote the product insert, designed it, built it, checked it, shipped it, picked the parts' suppliers, wiped down the instrument during spring cleaning, wrote the procedures about it. You get the idea. You might even need to bring some subject matter experts (SMEs) into the discussion. Include whoever you need, that's fine. Brainstorm. Why did this happen? Go.

3. Identify the root cause.?

This is the “analysis” part. This is usually where the fancy "tools" make an appearance. But remember, those tools are just a representation of some suggested ways to think. That's it. All we're doing here is thinking. So we ask, "Why did this happen?" And when you get an answer you say, "Okay, why did that happen?". Then you say, "Well okay, but why did that happen?" Until you get down to the fundamental, initial, root (call it whatever you want) reason for the problem.?

This is not necessarily an easy or quick process. You will have to dig around for each question. You'll feel relief, "Phew, okay we found the root". But then force yourself to say "Okay, just for good measure, let's ask one more, "But why did that happen?". You just keep going like an annoying toddler until you’re satisfied that you truly got to the bottom of it.

And another thing - remember that this isn't about making the auditor happy. Or doing something just because the procedure (that possibly hasn't been changed in twenty years) tells you to. This is about making sure you're always improving what you put out into the world.

Okay back to the "analysis":

4. Fix it.?

This will inevitably involve a CAPA - remember those things? You've got a procedure in place for this - but don't blindly follow it. Follow it with intention. And if it needs to be fixed, that can be next on your list of things to do. (Don't let procedures that don't work, or aren't easy to understand or use, stay in your system - you're just asking for trouble down the road. Always keep your eyes open for processes that aren't working or procedures that aren't doing their job well.)

The idea here is to fix it so it doesn't happen again (corrective action); to fix it so that something that could have happened doesn't (preventive action); and obviously, to fix what's broken (correction). So fix it.

5. Make sure it's been fixed.?

I bet this is where people start throwing around the word validate or verify (possibly not even really knowing the difference between them). Okay, use those words if you must, but really what you’re doing is checking up on things to make sure what was broken is now fixed.??

Remember, we’re making sure that this problem can’t happen again down the road. So you’ll probably need to write down a plan saying what you're going to do, when, to check on things.

And obviously you'll need to keep records of everything. Write it down. Type it in a Google doc. Stick it in a shared project management system. Who cares? The auditor doesn't care how sleek and sexy everything looks. The auditor cares that you've done what you're supposed to have done and can prove it. Technically, you don't need anything more elaborate than a pen or paper and a pile of binders. Yes, I know, that makes things cumbersome in big systems and is a bit old fashioned, but it's better than having a fancy electronic system that nobody knows how to use. Do what works. Big, small, fancy, plain. Doesn't matter.

That's it.?

In a nutshell and in simple, everyday words this is what a root cause analysis is all about.

Using simple words to explain what you're doing and think about what you're doing doesn't mean the root cause analysis will be any less effective. It just means everyone will understand what they're supposed to be doing and why. And so... gasp...it might even be MORE effective because no one will be? freaked out about this scary thing that makes them feel like they don't know what they're doing.

You DO know what you're doing. You've got this!

I hope this helps you help your team stop being afraid of things with official sounding, intimidating names - like Root Cause Analysis.

#medicaldevices #rootcauseanalysis #pharma #GMP #qualityassurance #biotech#LesleyWorthington

For those working on their English, here are a few of the idiomatic phrases that I slipped in. If you want to double check if your understanding matched how I used them, check here:

rings a bell - sounds familiar; feels like I've heard of this before

heart is racing - heart is beating fast (in this case, probably because of panic)

head is spinning - confused because there's so much to think about

use our heads - think

make a mountain out of a molehill - make something seem bigger (or harder or more serious) than it really is

big deal - to exaggerate the importance of something?

get to the bottom of it - find the real, original problem (hey, that sounds a lot like Root cause analysis, doesn't it?)

take the edge off - make it not so scary or stressful?

just for good measure - just to make sure you're doing everything as thoroughly as possible

to blindly follow something - to follow it without thinking

asking for trouble - creating a situation where you might have problems later on

down the road - in the future

in a nutshell - the idea in a short summary