Used in root-cause analysis, the cause-and-effect diagram is often aimed at technical issues. But apply it to change management and you can find out a host of reasons as to why people haven't adopted a process change. Columnist Jeff Cole explains how.
|
In 1943, University of Tokyo professor Kaoru Ishikawa picked up a piece of chalk, went to the blackboard, drew a diagram and promptly named it after himself. The Ishikawa Diagram - commonly referred to as a Cause/Effect Diagram or Fishbone Diagram - has been a staple of quality management tools ever since it was first used at the Kawasaki Steel Works.
|
Fishing for reasons a process change hasn't been adopted? |
What does this have to do with behavioral change? While used in root-cause analysis, the C/.E Diagram is often aimed at technical issues.
What’s to stop us from using this on the change management side? If you’ve rolled out a brand new process and nobody is using it like they should - that’s a problem. You can get to the root cause of that behavioral problem with this tool just like you would for a valve leak or production problem. It’s just a new use for a classic tool you may already be familiar with.
Authors’ advice varies on not only how to build a Fishbone Diagram, but also what the categories are. Many generally agree on six basic categories, which we’ll call Machines, Materials, Methods, Mother Nature, Measurement Systems, and People. The neat thing about a C/E Diagram is if anything ever goes wrong in a process, it’s often something in one or more of these six categories. This tool becomes a way to brainstorm and visually organize all the causes and sub-causes of the problem.
Simply place your problem in the "head of the fish" on the right side of the page (this is the "effect"). Draw a main spine leading into it and six arrows coming into that – one for each of the six topics above. Label the arrows with the six categories. This now helps to focus your team’s brainstorming around those key topics. As people generate ideas (causes), place them on the diagram. Drill down into those causes for sub-causes. When a process fails, it’s often several small things that occur jointly to generate a failure.
For example: If the problem is that nobody is using your new process, let’s see how the categories may help:
Machines: Is it possible they don’t have the proper software? Security access issues? Don’t have the proper equipment to start with? Proper equipment but it is not functioning? Any safety issues?
Materials: Did the participants not receive instructions? Are the instructions wrong? Are the inputs to the process late? Defective inputs or supplies?
Methods: Are people following some other method (like the old way)? Does the current method in any way prevent someone from following the process? Does the current method conflict with any safety, regulatory, or other requirements? Does the current method cause collateral damage to another process?
Mother Nature: If this is an outdoor process, does the weather in any way impact if the process is followed? If the process is temperature, humidity, light or environmentally sensitive are there any conditions preventing the process from being followed?
Measurement Systems: How are you measuring process engagement? Is it possible that the measurement system is "off" (and people really are using the process)? Are the measures people are evaluated by negatively impacted by following this new process?
People: Are the people not able to follow the process for any reason? Are the people able but not willing to follow the process?
You can quickly see that these potential causes above can be drilled down to sub-causes and sub-sub-causes. Eventually you have a nice listing that may likely encompass the true root cause.
If you are thinking this tool goes well with the "Five Why’s" technique, you are right! If you are thinking you could also accomplish the same analysis with a causal tree – right again! If you think the questions generated above would work well with an FMEA-type analysis, you win the prize! Many of the traditional quality tools we use for solving technical process problems can be applied to helping drive process change if we simply take a slightly different perspective!
As we wish a happy 70th birthday to the Ishikawa diagram in all its low-tech splendor, try dusting off this classic tool and applying it to your next change project. Happy change!