Stop Playing Detective: Why Most People Get Root Cause Analysis Completely Wrong

Last Tuesday, I watched a senior manager at a major Melbourne firm spend forty-five minutes in a meeting trying to figure out why their customer complaints had doubled. The discussion went something like this: "Maybe it's the new staff?" "Could be the system upgrade?" "What about the weather affecting deliveries?" By the end, they'd identified seventeen possible causes and assigned three different people to investigate completely unrelated issues.

Classic case of analysis paralysis masquerading as problem-solving.

Here's the thing that drives me mental about how most organisations approach root cause analysis – they treat it like a bloody treasure hunt instead of a systematic investigation. After fifteen years of watching businesses fumble around in the dark, I've come to one controversial conclusion: most people shouldn't be let anywhere near a root cause analysis without proper training.

And yes, I'm talking to you, Mr "I've got common sense, that's all I need."

Root cause analysis isn't about being clever or having good instincts. It's about following a methodology that prevents you from chasing shadows and wasting everyone's time. But before we dive into the how, let me share something that might surprise you: 73% of workplace problems that get "solved" using traditional brainstorming sessions resurface within six months. Why? Because nobody actually found the root cause in the first place.

The first controversial opinion I'm going to throw at you is this – most problems in Australian workplaces don't actually need solving. They need preventing. But we've become so addicted to being the hero who swoops in to fix things that we never step back and ask why the problem existed in the first place.

Take Toyota's approach to root cause analysis training – they don't just teach their people to fix problems, they teach them to prevent them. Revolutionary stuff, right? Except it's been around since the 1940s and most Australian companies are still playing catch-up.

Now, let me walk you through what real root cause analysis looks like, not the amateur hour version most people attempt.

First step: Define the problem properly. Not "sales are down" or "customers are unhappy." I mean really define it. When did it start? How often does it occur? What's the measurable impact? If you can't put numbers on it, you're not defining a problem – you're sharing an opinion.

I learned this the hard way about eight years ago when I spent three weeks investigating why a client's team productivity had supposedly dropped. Turns out, productivity hadn't dropped at all – one manager was just comparing busy periods to quiet periods and panicking. Lesson learned: assumptions make you look like an idiot.

Second step: Gather data, not anecdotes. This is where most people go wrong. They ask Bob from accounting what he thinks happened, then Sally from HR, then make decisions based on whoever told the most convincing story. Data doesn't lie. People? Well, they don't always intentionally lie, but memory is a funny thing.

The Five Whys technique gets thrown around a lot, and fair dinkum, it works when used properly. But here's where people mess it up – they stop at three whys because they've found something that sounds reasonable. Or they keep going to eight whys because they think more is better.

Five is five for a reason. Toyota figured this out through decades of testing. Trust the process.

Let me give you a real example. Problem: "Our delivery times have increased by 30% over the past quarter."

Why? Because drivers are taking longer routes.

Why? Because the GPS system is suggesting different paths.

Why? Because the traffic data was updated but not calibrated for our delivery windows.

Why? Because IT implemented the update without consulting operations.

Why? Because there's no cross-departmental communication protocol for system changes.

Root cause: Lack of communication protocol. Not "drivers are slow" or "GPS is rubbish." See the difference?

Here's my second controversial take: fishbone diagrams are overrated. Everyone loves drawing them because they look impressive in presentations, but half the time they become elaborate ways of documenting every possible thing that could go wrong rather than focusing on what actually did go wrong.

Sometimes a simple timeline is more effective than a complex diagram that takes three people to interpret.

The other thing that drives me nuts is when people confuse correlation with causation. Just because two things happened around the same time doesn't mean one caused the other. I once had a client convinced that their customer satisfaction scores dropped because they changed their office coffee brand. Turns out, they'd also changed their customer service phone system the same week, but apparently coffee was a more interesting culprit.

Now, here's where things get interesting. The real skill in root cause analysis isn't following the process – it's knowing when to stop digging. Some people get so obsessed with finding the "ultimate" root cause that they trace problems back to the Industrial Revolution. At some point, you need to find a cause that's actionable and within your control to fix.

This brings me to something most training courses don't tell you: sometimes the root cause is a person. Not their skills or their training or their resources – just them. They're either not capable of the role or they don't care enough to do it properly. This is uncomfortable territory for most managers, but pretending personality or attitude issues are always systemic problems doesn't help anyone.

I've seen problem solving decision making training programs spend hours teaching people to analyse equipment failures and process breakdowns while completely ignoring the human element. But here's the reality – in service industries, which most Australian businesses are, people problems are often the actual root cause.

The key is being brave enough to address it directly rather than hiding behind systems and processes.

Another thing they don't teach you in business school: sometimes the root cause analysis reveals that the problem isn't actually a problem. It's a feature of your chosen business model. If you're running a budget airline, people are going to complain about legroom. If you're operating a 24/7 call centre, you're going to have tired staff on night shifts. Don't waste time "solving" inherent trade-offs.

Let me share something that might sound obvious but apparently isn't: document everything. Not just your findings, but your process. I can't tell you how many times I've seen organisations solve the same problem multiple times because nobody recorded how they solved it the first time.

And please, for the love of all that's holy, follow up on your solutions. Root cause analysis without implementation verification is just expensive consulting.

Now, here's where I'm going to contradict myself slightly. Earlier I said most people shouldn't do root cause analysis without training, but I also think too many organisations over-complicate it. You don't need a Six Sigma Black Belt to figure out why your printer keeps jamming. Sometimes it really is just because someone keeps loading the wrong paper size.

The trick is knowing which problems need the full treatment and which ones need common sense. A good rule of thumb: if the problem costs more than $10,000 or affects more than ten people, bring in the proper methodology. Otherwise, just fix it and move on.

Speaking of methodology, let me tell you about one of the most useful techniques nobody talks about: the "So What?" test. After you've identified what you think is the root cause, ask yourself "So what?" If the answer is "Well, that's just how things are," you haven't found the real cause yet.

For example: "Why did the project run over budget? Because the client kept changing requirements. So what? Well, clients always change requirements." That's not a root cause, that's an excuse. The real question is why your project management process doesn't account for scope creep.

Here's something that'll probably annoy the quality management crowd: sometimes good enough is good enough. If you've identified a root cause that you can fix for reasonable effort and cost, don't keep digging for a "better" root cause. Perfect is the enemy of done, as they say.

I remember working with a Perth-based manufacturer who spent six months investigating why their defect rate had increased from 0.2% to 0.4%. The investigation cost more than fixing the defects for the next five years would have. Sometimes you just need to accept that some problems aren't worth solving.

Let me wrap this up with something practical: if you're going to do root cause analysis properly, invest in creative problem solving training for your team. Not because the problems are necessarily creative, but because most people's thinking gets stuck in obvious patterns. They see a customer complaint and immediately blame customer service. They see a safety incident and immediately blame the worker.

Real root cause analysis requires you to think differently, question assumptions, and sometimes discover that the obvious answer is completely wrong.

The bottom line? Root cause analysis is a skill, not a talent. It can be learned, but it requires discipline, proper methodology, and the courage to dig deeper than most people are comfortable with. Stop treating it like a group brainstorming session and start treating it like the systematic investigation it should be.

Your future self will thank you when you're not solving the same bloody problems over and over again.