How to Tell If a Root Cause Analysis Was Actually Thorough

Every organization I work with can produce a folder of completed root cause analyses. Filled in, signed, closed. What almost none of them can tell me is whether the thinking behind those records was any good, and the reason is not that anyone was careless. I have designed these processes, audited them, and picked up more than one from the person who built it and left, and the same limitation shows up from all three seats: the record is not built to show you what it does not contain.

I built one myself with more structure than the organization would carry. I wanted it to demonstrate full coverage of every impact area, so every area got a field. What came back was fields left blank, criteria scoped out, and a few that were plainly redundant, so I took structure back out. That was the right correction and it did not fix the underlying problem, because the underlying problem is not how much structure you have.

Why a finished root cause record can't tell you whether the analysis was thorough

A completed root cause record cannot distinguish a question that was never asked from an answer that was never written down.

A blank field is information. You can see it, and you can go ask about it. A question nobody thought to ask does not leave a blank, because there was never a field there to leave empty. The form was built around the questions someone anticipated, and it holds whatever thinking arrived with it, faithfully; it made it so an analysis that stopped one level short comes back looking exactly like one that went all the way.

The tools are not the problem here and I want to be careful about that. A structured method is a good way to record a decision, its basis, and what was considered, so the reasoning is retrievable later when someone comes asking and the anticipated questions are already answered. That is real value and it is most of why anyone documents anything. It is just not the same thing as evidence that the thinking happened.

The comparison to run: your procedure against three closed analyses

To find out whether your analyses go where your process says they should, read the investigation criteria in your own procedure against three closed records and check whether each named area shows up as actually considered.

Most procedures name them: upstream processes, training, the departments the issue touches, safety implications, sometimes customer effect. Then you open the records and the analysis went to one of those, or two. It is a good starting point because it costs nothing and because it is your own document doing the work; you are not applying somebody else's expectation, you are asking what we said we would ask against what we asked.

What you have found at that point is a gap between two documents. You have not found a shallow analysis. Those are different things, and the next move is a conversation rather than a finding.

Why “we considered that” is usually an honest answer

When someone tells you the team considered an area and simply did not write it down, they are usually telling the truth.

Most of this work happens in someone's head, which makes the whole comparison squishy. The response you get is mixed and reasonable: the criteria are only applicable when they are applicable, and we know when that is. Press a little and most people will concede that their operators are not working through all of it in any full-coverage way. Both of those are true at the same time, and it is easy to land on “we think of those things,” which you cannot argue with. Not because anyone is being evasive, but because the evidence that would settle it was never captured.

That is where this usually stalls, and it stalls differently depending on who is asking. An auditor's version has an answer: sample five closed analyses, and where one is thin, either write it up or go confirm the actual analysis with the person who ran it. That works because an auditor does it five times a year. The person accountable for the process needs it to be true across every event, and they cannot interview their way to knowing.

How to make the asking leave a trace

Give every prompted area a line for a response, and let “not applicable” count as a complete answer.

There is a real difference between asking a question and getting not applicable back and never asking it at all, and a conventional record cannot tell those apart. A line to respond to can. Where a justification is warranted, ask for one, and offer a short list of common justifications so the person is picking rather than composing. Where it is not warranted, not applicable on its own is a complete answer and should be treated as one.

Repeated not-applicables are not people gaming the form. If an area has been irrelevant on forty consecutive events, forty of them is the correct record, and reading that as pencil-whipping will cost you the credibility you need for everything else in the design.

Three other layers sit around that field and the field is the smallest of the four. The people conducting analyses are trained and then signed off on the skill, because asking well is a capability before it is a process step. The process prompts areas and themes rather than pre-defined questions, because you cannot enumerate every question a real event will need; you name the territory and let experienced people get to the questions from there. And the value has to be felt by the people running it. That is the ceiling I hit on my own build. If they will not use it, the useful tool is the one they will use, and their participation sets the limit whether you designed for it or not.

How to size analysis depth before you know the cause

Size the analysis by taking the symptom and asking what the same thing would mean in the highest-consequence area that could plausibly have it.

The objection to sizing depth by cost is that you do not know the cost until you have done the analysis, and that holds if you are estimating the cost of this event's root cause. It is not what I mean. Records filled in thinly in one area is a nuisance; the same behavior in the lab is a different order of problem, and you can run that transposition in the first ten minutes of an event, from the symptom alone, before anybody knows anything about cause.

Recurrence is the cost that is actually measurable, including a smaller repeat or the same issue surfacing in a different area at a different impact, and it is estimable enough to set how much analysis an event earns. Not every event earns full coverage, and treating them as though they all do is the overbuild; it is the same mistake as a form with a field for everything. The analysis is also the front half of a corrective action plan, and a plan built on an analysis that stopped early inherits the stop.

Who is accountable for knowing whether the process works

Accountability for whether a root cause process works sits with leadership, not with the person assigned the analysis.

The assignee and the chain that supports them, the training and the sign-off and the process itself, are the safety net. But leadership either determines the process and its objectives or sets the tone for how they get determined, and that includes deciding whether the work is measured at all. Unless you are willing to put numbers around this, recurrence and the same issue turning up somewhere else, you are working from vibes and rhetorical confirmation. There is something real in due diligence and in being primed to catch the rare instance, and it is not measurement.

Too little structure fails in the other direction and it is worth naming, because a correction to an overbuild can overshoot. If one person has been driving the analyses and the structure lives in their memory, it is hard to transfer, and worse, nobody knows that is the situation until they leave. If the thinking is tribal and consistent across several leaders, it does transfer, but through social onboarding, at the speed of exposure, and nobody can say what it consists of. At the floor it comes down to who is in the room that day. Neither end lets the person accountable for the process know whether it works, and the middle is not a compromise between them; it is the only place where the record carries any of the reasoning to the next person.

Frequently asked questions

Can a completed root cause record prove the analysis was thorough?

No. A record shows what was written down, and a question that was never asked leaves no blank field behind, so a shallow analysis and a thorough one can produce records that look the same. The record is good evidence of the reasoning it captured and poor evidence about the reasoning it did not.

What is the fastest way to check whether our analyses are deep enough?

Read the investigation criteria in your own procedure against three recently closed analyses and check whether each named area appears as considered. The gap that opens is a starting point for a conversation with the people who ran the analyses, not a finding on its own.

Does adding “not applicable” fields just create more paperwork?

Only if you require prose for every one of them. Offer a short list of common justifications to pick from, and accept not applicable on its own where no justification is warranted. The point is to make an area that was considered and dismissed look different from an area nobody looked at.

How much analysis should a single problem get?

As much as the consequence of it happening in a higher-stakes part of the operation warrants. Transpose the symptom to the area where it would matter most, size the effort to that, and accept that most events do not earn full coverage of every impact area.