There have been a couple of great columns in recent weeks in Quality Digest Daily dealing either directly or indirectly with the subject of root cause analysis. Mike Micklewright gave us his spin on medical consequences of inadequate root cause analysis and Dirk Dusharme illustrated the pitfalls of gathering data and then not using it to do root cause analysis.
ADVERTISEMENT |
Emphasis on effective root cause analysis has gotten increased attention in several sectors. Registrars, for example, are requiring more substantial evidence of root cause analysis as part of responses to their requests for corrective action. All of this is good news. Except, my personal experience is that, although people understand that they’re required to do root cause analysis, they don’t comprehend three issues:
1. What root cause analysis is
2. How to conduct effective root cause analysis
3. What the results of root cause analysis should yield
…
Comments
Root Cause Analysis
Dr. Richard Cook suggests regarding complex systems that:
Post-accident attribution accident to a ‘root cause’ is fundamentally wrong.
Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident.
There are multiple contributors to accidents. Each of these is necessary insufficient in
itself to create an accident. Only jointly are these causes sufficient to create an accident.
Indeed, it is the linking of these causes together that creates the circumstances required
for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The
evaluations based on such reasoning as ‘root cause’ do not reflect a technical
understanding of the nature of failure but rather the social, cultural need to blame
specific, localized forces or events for outcomes.1
The complete "treatise" is available at:
http://www.ctlab.org/documents/How%20Complex%20Systems%20Fail.pdf
Dr Richard Cook's assessment of Root Cause
I would agree initiall with Dr. Cook that "root cause" is not something which can be determined upon a process. It can be determined upon finite objects such as machines but not processes in all cases as most process failures are attributable to a chain of events (causis) which lead to the eventual failure. I would disagree that the use of "root cause" is related to a social, cultural need to blame. I would think that causation analysis (or problem solving for that matter) is more related to the elimination of pain or discomfort.
The problem I discoverd after decades of following the normal school of fish is that to often folks attempt to use causation analysis (aka root cause analysis) to solve each and every problem they encournter, especially for process which have undetermined variation (process adjustments are outside the control of the processs owner) or the process is simply unstable or incapable. Performing causation analysis in these conditions is futile.
#4 Separates the Alchemists from the Firefighters
Of all the things we (humanity) can improve on, I believe it is the development of solutions that don't create even bigger problems - something I am fond of calling "Cane Toadyism" after the less-than-successful Australian pest control strategy.
Being able to truly transmute a broken process into one that not only performs to expectations but is also self-sustaining in its effectiveness improvements and currency is something that any quality professional worth their salt aims for: in other words, we should be working to gradually make our positions obsolete - not easy for a species with an innate aversion to change and an inherant instinct for self-preservation.
Be the change you want to see in this world.
Mahatma Gandhi
Right on!
Denise,
I couldn't have said it better....'Organizations have to stop assigning people to do root cause analysis without giving them the necessary training and tools.' It's also beneficial if people are knowledgeable of the process for which they are conducting a RCA. Nice article!
Sandra Gauvin
http://CurrentQuality.com.
Root Cause is not Problem Solving
Many speak of Root Cause as if its the end all be all of Problem solving but that is simply not the truth.
Root cause (actually contributing causes, as there is generally never a single root cause but a string of contributing causes) is a tool that is used to solve problems when the current methodology is going to remain in place. Contributing causes analysis should never I repeat NEVER be used as an initial tool to solve a problem.
First problems must be well stated and then classified as one of two types
1) Unexpected results (a unexpected event has occurred in an otherwise effective process)
1a. Anomaly 1b. Chronic occurrence
2) There is a Gap between the Current State and the Desired State
To solve problem type # 1, Causation analysis will most likely be employed because the current business process is going to be maintained. Unless the current process has undetermined variation (explained in later)
To solve problem type # 2, its rare that Causation analysis will ever be employed as the conditions are known related to the expectation (desired state) and the (current state) and all that is needed is to fill in the gap between the two (usually creative thinking).
Failure occurs when causation analysis (aka root cause analysis) is used improperly to search for the causes of failure for a process which is in the end, incapable or unstable due to variation. The first thing to determine related to any business problem would be the capability and stability of the current process toward achieving the desired result. Only after process capability and stability the are determined, is an organization capable of making a good decision related to seeking out failure related cause analysis.
If the process is initially determined to be froth with variability, then there is no way to ever determine any factual causation, because the variability simply can never be repeated accurately, which means the causes can never be determined accurately. Its better, and less expensive to the organization, in those cases, to simply re-engineer the process so its capable of achieving the desired state continually.
A case in point would be a manufacturing process which provides chronic results related to a wide variety of acceptance characteristics, where most controls are open to adjustment by both the operator as well as other external sources. The variation possibilities are endless with this process therefore “root cause” analysis would never result in any reliable resolution. This process, in its current state, is neither stable nor capable due to the indeterminate amount of variation inherent in its design. Spending any time attempting to determine causation will simply be time (and business assets) spent in vain. Believe it or not this scenario is quite common in manufacturing. The argument often given in this case is that determination the cause of failure, assist in avoiding the same mistakes when the process is redefined, however the combinations of all variation and its related causes, would all need to be considered in order for that statement to ever be accurate . Why should an organization waste its resources if they are fairly sure the end result will be the re-engineering of the process?
Next would be considering a process which runs continually at three sigma and which experiences a hiccup for some unforeseen reason (Anomaly). For this situation, causation analysis is warranted because the process is both stable and capable and should be maintained and the causes of the anomaly identified.
It’s important to remove the perception that all things occur because of a single or “root cause”, which is usually only true related to machinery malfunction. Process which are generally well behaved, tend to experience a sequence of causes or events which result in failure. Causation analysis can be a very beneficial tool when applied correctly, however when applied incorrectly, it can be a disruptive nightmare. The trick is knowing when to properly apply causation analysis tools.
Add new comment