Root Cause Analysis Example

Written by:  • Edited by: Michele McDonough
Updated May 19, 2011
• Related Guides: Project Management Methodology | Root Cause Analysis

This article gives a brief explanation of what a root cause analysis is and then walks you through an example of a root cause analysis.

What is a Root Cause Analysis?

A root cause analysis is a project management methodology that attempts to get to the bottom of a problem. The five whys methodology is an example of a commonly used Six Sigma technique for performing a root cause analysis. Root cause analyses aim to help resolve consumer complaints about quality, fix problems that occur in the production process, or create more productive processes. Once identified, the root cause will help eliminate and prevent problems that occur in the future. When performing a root cause analysis, you break down the failure of a product or process to determine what exactly went wrong. Prevention of problems is much less expensive for your company than repairing the problem.

How is a Root Cause Analysis Performed?

picture
click to enlarge
Basically, a root cause analysis comes about when the need for a quality improvement project arises. This happens when some problem or defect has been found - either in the quality of a process or in the quality of a product.

When beginning a root cause analysis, it's important to get down to the core of the problem. Here are the important steps of a root cause analysis:

1. You must provide a clear definition of the problem.

2. You need to gather any data concerning the problem and analyze all evidence of the existence of the problem or issue.

3. Once you have solid data, analyze the problem by asking "why." Keep asking "why" until you cannot go any further down the causal relationship ladder and all potential causes have been identified.

4. Once identified, you can then analyze the causes for those that are changeable for prevention of the problem in the future.

5. Brainstorm workable solutions for the team. Eliminate causes that are not necessary to the process and change those that are within your control.

6. Implement the changes through effective creation of a change management plan. Monitor the results.

If necessary, repeat steps one through six to eliminate further causes.

Root Cause Analysis Example

Brenda's company has a problem. For every ten t-shirts her company produces, there is a defect. The screen-printing on the t-shirts is blurry and off-center. Moreover, some of the colors bleed through the fabric. Customers and distributors have been complaining. Brenda will have to perform a root cause analysis in order to get to the bottom of the problem.

She first calls a meeting with key stakeholders in the quality improvement project. With the stakeholders, a problem definition is reached, "The images on the t-shirts are not printing correctly."

Brenda assigns the task of data collection to two team members. They find the following: While 1/10 of t-shirts experiences a serious highly-noticeable defect, 1/4 of all shirts have an image that is off-center, 1/3 of the shirts have images ranging from slightly blurred to extremely blurred, and more than half of the shirts, almost 2/3 have images that bled through the t-shirt fabric in varying severities from barely noticeable to highly noticeable.

Brenda decides this problem can be better analyzed through using a Pareto chart and she creates one in Excel. After examining the data, she decides to focus on the cause of the image bleed.

Brenda asks, "Why?"

After determining that the quality management project would focus on the cause of the image bleed on the t-shirts (because almost 2/3 of the t-shirts produced by her company show this defect), Brenda begins to ask "why" to determine the cause of the problem. At the top of a sheet of paper, she writes "2/3s of t-shirts produced bleed through the material from a severity range of barely noticeable to highly noticeable."

Underneath this, she writes, "Why?"

"The t-shirt fabric is too thin." This first response can't be possible, because the company carefully researched the fabric and the ink for the project to ensure the materials would work. So, she looks for an alternate cause and comes up with:

"The ink isn't drying fast enough."

"Why not?" She asks the question, again, to get closer to the root cause of the problem.

"Because the presses are using too much ink." If this is the answer, it would also solve another problem the company has been experiencing, the blurring of images printed on 1/3 of all shirts produced.

Another potential problem at this stage could be that the ink ordered wasn't correct for the project. However, Brenda checks the inventory logs and finds that this isn't the case.

"But why are the presses using too much ink?"

"Because the presses haven't been properly calibrated."

It seems as though this last answer is a contender. Brenda sits down with her project team and constructs a plan for changing the calibration on the machines.

Brenda's Team Implements the Change

picture
click to enlarge
Brenda's team goes back to the presses and they calibrate the machines according to the change management plan. Once each machine has been calibrated, they run a sufficiently large trial run to determine whether the problem was solved. The project is carefully monitored to ensure product quality. The team finds that the cause identified was the root cause of both the blurred images and the image bleeding. However, they did not solve the problem of the images that were off-center. Brenda schedules time to perform another root cause analysis to eliminate this problem.

Summary

While some root cause analyses will produce results quickly like Brenda's, your team may go through the quality improvement process several times before determining which causes to tweak, change, or eliminate completely. By completing a complete root cause analysis before undertaking any quality improvement project, your team can save money and time by preventing problems, rather than repairing problems.


Comment

Showing all 1 comments
 
Ken Nov 25, 2009 1:28 PM
5-Why Problems
While I might agree "5-Whys" is better than nothing, it is actually an extremely weak "root cause analysis" method. It suffers from inherent weaknesses:

- Only finds a single problem, unless you decide to run through an arbitrary number of 5-Why chains. And then, how many should you select?

- Rarely goes to the actual root cause level
"improperly calibrated presses" is not a root cause. Was it a training issue? a procedure problem? a maintenance periodicity problem? were the right calibration tools not available? I could go on, but you get the point.

- Based entirely on the biases of the investigator. If you're a training person, your questions are going to find training problems (whether there were any or not). Conversely, if you don't know anything about human engineering and equipment design, you won't think to ask those questions. Therefore, you'll be missing possibly critical problems.

- Almost always suffers from "confirmation bias." That is why people like it. It gives them the answer they were looking for in the first place. It justifies their thought process, whether it was right or not.

Even in your example, it looks like you only went 3 whys deep. Why not 5? or 6? or 15? The point is, "5 whys" is an arbitrary number that really doesn't mean anything.

I've watched 5-Whys used along-side an advanced root cause analysis technique (TapRooT). It was embarrassing seeing the difference in the results. The users asked why they were bothering with the 5 Why method when an obviously superior technique is available.

I'm glad to see you are advocating root cause analysis to find the reasons that problems occur. This is a huge step in the right direction. However, "5 Whys" is an old technique that was designed before advanced root cause analysis became available. I encourage you to take a look at a less biased, easy-to-use, accurate system. TapRooT is an excellent example.
 
blog comments powered by Disqus
Email to a friend