3 ms·

Avoiding the trap of "root causes" is exactly what has lead to such a significant reduction in failures! Avoiding "root cause" thinking doesn't mean that there

Avoiding the trap of "root causes" is exactly what has lead to such a significant reduction in failures! Avoiding "root cause" thinking doesn't mean that there isn't something that can be found and fixed. The intent is to keep your mind open to the fact that these systems and the interaction of their components are phenomenally complex. There are many contributing factors to a loss, not just a single error. Root cause analysis is harmful because it artificially limits your investigation to a predetermined "single" error or fault. Once the first or most salient error or fault is found (very commonly a human operator), the investigation stops because the "root cause" was found. Instead of stopping at the root cause, you keep digging in attempt to find all the possible contributing factors, no matter how big or small. You can prevent many future failures of the system, not just the same one, by learning about many places where your defenses and mitigations were weak. NTSB reports are a great example of how useful this approach is. Instead of identifying a root cause, they list many contributing factors, all of which can be improved to raise the level of safety significantly rather the fixing a single root cause. As a recent example, think of the Boeing 737 MAX. What was the "root cause"? Was it: * A software bug in the MCAS system? * The removal of a redundant method for sensing angle of attack? * The decision to make the "AoA Disagree" light an optional upgrade? * Making substantially unstable changes to the existing airframe? * The desire for it be be "another 737 variant" for pilot classification? * The insufficient pilot training w.r.t. to the new MCAS system? * Organizational pressures to not lose the AA contract to Airbus? * Executive leadership that prioritized business over safety? The answer is all of the above, and more! By identifying all of these past "a software bug in the MCAS system" we have the opportunity to fix many safety issues which could be contributing factors to future failures. There is an even more in depth example of this in Chapter 5 of Nancy Leveson's book Engineering a Safer World. She spends over 60 pages describing the environment and circumstances that lead to a US Air Force F-15 shooting down a friendly US Army Black Hawk over northern Iraq in 1994.

0xbadcafebee 6y ago
> Root cause analysis is harmful because it artificially limits your investigation to a predetermined "single" error or fault. The Five Whys specifically does not stop at a single root cause or fault, that's why it's the five why's and not the one. Moreover, robustness cannot emerge from a single event no matter how much you analyze it. It comes from continuous improvement processes, quality assurance, war games, service level analysis, etc. It's a multi-headed hydra of efforts to improve a system. One of those things is RCA of service-impacting events, or manufacturing defects, or customer complaints. This is like those "considered harmful" blog posts so fashionable a few years ago. So it turns out that if you blindly and inaccurately follow a generic process, it might not work out great. Who knew? It's almost like there might be subtlety involved.
- bobsomers 6y ago
  > The Five Whys specifically does not stop at a single root cause or fault, that's why it's the five why's and not the one. The Five Whys is a good start. It gets you thinking past the first cause you see. But it still suggests that there is a single causal chain with a single root issue. Something like STAMP is designed to find any possible contributing factors, whether they are related in a causal chain or only had an indirect impact on the loss. > Moreover, robustness cannot emerge from a single event no matter how much you analyze it. It comes from continuous improvement processes, quality assurance, war games, service level analysis, etc. It's a multi-headed hydra of efforts to improve a system. I don’t think I said anything which contradicts this, and I generally agree. The point I was, perhaps unclearly, trying to make is that by including any possible contributing factor in your analysis, you can fix many issues you learned about from a single event. Issues which may have been contributing factors to future, different events. One loss is not enough to fix all the holes, but you want to learn as much as you possibly can from each one when it happens.

0xbadcafebee 6y ago

> Root cause analysis is harmful because it artificially limits your investigation to a predetermined "single" error or fault. The Five Whys specifically does not stop at a single root cause or fault, that's why it's the five why's and not the one. Moreover, robustness cannot emerge from a single event no matter how much you analyze it. It comes from continuous improvement processes, quality assurance, war games, service level analysis, etc. It's a multi-headed hydra of efforts to improve a system. One of those things is RCA of service-impacting events, or manufacturing defects, or customer complaints. This is like those "considered harmful" blog posts so fashionable a few years ago. So it turns out that if you blindly and inaccurately follow a generic process, it might not work out great. Who knew? It's almost like there might be subtlety involved.

bobsomers 6y ago
> The Five Whys specifically does not stop at a single root cause or fault, that's why it's the five why's and not the one. The Five Whys is a good start. It gets you thinking past the first cause you see. But it still suggests that there is a single causal chain with a single root issue. Something like STAMP is designed to find any possible contributing factors, whether they are related in a causal chain or only had an indirect impact on the loss. > Moreover, robustness cannot emerge from a single event no matter how much you analyze it. It comes from continuous improvement processes, quality assurance, war games, service level analysis, etc. It's a multi-headed hydra of efforts to improve a system. I don’t think I said anything which contradicts this, and I generally agree. The point I was, perhaps unclearly, trying to make is that by including any possible contributing factor in your analysis, you can fix many issues you learned about from a single event. Issues which may have been contributing factors to future, different events. One loss is not enough to fix all the holes, but you want to learn as much as you possibly can from each one when it happens.