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!
Friday, February 19, 2010
Tuesday, February 16, 2010
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.
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.
Thursday, February 04, 2010
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.
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.
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.
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.
Monday, February 01, 2010
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:
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
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................................
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:
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!
Subscribe to:
Posts (Atom)
