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!
Thursday, January 28, 2010
What is a Mother-Source?
A long-term part of Failsafe's approach to Latent or Root Cause Analysis (at least since 1994) has been my insistence on the need for a Mother-Source the help drive the process.
Although not a very "manly" phrase, those who understand its intent and agree with its purpose insist on using it. In this respect, the phrase is almost like a litmus test to see who is qualified to drive the process that Failsafe has been promoting. If you understand, and buy into the overall intent of Latent Cause Analysis, you will appreciate being part of a Mother-Source.
For those who have not been exposed to Failsafe's approaches, the Mother-Source is a nurturing group of people (thus the phrase Mother-Source) bound together by a passion for ingraining a "latent cause mentality" within their workforce.
A "latent cause mentality" is one in which everyone, everywhere (all levels) has a keen desire to see themselves as part of their problems (whatever the problem), rather than blaming things on other people and things.
The Mother-Source ought to be organizational immune system's response to the BLAME VIRUS.
Although not a very "manly" phrase, those who understand its intent and agree with its purpose insist on using it. In this respect, the phrase is almost like a litmus test to see who is qualified to drive the process that Failsafe has been promoting. If you understand, and buy into the overall intent of Latent Cause Analysis, you will appreciate being part of a Mother-Source.
For those who have not been exposed to Failsafe's approaches, the Mother-Source is a nurturing group of people (thus the phrase Mother-Source) bound together by a passion for ingraining a "latent cause mentality" within their workforce.
A "latent cause mentality" is one in which everyone, everywhere (all levels) has a keen desire to see themselves as part of their problems (whatever the problem), rather than blaming things on other people and things.
The Mother-Source ought to be organizational immune system's response to the BLAME VIRUS.
Wednesday, January 27, 2010
Open Mother-Source Forum
In December, 2009 I announced my desire to facilitate an Open-Mother-Source (OMS).
Several of you have responded favorably to this idea, so I will take it to the next step. I do have a initial "vision" for this, but I will as open an possible to go wherever the membership takes us.
As I presently see it, the OMS is to be a periodic web-based meeting for people who are interested in promoting latent cause analysis at their place of business. Our primary objective will be to "promote and advance the cause," where we will define "the cause" together.
A secondary objective will be to demonstrate the intent and effectiveness of the Mother-Source concept, as promoted by Failsafe. As most of you know, the Mother-Source provides the energy for inculcating a latent cause mentality within the organization, is the keeper of the process, as well as the organization's immune-system response to the BLAME VIRUS.
This will not be a series of Failsafe training sessions, nor an attempt to sell Failsafe services. It is a genuine attempt to "practice what we preach" by working together with a larger group of people to address key obstacles to growth in this field.
This will be a free service, provided by Failsafe (at least initially).
This new, OMS forum will be open to anyone who meets the following criteria:
avoid re-inventing the wheel by tapping into what others have done.
out of the box (company box) place to ask for help and give guidance
potential source of help and energy to address existing obstacles
witness the intent and power of a "mother-source" in action
become part of something bigger, because none of us is as smart as all of us
place to vent frustrations to Failsafe -- and for Failsafe to HEAR them -- for eventual improvement of the ROOTS process or resolution of obstacles
published minutes
scheduling, promotion, moderation of meeting by Failsafe
Several of you have responded favorably to this idea, so I will take it to the next step. I do have a initial "vision" for this, but I will as open an possible to go wherever the membership takes us.
As I presently see it, the OMS is to be a periodic web-based meeting for people who are interested in promoting latent cause analysis at their place of business. Our primary objective will be to "promote and advance the cause," where we will define "the cause" together.
A secondary objective will be to demonstrate the intent and effectiveness of the Mother-Source concept, as promoted by Failsafe. As most of you know, the Mother-Source provides the energy for inculcating a latent cause mentality within the organization, is the keeper of the process, as well as the organization's immune-system response to the BLAME VIRUS.
This will not be a series of Failsafe training sessions, nor an attempt to sell Failsafe services. It is a genuine attempt to "practice what we preach" by working together with a larger group of people to address key obstacles to growth in this field.
This will be a free service, provided by Failsafe (at least initially).
This new, OMS forum will be open to anyone who meets the following criteria:
- must be either a corporate employee or Licensed Failsafe Affiliate
- must not be a competing consultant
- must have a passion for helping one another (ourselves included) see themselves as part of our problems, rather than blaming things on other things or people
- must be willing to work with other Open-Mother-Source-Central members to advance the cause
- must be willing to further define the cause
- must strive to attend all web-based meetings
If you meet the above criteria, and want to be part of something bigger, please join us.
DATE of 1st Meeting: Thursday, March 18, 2010.
TIME: 1:00 PM - 3:00 PM Eastern
PLACE: Your computer, via GoToMeeting (scheduled by Failsafe
TO REGISTER: Click to join the Failsafe-OMC YahooGroup. You will be asked some qualifying questions (to avoid the SPAMMERS). As soon as I see that are admitted to the group, I will send informattion about how to gain access to our web-based meetings. Note: Your membership in this group is totally within your control (you may leave whenever you wish).
MORE INFORMATION: on Failsafe's web site
Thursday, January 21, 2010
FORCED to learn from things that go wrong??
Sometimes I wonder about the intentions of companies who are doing "root cause analyses." I wonder why they are doing them. I remember that in the early days (1970's), suggesting that people do a root cause analysis was like suggesting that they get a root canal. Few, if anyone in the industries that I was serving (mainly chemicals) seemed very interested.
Then along came OSHA 1910, and all the Process Safety Management (PSM) requirements. To be honest, I didn't even know that these requirements were being developed until 1992, when concurrent to their introduction my business started booming. I have been a fortune recipient of these requirements ever since.
Or have I?
Sometimes I wish I would not have chosen the professional path I am on (root cause analysis), because it highlights parts of the human condition that are hard to accept, and even harder to deal with. Sometimes it's easier to be ignornant than to be comfronted with a difficult truism.
For example, many of us who have dedicated our professional lives to the advancement of "root cause analysis" have learned that the catastrophic events that precipitated the above-mentioned PSM requirements were caused by a cueing-up of unresolved small problems. In other words,
Big problems are caused by unresolved small problems.
At one time, I wondered if those of us in the "root cause analysis business" were the only ones that knew this. Or, I wondered, does everyone inherently know this but would rather not acknowledge it?
The answer to this question came rather bluntly to me about 2 years ago in the mid-west, where I was training a group of maintenance people in the principals of root cause analysis (or latent cause analysis, per Failsafe). When I stated the above eureka, i.e., that big problems are caused by unresolved small problems, I felt like I had unleashed a pack of rabid wolves! The maintenance people told me, rather crudely, that:
Why do our companies sit back and wait for big things to go wrong, and then do their root cause analyses -- even when the results of these large investigations seem to always point to the same truism: big problems are caused by unresolved small problems.
Why do companies spend a lot of money to train their people in an investigative method so that they can wait for a big problem to occur (in order to investigate it)?
Why don't these same companies require their trained people to use their training on the small problems occuring in their work lives? Wouldn't it be better to learn from our small problems so that we can avoid the big ones?
Why do so few people seem interested in learning from things that go wrong?
Do we have to wait for OSHA (or someone else) to FORCE us to do what we ought to have been doing all along?
More importantly:
Then along came OSHA 1910, and all the Process Safety Management (PSM) requirements. To be honest, I didn't even know that these requirements were being developed until 1992, when concurrent to their introduction my business started booming. I have been a fortune recipient of these requirements ever since.
Or have I?
Sometimes I wish I would not have chosen the professional path I am on (root cause analysis), because it highlights parts of the human condition that are hard to accept, and even harder to deal with. Sometimes it's easier to be ignornant than to be comfronted with a difficult truism.
For example, many of us who have dedicated our professional lives to the advancement of "root cause analysis" have learned that the catastrophic events that precipitated the above-mentioned PSM requirements were caused by a cueing-up of unresolved small problems. In other words,
Big problems are caused by unresolved small problems.
At one time, I wondered if those of us in the "root cause analysis business" were the only ones that knew this. Or, I wondered, does everyone inherently know this but would rather not acknowledge it?
The answer to this question came rather bluntly to me about 2 years ago in the mid-west, where I was training a group of maintenance people in the principals of root cause analysis (or latent cause analysis, per Failsafe). When I stated the above eureka, i.e., that big problems are caused by unresolved small problems, I felt like I had unleashed a pack of rabid wolves! The maintenance people told me, rather crudely, that:
"You've been hired to come in here and tell us THAT? Is this some sort of revelation to you? Maybe you should sit down and let us teach you a thing or two. We've been trying to point this out for years and years! How dare you come and preach to us!
Why do our companies sit back and wait for big things to go wrong, and then do their root cause analyses -- even when the results of these large investigations seem to always point to the same truism: big problems are caused by unresolved small problems.
Why do companies spend a lot of money to train their people in an investigative method so that they can wait for a big problem to occur (in order to investigate it)?
Why don't these same companies require their trained people to use their training on the small problems occuring in their work lives? Wouldn't it be better to learn from our small problems so that we can avoid the big ones?
Why do so few people seem interested in learning from things that go wrong?
Do we have to wait for OSHA (or someone else) to FORCE us to do what we ought to have been doing all along?
More importantly:
Do YOU wait for someone to require YOU to do what YOU know YOU ought to have been doing all along?
Monday, January 18, 2010
The death of Root Cause Analysis (at least for Failsafe Network)
Two years ago, in January 2008 I decided to listen to Failsafe's 4-day "Root Cause Experience" class attendees and change the name of Failsafe's pursuit from "Root Cause Analysis" to "Latent Cause Analysis."
Class attendees pointed out a fact about Failsafe's approach to "root cause analysis" which made the phrase counter-productive. Since Failsafe's methods do not identify "root causes," why use the phrase "root cause analysis?"
That's right -- Failsafe's approach to "root cause analysis" does not identify root cause! Instead, Failsafe's methods address the Physical, Human, and LATENT Causes.
Therefore, Failsafe Network, Inc. is now teaching, mentoring, and leading organizations towards doing Latent Cause Analysis.
Let me explain.
Think of anything that exists within nature -- mountains, oceans, trees, grass, bees, birds, even human beings. Scientists have done their best over the years to understand how all these things "came to be." They (scientists) attempt to understand the physical causes (reasons, factors) that explain our existance. In general, then, as humans we strive to understand the physical reasons for what we see. It seems innate within us that we yearn for this understanding.
Now shift your thoughts to things that we, as humans, create. Let's say we build a foot bridge over a creek. Just as with "nature," there is a physical explanation for the existance of the foot bridge. But since human beings put it there, there are also "human causes" (reasons, factors) that exist. After all, the foot bridge didn't simply appear (as did the mountains, oceans, grass, bees, etc.). Human beings put it there. It becomes their responsibilty.
Now let's introduce "things that go wrong." Let's say the footbridge collapses while someone is walking across. When something like this occurs, all that has been said remains true. We can initially strive to understand the physical causes (reasons, factors) of the collapsed foot bridge. But then, since the foot bridge was put there by human beings (and is therefore their responsibility), we also ought to understand the human causes (reasons, factors). We need to know "who did what wrong" (or, what were the points of inappropriate human intervention) that enabled the physics.
This is not to say that these human beings are "bad," or even that they knew they were doing something inappropriate. In fact, most of the time they didn't know. That's how we learn -- we go through life, doing the best we can each moment that presents itself until WHAM -- something goes wrong. Then, looking back at it (in retrospect, using 20/20 hindsight), we can see what we did (or didn't do) that enabled the physics.
But why do people do what they do? Why am I taking time to write this short article on this blog? Why did I get up this morning at 5:00 AM, when I was so comfortable under my bed covers? Why did I mess up my driveway when I plowed the snow off of it this winter?
If all we do is identify and act on the physical and human causes (reasons, factors) of our problems, then all we've done made sure the last incident will not happen again (the fallen footbridge, for example). And although there's nothing wrong with making sure the last incident will never happen, that's not enough. In fact, only going this far will cement you into a totally reactive existance -- just waiting for new (and more catastrophic) things to go wrong in your life.
Things go wrong in our lives to teach us something about ourselves. When we see the truth about ourselves, we change. When we change, our future (and the futures of those around us) will change -- for the better.
Therefore, the thrust of Failsafe's approach (Latent Cause Analysis) is to first understand the physics, and then understand the human interventions, but then to address the latent causes of the event.
I will write much more about latent causes in a future post. For now, let me give you the bottom-line Failsafe definition of a latent cause. The latent causes of an event are the answers to two questions:
1. What is it about the way WE ARE (as a family, business unit, organization, etc.) that contributed to this event?
2. What is it about the way I AM (as an individual) that contributed to this event?
When a person sincerely answers question #2 (above), it'll change their life. Things go wrong in our lives to teach us something about OURSELVES.
When people change, everything else changes.
Class attendees pointed out a fact about Failsafe's approach to "root cause analysis" which made the phrase counter-productive. Since Failsafe's methods do not identify "root causes," why use the phrase "root cause analysis?"
That's right -- Failsafe's approach to "root cause analysis" does not identify root cause! Instead, Failsafe's methods address the Physical, Human, and LATENT Causes.
Therefore, Failsafe Network, Inc. is now teaching, mentoring, and leading organizations towards doing Latent Cause Analysis.
Let me explain.
Think of anything that exists within nature -- mountains, oceans, trees, grass, bees, birds, even human beings. Scientists have done their best over the years to understand how all these things "came to be." They (scientists) attempt to understand the physical causes (reasons, factors) that explain our existance. In general, then, as humans we strive to understand the physical reasons for what we see. It seems innate within us that we yearn for this understanding.
Now shift your thoughts to things that we, as humans, create. Let's say we build a foot bridge over a creek. Just as with "nature," there is a physical explanation for the existance of the foot bridge. But since human beings put it there, there are also "human causes" (reasons, factors) that exist. After all, the foot bridge didn't simply appear (as did the mountains, oceans, grass, bees, etc.). Human beings put it there. It becomes their responsibilty.
Now let's introduce "things that go wrong." Let's say the footbridge collapses while someone is walking across. When something like this occurs, all that has been said remains true. We can initially strive to understand the physical causes (reasons, factors) of the collapsed foot bridge. But then, since the foot bridge was put there by human beings (and is therefore their responsibility), we also ought to understand the human causes (reasons, factors). We need to know "who did what wrong" (or, what were the points of inappropriate human intervention) that enabled the physics.
This is not to say that these human beings are "bad," or even that they knew they were doing something inappropriate. In fact, most of the time they didn't know. That's how we learn -- we go through life, doing the best we can each moment that presents itself until WHAM -- something goes wrong. Then, looking back at it (in retrospect, using 20/20 hindsight), we can see what we did (or didn't do) that enabled the physics.
But why do people do what they do? Why am I taking time to write this short article on this blog? Why did I get up this morning at 5:00 AM, when I was so comfortable under my bed covers? Why did I mess up my driveway when I plowed the snow off of it this winter?
If all we do is identify and act on the physical and human causes (reasons, factors) of our problems, then all we've done made sure the last incident will not happen again (the fallen footbridge, for example). And although there's nothing wrong with making sure the last incident will never happen, that's not enough. In fact, only going this far will cement you into a totally reactive existance -- just waiting for new (and more catastrophic) things to go wrong in your life.
Things go wrong in our lives to teach us something about ourselves. When we see the truth about ourselves, we change. When we change, our future (and the futures of those around us) will change -- for the better.
Therefore, the thrust of Failsafe's approach (Latent Cause Analysis) is to first understand the physics, and then understand the human interventions, but then to address the latent causes of the event.
I will write much more about latent causes in a future post. For now, let me give you the bottom-line Failsafe definition of a latent cause. The latent causes of an event are the answers to two questions:
1. What is it about the way WE ARE (as a family, business unit, organization, etc.) that contributed to this event?
2. What is it about the way I AM (as an individual) that contributed to this event?
When a person sincerely answers question #2 (above), it'll change their life. Things go wrong in our lives to teach us something about OURSELVES.
When people change, everything else changes.
It's been a long, long time
It's been quite a while since I last posted to this blog -- and one of the things I'll be trying to do this year is post much more frequently.
So starting this month (January, 2010), I'm going to be sharing what I am thinking about, relative to Latent or Root Cause Analysis.
If any of you who read this blog would like me to share my thoughts about anything in particular, please let me know. Either respond on this blog, of write me a personal email.
So starting this month (January, 2010), I'm going to be sharing what I am thinking about, relative to Latent or Root Cause Analysis.
If any of you who read this blog would like me to share my thoughts about anything in particular, please let me know. Either respond on this blog, of write me a personal email.
Thursday, April 21, 2005
Slow Down!
While presiding over a fascinating 4-hour discussion, an upper-level manager asked in exasperation:
The 4-hour discussion was prompted by two Root Cause Analyses that were presented by their Principal Investigators (PI's) to a group of 30 people who had just gone through 4 days of Root Cause Analysis training. Amongst the trainees were operators, maintenance people, technical resources, and managers. The recently-trained people were surprised at what was presented by the trained PI's, and especially at their answers to some of their questions.
As the PI's listened to the criticism, they became a bit emotional. After being more-or-less attacked by the recently-trained group, one of the PI's stood up and said:
The impassioned plea from the PI's lasted about 30 minutes. The essence of their argument was that management is not interested in truly understanding why things go wrong. They're too focused on goals and objectives. They're going fast, and they want to go faster. After they finished their rebuttal, about 25 of the attendees loudly applauded!!!!
As I said, managers were in attendance. They had been part of the 4-day training. One of them was a Plant Manager. Sitting in silence, listening first to the attacks and then to the PI's as they defended themselves, and finally after hearing the applause, the Plant Manager asked a pointed question:
The group's response was interesting. One fellow tried to explain WHY it was important to slow down. Another person said "you shouldn't have to ask that question because you've taken the same training as us!" Another suggested that "slowing down is a matter of attitude, more than it is action."
As I listened to the Plant Manager's question, and then the attendees answers I tried to put myself in her shoes. I immediately understood. What DO we mean when we ask each other to slow down? Why do we always expect the OTHER person to do the "slowing down" instead of asking ourselves the same question?
What, exactly, do you mean when you say that I have to SLOW DOWN!
The 4-hour discussion was prompted by two Root Cause Analyses that were presented by their Principal Investigators (PI's) to a group of 30 people who had just gone through 4 days of Root Cause Analysis training. Amongst the trainees were operators, maintenance people, technical resources, and managers. The recently-trained people were surprised at what was presented by the trained PI's, and especially at their answers to some of their questions.
Why didn't you follow the approach suggested in the training? Why did you take so many shortcuts? Why did you leave-out the most important ingredients of a successful investigation (keeping the 3 vectors of evidence separate, and requiring the stakeholders to come to their own conclusions).
As the PI's listened to the criticism, they became a bit emotional. After being more-or-less attacked by the recently-trained group, one of the PI's stood up and said:
You have no idea of how difficult it is to do the things we've been taught in the classroom. The methods are easy, and the concepts are sound. But getting the required resources and time is almost impossible.
The impassioned plea from the PI's lasted about 30 minutes. The essence of their argument was that management is not interested in truly understanding why things go wrong. They're too focused on goals and objectives. They're going fast, and they want to go faster. After they finished their rebuttal, about 25 of the attendees loudly applauded!!!!
As I said, managers were in attendance. They had been part of the 4-day training. One of them was a Plant Manager. Sitting in silence, listening first to the attacks and then to the PI's as they defended themselves, and finally after hearing the applause, the Plant Manager asked a pointed question:
What, exactly, do you mean when you say that I have to SLOW DOWN! Can you tell me what you'd like me to do? What would you like me to change? How would you like me to act?
The group's response was interesting. One fellow tried to explain WHY it was important to slow down. Another person said "you shouldn't have to ask that question because you've taken the same training as us!" Another suggested that "slowing down is a matter of attitude, more than it is action."
As I listened to the Plant Manager's question, and then the attendees answers I tried to put myself in her shoes. I immediately understood. What DO we mean when we ask each other to slow down? Why do we always expect the OTHER person to do the "slowing down" instead of asking ourselves the same question?
What, exactly, do we mean when we say we ought to slow down?
Any ideas?
(please post them)
Monday, April 18, 2005
Do you WANT to be on the Merry-Go-Round?
I am bothered, and this is my place to vent. My feelings come from some recent comments coming from the www.rootcauselive.com forum.
It's important to note that this item received the second-most votes of any any item. About half the voters voted for this item. In other words, this is not the whim of one person, but an opinion of many "rooticians."
In the following paragraphs, I'm going to say some things that have been presented to about 1500 people over the last 2 years. These comments have been made in seminar-form, as part of an overview lecture about Root Cause Analysis and have been overwhelmingly agreed-upon from the people who operate, maintain, and manage our industrial facilities.
We are on a Merry-Go-Round!
We are spinning round and round but to a large degree going no-where. The Merry-Go-Round spins faster and faster as the years go by, consuming us all in the useless endeavor of "holding on," while we should/could be doing other things. Carl Jung said:
Our intellect has created a new world that dominates nature, and has populated it with monstrous machines. The latter are so indubitably useful that we cannot see even a possibility of getting rid of them or our subservience to them.
In spite of our proud domination of nature, we are still her victims, for we have not even learned to control our own nature. Slowly but, it appears, inevitably, we are courting disaster.
As any change must begin somewhere, it is the single individual who will experience it and carry it through. The change must indeed begin with an individual; it might be any one of us. Nobody can afford to look round and to wait for somebody else to do what he is loath to do himself.
Few people will want to see the Merry-Go-Round -- very few.
If you don't like the Merry-Go-Round analogy, consider the Leaning Tower of Pisa. To one extent or another, we were all born on a leaning tower. We have never stepped-foot off the tower and never had any visitors. There are no windows or doors. We live on the tower with 10,000 other people. We are all on this leaning tower, to varying degrees.
Now, let's get back to the voting I was discussing in the beginning of this article. The problem, as apparent from the voting, is that most people don't want to see the leaning tower.
Root Cause Analysis is NOT just another program or tool. It is a way of seeing -- something that can change a person's life. It can help us see the Merry-Go-Round. Please don't treat this subject lightly. Please have continuous ties to outsiders; people who can help you see things that you cannot see. Certainly, you ought to acknowledge those in your own organization that are drawn to this endeavor. That's how to inculcate the effort at your site. But make sure they are connected to outsiders also -- to help them remain as pure as they can be in seeing the causes of their problems.
An unnamed organization revealed that even after experiencing some very well-received Root Cause Analysis training it is struggling to inculcate a root cause mentality. The organization asked for advice.
I requested that forum members suggest specific, actionable items to help this organization move in the right direction. I summarized people's ideas, then asked everyone to vote on their 3 favorite. 58 people voted -- one of the most popular of all our polls. But I was shocked at some of the results.
The suggestion that received the most votes was no surprise. In fact, I was glad to see it!
Insist that management issue objectives, responsibilities, policies and procedures supporting the RCA effort. Set specific objectives in people's performance reviews relating to RCA, especially for those who will have to do RCA's. Expectations, milestones, incentives, and rewards must all be delineated.
It was the second-place suggestion that caught my attention:
Internalize RCA in your company. Have mentors that will train others, as well as lead company RCA's. Do not be dependent on outside consultants when something goes wrong.
At first glance, there is nothing alarming at this statement. In fact, inculcation depends upon internalizing the RCA effort. But as comments continued to trickle-in, I began to see a major problem -- especially after a respected forum contributor STRONGLY suggested that it is best for an organization to align itself to someone offering train-the-trainer packages to minimize training dollars as well as dependency on the trainer/consultant.
I requested that forum members suggest specific, actionable items to help this organization move in the right direction. I summarized people's ideas, then asked everyone to vote on their 3 favorite. 58 people voted -- one of the most popular of all our polls. But I was shocked at some of the results.
The suggestion that received the most votes was no surprise. In fact, I was glad to see it!
Insist that management issue objectives, responsibilities, policies and procedures supporting the RCA effort. Set specific objectives in people's performance reviews relating to RCA, especially for those who will have to do RCA's. Expectations, milestones, incentives, and rewards must all be delineated.
It was the second-place suggestion that caught my attention:
Internalize RCA in your company. Have mentors that will train others, as well as lead company RCA's. Do not be dependent on outside consultants when something goes wrong.
At first glance, there is nothing alarming at this statement. In fact, inculcation depends upon internalizing the RCA effort. But as comments continued to trickle-in, I began to see a major problem -- especially after a respected forum contributor STRONGLY suggested that it is best for an organization to align itself to someone offering train-the-trainer packages to minimize training dollars as well as dependency on the trainer/consultant.
It's important to note that this item received the second-most votes of any any item. About half the voters voted for this item. In other words, this is not the whim of one person, but an opinion of many "rooticians."
In the following paragraphs, I'm going to say some things that have been presented to about 1500 people over the last 2 years. These comments have been made in seminar-form, as part of an overview lecture about Root Cause Analysis and have been overwhelmingly agreed-upon from the people who operate, maintain, and manage our industrial facilities.
We are on a Merry-Go-Round!
We are spinning round and round but to a large degree going no-where. The Merry-Go-Round spins faster and faster as the years go by, consuming us all in the useless endeavor of "holding on," while we should/could be doing other things. Carl Jung said:
Our intellect has created a new world that dominates nature, and has populated it with monstrous machines. The latter are so indubitably useful that we cannot see even a possibility of getting rid of them or our subservience to them.
In spite of our proud domination of nature, we are still her victims, for we have not even learned to control our own nature. Slowly but, it appears, inevitably, we are courting disaster.
As any change must begin somewhere, it is the single individual who will experience it and carry it through. The change must indeed begin with an individual; it might be any one of us. Nobody can afford to look round and to wait for somebody else to do what he is loath to do himself.
If you don't like the Merry-Go-Round analogy, consider the Leaning Tower of Pisa. To one extent or another, we were all born on a leaning tower. We have never stepped-foot off the tower and never had any visitors. There are no windows or doors. We live on the tower with 10,000 other people. We are all on this leaning tower, to varying degrees.
Now, let's get back to the voting I was discussing in the beginning of this article. The problem, as apparent from the voting, is that most people don't want to see the leaning tower.
One of the most common investigative principles is to use outsiders to lead investigations, because they can see things that insiders either cannot or are unwilling to see. Outsiders are not on the same Merry-Go-Round, or in the same Leaning Tower as the insiders. Outsiders have little or no political stake in the investigative findings. Outsiders are more likely to help people see their own leaning tower.
Of course, organizations cannot afford to wait for a catastrophe, and then call-in an outsider to investigate it! How, therefore, can an organization internalize its effort and still remain unbiased. In other words, how can someone who is on the leaning tower acknowledge that he's on it before it causes a problem?
It is not easy! That's the point of this article! Every organization ought to have clear, established ties to outsiders -- people that can help them see themselves as they are.
It is a mistake for an organization to purchase a train-the-trainer package from a consulting group, then tell them to go away! As a consultant and trainer, I know that organizations pick and choose what they want to embrace from the training that I provide. This is very frustrating because "it's the whole thing that works, not bits and pieces of the whole thing!" I cannot image what would happen if I trained 10 trainers, who in turn pick and choose what they think is important, who in turn train another 100 people, who also will pick and choose!
So here's the bottom-line, as least as I see it. Helping people learn from things that go wrong depends on courage, insight, and desire -- traits not often found in our fast-paced world....It is the single individual who will experience it and carry it through....
Root Cause Analysis is NOT just another program or tool. It is a way of seeing -- something that can change a person's life. It can help us see the Merry-Go-Round. Please don't treat this subject lightly. Please have continuous ties to outsiders; people who can help you see things that you cannot see. Certainly, you ought to acknowledge those in your own organization that are drawn to this endeavor. That's how to inculcate the effort at your site. But make sure they are connected to outsiders also -- to help them remain as pure as they can be in seeing the causes of their problems.
Wednesday, February 09, 2005
Do Managers Know what Root Cause Analysis Really Is?
When I am hired to teach Root Cause Analysis to an on-site group of people, one of the most common questions I hear is "does our management know what you're teaching us?" My generic answer is "no!" In my experience, most managers and executives think that Root Cause Analysis is something done by engineers and other technically-inclined people on either complex, long-term problems or the sudden disasters that all of us dread. They don't think it's necessary to attend the training themselves, since they don't think they'll be involved -- other than in a support role.
Twice in my career, however, I have had the "management team" sit through one of my 4-day classes. The first time this happened, about 5 years ago, it was a resounding success. The management team realized that Root Cause Analysis was much more than they imagined. They quickly got on-board and supported a refinery-wide effort.
The second time, however, was not as encouraging. In retrospect, I fear that this second "data-point" might be typical.
I knew I was in trouble after the 1st hour. Blank, glazed eyeballs stared me in the face. By lunchtime, I saw them huddled together discussing whether or not to cancel the training. At quitting time on the first day, the Human Relations manager approached me and said:
I looked at this person in disbelief and asked, "Didn't you say you were the HUMAN RELATIONS manager? You cannot see how you can relate to this???"
My disbelief stemmed from the fact that much of the first day was spent on the human-side of Root Cause Analysis, including how important it was to get everyone involved in "root cause thinking," but how difficult that would be in an environment of fear. I also tried to challenge their perception of Root Cause Analysis (as I do in all my classes), but as the saying goes:
How true! How true! Blogs like this are where people like me can express their thoughts for others to read and then make comments. I am expressing these particular thoughts because the experience greatly moved me. After all these years of trying to encourage the lower-level people to "learn from things that go wrong," I was confronted with THEIR reality, and it's worse than I thought:
Twice in my career, however, I have had the "management team" sit through one of my 4-day classes. The first time this happened, about 5 years ago, it was a resounding success. The management team realized that Root Cause Analysis was much more than they imagined. They quickly got on-board and supported a refinery-wide effort.
The second time, however, was not as encouraging. In retrospect, I fear that this second "data-point" might be typical.
I knew I was in trouble after the 1st hour. Blank, glazed eyeballs stared me in the face. By lunchtime, I saw them huddled together discussing whether or not to cancel the training. At quitting time on the first day, the Human Relations manager approached me and said:
I am getting absolutely nothing out of this and will probably not come back tomorrow unless you can convince me that I should. I cannot see how I can possibly benefit from this, or how I could apply it in my world.
I looked at this person in disbelief and asked, "Didn't you say you were the HUMAN RELATIONS manager? You cannot see how you can relate to this???"
My disbelief stemmed from the fact that much of the first day was spent on the human-side of Root Cause Analysis, including how important it was to get everyone involved in "root cause thinking," but how difficult that would be in an environment of fear. I also tried to challenge their perception of Root Cause Analysis (as I do in all my classes), but as the saying goes:
Some people listen but do not hear.
How true! How true! Blogs like this are where people like me can express their thoughts for others to read and then make comments. I am expressing these particular thoughts because the experience greatly moved me. After all these years of trying to encourage the lower-level people to "learn from things that go wrong," I was confronted with THEIR reality, and it's worse than I thought:
Not only do most managers not know what Root Cause Analysis is, they don't WANT to know.
If the normal reaction to this seminar were the same (apathy and boredom), then I'd know that I was the problem. But I am continually encouraged and energized by class attendees -- especially attendees from the hourly ranks -- the hands-on folks who KNOW why things go wrong. They see this as a PRACTICAL way to make a REAL difference.
Why is there such a discrepancy between the way the hands-on folks see this subject (Root Cause analysis) and their managers? Why am I continually drawn towards supporting the PLIGHT of the hands-on folks -- in the face of borderline-oppressiveness from their managers?
Actually, the answer is obvious.
PS: Of course, I am not speaking here about ALL managers, or ALL organizations. There are some excellent examples out there.
Tuesday, January 11, 2005
Introducing the Failsafe Network BLOG
Failsafe Network is a small consulting company that focuses on organizational and individual Root Cause Analysis. It is recognized that Blogs and their syndication are the wave of the future. Therefore, this trial is being undertaken to experience the usefulness of the concept.
It is hoped that several times a week, C. Robert Nelms (President and founder of Failsafe) will contribute relavent thoughts via this Blog.
Please visit the Failsafe web site for many useful pieces of information relating to Root Cause Analysis.
C. Robert Nelms
It is hoped that several times a week, C. Robert Nelms (President and founder of Failsafe) will contribute relavent thoughts via this Blog.
Please visit the Failsafe web site for many useful pieces of information relating to Root Cause Analysis.
C. Robert Nelms
Subscribe to:
Posts (Atom)
