Root Cause Analysis: When to Stop
“Is that Miss or Mrs.?” the receptionist asked. “Miss,” replied the elderly lady. “My friends just call me Di.”
The receptionist nodded as she typed. “Got it. Miss Di Agnosed. That should be all we need for the records. You can see the doctor now.”
Dr. W. R. Ong smiled pleasantly. “What seems to be the problem, miss?”
“Well I have this rash….” Dr. Ong looked at the proffered hand. “I also have pain in my shoulder and my foot.”
“I’ll need to refer you to others for that,” Dr. Ong said. “In the meantime, I’m prescribing an ointment that should take care of your rash.”
During the next few days, Di visited a chiropractor, who gave her an adjustment for the pain in her shoulder; and a masseuse, who massaged her foot. Nothing really helped. She was still miserable.
Di told all of this to her niece, Jane. Jane was a trained Six Sigma Black Belt. “Gee, Aunt Di, it sounds like a set of related symptoms. In Six Sigma we learn to carefully analyze related problems to determine their root cause. Let’s see what we can find out about your condition.”
Jane spent a couple of hours questioning her aunt and searching the Internet before concluding that her aunt’s problem was probably shingles. It accounted for all of Aunt Di’s symptoms and matched up with her medical history, age, and a number of other factors.
The healthcare profession failed Miss Di Agnosed for a number of reasons.
- Each person she visited was a specialist trained to understand one aspect of health.
- Specialists aren’t trained in systems thinking.
- Each person had an economic incentive to treat a symptom.
- None of them had time to properly analyze Di’s symptoms.
These issues are common to nearly every business. Problems won’t be solved until they’re approached properly. Not being a Black Belt doesn’t let you off of the hook. Problem solving is the cognitive process of identifying how to best proceed from an undesirable state to a desired state. It’s both an art and science. Here are a few guidelines to help you do a better job of problem solving.
Take a System View
The story above illustrates why this is important. Typically, problems present themselves as symptoms, but you won’t really correct the problem until you treat the cause.
Categorization of Causes Isn’t Identification
As Quality 2.0 professionals, we learn about a variety of tools to help us categorize potential problem causes. Cause-and-effect diagrams, Pareto diagrams, affinity diagrams, and tree diagrams are a few examples. However, just because you place a possible cause into a category doesn’t mean that you’ve identified the cause. In fact, sometimes putting the cause into a category does more harm than good. Categorization is a data-reduction technique that helps our minds deal with too much information, but it’s not useful for validating causes or solutions.
There’s No Ultimate Root Cause
The term “root cause” is a misnomer. In reality, a search for an ultimate root cause would inevitably result in infinite regress to the uncaused first cause. Although this may be an interesting philosophical exploration, it isn’t worth much in terms of finding a practical solution. Instead, we pursue causes to the point where we can apply practical solutions. This often means addressing multiple “root causes” that contribute to a portion of the symptoms. Categorization techniques can help by showing which of several root causes will have the greatest effect in any given solution.
Knowing Where to Stop and Apply a Solution Is a Matter of Judgment and Economics
I once worked with a process engineer on a problem involving printed circuit boards. The symptom was a complete failure at the very end of a long, multistep process. The photoresist material, known as Riston, simply fell away from the copper circuit board at the end of the process. A series of designed experiments revealed that the problem could be eliminated by choosing the exposure level at one process step based on the pressure setting used on the previous step. At this point, I, as the quality engineer, was satisfied that the problem had been solved, and I moved on to other projects. However, the process engineer delved deeper and learned that the root cause (for him) was that too much energy was input when both pressure and exposure settings were high, causing a breakdown of the Riston at a molecular level. His deeper knowledge allowed him to design improved storage and transportation specifications to prevent even more Riston failures.
Which of us was correct? Both! The process engineer and the quality engineer had different responsibilities, and this dictated different stopping points in the search for root causes. The same applies to everyone in your organization. What’s the proper level for you?