Finding the Root Cause

The goal of Root Cause Analysis (RCA) is to find the fundamental reason for a problem, and then eliminate that reason so the problem will not recur.

An example may help explain this concept. A quality problem is reported in assembling a product. Inspecting the subassembly shows that one part varies in length from unit to unit, making it hard to fit the final product together. The immediate cause is the length of that one part. A check of the machine that cuts that part shows a loose adjustment. Tightening it to specifications makes everything work well…for a day or two. After a few cycles of quick fixes, a root cause analysis seeks the reason why that adjustment does not remain fixed. Is there excessive vibration? An untrained employee who makes the adjustment incorrectly? Does excess lubrication make something slip? Is a lock nut missing?

Suppose the problem was the missing lock nut. Why did it go missing? After replacing the lock nut, what will keep the new one from "going missing" too? Perhaps a change to the maintenance manual will point out this small but vital part.

So root cause analysis seeks the underlying cause of a problem, seeking the long-term solution.

RCA takes place after an error has occurred and been detected. Often it is only invoked after this error has occurred repeatedly, because people are inclined to fix the immediate problem without spending more time and effort to trace the roots.

A Sample of Root Cause Analysis Techniques

Here is a very small sample of RCA techniques:

Five Whys
The Ishikawa Diagram (Fishbone Diagram)
FMEA: Failure Mode and Effects Analysis

Five Whys

This approach is to ask the question "Why" five times, expecting to find a problem in an ongoing process. Improving the process should fix the problem by preventing the chain of events leading to the problem.

From the above example, the problem is "We cannot assemble this product". Then ask:

Why? One part is too long or too short
Why? The machine that cuts this part works inconsistently
Why? One adjustment is loose
Why? A lock nut is missing
Why? The maintenance manual does not mention this lock nut

The solution then is to update the manual, which the maintenance worker uses, so the lock nut will be included.

Credit for this approach is given to Sakichi Toyoda of Toyota Motor Corporation.

Note that this approach may be too simplistic. Even in this simple example, the root may have been deeper: the maintenance worker's trainer's manual omitted this lock nut.

Also, Five Whys does not guarantee the same solutions from different analysts. One analyst might ask "Why did we have an incomplete training manual"? "Why did we not insist on proofreading the manual"? Another analyst, with an instinct for product design, might recommend slots instead of round holes, to make the final product easier to assemble with more leeway for the sub-assembly. A third could point to the need for error-proofing or quality testing immediately after the machine with the loose adjustment. You may want to refer to this article on poka-yoke error-proofing .

Ishikawa Diagram (Fishbone Diagram)

This technique is named for Kaoru Ishikawa, who developed the diagram that shows how the environment, equipment, management, materials, measurements, methods and people might have contributed to one problem. This tool uses questions such as:

Does the environment affect the process? Did extreme temperature, humidity, vibration or other environmental factors affect the equipment or the operators?
Is the correct equipment being used, in the correct manner? Is it properly maintained?
Did management promote and reward quality and safety, or put all the focus on cost-savings and productivity?
Was the correct material used? Was it tested for quality before use? Was it handled properly?
Were measurements taken with properly-calibrated instruments, by properly-trained personnel?
Are the methods documented? Are workers and processes audited to ensure the methods are being followed correctly? Were the methods tested to ensure they worked properly?
Were the right people operating the equipment? Were they trained? Did they have adequate experience? Are there barriers to understanding the tasks, such as language? Were the people fatigued or distracted?

A thorough set of questions will seem repetitive:

"Were people distracted by the environment"?
"Did the environment distract the people"?
"Were people affected by the hot, cold, noisy, windy, smelly or dirty environment"?
"Did the hot, cold, noisy, windy, smelly or dirty environment affect the people"?
"Did management ignore the problems caused by the hot, cold, noisy, windy, smelly or dirty environment"?
"Were measurements affected by changes in temperature in the environment"?
"Did the hot or cold environment affect the measurements"?

Root cause analysis using Ishikawa diagrams may fail to distinguish between "necessary" and "sufficient" conditions. From the original example: the missing lock nut was "sufficient" to cause defects in one machine's output, and so it caused the assembly problems. However, if excessive vibration can also cause slippage even if the lock nut were present, then it was not "necessary" for the lock nut to be missing.

Different analysts might find different root causes. Could the first example truly be a "people" problem? The maintenance worker lacked the training or experience to include the lock nut.

FMEA: Failure Mode and Effects Analysis

The FMEA approach tries to analyze "all" the potential failures, the modes or ways in which the failures occur, and estimate how serious the effects of the failures are. This is usually seen as a predictive exercise, where Root Cause Analysis reviews a failure after the fact.

RCA can certainly benefit from a prior FMEA analysis, if the failure had been noted already.

FMEA is often considered a "bottom-up" approach that is better at predicting single cause failures than problems stemming from complex causes.

In the original example, one may have asked "What if this lock nut goes missing?" The recommended action would have been "Ensure that the lock nut is replaced after maintenance", and quite possibly the maintenance manual would have been corrected at that time.

Implementing a Root Cause Analysis Technique

The first step in implementing any RCA technique is to become convinced that the benefit is worth the cost. If your factory currently fixes each problem as though it would never recur, then start by tracking problems and estimating the costs to repair each. Upon review, some problems will be seen as recurrent. These are the first candidates for RCA.

Perhaps the easiest RCA is "Five Whys". Open an investigation into one recurring problem, and ask "Why" until one or more processes have been identified. Make the changes as indicated, and include this fact in the log of problems. Hopefully that one problem will not arise again.

The basic Ishikawa diagram approach can be used without a huge investment in training. Simply follow the discipline of working through the six main areas (environment, equipment, management, materials, measurements, methods and people), asking which of these could contribute to the problem. It does take practice to do this well, however. For example, it might take careful questioning to realize that the raw materials may have been damaged by an unusual environmental condition after they had been inspected.

If the methods described above do not solve the problem, consider using Six Sigma. Sometime statistical tools are needed to understand the process and find the root cause.

Choosing the best RCA for your factory depends on many variables, including the type of work, the complexity of the problems, and the skill levels of the employees. Some overall manufacturing methodologies, such as Six Sigma, have their own techniques for determining the root cause of problems. If you already use a methodology, be sure to check for the problem-solving techniques that fit into that program.

By Oskar Olofsson