One might take it for granted that everyone can define the term root cause. If asked, most people would have a definition. But these definitions would vary.
Therefore, a basic problem in root cause analysis is that people don’t even agree on the definition of “root cause.”
So what is my definition?
The most basic cause (or causes)
that can reasonably be identified
that management has control to fix and,
when fixed, will prevent
(or significantly reduce the likelihood of)
the problem’s recurrence.
David Busch and I started developing this definition in 1985. We quickly found that not everyone would agree with this definition. However, several key ideas sprung from the definition that became the bedrock upon which the TapRooT(R) System was built.
First, when one finds a root cause, one has found something that management can fix that will prevent the problem’s recurrence. This is a key because it keeps one looking until a fixable solution can be found.
Second, the definition targets problems that are within management’s grasp to fix. For example, one might say that the root cause of a fall is gravity. This would not be a root cause by this definition because management can’t fix gravity.
Third, the definition helps answer the always troubling question of how much investigative effort is enough. This question really comes down to a trade-off between a “reasonable” effort (usually defined as the least possible effort) and finding the “most basic” cause(s) (sometimes seen as a never ending quest if people can’t agree on the definition of a “basic cause”). The final arbitrator between these two competing priorities (timeliness and completeness) is the requirement to find the fixable causes of an incident that, when corrected, will prevent the incident’s recurrence. Therefore, an investigator has expended a “reasonable” effort if one has identified the fixable causes of an incident.
Fourth, the definition implies that a problem may have more than one root cause. In our early experience investigating and reviewing hundreds of incidents we found that, on the average, incidents had two to three root causes per simple incident (a simple incident is one with one or two causal factors). In our experience with more complex incidents in more complex systems (with multiple safeguards and multiple causal factors in the incident), we often found 10 or more root causes (things that can be improved) in a single, complex incident. allowing for multiple root causes stops the arguments over which cause is the “rootiest” of the root causes. Any cause for a problem that fits the definition is one of the problem’s root causes. This is true even if the cause only made the problem worse or more likely.
My definition is a jumping off point in the search for a tool that will help a problem solver find fixable root causes. The definition is helpful in the search for root causes, but it is not sufficient. So we had to do more than just develop a definition. We had to develop a system to find root causes.
So the definition started the development of an advanced root cause analysis tool: TapRooT(R) System and the Root Cause Tree(R).
The Root Cause Tree(R) gives an investigator an operational definition of “What is a root cause?”
Thus the definition becomes less important when you have a tool that can help you consistently meet the goals of the definition – stopping problems from recurring by implementing successful corrective actions.
For more information on TapRooT(R) and the Root Cause Tree(R) read the TapRooT(R) Book.
Category: Root Causes