Root Cause

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.

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:

Root Cause Analysis (RCA) is rapidly becoming another one of those “flavour of the month” TLAs (Three Letter Acronyms). Like all TLAs, it is easy to get carried away with the hype surrounding the approach. Inevitably, then, the reality doesn’t live up to the expectations created by the hype. But nevertheless, the appropriate application of Root Cause Analysis techniques can yield significant organisational and individual benefits. This paper discusses some of the practical issues surrounding the implementation of Root Cause Analysis processes within organisations, and in doing so, attempts to give some guidance to those wishing to obtain success from their Root Cause Analysis program.

Root Cause Analysis has the potential of CHANGING people, IF the leader of the investigation knows of this potential. Far from “just another problem-solving exercise,”the root cause analysis should SLOW PEOPLE DOWN to the extent that they can see the truth of the incident under inquiry, WHATEVER THE TRUTH MIGHT BE. This paper focuses on two parts of our human nature which are large obstacles to root cause discovery, i.e., our unwillingness to slow down, and our unwillingness to let go of certain basic assumptions about life. Warning: This paper is designed to challenge the way you think about Root Cause Analysis.

I was asked recently to give a second opinion on the cause of failure of an axial piston pump. The hydraulic pump had failed after a short period in service and my client had pursued a warranty claim with the manufacturer. The manufacturer rejected the warranty claim on the basis that the failure had been caused by contamination of the hydraulic fluid. The foundation for this assessment was scoring damage to the valve plate.

This paper presents an overview of an integrated process for system maintenance, fault diagnosis and support. The solution is based on Qualtech System, Inc.’s (QSI’s) TEAMS toolset for integrated diagnostics and involves several key innovations. As a showcase of the integrated solution, QSI, along with Antech Systems and Carnegie Mellon University (CMU), have recently completed a research project for the Information Technology Branch at the Naval Air Warfare Center–Aircraft Division (NAWC-AD) in St. Inigoes, MD. The entire system, termed ADAPTS (Adaptive Diagnostic And Personalized Technical Support), provides a comprehensive solution to integrated maintenance and training.

I use the term RCPE because it is a waste of good initiatives and time to only find the root cause of a problem, but not fixing it. I like to use the word problem; a more common terminology is Root Cause Failure Analysis (RCFA), instead of failure because the word failure often leads to a focus on equipment and maintenance. The word problem includes all operational, quality, speed, high costs and other losses. To eliminate problems is a joint responsibility between operations, maintenance and engineering. 

Semiconductor devices are almost always part of a larger, more complex piece of electronic equipment. These devices operate in concert with other circuit elements and are subject to system, subsystem and environmental influences. When equipment fails in the field or on the shop floor, technicians usually begin their evaluations with the unit’s smallest, most easily replaceable module or subsystem. The subsystem is then sent to a lab, where technicians troubleshoot the problem to an individual component, which is then removed–often with less-than-controlled thermal, mechanical and electrical stresses–and submitted to a laboratory for analysis. Although this isn’t the optimal failure analysis path, it is generally what actually happens.