An Integrated Process for System Maintenance, Fault Diagnosis and Support

If I have an unwanted situation which consumes resources and tends to happen in a repeated fashion then there is a possibility that it might be beneficial to figure out what is really causing this situation to occur and remove it so the situation does not occur again. This is generally referred to as Root Cause Analysis, finding the real cause of the problem and dealing with it rather than simply continuing to deal with the symptoms.

There are many types of RCA tools available to organizations, including 5 Why?, Fault Tree Analysis, Interrelation Diagrams, Ishikawa Diagrams (Fishbone, Cause and Effect) and many others. A great example is the 5 Why? method: starting with the incident itself, an RCA team would continue asking “Why did this happen?” until they arrive at the root cause. Refer to the following example:

I was recently engaged by a client to conduct failure analysis on a large (and expensive) hydraulic cylinder off an excavator. This hydraulic cylinder had been changed-out due to leaking rod seals after achieving only half of its expected service life. Inspection revealed that apart from the rod seals, which had failed as a result of the 'diesel effect', the other parts of the hydraulic cylinder were in serviceable condition.

From my own RCA experiences at industrial sites and manufacturing facilities, I have found that there is little consensus regarding what constitutes an Root Cause Analysis activity, what it is supposed to accomplish, how it will be applied, who should do the activity, when it will be applied, etc. Very little agreement exists on these basic RCA points. Ask these RCA questions in your work environment and listen to the diversity of opinions you will hear in reply.

The business process is most commonly named Root Cause Failure Analysis (RCFA) or root cause analysis. The name itself implies the largest and most expensive problem when implementing problem solving in an organization. The results wanted from the process are to eliminate the problem, not to analyze the failure. To convey the desired result to the organization, the name should therefore be changed to Root Cause Problem Elimination (RCPE).   

DOE Order 5000.3A, "Occurrence Reporting and Processing of Operations Information," investigation and reporting of occurrences (including the performance of root cause analysis) requires the and the selection, implementation, and follow-up of corrective actions. The level of effort expended should be based on the significance attached to the occurrence. Most off-normal occurrences need only a scaled down effort while most emergency occurrences should be investigated using one or more of the formal analytical models. A discussion of methodologies, instructions, and worksheets in this document guides the analysis of occurrences as specified by DOE Order 5000.3A.

To successfully carry out this mission, a root-cause investigation needs to be evidence-driven in accordance with a rigorous application of the bedrock of all root-cause methodologies: the Scientific Method. Consistent with the Scientific Method, underlying assumptions have to be questioned and conclusions have to be consistent with the available evidence, as well as with proven scientific facts and principles. Sometimes root-cause investigations fail to fulfill their primary mission and the failure recurs. In that regard, diagnosing the root cause of root-cause investigation failures is, in itself, an interesting topic. Here are three common reasons why some root-cause investigations fail their mission.