How to find the root cause of a problem

To find the root cause of a problem, describe the problem precisely, go and see where it happens, map the possible causes widely with a fishbone diagram, narrow them with data, then trace the strongest candidates with "five whys" until you reach something you can change. Finally, test the cause: if fixing it does not make the problem shrink, you have not found it. Most teams skip the first and the last step, which is why their "root causes" turn out to be opinions.

Why teams stop at the first cause

The first explanation that sounds right usually wins, especially when a senior person offers it. "Staff need more training" and "the system is slow" are the two most common false root causes in any organisation. They are convenient because they are partly true and point at someone else.

A root cause has three tests. It is within reach: your organisation can change it. It explains the pattern: when and where the problem appears, and where it does not. And removing it reduces the problem. A cause that fails any of these is a symptom, a contributor or a guess.

There is also rarely one root cause. Most stubborn problems in services and operations come from two or three causes acting together. Plan to find a few, and to rank them.

How to find the root cause: seven steps

1. Write the problem as a fact, not a judgement

"Customer service is poor" cannot be analysed. "In September, 31% of refund requests took more than ten working days, against a target of five" can. Write what is happening, where, since when and how much, and what normal looks like. If you cannot fill in the numbers, that is your first task.

Also write what the problem is not. If late refunds happen in one region but not another, or on card payments but not bank transfers, the contrast is one of your best clues.

2. Go and see

Before any workshop, spend time where the problem happens. Sit with the team that processes the refunds, follow one case from start to end, watch a customer try to complete the task. Contextual observation catches workarounds, missing information and handovers that no report shows. Meeting-room analysis without this step mostly reproduces what people already believed.

3. Map the process

Draw the steps as they really happen, not as the procedure says. A process flowchart quickly shows loops, waiting points and handovers between teams. Problems tend to gather at handovers, where each side assumes the other is checking.

4. Map possible causes widely with a fishbone diagram

The fishbone, or cause-and-effect diagram, was popularised by Kaoru Ishikawa in Japanese quality management in the 1960s, and many people still call it the Ishikawa diagram. Write the problem at the head and draw major branches for categories of cause. The classic set is people, methods, machines, materials and measurement; for services, many teams use people, process, policy, technology, information and environment.

Ask the group to fill every branch before discussing any of it. The goal of this step is breadth. You are listing candidates, not reaching verdicts. Mark the ones the group can support with something they have seen, and the ones that are only suspicion.

5. Narrow with data

Now test the candidates against facts. Pull a sample of cases and tag each one with its likely cause. A Pareto analysis, named after the economist Vilfredo Pareto and brought into quality work by Joseph Juran, sorts causes by how often they occur and usually shows that a few account for most of the cases. Juran called them "the vital few". Fifty well-tagged cases are often enough to see the pattern.

If you cannot get data, run a short check: two weeks of tally marks by the people doing the work is better than none.

6. Ask "why" until you reach something you can change

Take each of the two or three strongest causes and ask why it happens, then why that happens, and so on. The technique is credited to Sakichi Toyoda and was made famous by Taiichi Ohno as part of the Toyota Production System. Five is a rule of thumb, not a target; you may need three or seven.

Three disciplines keep five whys honest. Answer each "why" with a fact, not a feeling. Allow the chain to branch when there are two real answers. And stop when you reach something your organisation controls and could change; going further usually ends at "because people are human" or "because of the budget", which help no one.

Even inside Toyota, five whys has critics who say it is too basic for complex problems. That is why it comes after the fishbone and the data here, not instead of them.

7. Test the cause before you fix it

Write the root cause as a statement you could prove wrong: "Refunds are late mainly because cases missing a bank reference are put on hold without anyone contacting the customer." Then design a small test. Fix it for one team, one region or two weeks, and see whether the problem moves. If it does not, go back to step 5 with what you have learned.

Choosing the right tool for the problem

• Five whys for a single, well-defined failure with a clear chain of events.
• Fishbone analysis when many factors may be involved and you need the whole team's view.
• Pareto analysis when you have many cases and need to know which causes matter most.
• Problem tree when the problem is broad and social or organisational, and you need to see causes and effects in layers.
• Failure modes analysis when you want to prevent problems in a new process before they happen.

Illustrative example

Illustrative. A mid-sized utility in Canada was receiving complaints that refunds for overpaid bills were slow. The first explanation, offered in a management meeting, was that the refunds team was understaffed.

The improvement lead wrote the problem as a fact: 31% of refunds in the last quarter took more than ten working days, mostly in one of three regions. She spent two mornings with the refunds team and followed six cases end to end. A fishbone session produced 27 possible causes across six branches.

She then tagged 60 late cases. Pareto showed that 38 of them had one thing in common: the customer's bank details were incomplete, so the case was put on hold. Five whys on that cause went: on hold because the bank reference was missing; missing because the online form did not require it; not required because the field was optional when the form was moved to a new system; never noticed because hold cases did not appear in the team's daily report.

The test was cheap: make the field required in the one region with the most late cases, and add hold cases to the daily report. Within a month, late refunds in that region fell sharply, and staffing never came up again.

Common mistakes

• Starting with the fishbone in a meeting room. Without facts and observation, it records opinions with a diagram around them.
• Letting one person's theory set the frame. Collect causes silently and in writing first, then discuss.
• Stopping at "human error". People make errors in systems that allow them. Ask what made the error easy.
• Going past your reach. "Because of regulation" may be true, but if you cannot change it, stop one level earlier at what you can.
• Only one chain. If your five whys never branched, you probably missed a contributing cause.
• Declaring victory without a test. A root cause is a hypothesis until removing it reduces the problem.
• Turning analysis into blame. If people expect blame, they hide the facts you need. Say clearly at the start that you are looking at the system.

Questions people ask

What are the steps of root cause analysis? Define the problem with facts, observe where it happens, map the process, list possible causes widely, narrow them with data, trace the strongest causes with "why", and test the cause with a small change before rolling out a fix.

What is the difference between five whys and a fishbone diagram? A fishbone diagram spreads wide: it lists many possible causes in categories. Five whys goes deep: it follows one cause down to its origin. Use the fishbone to find candidates and five whys to trace the strongest ones.

How do you know you have found the root cause? When it is something you can change, it explains where and when the problem happens and where it does not, and a small test that removes it makes the problem measurably smaller.

Where to go next

The four guides you will use most are five whys, fishbone analysis, Pareto analysis and the problem tree. Once you know the cause, turn it into a sharp brief with how to write a problem statement, and see the full map of methods in which innovation tool to use.