How to Perform Root Cause Analysis: The One Skill Every Manager Needs (But Most Get Wrong)

Connect with us: SB Nation | Doodle or Die | Pexels | Medium | Elephant Journal

Three weeks ago, I watched a $2.3 million project go sideways because nobody - and I mean nobody - bothered to ask "why" more than once. The project manager, a bright spark from Melbourne with an MBA and everything, blamed the vendor. The vendor blamed the timeline. The timeline got blamed on "unrealistic expectations." Classic stuff.

But here's what really happened: someone approved a purchase order without checking if the equipment would actually fit through the bloody warehouse door. That's it. One measurement. One question nobody asked.

This is exactly why root cause analysis isn't just some fancy management buzzword - it's the difference between fixing problems and just moving them around like deck chairs on the Titanic.

What Root Cause Analysis Actually Is (Spoiler: It's Not What You Think)

Most people think root cause analysis is about finding someone to blame. Wrong. Dead wrong. It's about finding the actual reason something went pear-shaped so you can prevent it happening again.

The whole point is getting past the surface symptoms to the real issue underneath. Like when your car keeps breaking down, you don't just keep buying new batteries - you figure out why the batteries keep dying in the first place.

I've been doing this for seventeen years now, and I reckon about 78% of workplace problems get "solved" by treating symptoms instead of causes. We're brilliant at putting band-aids on broken legs.

The Five Whys: Simple But Not Easy

Here's the thing everyone gets wrong about the Five Whys technique - they think it's about literally asking "why" five times. Sometimes you need three whys. Sometimes you need eight. The number isn't magic.

Let me walk you through a real example from last month:

Problem: Customer complaints about delayed deliveries have doubled.

Why #1: Why are deliveries delayed? Because our drivers are taking longer routes.

Why #2: Why are drivers taking longer routes? Because the GPS system is directing them inefficiently.

Why #3: Why is the GPS directing them inefficiently? Because it hasn't been updated with new road closures and construction zones.

Why #4: Why hasn't it been updated? Because nobody was assigned responsibility for maintaining the system.

Boom. Root cause: lack of clear responsibility for system maintenance. Not "bad drivers" or "unrealistic customer expectations."

The communication training aspect here is crucial too - half the time, problems persist because teams aren't sharing information effectively about what's actually happening on the ground.

Where Most People Stuff It Up

The biggest mistake I see - and I see it constantly - is stopping too early. Someone asks why once, maybe twice, gets an answer that sounds reasonable, and calls it done. That's not analysis, that's just chatting.

Another classic error: getting emotional about it. Look, I get it. When something goes wrong, especially something expensive or embarrassing, people want heads to roll. But if you're more interested in punishment than prevention, you're doing it wrong.

I worked with a company in Brisbane where every time something went sideways, they'd have a "lessons learned" meeting that was basically just a public flogging session. Surprise, surprise - people stopped reporting problems early. They'd wait until issues were so big they couldn't hide them anymore.

That's counterproductive as a chocolate teapot.

The Fishbone Diagram: When Five Whys Isn't Enough

Sometimes problems are more complex than a simple chain of whys can handle. That's when I break out the fishbone diagram, also called an Ishikawa diagram after the Japanese bloke who invented it.

Picture a fish skeleton. The head is your problem, and each bone represents a potential cause category: People, Process, Equipment, Materials, Environment, and Management. Under each bone, you list specific factors that might contribute to the issue.

This approach is gold when you're dealing with recurring problems or situations where multiple factors are at play. Like when workplace morale takes a nosedive - it's rarely just one thing causing it.

The beauty of the fishbone is that it forces you to consider causes you might not have thought of otherwise. Maybe the problem isn't just training or procedures - maybe it's the physical workspace making people cranky, or outdated equipment slowing everyone down.

Real Talk: Sometimes the Root Cause Is Uncomfortable

Here's what nobody talks about in those glossy management textbooks: sometimes the root cause points directly at senior leadership decisions. Or company policies that made sense five years ago but are now causing chaos.

I once did an analysis where customer service complaints kept escalating because staff couldn't make basic decisions without approval. The real cause? A micromanagement culture that had developed after one bad incident years earlier. Nobody wanted to admit it, but the "solution" had become worse than the original problem.

This is where things get politically tricky. You need effective communication training to handle these situations diplomatically while still being honest about what you've found.

The key is presenting findings as system issues rather than personal failures. Instead of "John's decision caused this," try "the current approval process creates bottlenecks that led to this situation."

Tools That Actually Work (And Some That Don't)

Beyond the Five Whys and fishbone diagrams, there are heaps of other tools floating around. Some are useful, others are just complexity for complexity's sake.

Pareto Analysis is brilliant for identifying which problems to tackle first. The 80/20 rule applies to most business problems - 80% of your headaches probably come from 20% of the root causes.

Failure Mode and Effects Analysis (FMEA) sounds fancy but it's basically systematic paranoia. You identify all the ways something could go wrong and rate them by likelihood and impact. Useful for complex processes, overkill for simple issues.

Statistical Process Control charts are fantastic if you're dealing with processes that generate measurable data over time. Completely useless for one-off incidents or people problems.

I'm not a fan of overcomplicated approaches that require three-day training courses to understand. If your analysis method is harder to learn than the actual job, you're probably overthinking it.

The Human Element: Why People Problems Are the Hardest

Technical problems are usually straightforward to analyse. Machine breaks down, you check maintenance records, usage patterns, environmental factors. Pretty logical.

People problems? That's where things get messy. Human behaviour is influenced by factors that aren't always visible or quantifiable. Someone's having personal issues at home, team dynamics are toxic, or there's miscommunication happening that nobody wants to admit.

The trick with people-related root causes is creating an environment where folks feel safe being honest. If everyone's worried about getting thrown under the bus, you'll never get to the real issues.

I learned this the hard way early in my career. Kept getting reports that "training wasn't effective" when the real problem was that new employees were too intimidated to ask questions. The training was fine - the culture was the issue.

When to Stop Digging

Sometimes you can analyse something to death. There's a point where you need to say "this is deep enough" and move on to solutions.

Generally, I stop when I reach one of these points:

• The next level down would require resources that exceed the problem's impact
• The cause is something genuinely outside our control (like market conditions or natural disasters)
• We've identified actionable items that will prevent recurrence

Don't get trapped in analysis paralysis. Perfect understanding isn't always necessary - sometimes "good enough to prevent it happening again" is sufficient.

That said, I've seen too many managers who stop at the first explanation that doesn't require them to change anything. That's not analysis, that's excuse-making.

Making It Stick: Implementation Matters More Than Analysis

Here's the thing that drives me absolutely mental: brilliant analysis that gets filed away and forgotten. I've seen comprehensive root cause reports that could've prevented millions in future problems, sitting in someone's inbox gathering digital dust.

The analysis is only valuable if it leads to actual changes. Document your findings, sure, but more importantly, assign specific actions to specific people with specific deadlines.

And follow up. Check that the changes are actually working. Sometimes what looks like a root cause turns out to be just another symptom once you implement solutions.

Create systems to monitor whether your fixes are effective. Set up check-ins three months out, six months out. Make it someone's job to ensure the problem doesn't resurface.

The Bottom Line

Root cause analysis isn't rocket science, but it does require discipline and honesty. Most problems have causes that are visible if you're willing to look past the obvious explanations and ask uncomfortable questions.

The problem solving training we do with teams always emphasises this: fix the system, not just the symptoms. It takes more effort upfront, but it saves massive headaches down the track.

Stop accepting "that's just how things are" as an explanation. Every recurring problem has a root cause, and most of them are fixable if you're willing to dig deep enough.

The next time something goes wrong in your workplace, resist the urge to find a quick scapegoat. Ask why. Then ask why again. Keep asking until you get to something you can actually fix.

Your future self will thank you for it.