What to Do After Root Cause Analysis: Test the Cause Before You Fund the Fix

A root cause analysis ends. That does not mean it found the root cause. The step between the investigation and the corrective action plan is testing whether the cause you landed on is the cause the evidence supports or the cause the investigation stopped at. Most corrective actions fail not because the fix was wrong, but because it addressed a stopping point the team mistook for a finding.

I watched the Columbia Accident Investigation Board work through exactly this problem in 2003. NASA's initial investigation identified the physical cause of the shuttle's destruction: a piece of insulating foam had struck the left wing during launch, creating a breach that allowed superheated air to enter during re-entry. The foam strike was real. The physical mechanism was well documented by the Columbia Accident Investigation Board. And if the investigation had stopped there, the corrective action would have been straightforward: fix the foam shedding problem.

The Board did not stop there. It found that NASA's organisational culture was, in its own words, "as much a cause of the accident as the foam." Foam strikes had been observed on previous flights and reclassified from a safety-of-flight concern to an acceptable maintenance issue. Engineers who raised concerns during the Columbia mission were overruled by managers who treated the absence of proof of danger as proof of safety. The "root cause" that would have emerged from a narrower investigation was real but incomplete. The organisational cause sat behind it, unaddressed.

The corrective action for a foam problem is an engineering fix. The corrective action for a culture that normalises known risks is something else entirely. If you fund the first without testing whether the second exists, you have fixed the symptom the investigation surfaced while leaving the system that produced it intact.

1. Rewrite the root cause as a testable claim. "Inadequate training" becomes "We believe the operator lacked specific knowledge that, if present, would have prevented this event."
2. Score the claim on influence and confidence. High influence on the outcome plus low confidence in the evidence equals a cause that needs investigation before it receives funding.
3. Investigate the high-risk claims. One data check, one interview, or one comparison with a similar event.
4. Design corrective actions only for verified causes. The Walk guides you through testing whether the cause is a finding or a stopping point, before the fix gets a budget.
5. Assign ownership and a review trigger. Each corrective action gets a named owner and a condition under which the fix should be reconsidered.

After a root cause analysis, the standard next step is corrective action planning. The step worth taking first is to test whether the identified cause is a verified finding or the point where the investigation stopped.

The standard next step: plan the corrective action

Root cause analysis methodologies converge on the same endpoint: once you have identified the root cause, you plan and implement corrective actions. A fishbone diagram maps potential causes into categories. A fault tree narrows the logic. A "five whys" sequence drills through layers. At the bottom, the team writes a root cause statement and a corrective action plan that assigns responsibility, sets deadlines, and specifies what will change.

The sequence is logical. An event occurred. The organisation investigated. The investigation produced a cause. The cause generated a fix. Presented in an incident report, the completed plan reads as accountability. The AHRQ Patient Safety Network describes root cause analysis as "a structured method used to analyse serious adverse events," and the corrective action step is where that structure converts into change.

What the corrective action step adds

Root cause analysis without corrective action is an academic exercise. The corrective action step converts analysis into operational change. It assigns a named person to a specific fix. It sets a deadline. It creates a record that the organisation responded. If you have completed a fishbone diagram and want to move beyond the diagram, corrective action planning is what every incident management standard recommends.

The contribution is closure. An event occurred. The organisation investigated. The investigation identified a cause. A fix was designed and assigned. That loop, when it works, is how organisations learn from failure. It is the step that separates investigation from inaction, and in complex problem solving environments where events recur, the loop is the mechanism for improvement.

The problem is not the corrective action step itself. The problem is what happens when the cause it addresses was never properly verified.

Rewrite the root cause as a claim and test it before the corrective action plan commits budget to a stopping point. Start the Walk →

Where the standard playbook breaks down

The breakdown happens at the boundary between "cause identified" and "cause verified." James Reason's work on organisational accidents showed that failures in complex systems rarely trace to a single root cause. His Swiss cheese model describes how multiple layers of defence must fail simultaneously for an accident to occur. A root cause analysis that stops at the first plausible cause will identify one hole in one slice, not the alignment of failures across the system.

Kellogg and colleagues reviewed the outputs of root cause analyses across multiple hospitals and found that the most commonly proposed corrective actions were "weaker actions": retraining, policy reminders, and enforcement of existing procedures. These are the fixes that follow when the investigation stops at the human error layer rather than the system design layer. The team identifies "the operator did not follow the procedure" as the root cause. The corrective action is retraining. The event recurs because the procedure was unworkable in the first place, and nobody tested that assumption.

Peerally and colleagues identified eight problems with how root cause analysis is practised in healthcare, including the tendency to produce single-point explanations for events that had multiple contributing causes. The "root" in root cause analysis implies there is one. In practice, there are several, and the one the team writes down is often the one that was most convenient to name, not the one with the strongest evidence behind it.

Sidney Dekker described this as the stopping problem. Investigations do not discover causes so much as construct them. The point at which an investigation stops is a choice, shaped by time pressure, political considerations, and the team's assumptions about what counts as a sufficient explanation. "Inadequate training" is a popular stopping point because it is actionable, inexpensive to address, and does not implicate the people in the room. Whether it is actually the cause is a separate question, and one that most investigation processes do not require the team to answer.

I have seen this pattern across industries. A manufacturing team completes an RCA after a quality failure. The root cause statement says "operator error." The corrective action is retraining. Six months later, a different operator makes the same error in the same conditions. The conditions were the cause. The operator was the stopping point. The same pattern appears wherever problem solving techniques in business stop at the first plausible explanation rather than the one with the best evidence.

The step to take first

The corrective action step is not the problem. The problem is acting before testing. Before a root cause enters a corrective action plan, it needs to survive a simple question: is this the cause the evidence points to, or is this the cause we stopped at?

Take the root cause statement from your most recent RCA and rewrite it as a claim. "Inadequate supervision" becomes "We believe supervision was insufficient to prevent this event, and that additional supervision would have changed the outcome." Then ask two things about that claim: how much influence does it have on the outcome, and how confident are we that it is true? A cause with high influence and low confidence is the one that needs investigation before it receives budget.

A cause you have evidence for and that matters to the outcome can enter the corrective action plan. A cause you are guessing at and that carries the entire fix should not. The same test applies whether the analysis used a fishbone diagram, a fault tree, or a five-whys sequence. A cause earns the right to generate a corrective action only after someone tests whether it is true.

The manufacturing team from the earlier example would have written "operator error" as the root cause. Rewritten as a claim: "We believe the operator's actions were the primary cause of the quality failure, and that a different operator following the same procedure in the same conditions would not have produced the failure." Influence on the outcome: high, because the entire corrective action rests on it. Confidence: low, because nobody had tested whether a competent operator could follow the procedure under those conditions. That cause needed verification before it entered the corrective action plan, not after the retraining was complete.

When I work with teams after a root cause analysis, the first thing I do is separate causes they have evidence for from causes they have agreed on. The separation takes ten minutes, and it changes which corrective actions survive scrutiny. Most teams have never been asked to make that distinction, because the investigation process does not require it.

This is the step between completing a root cause analysis and committing resources to its corrective actions. Separate findings from stopping points. Test the ones that carry the fix. The Universal Decision-Making Method calls this "recognise assumptions" and places it before any commitment, because a fix built on an untested cause is not a solution.

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.