Abstract: If we have heard it once, we have heard it a million times – “let’s do a RCA on that failure.” The problem is that phrase will mean something different to everyone that says it. What is a RCA? That is a question that even the notable experts cannot agree on. With all of this “chaos”, how do we make any progress?
What is RCA?
Think about whenever you hear the mention of the term Root Cause Analysis (RCA.) What is a RCA? Is it a tool or is it a process? Is all RCA the same? These are very legitimate questions and there are no consensus answers unfortunately.
As an RCA provider, we participate with our peers on various discussion forums. We discuss such questions and issues that cause frustration to the RCA users. I would like to say that we make more progress than we do, however I would not be telling the truth. RCA providers, like any other type of vendor, have their business interests to protect. Sometimes trying to obtain a consensus on those questions may have an adverse impact on such business interests.
However, I have a different view. RCA, I believe, is a process, a public domain process. RCA is a term that cannot be trademarked because of its generic use in the public domain (some have tried!) When you hear about the various RCA types on the market such as Reliability Center, Inc.’s PROACT® or Apollo® or Kepner-Tregoe®, these are all merely different brands of RCA. Each one has their own merits and each go about solving a problem differently. However, they are all considered RCA from the perspective of the public.
Are There Common Elements to an Investigative Process?
I believe that there are common elements to the basic investigative process, where common elements are required in order for such processes to be called RCA. Think about any investigative occupation, be it an NTSB investigator, a police detective or a doctor, their thought processes are essentially the same.
- Preserve data associated with the event being analyzed.
- Organize a team with diverse backgrounds to be able to help review the data.
- Analyze the data with the team to try and reconstruct the cause-an-effect relationships leading up to what happened.
- Communicate the findings and recommendations to interested parties to obtain approvals for recommendations (or convictions in the detective’s case.)
- Track or monitor specific metrics to see if the recommendations are working.
Do these reflect more than what the term RCA usually connotes? Most likely the answer is yes. RCA to most would be the simple expression of cause-and-effect relationships. This usually takes the form of a logic tree, fault tree, fishbone diagram, event and causal factor diagram and/or a comparative time line. Most do not consider the other items in my list to be the responsibility of the RCA analyst. In some cases I don’t either.
However, what we must realize is that all the elements must be successfully completed if we are to see an improvement based on our work. Just because we complete a magnificent RCA and identify causes, does not mean that the problem at hand goes away.
We could make recommendations that may not work. We could make good recommendations that do not get approved. We could make recommendations that get approved but do not get implemented. You get the point. I do not care if you call it RCA or not, as long as the work gets done.
What is an “RCA Method”?
RCA methodologies like the brands I mentioned earlier represent the various approaches on the market to conducting RCA. Remember, RCA is merely a thought process. It is a way of thinking through why things go wrong. It is applicable anywhere and under any circumstances. It does not matter if you are trying to figure out why Crude Unit catches fire or why packages are delivered late to the customer. Each RCA brand has their own method. These methods have various rules embedded in their approaches. These rules provide the discipline for following their RCA methodology. Following these rules provides guidance for the user to adhere to the discipline of the method in the hopes for a successful outcome.
What are “RCA Tools”?
Many users associate the RCA tools as BEING the RCA method. That is not the case. The tools are merely vehicles to express the method. These tools, be it manual (paper-based) or electronic (software-based), embed the rules from the different methodologies.
Without proper training and experience in the method, the tools are usually a bunch of screens. I often use the analogy that Microsoft Word has a ton of capabilities, but if you do not know proper English (or whatever language) and grammar, it does not help you much.
Many who look to RCA tools are looking for what I call: “Auto-RCA” solutions. They’re looking for the easy way out. They are looking for something to give them the answer so they do not have to think for themselves. Do such tools exist? Sure. Do such tools have all the answers? No. Do the users think these tools have all the answers? Yes. There lies the danger.
Many organizations have the equivalent of “troubleshooting flow diagrams”. Any organization that produces a product usually has field representatives or tech support personnel who follow such “troubleshooting flow diagrams”. Even 911 operators follow predetermined logic paths to aid in responding to certain types of situations. The same goes for RCA.
So this demonstrates that troubleshooting flow diagrams represent past experience. This past experience is formatted in such a manner to provide education to others about lessons learned from that past experience. As mentioned above though, the perception of any drop down list is that it is all inclusive. This is simply not true. Not all variables associated with all situations can be captured in such lists. These lists may represent only the most common occurrences therefore unique occurrences (new) may not be captured.
When such past experience is available to us during the course of our RCA’s, my advice is to first exhaust the knowledge of the RCA team about the possible hypotheses and then reference the past experience to see if perhaps other hypotheses were overlooked. Why? As the author of “Theory of Constraints” Eli Goldratt once alluded to, “an expert is not someone who gives you the answer, but rather someone that asks you the right question.”. This is what RCA is all about. If I were to give you the answer, you have not learned. If I ask you the right question, then you will have to use your deductive and inductive reasoning skills to draw your own conclusion. When this reasoning process has occurred, you will have learned.
By rubber stamping the logic of someone else because it exists, we will likely not explore unique conditions that may not be in the existing logic and therefore miss a key contributing factor. This increases the risk of recurrence of the undesirable outcome. While the use of the “toolbox” is a common analogy, it does have merit for RCA. Just because someone has very fancy tools in their toolbox does not make them an expert craftsmen…know how to properly use your tools and we will be more successful in half the time!
Robert J. Latino is CEO at Reliability Center, Inc. Mr. Latino is a practitioner of root cause analysis in the field with his clientele as well as an educator. Mr. Latino is an author of RCI’s Root Cause Analysis Methods© training and co-author of Basic Failure Analysis© training. Mr. Latino has been published in numerous trade magazines on the topic of root cause analysis as well as a frequent speaker on the topic at trade shows and conferences. His most recent publication is titled “Root Cause Analysis – Improving Performance for Bottom Line Results” He can be contacted at 804/458-0645 or firstname.lastname@example.org