Root Cause Analysis

Agile Core Principles
June 18, 2018
Harnessing the power of Retrospection
June 20, 2018

Root Cause Analysis

I would like to say root cause analysis is an art, because in my experience, the real problem in a Six Sigma project or in a lean implementation is not that we don’t know the solutions –it’s that we don’t exactly know what the real root causes are.

We tend to be blind to some causes that seem to be obvious to other people. As we don’t see them, we don’t analyze them, so the solutions we often apply are just Band-Aids that only hide for a while the real root cause. The problem ultimately returns, and we continue to spend more money, effort and time at it in a futile attempt at a solution.

So what is actually a root cause?

A root cause is an underlying cause. A root cause is a factor that caused a nonconformance and should be permanently eliminated through process improvement. As I was stating before, we could just look for the first cause that comes to mind, or train our teams to conduct a thorough analysis every time we have an issue to make sure we always solve it right the first time.

Types of root causes:

Common or Environmental causes tend to cover 85% of the cases. They’re called common because they equally affect all staff in a section.

Special or local causes (the other 15%) are specific to a local condition. In many cases, they can be corrected on a statistical signal by the employees themselves.

Tools to identify root causes

Recommendation is to work in teams to solve issues, inviting experts, managers, and operators to participate depending on the severity of the problem, so as to make sure you have ideas from everyone involved. A flip chart or a computer shared over a big screen will help you collect all the ideas and keep track of them.

5whys: To identify the root cause of a problem, Toyota’s Taiichi Ohno urged workers to ask “Why” five times. Frame the problem as a question, ask “why” (what are the first level causes of the problem?), write each cause down, and for each cause, keep asking “Why” until no more answers can be arrived at. By the time you have asked “Why” five times, you are usually at the root cause. Use the final causes suggested to generate possible solutions, and use data to accept/reject each proposed cause.

Fishbone diagram: (or Ishikawa diagram) decomposes a problem into potential logical causes. From the Fishbone, we need to test the most likely candidates. You can use the 5whys to drill down on each main cause to make sure you get to the underlying cause. Your team can use “multi-voting” to narrow down the list, and then test the chosen option. This technique is effective and simple.

Control chart: It is a more sophisticated tool but is really useful to objectively distinguish common and special causes. Control charts are generally used to control processes (DMAIC control phase), but they can also be used to analyze processes and improve upon them. Most processes are not under statistical control, so attentive use of control charts can identify assignable causes. They will only detect processes that are out-of-control, not why the process is out of control, but it’s still a good way to start.
Once you detect you have an issue, you can use the 5whys or the Fishbone diagram to understand why it happened. Common causes will generate most of the variations on your chart, but special causes will be very clear, so that any employee can detect them by himself. When a new data point falls outside the control limits or violates one of the rules it is an indication that a special event has occurred. Root cause analysis is designed to help identify not only what and how an event occurred, but also why it happened. Understanding why an event occurred is key to developing effective solutions. Identifying root causes is the key to preventing similar recurrences.

Why isn’t everybody doing it then?

This process is pretty time consuming and not all projects are capable or willing to spend more additional resources on such tasks, especially if they are low-priority and the projects are small apps or something that is not rich on multiple handy features. There are even times where some team members already know what hides in the root-cause making this activity useless.

 

How can I tell whether any root-cause analysis should be performed?

There are several factors, by measuring which you will be certain on whether the root-cause analysis session is something your project can afford. First of all take a deep look at the defect. Is it worth is? Secondly go through your current test coverage as well as your test plan to make sure if you need this additional work in the first place. Then review defect priority to make sure if it requires additional attention and take a good look at your team: are they up for more work? Do they have time? Is it really necessary? And if all the mentioned above factors are satisfying you should go for root-cause analysis.

 

Leave a Reply

Your email address will not be published. Required fields are marked *