by Kevin McManus, Chief Excellence Officer and Systems Guy, Great Systems
How Do You Find Root Causes?
I believe that in order to improve ANY process, you have to find and minimize the root causes of process waste. Most organizations would say that they know this, and they could easily show you how they invest lots of time and money over time in attempt to do this. What they might struggle to do however is show you how effective their current approach to performing root cause analysis is.
The following questions represent those that I have been asked to comment on in recent months.
When should a formalized “root cause analysis” be conducted on an equipment failure event?
Before we can effectively answer this question, we need to determine what is meant by the term ‘formalized.’ Most people consider root cause analysis to be formal in nature if some tool, or set of tools, is used to help guide people towards the root causes of a problem (as opposed to simply standing around and relying on opinion). My personal definition goes a little further however. To me, an RCA process is not formal unless facts are used to validate the root causes that are selected, and ideally, to also help guide the problem solvers towards a comprehensive set of possible root causes to begin with. Often, the list of possible root causes itself is much less than adequate because the belief systems, opinions, or knowledge base of the problem solver does not consider a sound list of human engineering, communication, procedure, training, work direction, or management system root cause possibilities. If your list of possible root causes is too narrowly defined, you won’t even begin to consider certain problem roots, no matter if you are using a formal tool for analysis purposes or not.
Ideally, all equipment problems should be analyzed. Unfortunately, few organizations, if any, have the resources for pursuing this ideal in the short term. In turn, equipment problems must be attacked from two perspectives. First, all major problems should be formally analyzed. The organization must determine what ‘major’ means by considering acceptable downtime duration or cost thresholds. Secondly, all downtime problems of a significant (again, management must define the significance threshold) nature should be captured in a database for subsequent Pareto analysis. Formal root cause analysis is then used on the biggest bar of the Pareto chart, just as it was for the singular equipment problem.
As root cause analysis process formality and soundness of design increases, your problems should decrease over time. Conversely, if you choose to rely on a primarily opinion based root cause tool such as fishbone diagrams or the five whys, you will compromise the results of your root cause analysis efforts, whether you used these tools in a formal manner or not. In too many organizations, problems keep coming back because the problems were not analyzed using a sound RCA process, facts were not used to validate the root causes that were selected, and a less than adequate list of possible causes was considered in the first place.