Root Cause Analysis Example

Many years ago, Aristotle provided us with a helpful way of seeing problems and in dealing with them:

Since everything that is in motion must be moved by something, let us suppose there is a thing in motion which was moved by something else in motion, and that by something else, and so on. But this series cannot go on to infinity, so there must be some first mover. – Aristotle, Physics

In a series of events, where people are involved, mistakes happen. Functional areas such software engineering, industrial engineering or more general areas such as medicine, law, or sociology — these areas are composed by a series of events, involving people, process, machines, environment, and other items. Undoubtedly, mistakes will happen.

What typically happens in response to mistakes is that blame is thrown around, which builds resistance, then communication fails which could lead to project failure. The better approach is to identify the root causes of mistakes and attacking that, instead of what might be perceived as the cause: Perceived causes are most likely symptoms and not the root cause, in which case the problem was never really solved.

Jeff Bezos understand the concept of root cause analysis. In this example, Jeff Bezos does root cause analysis in a profoundly simple way.

Ohno was fond of using the following example to illustrate Root Cause Analysis:

1. “Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.
2. “Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
3. “Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
4. “Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
5. “Why is the intake clogged with metal shavings?”
Because there is no filter on the pump.

This, more rigorous and long-lasting, approach to solving problems is called Root Cause Analysis. There are several tools that can aid in the process of Root Cause Analysis. One common tool developed by Toyota is called “5-why’s”. Basically, it is a simple approach of asking “why” several times until you arrive at an atomic but actionable item. To visually view the process of the “5-why’s”, a tool called an (Ishikawa Diagram) or a (Cause-and-Effect Diagram) or a (Fishbone Diagram) is often helpful — this tool is referred by either of these.

Main Components of an Ishikawa Diagram

1. At the head of the Fishbone is the defect or effect, stated in the form of a question.
2. The major bones are the capstones, or main groupings of causes.
3. The minor bones are detailed items under each capstone.
4. There are common capstones, but they may or may not apply to your specific problem. The common ones are:

• People
• Equipment
• Material
• Information
• Methods/Procedures
• Measurement
• Environment

After completing your Fishbone Diagram excercise as a group, it is helpful to test your logic by working the bones: top-down OR bottom-up like:

this happens because of g; g happens because of f; f happens because of e; e happens because of d; d happens because of c; c happens because of b; b happens because of a.

The excercise above is crucially important — you must test your logic so that it makes pragmatic sense and that the atomic root cause is actionable — that is, you can do something to correct it, reduce it, or eliminate the root cause.

Once you or your team arrive at a root cause for a specific capstone, then you typically “cloud” it to identify it as a root cause. A good rule is that there is typically *NOT* 1 root cause for a problem, but potentially several. Below is a diagram of one fishbone, decomposed:

Fishbone Diagram: A Few Helpful Hints

1. It is helpful to pull many people into the construction of these diagrams, as this ensures enough diversity of thought to make sure you get the righ potential root causes.
2. Keep asking “why” until you arrive at something atomic and actionable.
3. The purpose of this tool is to answer a question, then brainstorm about how to fix the identified root cause.
4. Getting more people involved will give them a sense of ownership — and that sense of ownership is very important because now that they feel part of the process, resistance to change will likely be less of a problem.

Real-World Example of Root Cause Analysis

I once helped a large healthcare organization save several million dollars. This organization had the largest call center in California, handling over 8 million calls per year. These were mostly inbound calls, resulting from some internal mistake that caused people to call. My job was to identify the largest opportunity (call type), why are people calling, and eliminating or reducing the root causes.

After pulling log file data and running this enormous data set against my handy-dandy, home-grown regular expression engine (written in Python), we stratified the data into logical stratifications and identified that the largest number of calls into the call center were calls related to a specific product. This discovery naturally begs the question “why” — i.e., this question forms the head of our fishbone: “Why are x% of calls related to x product type?”

We got a cross-functional team together and proceeded with the Ishikawa excercise and identified several root causes. After running the root causes against a prioritization matrix, we went after the low hanging fruit, then the more difficult root causes after that. The result? We demonstrated a quantifiable reduction of inbound calls of this specific type — a reduction of ~8%, which amounted to over $2 Million Dollars in cost savings.

Facts Versus Data

Ohno seems to see a difference in the two.  In his words,

The root cause of any problem is the key to a lasting solution, Ohno used to say.  He constantly emphasized the importance of genchi genbutsu, or going to the source,’ and clarifying the problem with one’s own eyes. Data’ is of course important in manufacturing, he often remarked, but I place greatest emphasis on facts.’

I believe what he means is that data, is a degree removed from the actual place where the phenomena is happening.  He placed a greater value on being where the work is done and where value is added.  Whereas data is often on a computer screen or on paper.  He preferred to be at the source of the phenomena.

Root Cause Analysis can be used anywhere. In software engineering, it can be used to identify the root causes of bugs in code; in industrial engineering, root cause analysis can be used to identify defects in design; in medicine, root cause analysis can be used to arrive at the reasons for mistakes or lack of patient satisfaction.

Root Cause Analysis is a helpful business tool with application to all areas of business and technology. Eliminating or reducing the root cause is much more effective than fixing a symptom. Involving people in the process will ensure buy-in and the elimination of resistance.

Creating an Improvement Culture

Ohno believed that by empowering each associate to have ownership and improve their work and the Gemba, that is how innovation is achieved and a culture of improvement is created ” it is empowering your people to make the right changes using the tools that work ” Root Cause Analysis is one of the tools that can help empower your employees and help to create a culture of improvement throughout your enterprise.  One item missed by most people is that Toyota doesn’t just build cars, but it also builds people.  Root Cause Analysis is an effective tool that helps associates feel empowered to make their everyday work better.