BACK TO BASICS
Curse of the Super-fish-al
by Martin Hedley
A powerful tool in the problem solving toolbox is the fishbone or Ishikawa diagram, which helps us identify root causes. When testing the relationship between each cause and effect, we often encounter results we do not like and start to develop profound knowledge. Unfortunately, this extremely influential tool is often used superficially. Why is this so?
Root cause analysis teaches us to ask, “Why?”
five times, and from this I developed these five ways not to use a fishbone. (See
Figure 1 for an example of a superficial fishbone diagram.)
Throwaway. The fishbone is best used as a living document in the workplace where the problem is being solved. In the West, we develop a fishbone, gain some knowledge from it and file it. The learning experience of the team is hidden and not built upon. In Japan, however, the fishbone stays on the wall and ideas are added in the normal course of work.
Facilitators must encourage teams to leave fishbones where they are, regard them as living documents and build on them.
Rigid. We put many diagrams in the computer because they may be reviewed by management and because we need to put them in our storyboards. Fishbones, however, do not fit neatly into a computer; they are limited to one or two levels to maintain readability, and inputting them takes time away from solving real problems. Few people have access to large scale plotters, and the normal rendition is a neat but insufficient representation of the team’s analysis on 8.5 by 11-inch paper.
Facilitators could refer to fishbones in storyboards and invite people to see the real thing if they need to. Facilitators could also publish a large version of the fishbone in pencil, on the wall near the team that created it, challenge the team to flesh out the bones and return occasionally to see what’s happening.
Superficial. Forty-nine of 50 fishbone diagrams I recently reviewed went no deeper than the second level of decomposition. When asked why, the most common answer was, “We already knew what the problem was!” Then why does the problem still exist?
The second most common response was, “We’ve solved it before.” If this is the extent of the fishbone’s use, we are better off using a tree diagram, whose rigid lines and rectangles appeal more to the Western eye. They’re easier to put into a computer, too, but that misses the point.
Facilitators must push teams to stick with the tool and force the analysis.
No data. Opinions given during brainstorming sessions are insufficient in deep analysis. The real work begins when brainstorming is over. A good lawyer is not impressed by opinions in the courtroom. She establishes facts and prevents an opposing lawyer from asking opinions of her witness. We need to use these types of techniques in fishbone analysis.
Facilitators need to prove the relationship between the potential causes. They also need to resist accepting lack of funds, lack of communication or lack of training as items on the bones because many problems can be blamed on those causes, and they are not usually actionable. Facilitators must push back on team resistance to get data.
Unbalanced. Ideas on the fishbone never have equal importance and must be validated with data. When the count and severity of occurrence are applied to the ideas, we can isolate the important ones.
One team I worked with insisted “lack of staffing” was the root cause of customer complaints. The CFO was not impressed. So, I had the team evaluate the complaint types and weight the impact of occurrences based on known customer feedback and frequency. The most significant root cause turned out to be a policy that caused callers to flow through particular calling trees in the automated voice response system. A simple programming change alleviated this problem and relegated it to number seven on the priority list.
Facilitators must insist the team validate the ideas on the fishbone and demonstrate they do not have equal importance.
Avoiding these five pitfalls will restore our ability to solve deep seated issues.
MARTIN HEDLEY is a process based and change management consultant with Sharp Resources Inc. in Eagle, ID. He earned a bachelor’s degree in geometrics from the University of Newcastle-Upon-Tyne in England. Hedley is a member of ASQ, a Six Sigma Master Black Belt and a certified quality auditor.