Root Cause Analysis: Three Practical Techniques for Solving the Right Problem

At BeyondFS, we use a few simple tools to ask better questions and get everyone pointing in the same direction. Here are three techniques we come back to time and again.

There’s a moment right at the start of any project where you can either set yourself up for success, or build in confusion from day one. 

That’s why we start by asking what we call the Framing Question:   

How can we improve [target process], to overcome [identified pain points], whilst exploiting [strengths and opportunities], in order to achieve [organisational goal]. 

This is an example of the “measure twice, cut once” principle. Before you get into planning or delivery, it’s a step back to make sure you’re solving the right problem – because if you frame that wrong, everything that follows is built on shaky ground. 

In one project we were helping a client who needed to overhaul their change control process. Delivery risks were creeping in, and there was a real danger they'd miss a key regulatory deadline. Before diving into process maps and risk logs, we sat everyone down and framed it like this: 

How can we improve our client's change request process to overcome unapproved delivery risks, while making the most of strong relationships between project managers and the project management office (PMO), so we can meet the regulatory deadline without late-stage rework? 

It took 20 minutes to agree this sentence, but it ended up being the anchor for the next three months of work. When decisions started drifting, as they always do, we were able to pull everyone back to that one clear aim. 

You can also use this technique for internal business cases, especially when it’s not immediately obvious why a piece of work matters. 

Sometimes the problem isn’t one big thing - it’s lots of little things all tangled up together. That’s when a Fishbone Diagram helps. 

You start with the problem at the “head” of the fish. Then you map out all the contributing causes, grouped into standard categories like People, Process, Tools, Governance, and Environment. 

It looks something like this: 

As an example, say your team is missing SLAs, morale’s dipping, and complaints are going up, but no one’s quite sure why. 

You run a Fishbone session with the people closest to the work. Map out everything: tasks, hand-offs, decision-making, systems, and practical stuff like desk layout, noise, or broken comms channels. 

You can tweak the categories to fit your environment. In financial crime projects, we often use headings like Systems, Data, Policy, Training. 

Then use red-dot voting (more on that below) to highlight where the team thinks the real issues sit. 

Within an hour, you’ve usually separated the minor noise from the things that need proper attention. 

Adding structure and discipline matters. Left to themselves, people will naturally jump to the causes they already know about. A Fishbone forces you to go wider. 

Sometimes a problem seems simple but keeps coming back. That’s a sign you’re fixing a symptom, not the real cause. 

This is where the Five Whys technique helps. You keep asking "Why?" until you hit a cause you can actually fix. 

For example, we were reviewing supplier governance for a client, and late due diligence reports were a constant factor. The conversation went like this: 

• Problem: Supplier due diligence reports are late 

• Why? The workflow steps aren’t being followed 

• Why? People don’t know who owns each step 

• Why? Ownership wasn’t updated after a team restructure 

• Why? The target operating model (TOM) document wasn’t updated 

• Why? There’s no governance process for keeping it live 

At first glance, the obvious solution would have been retraining staff. But the real issue was structural: the governance framework couldn’t keep up with organisational changes. 

The eventual fix was to introduce a quarterly review of the TOM document, linked to human resources (HR) updates. 

If you want a quick, visual way to surface the biggest causes, red dot voting is a simple trick that works brilliantly. 

Start with a Fishbone diagram (or just a list of causes). Give everyone three red stickers. Ask: Where do you think the biggest problem is? 

You’ll quickly see where the real consensus lies - which is particularly useful when you’re dealing with a room full of strong opinions. Just watch out for bias, and sense-check what comes up against the data where you can. 

This method has its roots in the famous wartime “measles map” story, where engineers realised that the planes they were studying (full of bullet holes in the fuselage) weren’t showing them the real vulnerabilities. The planes that didn’t make it back were the ones they needed to learn from. Just because you can see a problem doesn’t mean you’re seeing the whole problem.