Root Cause Analysis Tools: Which One to Use, When, and in What Order

A consumer products company I worked with had a problem with its finished goods that kept coming back for more than a decade, at least by the count of its longest-tenured employees. It wasn’t a safety issue, but customers noticed it, and every time it showed up it chipped away at how those customers saw the brand.

They weren’t ignoring it, either. Every time it came back they did what most companies do: got everybody in a room, ran a round of testing, landed on something that looked like the cause, documented it, retrained the people involved and checked it off the list. A few months later, sometimes a year later, it was back.

When we finally got to the bottom of it, we didn’t use a single tool they hadn’t heard of. We used the same root cause analysis tools everybody uses. What changed was which tool we picked up first, and the order we used the rest of them in.

Prefer listening? Check out this week’s Solo Session where I go even deeper on the topic.

Why the problem keeps coming back after you “fixed” it

I see the same loop all the time. Something goes wrong, and somebody Googles how to run a five whys. You get the team into a room, ask why five times, retrain everybody, make sure it’s documented, and you’re a hundred percent confident the problem is solved, right up until it happens again.

When companies reach out to me about this, they rarely describe it as a root cause problem. They say something like “same problem, different day,” or “we keep fixing the same thing.” Most leaders can name at least one problem they feel like they’ve fixed several times this year, or several times over the last few years.

In most of the shops I walk into, the tool has very little to do with why the problem keeps coming back. Two other things do. The first is picking a tool out of habit instead of matching it to the problem in front of you. The second is where the investigation stops, which, more often than not, is at a person.

Not every problem deserves a full investigation

I get some pushback on this one, but I’ll say it anyway: not every problem needs a full root cause investigation.

You always have to weigh the work against the risk. How big is this issue, what’s it costing, and how exposed are we if it happens again? If you don’t understand the scope and the impact, it’s easy to build a process that requires the full treatment for everything, and that turns into a lot of bravado. People go through the motions on the small stuff, and over time they start phoning it in on the big stuff too.

I was talking with someone recently who had built a set of AI bots to handle a lot of the admin prep work in their business, with a person reviewing every output before it moved forward. That’s a good design on paper. In practice, people get fatigued from double-checking things that are almost always right, and slowly but surely the review turns into “yep, looks good, go.” A root cause process that demands a full investigation for every hiccup fails the same way.

So scale the response to the problem:

• Small and contained: contain it, log it and move on.
• Logged and starting to repeat: look closer. One client of mine put it well when we were working through a minor setup error together: “this exact issue hasn’t happened, but this issue in a different form does happen all the time.” That pattern only shows up if you log the small ones.
• Reaching customers or costing real money: this is where the full investigation earns its time. In the same conversation I pointed out that if the mistake had been on a $10,000 order that had to be remade, we’d be having a very different discussion.

Root cause analysis tools, and which one to use when

I’ll make an admission first. I usually start with a 5 Whys, and the main reason is that I’ve run so many of them that I’m pretty versed in how to administer one with a team. That’s my habit, though, and it isn’t a rule anybody else should copy. Here’s how I’d actually think about where to start.

Scope is usually what decides the starting point. Some product quality problems are obviously tied to one work center or one piece of equipment, and you can start close in. Others could have happened anywhere, and if you start close in on one of those, you’ll do a beautiful 5 Whys on the wrong part of the operation.

The fishbone and the Pareto chart are the two tools I don’t talk about enough. Both help you get to a short list. The fishbone does it by getting everybody’s theories in front of the group, and the Pareto does it by letting the data rank them. Once you have that short list, the 5 Whys or an 8D does the digging.

A 5 Whys is a tool I love, and it’s also the one that goes wrong most often. Asking why five times is the easy part. The hard part is picking apart each answer and asking the next appropriate question, and when a team isn’t practiced at that, the 5 Whys stops at a symptom or stops at “operator error.” I’ve watched this enough times to believe that people rarely don’t know the answer. What they’re missing is the next question. (If your investigations keep stalling before they even start, the problem is often upstream, in a weak problem statement.)

I hate giving “it depends” as an answer, but it’s the truthful one, and it’s also why this is hard to do well until you’ve done it a bunch of times. You make mistakes, you make assumptions, and eventually you build enough experience to know which flow of tools gets you closest to the answer without walking in with any preconceived notion of what the answer is.

It wasn’t the tool. It was the order.

Back to the consumer products company. The problem could have started anywhere across their supply chain, so we didn’t start with a 5 Whys. The order went like this:

1. A high-level process map of the entire supply chain for that product, so we could see every touchpoint that could possibly affect the finished goods.
2. Data analysis, which mostly told us how little data there was. Their formal complaint tracking was only a couple of years old for a problem that was more than a decade old, and that gap told us something too.
3. A Pareto on what data we did have, to narrow where to look.
4. Interviews with employees and with suppliers. These were the most telling part of the whole investigation. The people closest to the process knew things that had never been written down or connected.
5. A 5 Whys, once we knew where to point it.

The root cause turned out to be no governance over one of their tier 2 suppliers, the supplier to their supplier. Think about where every earlier investigation had been run: inside their own building, by their own team, on their own process. No 5 Whys run in that room was ever going to reach a supplier two steps removed, because nobody in that room owned that relationship.

The tools were never the problem. The map and the interviews pointed somewhere nobody had looked, and getting the order right is what finally let them resolve something that had been plaguing them for a really long time.

Walking in with the answer already decided

The other reason the order matters is that it protects you from your own assumptions.

Earlier in my career, I was running a print manufacturing plant where we had an intermittent problem between printing and die cutting. In printing, the image has to land in the same spot on every sheet, which is called register, and it has to hold all the way through the die cutter. Any variation in register on the press, on the die cutter or between the two makes it look like the print shifted, and the finished product is unusable.

We went in assuming it was a setup issue, either on the press or on the die cutter, and most likely an operator who wasn’t setting up correctly. After a lot of monitoring, a lot of testing and a lot of 5 Whys, it turned out to be mechanical. The die cutter had an inner and an outer set of head stops, and the outer set wasn’t functioning. The operators didn’t know that. They thought they were using all four, which is what you’re supposed to do on a wide sheet. When press speeds hit a certain level, the sheet would hit the two inner head stops, twist one way or the other depending on how it came across the feed table, and come out of register.

That’s what makes a starting assumption expensive. Once you’ve decided it’s the operator, every tool you pick up becomes a way to prove it. You’re not investigating anymore, you’re building a case.

Equipment, system or human: how I classify errors

This brings me to the definition I use for human error, which is probably different from most people’s. I’ve landed on it based on the things I’ve come across and dealt with firsthand. In my world there are three kinds of errors:

• Equipment: a part failed. The head stops are a good example.
• System: a process exists and the tools exist, but they weren’t followed.
• Human: there was no system, and somebody had to make it up.

Most investigations stop at the second one and call it the third. Joe didn’t follow the procedure, so it’s a people problem. My contention is that most of the time, people don’t follow a process for a reason. You may not agree with the reason, but very few people deliberately go outside the system. I’m not saying never, because I’ve come across a few bad actors who want to cause disruption. I’m talking about the other 99 out of 100 people. When they go outside the bounds of a process, there’s a reason, and it’s our responsibility as leaders to understand what it is. That’s why I classify it as a system failure.

Human error, the way I use it, means there was no system. Maybe the scenario only comes up once or twice a year and there’s “technically a process for it,” but it’s loose enough that everybody makes it up as they go. That’s human judgment, and judgment won’t always line up with what leadership would have wanted. That’s a fair use of “human error,” and it’s also a huge opportunity, because the fix is to define the process and build a system that supports it.

So I have very few human errors in my world. Most things get classified as system errors, and I’ve seen that shift become one of the most effective levers there is for driving repeat issues completely out of a business. It’s also the point most root cause analysis guides skip: you can’t find a deviation from a standard that was never defined.

“Retrained” is a bet, not a fix

When I raise this with a quality manager, the pushback I get is usually some version of: “We retrained, we documented it, and it hasn’t come back in six months. Retraining worked.”

Maybe it did. I’m sure there are cases where retraining is the right fix. More often, though, it’s something we rest on, and we’re really just gambling that the problem won’t come back. My first question back is always whether they’ve tested it. Has anyone deliberately introduced the failure into the process to see whether the retraining actually holds? I’d venture a guess that it rarely happens. (I wrote about how to test whether a corrective action worked a couple of months back.)

Retraining is the right fix in a narrow situation: a relatively new person running into something for the first time, inside a well-developed system. By well-developed, I mean a system that doesn’t rely on memory. It relies on understanding and following the workflow. That nuance matters, because some people will hear it and think, well, I do have a process, people just have to pay attention. That’s not what I’m talking about. If the process only works when somebody remembers the right thing at the right moment, it isn’t the kind of system I mean.

A recent example: a custom manufacturer I’m working with runs a lot of repeat work for the same customers, and those jobs share most of their specifications. Their process is to pull up an old order, duplicate it, and then change everything that shouldn’t carry over. You can imagine how much an operator has to know and remember to do that right every time. One of the things that keeps slipping through is simple: the contact information, meaning who ordered the job and what their email is, which has to sync between their production system and their accounting system.

When it goes wrong, the natural reaction, there and almost everywhere else, is that it’s operator error and the team needs retraining on how to write up an order properly. Because I’ve been through this enough times, I pushed back. Even if that process were perfectly documented, there would still be room for mistakes, because the system has limitations built into it. So the options we’re working through look like a ladder:

• Turn off the ability to duplicate orders altogether, if the system allows it.
• If not, make the contact fields required and stop them from copying over, so nobody can save the order without entering them.
• If the system can’t do either, put the three critical elements in a pop-up checklist, a visual one-to-one check at the moment of entry.
• Whatever lands, audit it proactively. That’s the part people push back on most, and it’s how you move from somebody’s memory to a standard you can count on.

We’re still in the design phase on that one, so I can’t tell you how it ends yet. What I can tell you is that “operator error, operator retrained” is only ever as strong as people’s memory and the system you’ve built around them.

I saw this pattern at a much larger scale when a certified manufacturer ran a batch of its already-closed corrective actions back through a structured root cause process. In most of them, what the team had called the root cause turned out to be a symptom, and the preventive measures would never have stopped a recurrence. These were closed, audited corrective actions at a company with a working quality system.

Make the fix harder to forget than retraining

The fixes on that ladder run in order of strength. Reminders and retraining sit at the bottom. Above them come written instructions, then visual cues, then process controls in the system itself, and at the top, making the mistake impossible.

That top rung is the holy grail, and people tell me from time to time that it’s impossible. It isn’t. At one point in my career I was responsible for a plant that made mission-critical documents for retail, medical and transportation customers, industries where you really can’t get anything wrong. Our internal process had allowed mistakes to make their way out to customers, and after one very expensive failure we were tasked with what felt like an impossible goal: no errors leaving the building.

It was one of the hardest things I’ve done and one of the experiences I’m proudest of, mostly because of that team. In the year we finished making the changes, returns and allowances came in at 0.04%, and the one credit we issued was for a minor issue that had nothing to do with whether the product could be used. (The custom software we built as part of that system is in the corrective action article.)

Did it take time? A lot of it. Did it take a ridiculous amount of effort and cost us some money? Yes. It was worth it because of the triage question from the beginning: mission-critical documents were our entire business, so the exposure justified the depth. Not every problem earns that level of investment. The ones that can sink you do.

Who should run the investigation

In a 20 or 50 person company with no quality department, the default is for the person who owns the process to investigate their own process. That’s exactly how investigations end up proving whatever that person already believed.

My answer is that someone from leadership should run it, with the different teams that touch the process represented in the room. That person’s job isn’t to have the answer. It’s to keep asking the next question and to keep any one function from closing the investigation on its own theory. On the consumer products problem, the answer only came out because the employees and suppliers who touched the process were part of it.

What to do Monday

Pull the last five or ten corrective actions you’ve closed. If you don’t run formal corrective actions, pull your last five or ten 5 Whys, or the last five or ten product quality or service delivery problems your team dealt with.

Count how many of them were closed with some version of “operator error, retrained all operators” or “recreated the work instruction, retrained all operators.”

For each one, ask yourself honestly how likely that problem is to come back. Then pick the one you’d bet on coming back first, and before it does, run it again. This time, start by deciding how wide the problem could be, and choose the first tool based on that instead of habit.

Final Thoughts

The companies that keep fighting the same problem aren’t short on root cause analysis tools. Most of them already own every tool on the list. What they’re missing is the judgment about which one to pick up first, the discipline not to walk in with the answer already decided, and a definition of error that sends them looking at the system instead of the person.

For the consumer products company, a decade of recurring complaints came down to a question nobody had thought to ask about a supplier nobody owned. It wasn’t the tool. It was the order.

That’s it for today.

See you all again next week!

Dave