Root Cause Analysis Pitfalls: Trying to fix the wrong thing.

Solving problems in a quality environment is much like pulling weeds in a garden. If you do not get to the true roots of the weed, it will continue to resurface. It is easier in the short term to merely grab that pesky weed at the surface and tear off the visible portions without getting down to and removing the roots. In the long term however, the weed will actually cost you more time and effort because you will continue to do this again and again.

It is my sincere belief that doing a good job in your permanent corrective action (PCA) process typically means that the majority of your time should be spent focusing on data gathering and root cause analysis. In my estimation the 70/ 30 rule applies most of the time. This simply means that 70 percent of the time of the team will be spent in these areas.

Ask questions (a lot of them)

Before you start defining “potential” root causes to investigate you need to make sure that you have clearly defined the details of the problem. One of my favorite tools for this process is the IS/ IS NOT questioning technique. As the name implies this means asking the questions of where, and when the problem is being experienced and where it is not being experienced. This becomes extremely important in defining the problem. Let’s say for example that your company produces widgets for numerous global customers. One specific product that you supply is the same used in over 30 customer plants around the world, but only one is experiencing an issue. Using the IS/ IS NOT questioning technique will help your team to realize this and will force a different set of questions and cause you to ask why only this facility? Is there something different in how they use the product? Did they change their process? This line of thinking can change your list of potential root causes that need to be investigated instead of jumping right into brainstorming a list of potential causes.

Example of IS/ IS NOT questions:

IS (where is the problem)

• Who (is seeing the problem)
• When (did they start seing the problem)
• Where (on the product or process is the problem being seen/ experienced)
• How (often/ frequent is the problem being seen)
• Why (is this truly a problem)

IS NOT (Where is the problem not being seen but could or should be)

• Who (is not seeing the problem – plant/ area/ etc…Why)
• When (could the problem have first been experienced but was not/ why)
• Where (else could/ should the problem be but is not/ why)
• How (often/ frequent is the problem not being seen but could be/ why)
• Why (is this not really a problem)

The goal of this exercise is merely to make the team ask more questions at the outset not to ask a bunch of useless questions. If the question does not make sense for the issue, move on.

Root cause Analysis – my favorite tool to identify “Potential” root causes:

The fishbone diagram is in my opinion on of the best techniques to help teams identify potential root causes. The fishbone diagram is a tool that forces the root cause team to look in compartments or categories that could either be a cause or a contributing cause. The name “fishbone” is merely because the shape of the diagram looks like the head of a fish with the “bones” being the compartments/ categories to look at. Typical categories are the 5M/1E which is simply:

• Machine

• Methods

• Material

• Manpower

• Measurement

• Environment

There are others that work well in which the categories might be steps in the process that is experiencing the problem, departments, etc… The possibilities are endless and the creativity of the team will allow more ways to use the tool effectively.

Another tool that works well and can be used with the fishbone is the 5 Why questioning technique. This simply means that instead of accepting the stated potential root cause we ask “why” until it makes no more sense to the team or leads to a fix that is out of their control.

Example of 5 Whys:

Issue – I was late for work

Why 1 – I got up late

Why 2 – My alarm clock did not go off

Why 3 – Stopped running

Why 4 – Power went out

Why 5 – storm knocked the transformer our in my neighborhood

As I mentioned above this question could likely continue but we are already at a point that is out of my control. I cannot prevent storms or transformers from being knocked out but I can get a battery operated clock as an action to fix my issue. There are others as well such as back up power methods, etc… but I think you see my point.

The more we use these tools and techniques the more comfortable our teams become with them and more effective at using them which will result in less repeat issues.

Happy Problem Solving.

Mark