WHY Tree No-No

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?

Zero-Based Root Cause Analysis (2)

It is probably true that you will never learn anything that someone else didn't already know. If this is true, then shouldn't we spend a lot of time learning from other people? Let's explore this a bit....

Before I was born, people knew how to walk, talk, eat, etc. And then, I was born.

I know how I learned to walk, to talk, to speak in public, to write, to breath, to comb my hair (what’s left of it). I had to fail, and fail, and fail, and fail. So did Edison. Sometimes, failing leads people to understand that “hey, I ought to learn more from other people.” Other times, failing leads people to “hey, those other people were dead wrong!”

Failure is the only phenomena of life capable of changing the way we see things, if we’re willing to put aside “the shell.” We never know where “failure” will lead us.

Maybe the real issue here is within the word “learn.” Learn is too vague a word, at least for me.

One of the synonyms for “learn” is “discover.” Something special happens at the moment of discovery. It’s the “epiphany” that I seek, and that I’m interested in helping others seek. Eureka! Shock! Mind-blowing, life changing, instantaneous paradigm change! It’s really hard to get to that point when someone else does the thinking for you. In fact, you can’t. When someone else does the thinking for us, we turn into lemmings.

Nevertheless, I suppose it’s true that I've not learned anything that someone else didn’t already know. But the most important things in life are the things that change me (us). And these kinds of things can only be learned by personal discovery.

I am not saying that I don’t think we should learn from one another. Of course we should! If we don’t we’re doomed.

And am I not saying that codes, standards, checklists, and all of that are bad. I think they’re essential. Without them, we have "Haiti."

When any of us learns something, we should all do our best to apply those learning’s across the board – before an incident occurs.

Before.

Those learning’s are our past solutions to past problems that we should have already have applied to our lives.

When we have a current problem, it’s time to put our past solutions to the side (until we know how and why the event occurred). I’ve done this all my professional life, and it’s led me (and others) to places I’ve (we’ve) never imagined.

All the ancient books (and religions), all the past philosophies, all our current knowledge, all that’s in our text books and on the internet will not replace the need for me (each of us) to learn certain things myself (ourselves)– even if someone else already knew – as a result of something that has gone wrong.

Before the problem, learn from others. After the problem, forget what others learned and simply wonder “why it happened to me (us), especially if others knew better?” In the end, it’s a very individual, lonely, but breathtakingly ecstatic existence – if we’re willing to break out of the shell.

Zero-Based Root Cause Analysis (1)

I recently viewed a slide show about Foreign Material Management, i.e., making sure the wrong stuff doesn't get into our systems. It was based on learning's from past investigations, and was an excellent slide show.

We have learned an enormous amount about why things go wrong through investigating past incidents. Obviously, it is imperative to share what we've learned so that others do not experience needless pain.

As I was viewing the slide show, however, I remember thinking that there’s a difference between what we've learned, and how we've learned it -- a huge, monumental, life-shattering difference! Unfortunately, it seems that many people confuse the two.

Let's suppose, for example, that you have never eaten with with chopsticks. If you went to an oriental restaurant and were unable to use them on the first try, you would probably try another time, and then another until you were finally able to eat. In this simple example, you learned how to use chopsticks by trial and error.

Now let's suppose that you wanted to take your child to the same oriental restaurant, and you wanted him to avoid the frustration you had. You would most probably teach your child how to use chopsticks, based on what you've already learned. I think this would be good, responsible parenting.

We learn from our failues, and then we teach other people how to avoid that same failure. This is life. This is "being responsible." This is good.

But let's suppose your child couldn't use the chopsticks even after you taught him! The tendency, in this simple example, would be for you to compare what he was doing with what you told him to do. "Is he holding the chopsticks the way I suggested?"

We tend to investigate things that go wrong by comparing what went wrong with our predetermined understanding of "correctness." What if our predetermined understanding or correctness is invalid?

In the chopstick example, what if your adult hands were able to hold the chopsticks in a way that was impossible or ineffecitve for your child's smaller hands? Wouldn't it be better to simply look at the evidence in front of you, in this case your child trying to eat with chopsticks, with an open mind about what's going wrong. Even more, might it not even be better to let your child struggle a bit on his own? After all, he might invent a better way?

When we use our past learning’s as a basis of “goodness” when investigating an incident, I believe we’ve biased ourselves in the utmost manner. After all, what is bias? Isn’t it a “preconceived notion?” Isn’t bias the number 1 (or close to it) obstacle to learning something NEW? There’s a difference between how to learn, and how to apply those learning’s. We mix them up all the time.

Is it possible to do a root cause analysis without any reference to our past learning's?

I say YES! Not only do I say YES, I also say this is the ONLY way to grow -- to see what we've never seen, and go where we've never gone.

Beware of those who are asking you to compare what went wrong with a predetermined understanding of correctness.

More later..........

The Best Go Bag (or Go Box) I've ever seen.

In November, 2009 I had the good fortune to have been invited to Billings, Montana to present Failsafe's 4-day Latent Cause Experience. I was invited by Tim Mullowney, a person I met in Billings several years ago at another seminar I presented to his company. Tim and I "clicked" almost immediately, as we share many core values and beliefs. We don't talk incredibly often, but good friends don't need to. We just pick up where we left off.

When I received a call from him requesting the November seminar, I was delighted.

On the second day of the seminar, Tim came to the class with his Go Box (He knew that "Day 2" was when I started to talk about evidence). It was a relatively large, hard-cased yellow suitcase. He said it was full of evidence-gathering necessities that he learned he needed when he went through the class the first time. I assumed it was so large because of the cameras that might have been inside, but I was wrong.

I didn't really have time to look at its contents during the class, so I asked Tim if he'd like to do a "show and tell," for the benefit of all the attendees.

The resulting presentation blew me away.

I have never seen a better Go Bag (Box) -- nothing close to this one. When Tim Mullowney does something, he does it right! I'd even say his Go Box rivals most CSI's, and yes -- I think it even rivals the NTSB.

Please follow the link to see many photographs of the best Bo Bag (Box) I've ever seen, including information on how you can assemble your own.

http://failsafe-network.com/RCA-GoPage/Go-Box/root-cause-analysis-go-box.htm

Thank you Tim!

The NTSB's Go Concept

In the early 1980's, while working for Allied Chemical Corporation in Hopewell, Virginia, I had extraordinary freedom to quench my thirst for "why things go wrong."

Since I was living about 2 hours from Washington D.C. at the time, I was able to travel there often. I visited museums, the National Archives, as well as NASA and National Transportation Safety Board (NTSB) headquarters.

In my reading of formal investigative reports, I became especially interested in the NTSB, the way they are structured, the way they investigate incidents, and the obstacles they encounter. I remember calling them up one day, asking if I could interview one of their leaders, simply to learn about how they did things. I didn't know if they'd accept my request, but they did.

When I arrived, I was met by Thomas DeW. Styles, the Director of Accident Investigation for the National Transportation Safety Board. I had no idea they'd let me talk to the Director. I spent hours with this man, who allowed me to tape our conversation. I left with 3 volumes of books describing the workings of the NTSB, as well as about 50 pages of eventually transcribed notes, and a personal invitation to come to an upcoming open proceeding in New York City about a recent railroad incident.

One of the things I learned from Tom Styles was the emphasis they place on the "Go Concept."

The following text has been copied from http://www.ntsb.gov/abt_ntsb/invest.htm. I am copying it here because sometimes these links become inactive or out of date.

From the above NTSB link:

The NTSB "Go Team"

At the core of NTSB investigations is the "Go Team." The purpose of the Safety Board Go Team is simple and effective: Begin the investigation of a major accident at the accident scene, as quickly as possible.....

During their time on the "duty" rotation, members must be reachable 24 hours a day by telephone at the office or at home, or by pager. Most Go Team members ..... have tools of their trade handy -- carefully selected wrenches, screwdrivers and devices peculiar to their specialty. All carry flashlights, tape recorders, cameras, and lots of extra tape and film.

The Go Concept has been part of Failsafe's training ever since.

Failsafe acknowledges three major forms of evidence. We call them "The 3 P's:

People know things, the Physical manifestation tells us things, and history (Paper) can tell us things. (People, Physical, and Paper).

From the NTSB, Failsafe also acknowledges that all 3 forms of evidence is evaporative. It is very similar to dry ice, which starts to evaporate immediately on exposure to abient conditions.

All facilities that are sincere about learning from things that go wrong ought to have Go Teams, with Go Bags. I consider the presence of these "teams" and "bags" a litmus test for the sincerity of these kind of efforts.

In a future post, I will share the BEST Go-Box I have ever seen. It was assembled by an investigator operating out of a refinery.

The PRESENT Value of the WHY Tree

I've written about WHY Trees twice in the recent past, first to describe their origins and secondly to describe a gross problem in the way they are being used. I'd like to end, at least for the time being, by sharing my thoughts about the present value of WHY Trees.

Actually, these BLOG posts about the WHY Tree are in response to growing criticism that I have gone too far in my dismissal of their value. Some people (mainly, the engineers in charge of corporate investigative efforts) are so annoyed at my position that they are reaching out to other methods that focus on the construction logic-type diagrams. It seems as if some people would rather construct WHY Trees than go through the life-changing DISCOVERY process that is only possible when one sits down and immerses oneself in evidence.

Have you ever seen a CSI show where the investigators constructed WHY Trees? Nevertheless, perhaps I have gone too far in my downplaying of the WHY Tree -- thus the purpose of these posts. Allow me to emphatically state the following:

Yes, I do think the WHY Tree has value (read my other posts and you'll see that I LOVE WHY Trees).

First, the WHY Tree is an excellent way to graphically communicate your conclusions so that others can quickly understand, as long as they follow the "15-year-old-rule." (They must be constructed so that any average person can understand, without any interpretation).

Secondly, the WHY Tree is an excellent way for an investigator to be assured that cause and effect relationships have been established. It is very possible to investigate an incident and think that your logic is correct, only to see that the "dots do not connect" after all. This error can be minimized by constructing WHY Trees.

But please note when the WHY Trees in the above scenarios are are constructed. They are constructed after the investigator already knows why the incident occurred. WHY Trees are not an answer-generating machine. The only answers you will ever get (even in life) will come from the evidence that life presents to you.

Are WHY Trees of any use during an investigation? Sure!

There are two scenarios where WHY Trees can be used to help an investigator pursue the right paths, before the causes are known. But these two scenarios are wrought with dangers because of the biases that can emerge when you allow yourself to drift away from evidence.

First, when investigating a technically-complex sporadic failure (low frequency, high impact) with large amounts of evidence, it is sometimes useful to use the WHY Tree to show the varying possibilities of what might have contributed to the incident. Note the word "might." If you are not sure which of several possibilities might have contributed to an incident, a WHY Tree can be used to show all the possibilities.

For example, if a fire occurred near a pump and evidence suggests 3 possible ignition sources, the WHY Tree could list these causes on the row underneath "ignition source existed."

WHY Trees are also great when working with chronic failures (high frequency, low impact), because chronic failures have multiple failure modes -- each of them "true" a given percentage of time.

For example, let's say you have a pump that fails once per day (I am being extreme to make my point). If you did an LCA on each particular incident (one each day), you'd find that the pump failed (for example) due to excessive vibration 25% of the time, leaks 55% of the time, and shaft failures 20% of the time. As you pursue the top block of the WHY Tree, row after row, each row can be handed the same way (with percentages attached to them). If the pump failure has a monetary value associated with it, the percentages end-up indicating the "value" of addressing each block of the WHY Tree. I love using WHY Tree when working with chronic failures.

WHY Trees can be very useful, if not abused.

Remember, first gather evidence. Write a paragraph explaining what you know about the Physical Causes. Then define the Human Causes, bullet-style. Finally, define the Organizational and Personal Latent Causes. I strongly suggest defining the causes, in writing, before you ever think about drawing a WHY Tree. If you start drawing your WHY Tree before you understand the causes, you'll end up spending a whole lot of time drawing trees as opposed to immersing yourself in evidence.

Remember, we're trying to change people -- because when people change, everything else will change.

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.

Web-Based Latent Cause Analysis

Web-based Latent Cause Analysis?

It is admittedly gratifying to experience the energy and enthusiasm that accompanies almost all 4-day Latent Cause Experience Classes. It is even more satisfying when I get letters from some of you to tell me of some personal changes that you've made because of the key question:

What is it about the way I am that contributes to my problems?

It'd be easy to "pat myself on the back and say GOOD JOB, Bob."

But that's not how life works, is it?

I don't know about you, but every time I think I'm on top of things, the rug gets pulled out from under me. Sometimes, it comes from the mouth of a client, other times a pitiful seminar performance.

This time, it's been different.

Over the past year, I've had the chance to review more than my normal share of Latent Cause Analysis Reports. I usually see many Mini-LCA's (you send them in order to receive your attendee certificates). But 2009 was different. I've reviewed dozens of your reports, and

The official investigative reports that most of you are writing are very inconsistent (depth, terminology, and format), even within the same site.

Unfortunately, your investigative efforts will be judged based on the reports that you write.

Please understand, that the effectiveness of Failsafe's training will also be judged based on these reports (GULP)!

Although a Latent Cause Analysis can be ultimately successful without ever writing a report, and although an LCA can be an absolute failure and still produce a stellar report, it is a fact that your efforts will be judged almost solely by the reports you write.

The current state of the reports that many (not all) of you are writing is not your fault. It's mine.

I have not placed enough attention to this in the products and services offered by Failsafe, but this is going to change. More than anything last year, I learned the value of consistency; consistency in appearance, quality, terminology, and depth.

For your sake, as well as mine, Failsafe and some of its affiliates are working on a web-based template to guide you through a Latent Cause Analysis. It will require the user to supply specific kinds of information, in a specific order, to help you do a proper ROOTS-based investigation and to generate consistent reports.

Stay tuned................................

The BIRTH of the WHY Tree

Where did the WHY Tree originate?

I become aware of Fault Trees in the 1970's. This was almost inevitable, given that I was a chemical plant reliability engineer at the time, and was charged with researching the "state of the art" respecting reliability principals.

I discovered that Fault Trees were initially developed in the mid-1960's by Bell Labs to help evaluate the reliability of the Minuteman Intercontinental Ballistic Missile (ICBM) Launch Control System.

It's important to note that Fault Tree Analysis was originally designed to help evaluate the theoretical reliability of a system in its design-state, so that overall reliability could be improved while the project was still "on paper" (as in the ICBM system).

As an engineer, with the typical engineering way of seeing and thinking, I quickly grasped the format, symbols, and even mathematical intent of Fault Trees. But as my chemical plant focus shifted from evaluating overall system reliability to improving component reliability, I began applying the structure of the Fault Tree to help explain the causes of actual component failures in our operating chemical plants.

I remember doing "failure analyses" in many different chemical plants, explaining my conclusions with "Fault Trees."

After going into business myself for myself in 1985, I began to teach other people what I had learned about doing "Root Cause Analysis." At the time, I taught people to use "Fault Trees" as the backbone and driving force of a Root Cause Analysis.

Then it happened.

In the late 1980's, while teaching a Root Cause Analysis class in Fort McMurry, Alberta, Canada (in the Interpretive Centre across from the Sawridge Hotel), a chain-reaction of students rose their hands while I was teaching people how to use Fault Trees, saying:

• Student #1: What you are teaching is not a Fault Tree. Fault Trees are specific devises used in the design phase of a project to determine overall system reliability. (Note: the student was right -- I was wrong.)
• Nelms: Well, the structure is the same, isn't it?
• Student #2: I don't even like the name! Why would you use the name "fault" in a "root cause analysis?" People will think you're trying to find FAULT!
• Nelms: Well, uh, ummmm, (backtrack, sweat beads, and then a flash of BRILLIANCE). I said "well, what do you think I should do?"
• Student #3: Keep the technique -- it's a great technique -- but don't call it a FAULT tree. First of all, it isn't, and secondly, it's terrible word.
• Nelms: What should I call it.
• Student #4: (a nameless woman): If I were you, I'd call it a WHY Tree.

The WHY Tree is a trademarked name for a specific way of both driving and/or mapping the course of a Root Cause (or Latent Cause) Analysis.

More about WHY Trees is coming!