During a routine cataract operation in a large hospital, the wrong lens was implanted. It was caught and the operation safely redone. An investigation found two lenses had been in the room and a double check had failed, so the hospital issued a new protocol, ran training, improved its paperwork and put up a poster about double checks. A year later, in the same hospital, a different surgeon implanted the wrong lens in a different patient.¹

Root cause analysis is the structured work of finding out why something went wrong so that it does not happen again, and that case shows where it usually fails: in the fix, not the diagnosis. A 2020 systematic reviewsystematic review: A review that fixes its question and its rules for including studies in advance, then searches out every study that fits and weighs them together. Some systematic reviews pool the results into a meta-analysis; others describe what the studies found without combining the numbers.Full entry in the glossary of 21 studies of root cause analysis in health care found only 2 that could establish, even to some extent, that the analyses had improved patient safety.² Done well, the method has five steps:

1. Reconstruct what happened, without blame
2. Map the contributing factors, not one cause
3. Write each cause so it points at the system
4. Choose fixes that change the work
5. Give every fix an owner and a measure

What root cause analysis is, and why the name misleads

Root cause analysis is a family of methods, not one technique, for working out how and why an incident happened and how to stop it and similar problems recurring. A 2017 critique in BMJ Quality & Safety by Mohammad Farhad Peerally and colleagues argues that the name itself misleads: “the” root cause implies there is one, or only a few, so investigations too often end in a simple, linear story when incidents grow out of several factors acting together.¹

An illustrative case: a sales proposal goes to a client with another client’s name and prices in it. The sender is the obvious cause. But the proposal was copied from the last one because no clean template existed, the review was skipped because the deadline moved, and the file picker offered the latest document first. Correct only the sender, and those conditions wait for the next person.

That gap between finding causes and removing them is why the US National Patient Safety Foundation renamed the method root cause analysis and action, RCA2, in 2015: an analysis whose actions are never carried out and measured, it warns, wastes the time spent on it.³

Root cause analysis is one tool within process improvement, the wider practice of changing how recurring work gets done. The lesson: treat “root cause” as shorthand for a short list of contributing conditions, each with its own fix, rather than one culprit.

How to do a root cause analysis in five steps

A root cause analysis aimed at preventing repeats follows the five steps below, adapted for teams outside health care from the RCA2 guidance. That guidance was written for hospitals by an expert panel the National Patient Safety Foundation convened with support from The Doctors Company Foundation, and it rests on expert consensus and safety-engineering practice rather than trials.³

1. Reconstruct what happened, without blame

Start within 72 hours, RCA2 recommends, and rebuild the event as a flow diagram of what actually happened. Interview the people involved, but keep them off the review team. Findings must not be used to discipline staff, the guidance says, and each organization should define separately which acts are blameworthy and how it will handle them outside the safety process.³ People describe their shortcuts honestly only when that feels safe, the psychological safetypsychological safety: A shared belief within a team that it is safe to take interpersonal risks, such as asking questions, admitting mistakes or raising concerns, without being punished or embarrassed. It is about candor, not about everyone being nice.Full entry in the glossary that also shapes how well a team works together.

2. Map the contributing factors, not one cause

RCA2 tells teams to identify multiple contributing factors and not to stop at the first.³ For the proposal mix-up: under methods, copying last month’s file; under equipment, a file picker that lists recent documents first; under environment, a deadline that moved; under people, a new account manager who had never seen the review step.

3. Write each cause so it points at the system

RCA2 borrows five rules of causation from the US Department of Veterans Affairs. Among them: show cause and effect, avoid vague, negative words such as “poor” or “careless”, and give every human error and every broken procedure a preceding cause.³ So “Sam was careless” becomes “Proposals are built by copying the previous client’s file because no blank template exists, which makes it more likely that one client’s details reach another.”

4. Choose fixes that change the work

The action hierarchy, developed by the Veterans Affairs National Center for Patient Safety in 2001, ranks fixes by how little they rely on people remembering. Stronger actions change the design, such as a forcing function that makes the wrong step impossible, a simpler process or standard equipment. Intermediate actions include checklists, software alerts and fewer distractions. Weaker actions include training, warnings, double checks and new policies.³

1. Stronger actions: rely less on people remembering: forcing functions, simpler processes, standard equipment
2. Intermediate actions: in between: checklists, software alerts, fewer distractions, an independent second check
3. Weaker actions: rely more on people remembering: training, warnings, double checks, new policies

RCA2 asks for at least one stronger or intermediate action from every review: training and policy are often needed, but on their own are unlikely to keep a problem from returning. For the proposal, a template that fills in the client’s name from the customer database beats a pre-send checklist, which beats a reminder email.

5. Give every fix an owner and a measure

Assign each action to one person with the authority to carry it out, not a committee, with a date, a measure and a time to check, then tell the people involved what was done.³ Follow-through is where many analyses stall: studies cited by Peerally’s team put the share of recommended actions actually implemented at between 45 and 70 percent.¹

WiserHours

Before you close a root cause analysis

• Rebuild the event as a step-by-step flow, with interviews
• Agree that the findings will not be used for discipline
• List every contributing factor, not just the first one
• Rewrite each cause so it names a condition, not a person
• Include at least one stronger or intermediate fix
• Name one owner and a date for every fix
• Choose a measure and a date to check it

Find this checklist online:
https://wiserhours.com/process-improvement/root-cause-analysis/#checklist-root-cause-analysis-steps

Five whys, fishbone diagrams and fault trees: which tool to reach for

The three best-known root cause tools differ mainly in how many causes they let you see: five whys follows one chain, a fishbone diagram spreads causes across categories, and a fault tree works down from one failure through logical gates. Alan Card, writing in BMJ Quality & Safety in 2017, argues that five whys is too narrow for investigating serious incidents.⁴

Five whys comes from the Toyota Production System, and its popularity, Card writes, owes nothing to evidence that it works. His case in point is the classroom favorite that traces damage to a Washington monument, through pigeons, spiders and midges, to the lights, so the fix is to switch them on later. The real case was the Lincoln Memorial, and many details are wrong. Delaying the lights did cut the midges, but tourists complained and the lights went back on: the chain had left out other causes of wear, and the visitors.⁴

it is not simple, but simplistic

His other objections apply anywhere. Another team could produce five entirely different, equally valid whys for the same incident. In his hospital example, a full causal tree uncovered more than 75 causes and contributing factors, where five whys would target one or two. And the fifth why is not automatically the best place to act: a barrier close to the incident, such as a scanner that will not let a nurse give a drug without checking the patient’s wristband, can make the more distant causes irrelevant to a repeat.⁴

Myth

Ask why five times and you will reach the root cause.

Fact

A single chain of whys follows one path. Different teams can reach different, equally valid answers, and most contributing factors stay off the page.

The Institute for Healthcare Improvement describes the fishbone, or cause and effect, diagram as a way to explore and display the possible causes of an effect, grouped under headings such as materials, methods, equipment, environment and people.⁵ A fault tree is more formal. A 1981 handbook from the US Nuclear Regulatory Commission describes it as deductive: name one undesired “top event” and work down through OR gates, where any one input is enough, and AND gates, where all inputs must occur together.⁶

In practice, use a fishbone for most workplace incidents, a fault tree for a technical failure with a clear top event such as a system outage, and five whys only as a quick first pass that you then widen.

Does root cause analysis stop problems coming back?

Evidence that root cause analysis prevents repeat incidents is thin, and nearly all of it comes from health care. The 2020 review by Jimmy Martin-Delgado and colleagues concluded that the method helps identify causes of safety incidents but not put in place measures that stop them recurring. In about half its studies, the recommendations were weak ones that did not reduce adverse events, and analyses were seldom followed by a check that the action plan had been carried out.²

The picture is not all bleak. A 2022 systematic review of ten retrospective studies at the US Department of Veterans Affairs, which runs a standardized process, found that all reported improvements after the recommended actions were put in place, though they defined and measured effectiveness in varying ways; we read only its abstract.⁷

The study

Limited evidence

Eight years of one hospital's root cause analyses: Kellogg and colleagues, 2017

Researchers read every analysis the hospital carried out after a state-reportable adverse event. In the 106 analyses that proposed solutions, the most common were training, a change to a process and a reminder of an existing policy, and the authors conclude that the solutions proposed most often were weaker actions. Several kinds of event, including surgical items left inside patients, kept recurring despite an analysis each time.⁸

After one retained sponge, for example, the team judged the counting policy effective as written, named human error as a factor and proposed re-emphasizing the policy at an operating-room staff meeting. The authors’ point is that reminding people not to make mistakes cannot prevent them, because human error will always recur.⁸ The caveat: this is one hospital’s paperwork, not a test of what worked.

Offices write the same kind of plan. After a payroll run goes out late, the actions read “remind the team of the cutoff date” and “add a note to the procedure”. Both ask people to remember harder, and neither changes what made the run late.

Common mistakes that let the problem return

Three of the traps that Peerally and colleagues describe in health care could arise in any workplace. First, under deadline pressure, affected by hindsight and run by people who are not independent of the organization, a team may settle on a cause of mutual convenience that edits out causes beyond its remit.¹

Second, analyses done one incident at a time make it hard to see a weakness that keeps recurring, and similar events recur in the same or similar organizations. Third, when suppliers or other outside parties contribute, analyses tend to pull responsibility back into the organization where the incident happened, which often lacks the power to change them.¹ If three late deliveries in a quarter are each blamed on the packing team, only reading the reviews side by side shows the same supplier was late every time.

Who is in the room matters too. Managers or coordinators were included in only about one study in four in Martin-Delgado’s review, and the authors note that the people who approve and carry out fixes are usually not the ones who did the analysis.² So review related incidents together, and bring in whoever owns the budget or the process before actions are chosen.

What NHS England uses instead of root cause analysis

England’s health service no longer asks providers of NHS-funded care to hunt for a root cause. Its Patient Safety Incident Response Framework, published in August 2022 to replace the 2015 Serious Incident Framework, favors system-based approaches over methods that assume a simple, linear identification of a single cause. It is proportionate: where risks are managed and improvement work is monitored, a provider need not investigate every similar incident individually, and responses exclude apportioning blame. Its effect is being evaluated in a study funded by the National Institute for Health Research.⁹

The supporting guidance, updated in 2025 and citing Peerally’s critique, says evidence suggests root cause analysis prompts simple linear cause-and-effect analysis. The methods it promotes explore multiple interacting factors instead, such as an after action review built on four questions: what was expected, what happened, what the difference was and what the learning is.¹⁰

The US and English approaches disagree about the name more than the essentials. What a manager can borrow is proportion: after a missed client handover, a short team conversation around the four after-action questions may be enough, while a serious or recurring problem earns a full analysis.

The bottom line

Root cause analysis earns its keep only when it changes the work. Look for several contributing causes rather than one, write them so they point at the system, and include at least one fix that makes the error hard to commit instead of asking people to be more careful. Then give that fix an owner and a measure, and look again if the problem returns.