Finding Root Cause

Root Cause Analysis

Many times an improvement endeavor is kicked of with something like this, "Let's implement a new spreadsheet!" (as if we do not have enough of those already). Before charging forward with your shiny, new solution it would be nice to have some idea if it will solve the problem you are having. While the boss or some other ENTF on the team is trying to derail your team's performance, this is the perfect time for you to slam the brakes on and ask the team why the "fill in the blank measure" is not up to the standards as we all understand them.

If no one can answer in a way that most of your team member can agree upon, or passes the on/off test, then you should back up the train and venture into Root Cause Analysis. The following is how I typically perform this analysis with a team, and this is certainly not the only way.

We start with drawing the fish with the simple problem statement at the head, and since we are not on the manufacturing floor, draw four "bones" and label them as the image depicts. These assist in categorizing the potential causes. You may find other bones for your analysis based on the specifics of your problem.

When you have consensus on the problem statement, start gathering the potential causes. Everyone should have a permanent marker and a stack sticky notes to write their causes on while you, the facilitator, collects the stickies and sticks them to the bones. There will be no judging of potential causes, but giggling is allowed. This will go on until everyone is passed out on the floor from exhaustion.

At this point you and the team can start assigning some sort of numerical value to each sticky note in the form of a Risk Priority Number (RPN). This is from Failure Modes & Effects Analysis and is composed of the Severity of the cause, the number of Occurrences of the cause, and then the ability for people or systems to Detect the cause. I use a 1-3-9 scale with 9 being the worst and then define what each number means based on the problem we are facing. This scale creates differentiation between the potential causes. Multiply the Severity, Occurrence, and Detection numbers together and force rank the results from largest to smallest.

Now that we have some idea of the riskiness of the potential causes we can start apply 5-Whys to our list starting on the highest RPN. It is critical to have the right stuff-knowers in the room with this activity. Ask "why" however many times it takes to get to what the team can agree to as the Root Cause. It may take one Why or it may take ten Whys. These may branch off into other streams of Whys and in the end may look like a fault tree analysis without the Boolean symbols. When you think you have reached the Root Cause, go back up to the problem statement saying "Therefore" and listen for any holes in the logic where someone may have used magic fairy dust to connect down through the Whys.

Go through the stickies with high RPNs (I'm not going to give you a number, it's up to you and your Project Sponsor) until you feel you have address the problem and any potential issues you may face in the future. Sometimes a potential cause won't have a high RPN, but the team feels like it is something that needs to be addressed.

Give this technique a try so we can stop "solving" the same problems over and over again.