Tuesday, February 02, 2010

The Problem with WHY Trees

In a past post, I tried to explain a little about the origins of the Why Tree. As I said, they are a spin-off-of Fault Tree Analysis. Fault Trees, however, are classically constructed in the design phase of a project to help determine the mathematical probability of specific, catastrophic events.

Why Trees were originally developed by myself to help an investigator navigate through an investigation. I developed their use in the 1970's, 80's when I was Principal Investigator in a chemical company, and then in the early 90's as a Principal Investigator for hire (through Failsafe).

WHY Trees became my way of keeping control of the investigation. Even more, it seemed that every investigation I led yielded different WHY Tree methods. I became enamoured by them. I've written a little about these methods in "What You Can Learn from Things that Go Wrong,.....", and have listed a few of them below:

The 5,3, 1 Technique
Either / Or
Comprehensive / All Inclusive Test

Aside from the methods themselves, I discovered that WHY Trees were a great way to describe the time-line (the bottom elements occur first, and the top occur last). I also discovered the uniqueness in using WHY Trees for investigating chronic failures, and even found a way to tie monetary values to each block on the "Chronic WHY Tree."

In short, the WHY Tree became associated with "Bob Nelms," and his training. Looking back, however, this was all a monumental mistake.

I don't know why I hadn't seen it before, but suddenly I became aware of what was happening. When an investigatable incident occurred, many of my clients were quickly gathering their most experienced people (pertaining to an incident) into a room to construct WHY Trees.

Picture it. Ten to twenty experts in a room, debating "where the blocks should be placed," using their expertise to "figure out the most probable causes."

AND THEN they'd go out and gather evidence in support of their hypotheses.

When I found out how people were abusing these marvelous WHY Trees, I wanted to puke. I never suggested using WHY Tree in this manner.

The instruction has always been "gather evidence first, and then develop the WHY Trees."

There are no short cuts to discovery! There is no computer program, or software to purchase to process yield the answers we seek. People have to roll up their sleeves and get out there in the dirt. They also have to actually talk to other people. These are the things that most engineers would rather not do.

Concurrent to my disgust, I started teaching people how to do Mini-LCA's. Mini-LCA's follow almost all the steps of the full-scale LCA's, but don't involve as many people. When I was given only 4 hours to teach people how to do a Mini-LCA, I had to consider what to cut out of the training.

I decided to see what happened if I cut out the WHY Tree.

BINGO, it worked great. Not only that, but people who were familiar with the tedium of drawing WHY Trees were elated that I had dropped them from the 4 hour training.

Then I started to wonder. "I wonder if all those past investigations I led could have been done without WHY Trees?" One investigation after another, I queried my mind and discovered that:

The answers to our questions came from immersing ourselves in the evidence -- not by focusing on the WHY Tree!

I changed all of Failsafe's training to reflect this discovery. The engineers do not like the change. Engineers LOVE WHY Trees (I am an engineer myself, and I LOVE WHY Trees). But I discovered that WHY Trees are a diversion. They make us feel as if we're doing something, when we're actually biasing ourselves -- making it much more difficult to be SHOCKED with the truth.

Yes, WHY Trees have their place -- and yes they can be useful. But in the vast majority of cases, all we need to do is slow down and look at the evidence, because:

Everything we need to know about our existence is staring us right in the face, if we'd take time to look.

1 comment:

John L said...

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 just what was said in this post: 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).

So far, for smaller incidents, Midis and Minis, I have yet to have a reason to employ a WHY tree. Mainly because I see it as a cumbersome tool that I better be proficient at using or the exercise will be drawn out and possibly confusing to the stakeholders. And I have not had much trouble arriving at the causes without it. Given the scale of this incident I don't think a WHY tree would have been needed to explain what happened. But I'm not against using the WHY tree to help explain a more complicated incident or chronic failure if the facilitator deems it necessary. Generally, I don't think it is a necessary step for completing an LCA. The WHY tree should be a tool reserved for the facilitator. With the tree being developed by the stakeholders under the guidance of the facilitator.

Beware of stakeholders latching onto their own cause map, fault tree or even the WHY tree and implanting it in the LCA. It will usually be biased towards their understanding of the incident and could affect the realization of their contribution to the problem…or worse, direct blame at someone else.