Saturday, May 12, 2007

Root Cause Analysis - Part I - Introduction

The following write-up in on Root Cause Analysis. Some of what you will read is unique to me, other ideas and suggestions are an accumaulation from a number of sources that I pieced together over the years as I applied this Tool. You will not find an Ishikawa Diagram Below. The Ishikawa Diagram is better served for presenting some facts, it is NOT what Root Cause Is, Sorry!

Whether our jobs are in Operations, Sales, Engineering or Quality, or any other function within our organization we should become familiar with the concept of root cause analysis and how it can benefit our day-to-day job functions.

Each day we encounter problems or obstacles that make it difficult to perform our jobs or meet our goals. Every employee who performs their work function on a day-to-day basis becomes a problem solver. In our efforts to improve our work processes or to control and prevent defects, errors and obstacles, we all should be looking for the root cause that is causing the disturbance so that we can implement prevention solutions to avoid reoccurrence.

Symptom - An indication something is wrong (i.e. engine warning light flashes).

Root Cause - Something that produces the departure from a normal function or expected result (coolant level low).

Problems can come in many ways. Read my Post on the 3 Types of Problems at:

Note: - Many people, especially quality consultants (they need to prove they know more than you) will have lenghthy and confusing definitions, just keep it simple.

It is first important to clarify what is meant by prevention activities or solutions, or maybe it is better to clarify what are not prevention activities. Correcting errors, removing defects, reworking, redesigning or modifying are not prevention activities. They are fixing activities. These actions may or may not be a result of prevention actions, but they themselves are not preventive steps. Prevention has to do with WHY the order is incorrect, WHY the system repeatedly goes down, or WHY the software won’t work. Performing root cause analysis is not just action taken after a problem arises, but rather a technique that becomes a day to day work function that creates a mindset that constantly searches for ways to improve the work process and implement actions that will prevent out of control situations from happening. Clearing up a problem (no matter how fast/good) after an outage or an order doesn’t go through the system correctly the first time is not prevention. We need to design prevention into how we do things. This is what root cause analysis was intended to be used for when it was developed for continuous process improvement activities.

In order to conduct a systemic root cause analysis investigation the following items need to be available:
  • A process is required for identifying, documenting, and comparing the causes producing the problem that need correction and prevention.

When a problem occurs most experienced workers can immediately provide an answer to what they think will solve the problem. However, in may cases we will find that if the problem solving is done solely through the eyes of experience, the solutions suggested many times tend to be one-dimensional (non-systemic). For example, take service order fallout. An Order Writer sees something he/she can do to get the order through the system. The MIS Analyst sees as a solution to the same problem a way to change the input screen to avoid the problem. The Order Writer Supervisor sees a way to change the procedure to avoid the problem. The Sales Manager suggests that the work be contracted out as the best solution to the problem. While all of these actions may be valid, the objective of a true root cause analysis is to accurately obtain all of the causes, and to document them in a manner that provides sound decision making support for the Provisioning Department.

It is important to have an end-end perspective (systemic) view of the situation as well as the availability of objective data prior to dispersing resources (dollars, people) to correct a problem. Do we change input screens because there is a Temporary Order writer filling in for two weeks? Do we contract the work out because our initial training is not adequate? Do we write a new procedure for all because one area never got the last revision? The answer to these questions are “It Depends,” once all the facts are known we can make better decisions, to make them independently most often results in a temporary fix to a symptom, or worse, tampering with the system.

  • It is important to understand “Systems Thinking.”

Employees work in a system. "Management Owns The System. A system is a whole consisting of two or more parts, (1) each of which can affect the performance or properties of the whole, (2) none of which can have an independent affect on the whole, and (3) no subgroup of which can have an independent affect on the whole. In short, then a system is a whole that cannot be divided into independent parts or subgroup of parts.

When conducting root cause analysis we need to determine if the problem is an end result of many activities or inactivities, decisions and omissions that are part of how we are operating; or is the problem the first result of someone coming in contact with an existing condition that waits quietly to cause problems once it is put into operation. A good root cause analysis process should produce information that describes the type of system with which we are dealing. If our analysis techniques drives the analyst or team to produce only one root cause, or requires that the analyst or team to select a prepared brainstormed list of suggested causes that suggests that only one part of the system as being the most significant, then we have lost sight of the whole system. What happens next is the root cause analysis becomes subjective and highly prone to error based on the person who has the most authority or orator skills. It is for these reasons that meaningful root cause analysis must first focus upon the whole causal system. Prevention solutions cannot be implemented reliably without this type of focus.

  • It is important to understand the functions and procedures of the systems involved.

Once we know and understand the principles behind organizational structures and alignments, the mystery surrounding causes is replaced with fundamental, practical systems knowledge. That is, Process Management principles can be applied in order to design and ensure continuing control of processes and systems. The first premise of Process Management is that when principles are properly applied the result is predictable success; and when principles are not properly applied, the result is predictable non-stable system failure. With the essential layout of the whole causal system, and the understanding of functional principles, root cause analysis provides the opportunity to design quality into our operations, and to isolate and remove systemic non-value added activities.

  • Inside any organization, you must have In-Process Controls that prevent and monitor your systems.

Part of the root cause analysis process is identifying the points in the causal process where internal control exists. If the root cause method simply allows the analyst to provide an opinion of what he/she considers to be one of the problem areas we have not utilized this investigative tool properly.

Root cause analysis should therefore provide a means to decipher and systematically validate the cause and effect relationships in the system, so that process owner(s) making the decision have a means of validating the data upon which the solution is to be made based on customer and corporate goals. The process owner(s) overall knowledge of the organization’s finances, planning, goals and limitations, along with the capability to validate data better assures sound decision making and improved operations control results. Because we control what happens in our systems with policies, procedures and practices, a successful root cause analysis must identify prevention opportunities for continuous improvement, as well as identify those required corrections and fixes that are more obvious and immediate.

In summary, root cause analysis is the systemic process of obtaining and displaying data about counter-quality activities within an organization’s systems and processes; then identifying and analyzing them for decision makers to make sound preventive solutions.

click to enlarge

Dilbert © by Scott Adams

Remember - “Every time something is wrong, it costs money.”

Root Cause Analysis Part II - Planning a Root Cause Session -

Check Out Data Collection & Analysis Too

Also see Pareto Chart Analaysis @

1 comment:

Anonymous said...


Thank You, good stuff!