I 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 throw money 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. Problems appear when we have variations of usual systems or procedures, so in order to solve those problems, we look for the causes. As I was saying 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.

Edwards Deming, as statistician, also liked to say that there were two main kinds of causes - common and special.

Types of root causes

Common or Environmental causes tend to cover 85% of the cases. They’re called common because they equally affect all workers in a section. Poor light, humidity, vibration, poor quality cafeteria food, absence of a proper quality program, poor supervision or instruction, problematic procedures, mismatch between requirements and deliverables, poor arrangements for the comfort of workers, are all examples of common or environmental causes.

These are faults in the system, so they usually persist until they are addressed by management. Employees cannot change the lighting or write new contracts for raw material or call for action at a high level.

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. Signals tell an employee whether to leave the process as it is or to take action.

Common causes are more difficult to identify than special causes. When all special causes have been removed, common causes remain. Once a common cause is identified, management must decide whether it will be economically feasible to change it. Management’s obligation is to focus attention on the common causes of variability, but in many companies, employees are the first to be blamed when only 15% of it is their responsibility to resolve!

So if we really want to get rid of issues with quality, the art of root cause analysis should be managed accordingly to be able to identify the real root causes, and determine if they are common (to be fixed by management) or special (to be fixed by employees). If you are a Six Sigma practitioner, you would do this in the analyze phase of your DMAIC process.

Tools to identify root causes

My 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. The rules are: 6 or more consecutive points all going up or all going down indicate a trend, 8 or more consecutive points all on one side of the average indicate a process shift has occurred, and 14 or more consecutive points alternating up and down indicate a process which is being over controlled.
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.

If you need more information on how to use these tools, check out Simplilearn’s Lean Six Sigma Green Belt certification course here.

About the Author

Luciana PauliseLuciana Paulise

Luciana is a business consultant and founder of Biztorming Training & Consulting. She holds an MBA from CEMA University, a top-ranked institution at Buenos Aires, Argentina. She is also a Quality Engineer certified by the American Society of Quality (ASQ).

View More
  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.