I recently received an email that I simply must share. It's about the value of WHY Trees (or Cause Maps, or any other form of diagramming). Yes, these tools have value. But don't get pulled into the muck! BEWARE! The following is the email I received.
==========
I recently helped facilitate a Latent Cause Analysis where one of the stakeholders (an engineer!) had to do a cause map in order to communicate what happened and what caused the incident.
The facilitators obliged, thinking it couldn't be much different than a WHY tree, and I learned an important lesson.
When the engineer took it upon herself to do the cause map, she was immersed in it for 2 days (formatting, typing, coloring blocks, printing copies etc) instead of being immersed in the evidence with the rest of the stakeholders.
And what was worse, the other stakeholders were dragged through this map in a 4-hour presentation of causes and possibilities that reached into areas that weren’t supported by evidence.
The end result was a confusing document created by one person’s interpretation of the evidence.
Once the cause map exercise was complete, luckily we were able to save the stakeholder meeting and proceed with the LCA methodology. However, the waters were no doubt muddied by the cause map. But patience and persistence prevailed and we got the investigation back on track.
EVERYONE was discussing the evidence at hand and determined Physical, Human and Latent Causes while not even referencing the cause map.
This experience taught me something important: The answers to our questions come from immersing ourselves in evidence and pulling the causes from it, not focusing on the WHY tree (or cause map in this case).
==============
I know how fun and even constructive it can feel to spend time drawing cause maps and WHY Trees. Believe me when I say I am enamored by them myself. But I also know, through painful experience, how devious they can be to revealing the truth of the causes of an event.
Comments?
Tuesday, August 03, 2010
Subscribe to:
Post Comments (Atom)
3 comments:
Excellent observation with regard to why trees (or cause diagrams, whatever). I have found that keeping the diagrams as simple as possible, and including logic blocks and paths that are supported by the evidence are best. Minimize blocks that are based only on conjecture - or clearly cross them off to illustrate how they were ruled out by the evidence, etc. These can be helpful toward explaining the event to stakeholders or just about anyone else who can benefit from the insight. Making large and complex diagrams is usually only useful to the person (or team) that took the time to put it together.
One early experience with incident investigations involved a facility power outage where the evidence we had available could not explain what had happened. We consulted with electrical experts and others who could not conclude why the lights went black. In this case we put together an "exploratory" why tree to postulate on just about anything that could have gone wrong to put the lights out. We took small steps, and only went down to physical causes - but still the diagram was very large and took a whole day for a team to create. Then we used this to look for additional evidence to support or rule out the various blocks we had postulated. This was helpful toward a breakthrough, since the cause was a minor design flaw in the protective-relay trip circuit wiring that had existed for over 50 years. Recent changes in the power usage at the plant cause this flaw from being a benign hidden issue to a cause of a power outage. Nobody had suspected this type of flaw could exist, so no evidence was gathered - even though we had brought in industry power specialists and experts to analyze our power system.
The down side of this for me personally is that for a while I would start an investigation by trying to put together an exhaustive "exploratory" why tree to help focus on what evidence to gather. THIS IS THE WRONG APPROACH! First it consumes the investigation team's time at the start of an investigation when they should be spending every moment gathering evidence. Second, the tree that is developed is already biased by the thoughts and ideas of who is in the room, such that the whole investigation gets biased by speculation right up front.
After trying this for a couple of investigations I recognized the flaws, and have since then settled on the "evidence first" approach advocated in this post. If the evidence leads to understanding and conclusions then a simplified why tree is useful as an explanation and communication tool. In those rare investigations where the evidence does not lead to a conclusion then an "exploratory" tree (probably similar to what was put together by your engineer) can help with additional evidence gathering and areas for further investigation.
Excellent observation with regard to why trees (or cause diagrams, whatever). I have found that keeping the diagrams as simple as possible, and including logic blocks and paths that are supported by the evidence are best. Minimize blocks that are based only on conjecture - or clearly cross them off to illustrate how they were ruled out by the evidence, etc. These can be helpful toward explaining the event to stakeholders or just about anyone else who can benefit from the insight. Making large and complex diagrams is usually only useful to the person (or team) that took the time to put it together.
One early experience with incident investigations involved a facility power outage where the evidence we had available could not explain what had happened. We consulted with electrical experts and others who could not conclude why the lights went black. In this case we put together an "exploratory" why tree to postulate on just about anything that could have gone wrong to put the lights out. We took small steps, and only went down to physical causes - but still the diagram was very large and took a whole day for a team to create. Then we used this to look for additional evidence to support or rule out the various blocks we had postulated. This was helpful toward a breakthrough, since the cause was a minor design flaw in the protective-relay trip circuit wiring that had existed for over 50 years. Recent changes in the power usage at the plant cause this flaw from being a benign hidden issue to a cause of a power outage. Nobody had suspected this type of flaw could exist, so no evidence was gathered - even though we had brought in industry power specialists and experts to analyze our power system.
The down side of this for me personally is that for a while I would start an investigation by trying to put together an exhaustive "exploratory" why tree to help focus on what evidence to gather. THIS IS THE WRONG APPROACH! First it consumes the investigation team's time at the start of an investigation when they should be spending every moment gathering evidence. Second, the tree that is developed is already biased by the thoughts and ideas of who is in the room, such that the whole investigation gets biased by speculation right up front.
After trying this for a couple of investigations I recognized the flaws, and have since then settled on the "evidence first" approach advocated in this post. If the evidence leads to understanding and conclusions then a simplified why tree is useful as an explanation and communication tool. In those rare investigations where the evidence does not lead to a conclusion then an "exploratory" tree (probably similar to what was put together by your engineer) can help with additional evidence gathering and areas for further investigation.
I have come across similar issues in the past. It sounds like a Problem Management process would be useful to do the administration. I have worked in several Problem Management teams and have found they are best placed to do this kind of work. Allow the technicians to investigate the root cause and leave the Problem Managers to assimilate that information and present it to the business in their desired medium.
The Problem Manager
Post a Comment