Empirical Root Cause Analysis, Part 1

There are many reasons for performing a root cause analysis (RCA). These reasons include determining the cause of a failure in a product or a process as well for determining the root cause of the current level of performance when a product or process has been selected for improvement.

[ad:30218]

There are many tools available to help with performing an RCA. These tools include some of the seven quality tools such as the Ishikawa diagram, run chart, and scatter plot. Another possible tool set is the seven management and planning tools, which include tree diagrams and matrix diagrams. Other tools that may be useful depending on the nature of the problem being investigated. Calipers can be useful for taking measurements, microscopes can be used to view the structure of welds, and chemical titration can be performed to determine the composition of a solution. Even a hammer might prove useful in gaining new information when performing an RCA.

Empiricism in RCA

I once discussed a hypothetical RCA with a quality consultant. The hypothetical failure being discussed pertained to a plastic component that was breaking during assembly (see figure 1). The consultant attempted to explain how to perform an RCA. He said that first you do a failure mode and effects analysis (FMEA) and then a quality function deployment (QFD).” The consultant was asked about the need to actually look at the part due to the need for empiricism in RCA, to which he replied, “A QFD is empirical; you need to go into production and look at the work instructions.”

Figure 1: Hypothetical failed component

 

The example in question pertained to a failure rate of approximately 1 out of every 1,000 units, and the root cause was insufficient material thickness due to the design. In this scenario, the weak area would occasionally break during the assembly operation. Such a failure may not be identified in an FMEA or QFD. However, it would be obvious that the failure was occurring at an area with limited material if one only looked at the failed part. For an actual failure in production, there may not be time to assemble a proper FMEA team and to schedule FMEA meetings, whereas simply looking at the failed part may quickly provide sufficient information to identify the root cause of the failure.

Performing an FMEA and looking at work instructions are not necessarily wrong, but they are no substitute for actually looking at the defective component. The consultant is not alone in neglecting this; much of the available literature on RCA describes how a team should sit together and use quality tools to analyze a failure. Unfortunately, many authors fail to mention the need to “talk to the part,” as Dorian Shainin did, according to Keki and Adi Bhote in World Class Quality: Using Design of Experiments to Make It Happen (AMACOM, 1991). Teams and tools are often needed during an RCA, but the defective part should be a part of the team.

Much of the RCA literature seems to have deus ex machina solutions. The Merriam-Webster dictionary describes a deus ex machina as a stage device in Greek and Roman drama in which a god appeared in the sky by means of a crane to resolve the plot of a play. The modern RCA equivalent would be, “the engineers and production workers sat at the table and realized the root cause was....”

Looking at the failed part provides data. Hypotheses can then be generated while sitting around a table, but they must be evaluated with empirical data and not simply by brainstorming while sitting at a table. Empirical data are needed; this requires observing, testing, or measuring. William Thompson (Lord Kelvin) has been attributed with saying, “When you can measure what you are speaking about, and express it in numbers, you know something about it; when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind....”

An RCA needs to be empirical, and concepts to achieve this already exist. The scientific method can be combined with Box’s iterative inductive-deductive process and Deming’s plan-do-check-act (PDCA) cycle. These three concepts can be combined into one simple and easy-to-use approach to RCA. I’ll describe these in detail in part two.

This article is based on a conference paper for the 2015 ASQ World Conference on Quality and Improvement.

About The Author