RCA For Positive Events?
I've always been intrigued by the negative connotation that "Root Cause Analysis" usually exhibits when conversation arises about the use of RCA. Most novice problem solvers always think RCA is for negative events that happen. While RCA and other problem solving techniques do provide solutions to causes of negative events, RCA can be used conversely to communicate and share best practices across organizations. If a business sees that a particular business unit, site, or division is excelling at a particular reliability, quality, safety, or IT initiative conducting a RCA can be very valuable. Doing a RCA on a successful event can be very effective in sharing what was done to reach a particular goal or how the event exceeded expectations. Those results can then be communicated to other sites.
Imagine being able to look up an analysis on a successful turnaround, startup, IT software implementation, etc... and being able to leverage the causes of that successful event. This helps increase efficiency in planning, scheduling, and operation of special events.
In many organizations I notice a particular site or business level "loyalty" that can be detrimental to the overall company's goals and objectives. Internal competition is typically good and often valued, but when successes aren't shared due to this competition, diminishing returns of the competition begin to outweigh the advantages. Competition is good, but sharing knowledge is just as important.
I'm interested in your thoughts on the subject.
Regards,
Marcus McCoy | Account Manager, Apollo RCA
Comments
The RCA methodology was developed in a mindset of tools to solve problems.
And basically a problem has a negative connotation.
By this, RCA methodology has inherited a negative connotation.
The intrigue is not to understand this, but how to break this semantic culture.
We teach people to start defining the problem. (Negative connotation)
In a class a student asked me, can I use the RCA in a success case? What is the answer?
In connection with, is the common comment that RCA is a reactive not a preventive method.
I believe that this examples, demonstrate that RCA could be applied more abroad.
Marcelo Haick ASA
Posted by: Marcelo Haick | March 28, 2009 at 7:56 AM PDT
I believe the negative connotation associated with RCA is driven by the old management habit of assigning blame. Those that are experienced with evidence based RCA know that the most effective solutions are associated with the working environment, not the people.
That said, companies that have developed a solid RCA program know that they will spend most of their time, especially in the first few years, working on undesired (negative) events. But, I have had the pleasure as a Plant Manager to experience a well developed Apollo program and we did conduct RCAs on positive events. It was a very positive experience!
Conducting Apollo RCAs on positive events provided several learnings. First, it challenged our assumptions of the process. We found that our beliefs were often self-limiting. Second, we made improvements by serendipity! We identified "mistakes" in the Apollo RCA that were actually benefits.
Posted by: Tracy Willis | March 28, 2009 at 9:29 AM PDT
I think it is true that the negative connotation is associated with placing blame. I think that may be rooted in the use of the word problem.
I have always said that the process is to fix the problem and not the blame and the RCA process itself requires a problem definition. I looked up the definition of problem and there are two definitions in the dictionary. One related to a scientific type of problem but the other is 2 a: an intricate unsettled question b: a source of perplexity, distress, or vexation c: difficulty in understanding or accepting <I have a problem with your saying that>. I think that over the years the word problem, if not associated with numbers or science, came to be associated with the “source of distress” or the “I have a problem with your saying that”. We are conditioned to react to the word problem in a negative way and trying to change that is an experiment that Pavlov would enjoy. This thought struck me while reading the comment within the blog “Doing a RCA on a successful event …” why is that not referred to as “Doing an event on a successful problem..?” It appears that we inherently understand the difference between problem and event and use the appropriate term as needed. Since RCA is used to identify effective solutions perhaps it is as easy as changing the word problem to get everyone to have a different conditioned response. Since event can be used to identify both bad and good outcomes, the training could eliminate the word problem and replace it with event. Or some other neutral word of your choosing!
Posted by: Kevin Stewart | March 30, 2009 at 4:50 PM PDT
This idea has been tossed around for years and as always, there are two differing perspectives. We must agree that cause-and-effect relationships lead to both desirable and undesirable outcomes. Given that, whether deisrable or not, outcomes are historical...they have occurred in the past. Therefore there is not subjectivity in forecasting something that might happen as is the case with risk assessment.
I associate "event" with "consequence". While we often do RCA's only on negative events, when we think about it, we are actually doing them on severity of consequences. Because if the consequences were not severe enough, we would not be doing an RCA. When looking at successful consequences versus unsuccessful consequences, certainly we understand the realities of the workplace where the need for urgent reaction takes place to combat the unsuccessful consequence. There often is not an urgency to utilize scarce resources to look at things that have worked. I am not saying that there is not value in doing so as I believe there is, but especially in today's lean environment, using our resources for such proactive purposes is rare (but admirable).
Lastly, the issues we have seen with analyzing successful outcomes is that inevitably we cannot absolutely capture all of the variables that came into play to make the success happen. External variables such as the past economy, current economy, weather patterns, interest rates, pricing changes and many others could have a contribution to the success...but we are not positive as to if and how much they contributed.
Also there are competing factions internally such as initatives by maintenance, reliability, EH&S, finance, purchasing, operations, corporate mandates, etc. that will strive to get a piece of the credit for any notable successes.
While I believe that exploring successes with RCA is of value and possible, it tends to get clouded by the external and internal variables that could have had a hand in the "holes lining up in the swiss cheese at that time" for the success to happen. I think we have all been there when we take credit for a success and someone else bows up and says their project also had a contribution to the success.
If we wait just a little while, we will see how this pans out when our economy eventually picks back and who postiions themselves to take the credit!
Bob L.
Posted by: Bob Latino | April 14, 2009 at 5:01 AM PDT
I agree completely that we all need to be seeking more affirming and positive ways to tell the stories and to transfer information and knowledge within our organizations. However, I sense that we will face some daunting challenges in trying to use ARCA to identify the root causes of what went right. Logically, it sounds like the same process, on the surface, to analyze a success or a failure. However, I am struggling with the idea that success is not the same as failure, as it is not the opposite of failure. Rather, success is the absense of failure. So we need to think about that for a moment. ARCA already points to the things that go wrong among the many more things that go right. In most situations, the things required to be successful are so numerous, there is great difficulty in narrowing it down to but a few as root causes, and it is much harder to trace the interactions (causal relationships) between success factors. There are many "necessary but not sufficient" factors that lead to success, and only a very small percentage of such factors that contribute to failures.
Having said all of that, there is some hope, in that we should be able to identify within successful projects those paths of incipient failure or partial failure that were mitigated or overcome. This perhaps would allow us to see where we had systems or processes in place to create success out of potential failure. That's still a tough job, but one that may be worthy of effort in some circumstances.
Posted by: Dan Bennett | October 25, 2009 at 4:52 PM PDT