A few definitions, per the Center for Homeland Defense and Security:

  • Proximate cause (direct cause) - occurs immediately prior to the incident; directly results in its occurrence and, if eliminated or modified, would have prevented the undesired outcome

  • Root Cause - One of multiple factors (events, conditions or organizational factors) that created the proximate cause and subsequent undesired outcome. Typically multiple root causes contribute to an undesired outcome [my italics].

  • Root Cause Analysis - A method primarily used to identify the underlying cause of an incident or issue, and more effectively mitigate or prevent future similar incidents.

And from Thwink.org:

  • The Law of Root Causes - All causal problems arise from their root causes. Therefore, solving causal problems requires correct understanding of their causal structure.

  • For the purpose of solving difficult problems, [we should focus] our efforts where they will be most productive…

The inspiration for this post was reading No, seriously. Root Cause is a Fallacy, by Will Gallego, especially:

Let’s start with some understanding behind the appeal of root cause. The thinking is that you want to get to the underlying problem, starting at where it begins, rather than treating the downstream effects. I can appreciate resolving deeper underlying issues rather than “treating the symptoms” when problems large or small crop up. Our systems are complex. It’s very tempting to look at a singular part in an effort to simplify our understanding and achieve resolution…[However], if there are multiple paths to failure (there always are), then you don’t have a singular root cause [my italics].

Another great way to look at it is to approach the same line of thinking with success. When building a successful project, there’s never just one thing that goes right for it to succeed… Did the QA team’s thorough inspection to catch edge cases make it more robust to a wider audience?…How about your infrastructure team that built a monitoring system to allow for quick insights into potentially hazardous situations to be handled quickly and without significant impact? Or your delivery team, building a toolset that allows you to make incremental changes and fixes… Or..?

[Answer: all of the above, and then some.]

There is no root cause of success. Success is the outcome of many things going right. And failure is the outcome of many things going wrong. Focusing on the one big thing that went wrong (often a long time ago) is rarely the way to reverse failure. Whether it’s a failure of governance or technology.

Of course, each thing that goes right or wrong is the product of multiple factors (events, conditions, institutional or organizational factors). Whether one wants to call those factors “root causes” is partly a matter of semantics. But I find the phrase unhelpful and misleading, because the idea of multiple root causes is incompatible with the notion of a single root cause as commonly defined, e.g., the highest-level cause “that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s).”

Either you have multiple factors that contribute to an outcome, or you have a root cause. You can’t have both.

—

References:

No, seriously. Root Cause is a Fallacy, Will Gallego. April 2, 2018

Root Cause Analysis, Center for Homeland Defense and Security, Naval Postgraduate School. March 2017

The Law of Root Causes, Thwink.org

What is Root Cause Analysis? Quality Resources