I recently received an email that I simply must share. It's about the value of WHY Trees (or Cause Maps, or any other form of diagramming). Yes, these tools have value. But don't get pulled into the muck! BEWARE! The following is the email I received.
==========
I recently helped facilitate a Latent Cause Analysis where one of the stakeholders (an engineer!) had to do a cause map in order to communicate what happened and what caused the incident.
The facilitators obliged, thinking it couldn't be much different than a WHY tree, and I learned an important lesson.
When the engineer took it upon herself to do the cause map, she was immersed in it for 2 days (formatting, typing, coloring blocks, printing copies etc) instead of being immersed in the evidence with the rest of the stakeholders.
And what was worse, the other stakeholders were dragged through this map in a 4-hour presentation of causes and possibilities that reached into areas that weren’t supported by evidence.
The end result was a confusing document created by one person’s interpretation of the evidence.
Once the cause map exercise was complete, luckily we were able to save the stakeholder meeting and proceed with the LCA methodology. However, the waters were no doubt muddied by the cause map. But patience and persistence prevailed and we got the investigation back on track.
EVERYONE was discussing the evidence at hand and determined Physical, Human and Latent Causes while not even referencing the cause map.
This experience taught me something important: The answers to our questions come from immersing ourselves in evidence and pulling the causes from it, not focusing on the WHY tree (or cause map in this case).
==============
I know how fun and even constructive it can feel to spend time drawing cause maps and WHY Trees. Believe me when I say I am enamored by them myself. But I also know, through painful experience, how devious they can be to revealing the truth of the causes of an event.
Comments?
Tuesday, August 03, 2010
Wednesday, March 24, 2010
Zero-Based Root Cause Analysis (2)
It is probably true that you will never learn anything that someone else didn't already know. If this is true, then shouldn't we spend a lot of time learning from other people? Let's explore this a bit....
Before I was born, people knew how to walk, talk, eat, etc. And then, I was born.
I know how I learned to walk, to talk, to speak in public, to write, to breath, to comb my hair (what’s left of it). I had to fail, and fail, and fail, and fail. So did Edison. Sometimes, failing leads people to understand that “hey, I ought to learn more from other people.” Other times, failing leads people to “hey, those other people were dead wrong!”
Failure is the only phenomena of life capable of changing the way we see things, if we’re willing to put aside “the shell.” We never know where “failure” will lead us.
Maybe the real issue here is within the word “learn.” Learn is too vague a word, at least for me.
One of the synonyms for “learn” is “discover.” Something special happens at the moment of discovery. It’s the “epiphany” that I seek, and that I’m interested in helping others seek. Eureka! Shock! Mind-blowing, life changing, instantaneous paradigm change! It’s really hard to get to that point when someone else does the thinking for you. In fact, you can’t. When someone else does the thinking for us, we turn into lemmings.
Nevertheless, I suppose it’s true that I've not learned anything that someone else didn’t already know. But the most important things in life are the things that change me (us). And these kinds of things can only be learned by personal discovery.
I am not saying that I don’t think we should learn from one another. Of course we should! If we don’t we’re doomed.
And am I not saying that codes, standards, checklists, and all of that are bad. I think they’re essential. Without them, we have "Haiti."
When any of us learns something, we should all do our best to apply those learning’s across the board – before an incident occurs.
Before.
Those learning’s are our past solutions to past problems that we should have already have applied to our lives.
When we have a current problem, it’s time to put our past solutions to the side (until we know how and why the event occurred). I’ve done this all my professional life, and it’s led me (and others) to places I’ve (we’ve) never imagined.
All the ancient books (and religions), all the past philosophies, all our current knowledge, all that’s in our text books and on the internet will not replace the need for me (each of us) to learn certain things myself (ourselves)– even if someone else already knew – as a result of something that has gone wrong.
Before the problem, learn from others. After the problem, forget what others learned and simply wonder “why it happened to me (us), especially if others knew better?” In the end, it’s a very individual, lonely, but breathtakingly ecstatic existence – if we’re willing to break out of the shell.
Before I was born, people knew how to walk, talk, eat, etc. And then, I was born.
I know how I learned to walk, to talk, to speak in public, to write, to breath, to comb my hair (what’s left of it). I had to fail, and fail, and fail, and fail. So did Edison. Sometimes, failing leads people to understand that “hey, I ought to learn more from other people.” Other times, failing leads people to “hey, those other people were dead wrong!”
Failure is the only phenomena of life capable of changing the way we see things, if we’re willing to put aside “the shell.” We never know where “failure” will lead us.
Maybe the real issue here is within the word “learn.” Learn is too vague a word, at least for me.
One of the synonyms for “learn” is “discover.” Something special happens at the moment of discovery. It’s the “epiphany” that I seek, and that I’m interested in helping others seek. Eureka! Shock! Mind-blowing, life changing, instantaneous paradigm change! It’s really hard to get to that point when someone else does the thinking for you. In fact, you can’t. When someone else does the thinking for us, we turn into lemmings.
Nevertheless, I suppose it’s true that I've not learned anything that someone else didn’t already know. But the most important things in life are the things that change me (us). And these kinds of things can only be learned by personal discovery.
I am not saying that I don’t think we should learn from one another. Of course we should! If we don’t we’re doomed.
And am I not saying that codes, standards, checklists, and all of that are bad. I think they’re essential. Without them, we have "Haiti."
When any of us learns something, we should all do our best to apply those learning’s across the board – before an incident occurs.
Before.
Those learning’s are our past solutions to past problems that we should have already have applied to our lives.
When we have a current problem, it’s time to put our past solutions to the side (until we know how and why the event occurred). I’ve done this all my professional life, and it’s led me (and others) to places I’ve (we’ve) never imagined.
All the ancient books (and religions), all the past philosophies, all our current knowledge, all that’s in our text books and on the internet will not replace the need for me (each of us) to learn certain things myself (ourselves)– even if someone else already knew – as a result of something that has gone wrong.
Before the problem, learn from others. After the problem, forget what others learned and simply wonder “why it happened to me (us), especially if others knew better?” In the end, it’s a very individual, lonely, but breathtakingly ecstatic existence – if we’re willing to break out of the shell.
Zero-Based Root Cause Analysis (1)
I recently viewed a slide show about Foreign Material Management, i.e., making sure the wrong stuff doesn't get into our systems. It was based on learning's from past investigations, and was an excellent slide show.
We have learned an enormous amount about why things go wrong through investigating past incidents. Obviously, it is imperative to share what we've learned so that others do not experience needless pain.
As I was viewing the slide show, however, I remember thinking that there’s a difference between what we've learned, and how we've learned it -- a huge, monumental, life-shattering difference! Unfortunately, it seems that many people confuse the two.
Let's suppose, for example, that you have never eaten with with chopsticks. If you went to an oriental restaurant and were unable to use them on the first try, you would probably try another time, and then another until you were finally able to eat. In this simple example, you learned how to use chopsticks by trial and error.
Now let's suppose that you wanted to take your child to the same oriental restaurant, and you wanted him to avoid the frustration you had. You would most probably teach your child how to use chopsticks, based on what you've already learned. I think this would be good, responsible parenting.
We learn from our failues, and then we teach other people how to avoid that same failure. This is life. This is "being responsible." This is good.
But let's suppose your child couldn't use the chopsticks even after you taught him! The tendency, in this simple example, would be for you to compare what he was doing with what you told him to do. "Is he holding the chopsticks the way I suggested?"
We tend to investigate things that go wrong by comparing what went wrong with our predetermined understanding of "correctness." What if our predetermined understanding or correctness is invalid?
In the chopstick example, what if your adult hands were able to hold the chopsticks in a way that was impossible or ineffecitve for your child's smaller hands? Wouldn't it be better to simply look at the evidence in front of you, in this case your child trying to eat with chopsticks, with an open mind about what's going wrong. Even more, might it not even be better to let your child struggle a bit on his own? After all, he might invent a better way?
When we use our past learning’s as a basis of “goodness” when investigating an incident, I believe we’ve biased ourselves in the utmost manner. After all, what is bias? Isn’t it a “preconceived notion?” Isn’t bias the number 1 (or close to it) obstacle to learning something NEW? There’s a difference between how to learn, and how to apply those learning’s. We mix them up all the time.
Is it possible to do a root cause analysis without any reference to our past learning's?
More later..........
We have learned an enormous amount about why things go wrong through investigating past incidents. Obviously, it is imperative to share what we've learned so that others do not experience needless pain.
As I was viewing the slide show, however, I remember thinking that there’s a difference between what we've learned, and how we've learned it -- a huge, monumental, life-shattering difference! Unfortunately, it seems that many people confuse the two.
Let's suppose, for example, that you have never eaten with with chopsticks. If you went to an oriental restaurant and were unable to use them on the first try, you would probably try another time, and then another until you were finally able to eat. In this simple example, you learned how to use chopsticks by trial and error.
Now let's suppose that you wanted to take your child to the same oriental restaurant, and you wanted him to avoid the frustration you had. You would most probably teach your child how to use chopsticks, based on what you've already learned. I think this would be good, responsible parenting.
We learn from our failues, and then we teach other people how to avoid that same failure. This is life. This is "being responsible." This is good.
But let's suppose your child couldn't use the chopsticks even after you taught him! The tendency, in this simple example, would be for you to compare what he was doing with what you told him to do. "Is he holding the chopsticks the way I suggested?"
We tend to investigate things that go wrong by comparing what went wrong with our predetermined understanding of "correctness." What if our predetermined understanding or correctness is invalid?
In the chopstick example, what if your adult hands were able to hold the chopsticks in a way that was impossible or ineffecitve for your child's smaller hands? Wouldn't it be better to simply look at the evidence in front of you, in this case your child trying to eat with chopsticks, with an open mind about what's going wrong. Even more, might it not even be better to let your child struggle a bit on his own? After all, he might invent a better way?
When we use our past learning’s as a basis of “goodness” when investigating an incident, I believe we’ve biased ourselves in the utmost manner. After all, what is bias? Isn’t it a “preconceived notion?” Isn’t bias the number 1 (or close to it) obstacle to learning something NEW? There’s a difference between how to learn, and how to apply those learning’s. We mix them up all the time.
Is it possible to do a root cause analysis without any reference to our past learning's?
I say YES! Not only do I say YES, I also say this is the ONLY way to grow -- to see what we've never seen, and go where we've never gone.
Beware of those who are asking you to compare what went wrong with a predetermined understanding of correctness.
Beware of those who are asking you to compare what went wrong with a predetermined understanding of correctness.
More later..........
Friday, February 19, 2010
The Best Go Bag (or Go Box) I've ever seen.
In November, 2009 I had the good fortune to have been invited to Billings, Montana to present Failsafe's 4-day Latent Cause Experience. I was invited by Tim Mullowney, a person I met in Billings several years ago at another seminar I presented to his company. Tim and I "clicked" almost immediately, as we share many core values and beliefs. We don't talk incredibly often, but good friends don't need to. We just pick up where we left off.
When I received a call from him requesting the November seminar, I was delighted.
On the second day of the seminar, Tim came to the class with his Go Box (He knew that "Day 2" was when I started to talk about evidence). It was a relatively large, hard-cased yellow suitcase. He said it was full of evidence-gathering necessities that he learned he needed when he went through the class the first time. I assumed it was so large because of the cameras that might have been inside, but I was wrong.
I didn't really have time to look at its contents during the class, so I asked Tim if he'd like to do a "show and tell," for the benefit of all the attendees.
The resulting presentation blew me away.
I have never seen a better Go Bag (Box) -- nothing close to this one. When Tim Mullowney does something, he does it right! I'd even say his Go Box rivals most CSI's, and yes -- I think it even rivals the NTSB.
Please follow the link to see many photographs of the best Bo Bag (Box) I've ever seen, including information on how you can assemble your own.
http://failsafe-network.com/RCA-GoPage/Go-Box/root-cause-analysis-go-box.htm
Thank you Tim!
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!
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.
Subscribe to:
Posts (Atom)
