As an ex-aircraft mechanic and a “sometimes gotta work on my own car” mechanic, I have in the past borrowed or made some of the tools pictured below. The questions remain:
Wrong Tool?
Bad Access by Design?
Mechanic’s Ingenuity?
Or a little bit of them all?
Finally, ever have one of your modified tools bite you back? Share your stories in the comment section.
The picture above is from a airport jet bridge in Frankfurt, Germany.
If you look at the ground level you can just make out the wheels that carry a very heavy load.
You might also notice that they have a guard to keep people away.
Why did I notice this?
Because last year at the Knoxville airport a Delta employee was run over by these wheels. It totally crushed one leg.
There was no guard when the accident happened. Instead, Delta had a policy that all employees should be clear before the jet bridge was moved and stay clear while in motion.
Obviously, this administrative control (SPAC in TapRooT® lingo) failed (SPAC Not Used).
However, a physical guard might be a better safeguard than an administrative control.
Next time I get a chance I will have to see if the corrective action from the Knoxville accident was to add guards on the Knoxville jet bridges.
40 Years of Research Unlock the Value of Hands-On Training
Psychologists analyzed over 40 years of research across 16 countries to find the relationship between hands-on training and job performance. Burke et al. found that hands-on training was more effective than classroom style training for tasks that carried a high risk of death or injury. In lower-risk tasks, however, classroom style and hands-on training were equally effective.
The “Dread Factor” is the Key
They explain this phenomenon with a “dread factor,” the employee’s knowledge of the high risk of the task he or she is performing. The authors conclude that hands-on training should be considered for high-risk industries, even if it does cost more money. These realistic simulations heighten the “dread factor,” making a person more likely to remember training and adhere to safety standards.
This study best applies to the Training category in the Root Cause Tree®. Look under Understanding Needs Improvement: Practice/Repetition Needs Improvement. A problem with the “dread factor” could be due to poor learning objectives or instructional style as well. However, the trainee really needs practice so he or she understands the full risk of the task, as well as the procedural steps. If the training is “not repeated enough so that information [can] be learned and skills sharpened”, or “more simulator time [is] needed for proficiency”, then your facility may want to address this issue.
Ninth Time is the Charm
Can you think of a few employees who don’t understand the full risk of their tasks? Re-train them and revise the training program for new employees. Practice and present the procedure—including the risk—nine times total, as “…presentation of material up to nine times in a variety of settings and instructional techniques is commonly needed” (Corrective Action Helper® Guide).
For more information on training tips, look at Training in Organizations: Needs Assessment, Development, and Evaluation, Third Edition (1993) by Irwin Goldstein, published by Brooks/Cole Publishing Company, Pacific Grove, CA.
Want to learn more about our 7-Step Process? Click Here and learn how to find and fix real root causes with TapRooT®.
“The National Transportation Safety Board says the death of a monorail driver in July 2009 was the fault of a fellow Walt Disney World Resort employee.”
Here’s is what the NTSB report said the “Probable Cause” was:
“The National Transportation Safety Board determines that the probable cause of the July 5, 2009, collision between two monorails at Walt Disney World Resort in Lake Buena Vista, Florida, was the shop panel operator’s failure to properly position switch-beam 9 and the failure of the monorail manager acting as the central coordinator to verify the position of switch- beam 9 before authorizing the reverse movement of the Pink monorail. Contributing to the accident was Walt Disney World Resort’s lack of standard operating procedures leading to an unsafe practice when reversing trains on its monorail system.”
Here’s a link to a video on the Orlando Sentinel site that shows the new way that Disney controls the monorail:
Here’s what the Orlando Sentinel had to say about the cause of the accident:
“A lack of adequate safety protocols at Walt Disney World contributed to a 2009 collision between two monorail trains that killed a 21-year-old resort employee, federal investigators said Monday, concluding an investigation that took nearly two-and-a-half years.”
Here’s a You Tube video recreation of the accident:
What do you think?
Did the NTSB find the root causes of the accident?
What can you learn from the report and the accident that would impact operations at your company?
I attended the Milken Conference held in LA. Gary Becker, Nobel Prize and Presidential Medal of Freedom winner, explained the theory of human behavior and rewards.
Once again, the material we teach in TapRooT® Courses was confirmed through a different science – economics.
His economic theory is that people act because of the rewards built into the system.
So, if your boss with an MBA starts blaming folks after an incident – especially if rules were broken and the “enforcement” system isn’t working as intended, tell him/her to look into the research of renowned economist Gary Becker.
People are rational … The rewards system is broken.
TapRooT®’s Corrective Action Helper® can help you fix it.
For more information about TapRooT® Training, see:
From the articles:
“Cleanup crews in Idaho have finished clearing honey and an estimated 14 million bees that got loose after a delivery truck overturned on a highway.
Fremont County Sheriff deputies say several workers were stung during the first few hours of the cleanup Sunday.
And some observers told The Post-Register about seeing a strange black cloud and roaring noise above the spill area before realizing it was a massive swarm of bees.”
To make matters worse… more bees not contained may mean an increase of more bears.
Kevin Palardy, one of our Canadian based instructors, introducing the SnapCharT® Process. As you can see below, the course is not just a sit down and lecture course… you have to apply what you learn on each of the 7 Steps learned.
158 lives were lost on May 22nd, 2011, when Air India Express Flight 812 crashed after not aborting a landing. According to an article by Indian Aviation News,
“The court of Inquiry determines that the cause of the accident was Captain’s failure to discontinue an “Un-stabilised approach” and his persistence to continue with the landing, despite three calls from the First Officer to “go-around” and a number of warnings from the EGPWS”
According to the article being reviewed, the Government of India had inserted vide GSR No. 168(E) a very important rule to ‘The Aircraft Rules 1937′, which govern everything aviation in this country On 2009 March 13.
The rule:
75A. Reopening of Investigation – Where it appears to the Central Government that any new and material evidence has become available after completion of the investigation under rule 71, 74 or 75, as the case may be, it may, by order, direct the reopening of the same.
The article then references the findings that should reopen the case:
Here is a list of new and material evidence:
1. The fact that a huge portion of the wreckage was taken away from the crash site by locals and was sold as scrap metal. What the Court of Inquiry was inspected and studied (if at all they had done any study) was the remaining wreckage.
2. The reconstruction of the wreckage was never actually done by the CoI. The image of the reconstructed wreckage included in the report was a computer generated one.
3. While testifying before the court of Inquiry at Mangalore airport, Six survivors of the crash were made to answer a totally biased and misleading question by the CoI. The question was, “Do you think the accident occurred because of the fault of the pilot?” This was in plain violation of Rule 7.2.1 of the Manual of Accident/ incident investigation: ‘ The investigation of aircraft accidents and incidents has to be strictly objective and totally impartial and must also be perceived to be so’.
4. The “Hard Landing” circular issued by Air India is a major contributor to the accident. The CoI had chosen to ignore this vital fact.
Of course some of the issues from the article’s author stem from the investigation itself and are items that we teach our clients to avoid:
1. Spoliation of Evidence
2. Interviewing in a less effective manner which could have induced bias…. (leading the interviewee)
3. Focusing on what TapRooT® would define as a Causal Factor only and not the root causes for the Causal Factors
So the question for today’s Monday Lessons Learned is when would you, or when have you reopened an Investigation?
If you have ever sat in a TapRooT® Root Cause Analysis Course or Summit, you know that the transfer of knowledge and support from our instructors does not stop when the session ends. To help guide the next steps of continuous improvement, Mark Paradies and Linda Unger added Appendix C in our TapRooT® book, TapRooT®, Changing the Way the World Solves Problems. The tip today comes from “Topic 3: Knowledge” on page 461.
To ensure that TapRooT® Training is not just a one time event, we provide and suggest different knowledge opportunities:
The key concept to using and understanding knowledge is to identify the who, what, how and when as it relates to training. In our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training, key investigation facilitators are introduced to the ADDIE process (Analyze, Define, Develop, Implement, Evaluate). The only way do Analyze and Define is to go out and look at the tasks that people need to perform in order to be efficient. With that in mind let’s start with the following people:
1. Investigators
2. Certified Instructors
3. Managers
4. Improvement Program Leader (Owner/Champion)
5. Coaches/Mentors/Facilitators
6. Hands on Employees/Operators
7. Top Manager (Sponsor)
Start by identifying their core task and skills required to perform the tasks. You may find cross-over of tasks which is not a problem. Actually it gives you more resources to share in times of need.
Once you identify the tasks and possible skills, assess the level of knowledge needed. Here is a template from my U.S. Air Force training Matrix in our CFETP:
Task Performance Levels
1. Can do simple parts of the task. Needs to be told or shown how to do most of
the task. (Extremely Limited)
2. Can do most parts of the task. Needs only help on hardest parts. (Partially
Proficient)
3. Can do all parts of the task. Needs only a spot check of completed work.
(Competent)
4. Can do the complete task quickly and accurately. Can tell or show others how
to do the task. (Highly Proficient)
Task Knowledge Levels
a. Can name parts, tools, and simple facts about the task. (Nomenclature)
b. Can determine step-by-step procedures for doing the task. (Procedures)
c. Can identify why and when the task must be done and why each step is needed.
(Operating Principles)
d. Can predict, isolate, and resolve problems about the task. (Advanced Theory)
Subject Knowledge Levels
A. Can identify basic facts and terms about the subject. (Facts)
B. Can identify relationship of basic facts and state general principles about the
subject. (Principles)
C. Can analyze facts and principles and draw conclusions about the subject.
(Analysis)
D. Can evaluate conditions and make proper decisions about the subject.
(Evaluation)
By identifying the who, what and how, then we need to figure out where your TapRooT® Root Cause students will get to the performance levels needed to reduce or prevent problems (Incidents).
Biggest key here is that you will need to assess the skills of each team member listed above; where it starts:
1. Good Root Cause Analysis starts with a robust and usable method taught by knowledgeable facilitators; do this by sending them to the appropriate course. We teach and then give hands-on exercises; we follow up by working one on one with students as needed.
2. Develop in-house mentors/facilatators and assign those mentors as needed to help newly trained individuals. Some even get certified to teach in-house.
3. Look for systemic issues and identify additional knowledge and performance gaps. Decide who in the list above may need to attend one of the pre-Summit or Summit Activities.
4. Develop in-house group sessions to discuss lessons learned.
5. Schedule refresher training to give competency levels high.
Whenever I read about such outages, I think of the work of TapRooT® User Gerald Starling back in the 1990′s while he was at Bell South. He was one of the first people to apply advanced root cause analysis (TapRooT®) to network reliability problems after he heard about TapRooT® from a consultant at AT&T (sorry – don’t know his/her name).
Soon after, another company focused on high reliability computer operations, Tandem Computers, adopted TapRooT® for analysis of reliability issues.
Also, several government agencies adopted TapRooT® to analyze computer security issues (hackers and such).
But multiple mergers, the tech crash, and secrecy about technology issues has made it difficult to spread the word about the application of root cause analysis to computer network reliability issues.
Maybe the time is right for the spread of advanced root cause analysis across the computer industry to help improve network reliability?
If you are in the network reliability and security business, I’d suggest attending a 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course to learn the TapRooT® Techniques. Plus the course includes the patented TapRooT® Software (individual user edition) for each participant.
You’ll have to do a little translation (the examples in the class are not network reliability examples – the rest of the attendees wouldn’t understand them if they were) but others have told us that the learning is directly applicable to security and reliability issues of computer networks. See for yourself. Attend one of the courses listed at:
Just checking to see if TapRooT® Users got their Root Cause Network™ Newsletter today. I think you will find the Six Common Culture Problems story on page one both interesting and helpful when assessing culture issues.
Here’s a copy for download if you didn’t get yours by e-mail:
A great group of students for Kevin Palardy and I to work with and teach. With 32 being the maximum for a course, we had 7 on the waiting list. Make sure you are not on the next waiting list.
The mine is in Mullan, Idaho, a historic mountain mining town of 840 people in Idaho’s Panhandle. Baker said additional equipment was being flown in so crews could use a front-end loader remotely to dig away material clogging the tunnel. (more…)
“The world’s largest passenger aircraft clipped a much smaller commuter plane on a dark, wet tarmac at New York City’s Kennedy Airport, spinning it like a toy as hundreds of passengers sat in both planes. No one was injured.”
Interesting article today titled: “Restaurant to retrain staff after mixed-drink mixup”
On Friday, Taylor Dill-Reese went to an Applebee’s in Madison Heights, Michigan, where — among other things — she ordered her 15-month-old son Dominick an apple juice.
What the little boy apparently got instead was a margarita. His mom told WDIV-TV that she only realized something was wrong when Dominick “kind of laid his head on the table and dozed off a little bit and woke up and got real happy.”
The little boy reportedly began hailing strangers, too.
According to the article the restaurant stated, that it would begin to serve apple juice to children only from single-serve containers at the table and would “retrain all severs on our beverage pouring policy, emphasizing that non-alcoholic and alcoholic beverages must be stored in completely separate and identified containers.”
…. for our TapRooT® trained investigators, can you think of any other root causes than training? (more…)
So far I can’t get the whole report to download, but I can download the separate chapters. Once again, a massive report … This time over 350 pages with animation of certain key technical issues.
There are four best practice entries published on this weblog in the success story contest (view all entries here). Click the “Like” button for the entry you think should win an Apple iPad. All votes cast before Friday, March 4 at 6:00 p.m. EST will be tallied for the winner. In the event of a tie, the in-house instructors at System Improvements will cast the tie-breaking votes.
Entry #2: Stopping Future Accidents by Correcting Problems That Did Not Cause The Accidents Being Investigated
Submitted by: James Watson, Regional Specialist, System Safety Branch
FAA, Alaska
Challenge
TapRooT® investigation often identify actions and conditions that didn’t cause the actual accident being evaluated but that could be significant and, if not corrected, could combine with other factors to cause a future accident.
Action
These factors that the thorough analysis of TapRooT® helped identify are included in the presentation to management at the end of the talk (after the root cause analysis and corrective actions have been reviewed). This review includes explaining and discussing each of these potentially adverse factors with management. At a minimum, management is aware of these potentially adverse factors and the review often leads to discussion of additional corrective actions to address these issues.
Result
Accidents that might have happened are avoided by implementing corrective actions for problems identified during a root cause analysis that didn’t cause that accident but could have cause additional accident and were corrected by proactive corrective actions.
I got to the airport and checked in with 4 hours to spare.
The plane was lightly loaded.
Then, we had a 1 hour 30 minute gate hold due to weather because it was windy in Amsterdam (such is modern air travel).
We arrive 90 minutes late.
Now the bad part.
When I arrived in Amsterdam my bag didn’t come out.
I waited for a while to make sure it wasn’t the last one. 20 minutes slipped by.
I always stand near where the bags come out to make sure that nobody mistakenly takes mine. (I’ve stopped this from happening twice in my flying career.) I know my bag never came out.
Then I went to get in line to report the problem. There were about 50 people ahead of me. Another hour slips away.
I finally saw a person. They thought … it can’t be lost. It must have gone to the transfer station or perhaps one of the places where bags fall off the line. Or maybe you didn’t wait long enough. I’ll have some people check. I started filling out the paperwork while they searched. 30 more minutes slipped away from my life.
They also checked the computer. No note that any bag failed to make the plane. (Isn’t it part of modern airline security to make sure that your bag flies with you?) No note on the computer. It must be in Amsterdam – let’s check all the usual suspects again. 15 more minutes slip by.
Finally, they decide it is lost. They accept the form and tell me it will probably be on the next flight. They’ll bring it right over to my hotel when they get it and leave it at the front desk and tell them not to wake me if it comes in tonight late.
I think, “It is already late.”
“When is the next flight?”, I asked? They replied, “I’ll have to check.” … “Sorry – not until tomorrow, 9 AM. But we will update the bag status on-line (the internet!) as soon as we know anything and that will automatically text your cell phone.”
I check the baggage loop one more time on my way to customs. No bag.
The next morning I went to breakfast and checked with the front desk. No bag yet. And no text message.
After breakfast I decided to check the bag status on-line. Bag status was “unknown.” But there is a reassuring note that if your bag status is still unknown after four days, there is a special phone number to call. I begin to wonder … “If they have a special number, how many bags are never found?” I remember the 60 minutes story about the cavernous warehouse in Alabama for lost bags.
I decide it’s a good time to call the regular phone number and see what they say.
They check their system. Good news. The bag is scheduled for the 4 PM flight. I wonder, what happened to the 9 AM flight? What if I really needed my cloths? What if I was departing on a cruise or on to another international location?
I wait and hope.
By 7 PM, the bellman finally brings my bag to my room. That’s almost exactly 24 hours after we were suppose to land.
I was going over this in my head and thought …
This is a root cause analysis opportunity!
Why?
1. First … Think of the time wasted.
a. Over two hours of my time was spent just reporting the lost bag.
b. Some unknown amount of airline employee time was spent dealing with me, looking where bags could get lost (is says something that they know places to look), filling out paperwork, updating computer records, dealing with my call, and getting the bag delivered.
2. Second, I went a day without a bag. This could have been a minor disaster. Even though it wasn’t a disaster, it did leave me an unhappy customer. How many other unhappy customers like me are they creating every day?
Luckily, I travel prepared. This preparation is because I EXPECT them to lose my bag. This is a normal part of the frustration of flying. One more reason people drive if the trip is short. (I actually was thinking about a train trip from Milan to Amsterdam. I could have made it faster than my bag did flying.)
3. Third, is this a security violation? If making sure that the passengers bag travel with the passenger is a part of modern security, certainly this is a security failure.
Imagine how many future problems could be avoided if they started treating every lost bag as a customer service incident that needed to be investigated and reported to the CEO? I bet in a mater of weeks, or perhaps months, the number of “lost” bags for no good reason (like mine) would be ZERO.
The few remaining lost bags due to really tight gate connections (yes, people can run faster than bags can be delivered) would be be a very managible number and even those might be reduced.
What problem could they work on next?
What about delayed flights? Alaska Airlines did this and showed major improvements!
Bagage damage?
Plane damage?
Worker injuries?
Weather related delays?
Air traffic delays?
Security errors?
Long lines at the baggage counter?
Long lines at the ticket counter?
Slow baggage delivery?
All of these are fixable problems. They need advanced root cause analysis (not just stupid 5-Whys.) I’d bet many could be eliminated or at least dramatically improved at a low cost. And some might require some dollars to fix – but at what potential cost savings in the future?
Some could become a competitive advantage for a particular airline.
Others might improve the whole air travel experience.
Wow! Imagine the progress that could be made.
Root cause analysis is NOT just reserved for when planes fall out of the sky.
If only the airlines were interested in customer service!
Because no one is investigating this incident, flight delays, weather delays, air traffic delays … All these problems are just part of the fatiguing process of modern aviation. Which continues to get worse (a little more inconvenient all the time).
It will be no better when I fly out on Friday than when I flew in on Sunday.
Question: What do the wonderful group of people above and the four words below have in common?
Product, Equipment, Vendor, Employee………..
Answer: Ways to improve quality of product internally and externally and make work tasks safer were discussed and evaluated during an on site 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course held last week in New Jersey.
Kevin McManus (standing in back in Red with the group) and I had the pleasure to share manufacturing quality and safety best practices with a very passionate group of Rust-Oleum leaders in problem solving.
“Trask said the holes in the pipes were not the “root cause” of the leaks into the environment, but a “contributing cause.” The root cause, he said, was the pipe tunnel. Until the tunnel was breached, there was no leak outside the plant, according to Trask.”
Next, try this explanation:
“Smith accepted that this analogy explains Yankee’s concept of “root cause”: In a car crash where the brakes fail and then the air bag fails and the driver is injured, the root cause of the driver’s injury is the air bag failure, and the brake failure is a contributing cause.”
I think both of these explanations are misusing root cause analysis terminology.
Here is the TapRooT® defintion of “root cause”:
A Root Cause is the absence of a best practice
or the failure to apply knowledge
that would have prevented a problem.
Thus, none of the examples above would be root causes. They would all be Causal Factors that must be analyzed for their root causes.
A regulatory hearing with “intervenors” determined to shut down your plant can be a contentious environment to have a philosophical debate. I wish people would STOP trying to place blame and twist the meaning of words and put more effort into improving performance. Perhaps this statement by the Nuclear Regulatory Commission representative means that they think that vermont Yankee’s corrective actions are good enough even if their explanation of root cause leaves something to be desired:
“Neil Sheehan of the Nuclear Regulatory Commission said there was no one root cause, but a combination of problems—the holes in the pipes and the flaws in the pipe tunnel. He expressed confidence in Entergy’s root cause analysis.”
In the past two months I’ve had two TapRooT® Users say that a manager, not trained in TapRooT®, decided that they were spending too much time finding the root causes of problems. After all, before any investigation, the answers looked obvious to the managers. Why couldn’t the investigators just document what the manager already saw, ask “Why” five times, and come up with a simple, low-cost fix?
Of course, I started thinking about what management needs to know about root cause analysis. How they should realize that their “simple” idea is a recipe for disaster. Answers may be obvious but WRONG. Good answers to the right small problems keep big problems from happening and that’s what keeps their company from having the next Deepwater Horizon, Buncefield, or Three Mile Island. Do they want their company/site to be the next synonym for a disaster?
Then I started thinking …
What is enough?
How much effort is reasonable?
Are we giving management what they are paying for?
How can they tell?
What is Simple?
Einstein said:
“The answer should be as simple as possible, but not simpler.”
So, what is the right amount of root cause analysis? That’s a great question!
To answer that question, one must consider the purpose of incident investigations.
Investigation’s Purpose
The fundamental purpose of an incident investigation is to stop future serious accidents.
The Heinrich Pyramid shows the 300 reasons we investigate “no-injury accidents.” They have the potential to become injury accidents or fatalities. This same theory can be applied to quality incidents, hospital sentinel events, or any other major “bad thing” that is preceded by smaller events that foreshadow the big problem and give you a chance to improve before disaster strikes.
When management doesn’t see the purpose of investigating smaller problems to stop the big ones, they don’t know why anything but the smallest effort is needed.
Missed Opportunities
Some examples might help.
Let’s start with the explosion at the BP Texas City refinery. It killed 15 people, shut down one of the biggest refineries in the US for a year, and resulted in the biggest OSHA fine ever. But it could have been prevented. There were prior incidents. BP could have learned from them. If investigations commensurate with the risk had been performed and effective corrective actions had been implemented, the blowdown drum and stack would have been replaced with an adequately sized drum and flare. Procedures would have been usable and used. Rules for bringing on an extra operator during startups would have been followed. And human factors problems on the control boards would have been corrected. The prior incidents were there. All they needed was management to ask for advanced root cause analysis and effective fixes of smaller incidents to stop the major accident.
What about Three Mile Island? They did not learn from prior incidents. The nuclear industry had become complacent. They believed their own press releases about “high performance organizations.” An accident couldn’t happen at a nuclear plant. Too much defense in depth. The operators didn’t even believe it DURING the meltdown. A meltdown just could not happen. Hubris – an interesting phenomenon.
Then there is the last flight of the Concord. A prior incident had shown the potential for a fuel tank puncture. But instead of learning and preventing an accident (even if it meant grounding the Concord), engineers made calculations that showed the big accident couldn’t happen. Yet, it did. Previous corrective actions had been inadequate. Calculations can’t stop debris.
It Can’t Happen Here
In spite of the dozens of examples of accidents that could have been prevented by applying advanced root cause analysis of prior incidents and near-misses, some management still looks to save money on incident investigations. They must have read that:
A Penny Saved is a Penny Earned
But Ben Franklin also wrote:
Penny Wise and Pound Foolish
A Stitch in Time Saves Nine
And
An Ounce of Prevention
is Worth a Pound of Cure
Management must be kidding themselves that, “it can’t happen here.”
Your job is NOT to lull management into a sense of security. You must be ever vigilant and keep them aware that accidents are constantly trying to happen. Only a good defense of great root cause analysis of incidents and near-misses (that have the potential to cause major accidents) along with proactive audits & assessments targeted at high-risk activities can stop disasters. That’s why investing in advanced root cause analysis – TapRooT® – is completely cost justified.
Keep ROI High
Once management understands the reason for the investment in root cause analysis, you need to keep reminding them by explaining the accidents you prevent with each corrective action that is implemented. Explain the ROI (return on investment) that comes from preventing major accidents. Keep them aware that continued vigilance is the price of accident-free operations. It never stops.
In over 25 years of human factors and root cause analysis study, I’ve learned a few things that everyone should know. I don’t keep these root cause “best practices” a secret, but you would think that I did. Why? Because I find so many “experts” and lay people alike that don’t understand what I see as obvious. So I thought, “Why not share the seven most important ‘secrets’ here?” Then I could explain how the secrets are incorporated into TapRooT®.
7 Secrets
Here’s the list of the 7 Secrets (I’ll explain them in more detail in this, and upcoming, newsletters):
1. Your root cause analysis is only as good as the info you collect.
2. Your knowledge (or lack of it) can get in the way of a good root cause analysis.
3. You have to understand what happened before you can understand why it happened.
4. Interviews are NOT about asking questions.
5. You can’t solve all human performance problems with discipline, training, and procedures.
6. Often, people can’t see effective corrective actions even if they can find the root causes.
7. All investigations do NOT need to be created equal (but some investigation steps can’t be skipped).
Garbage In = Garbage Out
Most root cause systems operate as a “stand-alone” module. Information goes in and an answer comes out. They don’t help investigators collect accurate info.
To make matters worse, some root cause tools actually start by developing a “hypothesis” and then collecting information to verify (or perhaps disprove) the hypothesis. Extensive research has proven that once an investigator becomes invested in a particular hypothesis, his/her brain automatically starts looking for “facts” to confirm the hypothesis and disregards “facts” that are counter to the hypothesis. The result? You find what you want to find. This is not a robust root cause analysis process.
Investigation Tied To RCA
TapRooT® 7-Step Process
Copyright 2008 by System Improvements, Inc. Used by permission.
TapRooT® takes a completely different approach to how a root cause analysis process is used in an investigation. In the TapRooT® 7-Step Process, the root cause analysis tools are used throughout the investigation to make every investigation phase, including information collection, more robust.
Step 1: Planning
The first tool from the TapRooT® Toolbox that helps an investigator collect info is the SnapCharT®. The investigator starts using this tool to organize the investigation and decide what evidence needs to be gathered and assigns a priority to securing evidence that might be lost.
First Secret
That’s the first secret. Get accurate, complete, necessary information to understand the incident. If you try to analyze assumptions, you will be guessing at the root causes and fixing your guesses. That would be a “bad practice.”
Secret 2
Your knowledge (or lack of it) can get in the way of a good root cause analysis.
What? You think this is obvious? That’s OK. Many don’t recognize how this secret interferes with root cause analysis.
Let’s start with a popular root cause myth: Cause & Effect. Many think they can use the theory of cause & effect to find root causes. They assume that an experienced investigator who has seen a cause produce an effect can use that knowledge to diagnose future problems by using his/her experience to deduce the complex causal links (cause & effect chain) of an accident. This theory is the basis for many root cause analysis tools like 5-Whys, Cause-and-Effect Analysis, and FMEA.
An obvious problem with this theory is that inexperienced investigators don’t know many cause & effect relationships. They can’t find what they don’t know.
But many don’t understand that even experienced investigators may be led astray by the assumptions behind cause & effect analysis. How? Read on…
Investigator Trap
Experienced investigators are often trapped by the same cause & effect assumption that traps amateurs. How? First, even the most experienced investigators don’t know all the cause & effect relationships that cause accidents. This is especially true of the causes of human error. Many “experts” have little or no training or understanding of the psychology behind human error.
To combat the lack of knowledge, they recommend putting together teams of investigators with the hope that someone on the team will see the right answer. Of course, this depends on team selection to counter the inherent weakness of the assumption behind cause & effect. Also, it assumes that the rest of the team will recognize the right answer when another team member suggests it. Good luck!
More likely, the “strongest” member of the team will lead the team to arrive at the answers that he/she is experienced with.
Favorite-Cause-Itis
Experienced investigators often fall into the “favorite-cause-itis” trap. They use their experience to guide the investigation. This leads them to find cause & effect relationships that they are familiar with. Why? Because that is what they look for. They search for familiar patterns and disregard counter evidence. (The technical name for this phenomenon is “confirmation bias.”) The more experienced the investigator is … the more likely he/she is to fall into the trap.
Exposing this secret doesn’t make me popular with experienced guru investigators. They don’t want to admit that they have the same weakness as inexperienced investigators when it comes to cause & effect analysis. They try to explain that they don’t have preconceived ideas about the cause of any accident. But of course, this statement flies in the face of the basis of cause & effect analysis – that experienced investigators know the cause & effect relationships of accidents and can recognize them during an investigation.
TapRooT® Overcomes Favorite-Cause-Itis
How does TapRooT® overcome problems with “investigator knowledge”? Two ways. First, it keeps the investigation focused on “What happened?” while information is being collected. Because investigators don’t prematurely jump to finding causes, they are more likely to follow the evidence where it leads rather than following it where they want to go.
The main tool they use for collecting evidence is the SnapCharT®. They also use Change Analysis, Equifactor®, and CHAP. This combination of advanced tools produces superior information to analyze.
But the real magic behind TapRooT®’s root cause analysis is the Root Cause Tree®. The Root Cause Tree® takes the knowledge of hundreds of experts and makes it available to every investigator. (For the impressive list of sources used to build the tree, see Chapter 1 of the TapRooT® Book.) This knowledge doesn’t have to be in the investigator’s head because it is built into the Root Cause Tree® and the Root Cause Tree® Dictionary. Applying these systematic methods helps TapRooT® Users keep from jumping to conclusions.
The organization of causation in the Root Cause Tree® not only came from many reliable, advanced, sources but also was reviewed, critiqued, and tested. Beyond that, there are over 20 years of feedback from the international base of TapRooT® Users and members of the TapRooT® Advisory Board. This makes the TapRooT® System a unique, advanced process for finding the real root causes of problems.
Secret 3
You have to understand what happened before you can understand why it happened.
This secret seems obvious. Of course, you must understand what happened. But many investigators, and some root cause tools, start by asking “Why?” when they should be trying to understand “What happened?”
Starting by asking “Why” is jumping to conclusions. And this can lead the investigator to find causes that they have jumped to because they didn’t first seek to understand.
How SnapCharT®s Help
In the TapRooT® System, the first tool an investigator uses is a SnapCharT®. The SnapCharT® is a visual depiction of the evidence. It focuses the investigator on “What happened?” Any assumptions (not verified facts) are easily identified by their dashed boxes. The investigator then continues to look for more evidence to verify the assumptions or show a different, but also possible, sequence of events and conditions.
The SnapCharT® is an evolving document. The TapRooT® Book and the TapRooT® Courses teach the different “seasons” of SnapCharT®s. Each season has a purpose, which determines the level of detail shown on the SnapCharT®.
The Autumn SnapCharT® includes all the Causal Factors and evidence needed to find the incident’s root causes. Occasionally, an investigator will dis¬cover additional information when using the Root Cause Tree® to find root causes. This info needs to be added to the SnapCharT® to make it complete.
Below is an Autumn SnapCharT®.
Secret 4
Interviews are not about asking questions.
“What?” you might say … “I’ve always been taught to ASK questions as an interviewer.” What about the “open ended and close ended questions” routine that is commonly taught in some root cause training? And what about asking “Why?” five times? I thought I had to ask questions during an interview?
Let’s start with the popular 5-Why myth.
I won’t review all the problems with the 5-Why technique. I’ll just mention the one that most applies to interviewing. Consider this … what happens when you ask somebody a question like:
“Why did you do that?”
Does the person answer with lots of information or with justification?
The “Why” question turns off the “remembering” trail that we want the brain to go down and turns on the “justification” trail. After all, isn’t the purpose of an interview to collect information (not justification)?
Next, let’s look at the whole process of “questioning” during an interview. If the purpose of an interview is to collect information, we should use a process that stimulates remembering.
Researchers Fisher and Geiselman determined that the biggest problem with police interviews was the police interrupting the interviewees’ memory process with questions. It didn’t matter if the questions being asked were open ended or closed ended. Every time the interviewer interrupted the interviewee, his/her memory had to shift gears. S/he lost her/his train of thought and didn’t remember as much as s/he could. The interviewer didn’t get to important facts. (Facts were omitted when the interviewee was distracted by questions.)
Not only did interruptions for questions cause problems, but also the questions being asked didn’t help stimulate remembering. Fisher and Geiselman came up with a new interviewing process called “cognitive interviewing” that helps the interviewer encourage the interviewee to remember much more and thus improve the amount of information collected.
Another problem that was noted in Fisher and Geiselman’s research was that interviewees often tried to provide the interviewer with the “most important” information. They filtered what they told the interviewer. The interviewee didn’t understand that some detail that they thought was “unimportant” was something that the interviewer really needed. Because the interviewer didn’t know the detail, they couldn’t ask about it. Therefore, the information was lost.
The TapRooT® 5-Day Advanced Root Cause Analysis Team Leader Course includes cognitive interviewing combined with the TapRooT® SnapCharT® technique to improve interviews. This shifts the interviews from a questioning to a listening process. The cognitive interviewing process encourages interviewees to share all the info they know by encouraging them to remember. Also, the interviewee is told to provide details no matter how small or unimportant.
Secret 5
You can’t solve all human performance problems with discipline, training, and procedures.
If you look at most industrial accident/incident investigations, you find three standard corrective actions:
1. Discipline. Which starts with the common corrective action: “Counsel the employee to be more careful when …”.
2. Training. This may be the most used (and misused) corrective action of all.
3. Procedures. If you don’t have one, write one. If you already have one, make it longer.
The misuse of these three standard corrective actions is the reason that so many accident investigations don’t really cause performance to improve. They don’t solve the real problems.
What do we need to get better results? First, better root cause analysis. Second, development of better corrective actions based on the root causes of the problems. And third, corrective actions that provide the strongest safeguards to future errors.
TapRooT® provides the better root cause analysis and the Corrective Action Helper® Guide to help investigators develop better corrective actions. But the 2-Day, 3-Day, and 5-Day TapRooT® Classes also teach Safeguards Analysis to help investigators understand that all corrective actions are not created equal. Students learn that there is a hierarchy of potential corrective actions and that they should not just use the corrective actions that seem easiest to develop and implement. Rather, they should look for the strongest corrective actions that will ensure that a problem does not recur.
Secret 6
Often, people can’t see effective corrective actions even if they can find the root causes.
Why? Because they have performed the work the same way for so long that they can’t imagine another way to do it.
I didn’t initially believe this. I thought that once someone saw the root cause of a problem, the answer would be obvious. But students in a course finally convinced me that I was wrong.
Back in 1994, a team of students analyzed the root causes of a fairly simple incident. One of the root causes was that the valves being operated were not labeled. So far, so good.
But here was their corrective action:
Tell operators to be more careful when operating valves without labels.
They just couldn’t see that valves could be labeled. It was beyond their experience.
That was the day I decided that we needed to do something different to help people see different corrective action alternatives. This revelation eventually lead to the development of the Corrective Action Helper® Module of the TapRooT® Software and the Corrective Action Helper® Guide that each participant gets in our 2-Day and 5-Day TapRooT® Courses.
The Corrective Action Helper® Module/ Guide provides suggestions that can help investigators discover that there are other ways to solve problems beyond those of their experience. It does not guarantee that they will get the right answer but it does prod them in the right direction. Also, the Corrective Action Helper® Guide can be used by management to review the investigation team’s findings to see if they explored all the alternatives.
Secret 7
Now for the final secret…
All investigations do NOT need to be created equal
(but some investigation steps can’t be skipped).
I’ve seen people cringe when performing a root cause analysis of a problem is suggested. They think this means a team of selected experts spending months locked up in a room. After all, didn’t the CSB take three years and spend almost $3 million investigating the BP Texas City explosion?
It’s true that some investigations may take too long and cost too much. But that doesn’t mean that every root cause analysis needs to take too long and cost too much.
Root cause analysis should be scaled to the size of the problem and the risk of future accidents with similar causes. Small risk = small investigation. Big risk? Then spend more time and more investigative effort … dot each “i” & cross each “t.”
The hard part of responding appropriately is projecting the risk of the problem before the investigation starts. For example, sometimes an incident that seems quite simple can have complex causes that could, in different circumstances, cause a big accident.
Scale an Investigation
The TapRooT® System is flexible to accomodate any size risk. Use some techniques for every investigation. Others are just applied in major investigations.
For simple incidents, a single investigator draws a simple SnapCharT® of the sequence of events and identifies one to three easy to spot Causal Factors. They can do this working with those involved in a couple of interviews. Just one or two hours total.
Drawing a SnapCharT® is required because you have to understand what happened before you can find out why it happened.
Next, she takes those Causal Factors through the Root Cause Tree®. (Perhaps an hour of work.) Then another hour to develop some simple, SMARTER corrective actions based on the Corrective Action Helper® Guide and to document it with some short written sections in the TapRooT® Software. You are ready for approval. (About one half day’s work.)
What if management says that half a day is “too long”? After all, couldn’t you ask “Why” five times in about five minutes and then suggest a corrective action?
Of course, you could. But that isn’t root cause analysis. That’s just taking a guess and going with it.
Some small problems don’t deserve root cause analysis. Don’t waste time implementing poorly thought out corrective actions. Just categorize the problem and repair the failure. Paper cuts can’t cause fatalities.
The big accidents? Go all out. A full-blown investigation team with an independent facilitator. SnapCharT®, CHAP, Change Analysis, Equifactor®, Safeguard Analysis, and the Root Cause Tree®. Look for generic causes of each root cause. Then remove the hazard or target or change the human engineering of the system. Not the normal “training/ counseling” simple corrective actions. Something really effective at eliminating the root causes or the hazard.
Something in between? A response in between. Don’t go overboard. Just do what you need based on the size of the problem. And if you discover that a problem is bigger than you thought, let management know and change the scope of the investigation.
Applying the 7 Secrets
Know that you know the seven secrets, apply them in your investigations. The easiest way to do this is to apply TapRooT® as the standard incident investigation root cause analysis technology at your site. Start by attending one of our public TapRooT® Courses. Then get a site or corporate TapRooT® Software License and hold training at your sites. You’ll find the time (and lives) you save will be well worth the effort.
Aquí está una lista de los 7 Secretos del análisis de causa raíz.
1. Tu análisis es tan bueno o tan malo como la información que recopilas.
2. Tus antecedentes y experiencia pueden estorbar a un buen análisis de causa raíz.
3. Tienes qué entender claramente qué sucedió antes de que entiendas por qué sucedió.
4. Las entrevistas no son para hacer preguntas.
5. No se pueden resolver todos los problemas de desempeño humano con disciplina, entrenamiento y procedimientos.
6. Frecuentemente, las personas no pueden implementar acciones correctivas efectivas a pesar de que encuentran las causas raíz.
7. Todas las investigaciones no fueron creadas iguales (pero los pasos de la investigación no se pueden eludir).
Si entra basura – sale basuraLa mayor parte de los sistemas de análisis de causa raíz operan como un módulo único. Información entra y una solución sale. No ayudan, para nada, al investigador a recolectar la información correcta.
Para empeorar la situación, algunas herramientas empiezan desarrollando una “hipótesis de trabajo” y después recolectan la información para verificar (o quizás rechazar), la hipótesis. Investigaciones exhaustivas han demostrado de que una vez que un investigador se involucra en una hipótesis particular, su cerebro automáticamente busca “hechos” que confirmen la hipótesis y pasa por alto “hechos” que rechazan la hipótesis. El resultado es: tú encuentras lo que quieres encontrar. Este no es un proceso robusto de análisis de causa raíz.
Investigaciones Atadas a RCA
Proceso de 7 Pasos de TapRooT®
Copyright 2008 by System Improvements, Inc. Used by permission.
TapRooT® hace un enfoque completamente diferente de cómo el proceso de análisis de causa raíz se usa en una investigación. En el proceso de análisis de causa raíz de 7 Pasos TapRooT®, las herramientas se usan durante toda la investigación, para robustecer cada fase de la investigación, incluyendo la recolección de datos. Paso 1: Planeación
La primera herramienta de la caja de herramientas TapRooT® y que ayuda al investigador a recolectar información es la SnapCharT®. El investigador inicia la organización de la investigación con esta herramienta y decide qué evidencia le hace falta y le asigna prioridad a la obtención de evidencia que pueda perderse
Primer secreto.
Obtener la información necesaria para entender el incidente en forma completa y precisa. Si tratas de analizar las suposiciones, en esta etapa, estarías adivinando las causas raíz y ajustando tus adivinanzas, sin recolectar el resto de la información, lo que sería una mala práctica.
Secreto 2Tu conocimiento o falta del mismo puede atravesarse en el camino de un buen análisis de causa raíz
¿Piensan que esto es obvio? bueno muchas personas no se dan cuenta de que esto interfiere con su análisis de Causa Raíz
Empecemos con un popular mito del análisis de causa raíz: Causa & Efecto. Muchos piensan que se puede usar la teoría de Causa/Efecto para encontrar causas raíz. Ellos suponen que la experiencia del investigador que ha visto una causa producir un efecto puede utilizar ese conocimiento para diagnosticar futuros problemas, usando su experiencia para deducir los enlaces causales complejos (cadena de Causa/Efecto), de un accidente. Esta teoría es la base de muchos sistemas de análisis de causa raíz como: el 5 Por qués, el Análisis Causa/Efecto y el FMEA (Failure Mode and Effect Analysis – Análisis de Modo de Falla y Efecto).
Un problema evidente de esta teoría es que investigadores sin experiencia no conocen muchas de las relaciones de causa efecto y no podrán encontrar lo que no saben. Pero muchos no entienden que aún investigadores con experiencia pueden desorientarse por las suposiciones que hay atrás del análisis de causa/efecto. ¿Cómo? Sigamos adelante…
Celada del Investigador
Investigadores con experiencia caen frecuentemente en las mismas trampas de la causa/efecto en las que caen investigadores amateurs. ¿Cómo? Primero, aún los investigadores con más experiencia no conocen todas la relaciones causa efecto que originan incidentes. Esto es especialmente cierto para las causas del error humano. Muchos “expertos” no tienen entrenamiento o comprenden la psicología detrás del error humano.
Para combatir la falta de conocimiento, ellos recomiendan juntar equipos de investigadores con la esperanza de que alguien en el equipo vea la respuesta correcta. Para ellos, la composición del equipo de trabajo es crítica. Claro está que también dependerá de la habilidad del experto para convencer al resto del equipo que no detectó esa respuesta correcta. ¡Buena suerte con esto! Es más seguro que el miembro más “fuerte” del equipo imponga su opinión y lleve al equipo a las respuestas que le son más familiares (aquellas con las que él ha tenido éxito, pero no necesariamente la correcta).
Causitis Favoritus
Aún investigadores con experiencia caen frecuentemente en la trampa de la “causitis favorita”. Utilizan su experiencia para guiar la investigación. Esto los lleva a encontrar relaciones causa/efecto que les son cómodas y fáciles de explicar o que no requieren explicación por ser obvias. ¿Por qué? Porque están buscando precisamente eso – patrones de causa/efecto que les son familiares y eliminan la evidencia que indica otras relaciones. (El nombre técnico para este fenómeno es “parcialidad de confirmación”.) Mientras más experiencia tenga el investigador… más fácilmente caerá en esta trampa.
El exponer este secreto no me va a ser más popular con los “gurus” investigadores expertos. Ellos nunca van a admitir que sufren de las mismas debilidades que los investigadores novatos cuando se trata de análisis de relaciones causa/efecto. Ellos siempre me han tratado de explicar que no tienen ideas preconcebidas acerca de la causa/efecto de un incidente; pero esta declaración se desploma una vez que se analiza las relaciones causa/efecto encontradas en forma independiente y confirma, una vez más, que la suposición de que los investigadores expertos conocen las relaciones causa/efecto de todos los incidentes de memoria y que son capaces de reconocerlas durante una investigación.
TapRooT® Supera la Causitis Favoritus
¿Cómo le hace TapRooT® para superar los problemas que se tienen con el conocimiento de los investigadores? De dos manera: Primero mantener la investigación enfocada, mientras se recolecta la información, en “¿qué fue lo que pasó?” De esa manera se evita que los investigadores salten a conclusiones encontrando causas, es más fácil que los investigadores sigan la evidencia hacia donde ella conduce que cuando tratan de llegar a donde quieren llegar.
Recordemos que la principal herramienta que se utiliza para recolectar la información es la SnapCharT®. También podemos utilizar el Análisis de Cambios y Equifactor®, posiblemente PAHC, en casos más complejos. Esta combinación de herramientas avanzadas simplemente produce mejor información para analizar.
Pero la verdadera magia atrás del análisis de causa raíz de TapRooT® es el Árbol de Causa Raíz y el Diccionario que lo acompaña. El Árbol sintetiza el conocimiento de cientos de expertos y lo pone a disposición de todos los investigadores (una lista de las fuentes del Árbol está en el Capítulo 1 del Libro de TapRooT®), y lo que es más, este conocimiento no tiene que estar en la cabeza de los investigadores, no hay que memorizarlo, ya que está inter-construido en el Árbol y el Diccionario. Aplicando este método sistemático, evitamos que los investigadores salten a conclusiones o impongan sus opiniones en el resto del equipo.
La relación causa/efecto en el Árbol de Causa Raíz® no solamente viene de muchas fuentes confiables, pero también ha sido revisado, criticado y probado. Sobre esto también hay más de 20 años de retroalimentación de la base de internacional de usuarios y miembros del Consejo Consultivo. Esto lo hace de naturaleza única, para encontrar causas raíz reales a los diferentes problemas.
Secreto 3
Tienes qué entender lo que pasó, antes de intentar entender por qué pasó.
Esto secreto parece obvio. Hay que entender lo que pasó. Sin embargo muchos investigadores empiezan preguntando “¿por qué pasó?”, cuando deberían de estar tratando de entender “¿qué fue lo que pasó?”
Una vez que empezamos a preguntar “por qué”, empezamos a saltar a conclusiones. Y esto nos hace caer a las causas que adivinan el entrevistado o entrevistador, simplemente porque no intentaron entender desde un principio qué fue lo que pasó.
Cómo Ayuda la SnapCharT®
En el método TapRooT®, la primera herramienta que usa el investigador es la SnapCharT®. La SnapCharT® es una descripción visual de la evidencia. Enfoca al investigador en “¿qué fue lo que pasó?”. Cualquier suposición, pregunta pendiente de respuesta o hecho no verificado son fácilmente identificadas en sus cajas punteadas. Sin detener la investigación el investigador continúa buscando más evidencia dejando pendiente las suposiciones, continuando con la secuencia y con las diferentes condiciones asociadas a los eventos. Más tarde se buscará evidencia corroboratoria para intentar despejar las preguntas pendientes o confirmar las suposiciones. En muchos casos, al intentar despejar una suposición aparece una nueva secuencia de eventos y condiciones.
La SnapCharT® es, en consecuencia y por definición, un documento evolutivo. En los cursos enseñamos las diferentes estaciones, etapas, de las SnapCharTs®. Cada una de estas etapas tiene un propósito que determina el nivel de detalle que se muestra en cada una de las SnapCharTs®.
La SnapCharT® de Otoño incluye todos los Factores Causales y la evidencia necesaria, para encontrar las causas raíz del incidente. Ocasionalmente, un investigador puede redescubrir información adicional cuando recorre el Árbol de Causa Raíz®, para encontrar las causas raíz. Esta información requiere ser añadida (retroalimentada), a la SnapCharT® para completarla.
Abajo vemos un ejemplo de SnapCharT® de Otoño.
Secreto 4
Las entrevistas no son acerca de hacer preguntas.
“¿Qué qué?”, pudieran preguntar… a mí siempre me han dicho que haga preguntas en las entrevistas y qué pasa con la práctica de “preguntas cerradas y abiertas” que se enseña en los entrenamientos de causa raíz y qué pasa con eso de preguntar “¿por qué” 5 veces? Yo siempre he pensado que tenía que hacer preguntas durante una entrevista.
Empecemos por el popular mito del 5-por qués.
No repasaremos aquí todos los problemas de la técnica del 5-por qués. Sólo mencionaré el que aplica más frecuentemente a las entrevistas. Qué sucede… cuando le preguntas a una persona algo así como:
“¿Y por qué hiciste eso?”
¿Creen que la persona va a responder con información adicional o con una justificación?
La pregunta de “Por qué” cierra el tren de “recuerdo” en el que queremos que la mente se enfoque y abre el tren de “justificación”. Después de todo, el propósito de la entrevista es para recolectar información, no justificarla.
En seguida veremos el proceso completo de “preguntas” durante una entrevista. Si el propósito de la entrevista es para recolectar información, debemos usar un proceso que estimule el recordar.
Los investigadores Fisher y Geiselman determinaron que el problema más grave que había con las entrevistas policiacas era que los policías interrumpían el tren de pensamiento de los testigos y por lo tanto su proceso de memoria con preguntas. No importaba si las preguntas eran abiertas o cerradas. Cada vez que el entrevistador interrumpía al entrevistado su memoria tenía que cambiar de engrane y no podían recordar tanto como hubieran podido. El entrevistador no obtenía datos importantes ya que datos fueron omitidos cuando el entrevistado fue distraído por nuevas preguntas.
No solamente las interrupciones para preguntas causan problemas, sino también las preguntas que se hacen no ayudan a estimular el recuerdo. Fisher y Geiselman descubrieron un nuevo proceso de entrevistas llamado “entrevistas cognitivas” que ayudan al entrevistador a motivar a los entrevistados a recordar mucho más y por lo tanto mejoran la cantidad de información recolectada.
Otro problema que detectaron Fisher y Geiselman fue que los entrevistados frecuentemente tratan de dar al entrevistador la información “más importante“. Ellos filtraban lo que le decían al entrevistador. El testigo no entendía que algunos de los detalles, que ellos pensaron que no eran importantes, era precisamente algo que el entrevistador realmente necesitaba, pero como el entrevistador no conocía ese detalle, no podía preguntar por él. Por lo tanto la información se perdía.
El Curso de 5 Días de TapRooT® para Líderes de Equipo, incluye entrevistas cognitivas combinado con la técnica del SnapCharT®, para mejorar las entrevistas. Esto cambia la actitud del entrevistador de un proceso de preguntar a uno de escuchar. El proceso de entrevistas cognitivas motiva a los entrevistados a compartir toda la información que saben al estimular su proceso de memoria o recuerdo. También se le pide al entrevistado que proporcione todos los detalles que recuerde sin importar qué tan pequeños o poco importantes piense él que sean.
Secreto 5
No puedes resolver todos los problemas de desempeño humano con disciplina, entrenamiento y procedimientos. Si vemos la mayoría de las investigaciones de incidentes industriales, encontraremos estas tres acciones correctivas estándares:
1. Disciplina. Que se traduce “díganle al empleado que sea más cuidadoso cuando…”.
2. Entrenamiento. Esta es probablemente la más recurrida (y mal usada), de todas las acciones correctivas.
3. Procedimientos. Si no tienes uno, escríbelo. Si ya lo tienes, hazlo más largo.
El mal uso de estas tres acciones correctivas estándar es la razón por la cual tantas investigaciones de accidentes no generan ninguna mejora en el desempeño, no resuelven ningún problema real.
¿Qué necesitamos hacer para obtener mejores resultados? Primero, mejor análisis de causa raíz. Segundo, desarrollar mejores acciones correctivas basadas en las causas raíz de los problemas. Y tercero, acciones correctivas que proporcionen las mejores barreras para errores futuros.
TapRooT® proporciona un mejor análisis de causa raíz y el Manual de Acciones Correctivas® ayuda a los investigadores a desarrollar mejores acciones correctivas. Pero los cursos de 2, 3 y 5 días de TapRooT® también enseñan Análisis de Barreras y Protecciones para ayudar a los investigadores a entender que todas las acciones correctivas no son creadas iguales. Los estudiantes aprenden que hay una jerarquía de acciones correctivas potenciales y que no deben, simplemente, de usar las acciones correctivas que parecen más fáciles de implementar, sino que deben buscar la acción correctiva más robusta que asegure que el problema no volverá a ocurrir.
Secreto 6
Frecuentemente, las personas no pueden ver las acciones correctivas a pesar de que encuentran las causas raíz.
¿Por qué? Simplemente porque han hecho el trabajo de la misma manera por tanto tiempo, que no se pueden imaginar otra manera de hacerlo.
Al principio no comprendía esto y pensaba que, una vez que una persona sabía la causa raíz de un problema, la respuesta debía ser obvia, pero los estudiantes de uno de mis cursos finalmente me convencieron de que estaba equivocado.
En 1994, un grupo de estudiantes analizaron las causas raíz de un incidente relativamente sencillo. Una de las causas raíz era que las válvulas que estaban siendo operadas no tenían etiquetas. Hasta allí todo iba bien.
Aquí está su acción correctiva:
Díganles a los operadores que sean más cuidadosos cuando operen válvulas sin etiquetas.
Simplemente no podían ver que las válvulas tenían que ser re-etiquetadas, estaba más allá de su experiencia o no habían tenido el apoyo institucional para re-etiquetarlas.
Ese día fue cuando decidí que necesitábamos hacer algo diferente para ayudar a las gentes a ver alternativas diferentes de acciones correctivas. Esta revelación eventualmente llevó al desarrollo de un Módulo de Ayuda de Acciones Correctivas en el programa TapRooT®, y el Manual de Acciones Correctivas® que se entrega a cada estudiante en los cursos de 2 y 5 días.
El Módulo de Ayuda de Acciones Correctivas proporciona sugerencias que ayudan al investigador a ver otras formas de resolver los problemas más allá de lo que es su experiencia. Esto no garantiza que tundra una respuesta correcta, pero indudablemente los apunta en la dirección correcta. También, el Manual de Acciones Correctivas® puede ser usado por la administración para revisar los resultados de los equipos de investigación y ver que haya explorado todas las alternativas.
Secreto 7
Ahora el secreto final…
Todas las investigaciones NO necesitan ser creadas iguales
(pero algunos pasos de investigación no se pueden omitir).
He visto personas que se “encogen” cuando se sugiere hacer un análisis de causa raíz de un problema. Ellos piensan en un equipo de expertos pasando meses encerrados en un cuarto. Después de todo, el Buró de Seguridad Química se tomó tres años y gastó $3 Millones de Dólares investigando la explosión de la Refinería de Texas City.
Es verdad que algunas investigaciones se toman mucho tiempo y cuestan demasiado, pero eso no significa que todas las investigaciones de causa raíz requieren tomar mucho tiempo y costar mucho dinero.
El análisis de causa raíz debe escalarse al tamaño del problema y al riesgo de accidentes futuros con causas similares. Poco riesgo = investigación pequeña. Si el riesgo es grande entonces tomen más tiempo y más esfuerzo para ponerles puntos a todas las “i” y cruzar todas las “t”.
La parte difícil de responder apropiadamente es proyectar el riesgo que tiene el problema antes que se inicie la investigación. Problemas muy simples pueden tener causas complejas que pudieran causar, en diferentes circunstancias, un accidente grande.
Escalamiento de una Investigación
El sistema TapRooT® es suficientemente flexible para acomodarse a cualquier tamaño de riesgo. Se usan algunas técnicas para todas las investigaciones. Otras solamente se usan en investigaciones mayores.
Para accidentes simples un solo investigador dibuja una SnapCharT® sencilla de la secuencia de eventos, identifica uno, dos o tres Factores Causales fáciles de detectar, pudiendo trabajar con aquellos involucrados en un par de entrevistas. Una a dos horas en total.
El dibujar una SnapCharT® se requiere porque hay que entender qué fue lo que pasó antes de encontrar por qué paso.
El paso siguiente, toma los Factores Causales a través del Árbol de Causa Raíz (posiblemente una hora de trabajo), y luego una hora más para desarrollar acciones correctivas SMARTER basados en el Manual de Acciones Correctivas® y para documentarlo de alguna manera, de forma de estar listos para revisión y aprobación (aproximadamente ½ día de trabajo).
¿Y qué pasa si la administración dice que medio día es demasiado tiempo? ¿Por qué no preguntas 5 veces qué pasó y sugieren una acción correctiva?
Claro que se puede hacer, pero no es hacer análisis de causa raíz.
The following is an excerpt of a Safety Video that I watched years ago as an aircraft mechanic in the Air Force.
It reminds me of the aircraft specific hazard training that I received:
1. Avoid Bleed Air Boundary Zones… places where hot engine bleed air was directed to improve air flow over moving wing surfaces.
2. Avoid Moving Flight Surfaces… Flaps, Rudder and such
3. Avoid egress explosive exit points…. and the egress seats themselves if not pinned.
4. Be aware of possible hydraulic leaks in pressured systems…. 3,000 psi in many cases
5. Avoid landing gear being released when on jacks…. whether under power or quick released
6. And of course avoid engine intake and exhaust zones…. yes I have had to pull another airman back that was too curious.
Now I review incidents resulting from “line fire issues” and have to ask myself, “if I were just told to avoid line of fire issues on aircraft would that have sufficed?” No, neither should it be as a policy or corrective action.
Ever thought about volunteering to be a test subject for medicine … would you be concerned if you were in phase 1 of a new drug trial?
Listen to this podcast where the standard practice become a practice because no one had become very ill until this study. Each reinforcing non-injury becomes the reinforcement that this must be a good process.
Injury Type : Severed finger
Core Activity : Public school district
Location : Vancouver Island
ID Number : 2010110750411
Date of Incident : 2010-Jun
While washing the floor in a doorway, a worker slipped on the wet floor and fell. The worker was wearing a ring, which caught on the striker plate of the door, severing the worker’s finger.
For 12 years while enlisted as an Aircraft Mechanic in the United States Air Force, we were taught and had to practice “No Jewelry while working certain tasks.” Granted certain jewelry was allowed for office type work but not for what I had to do.
Then I left the service and saw that not many were practicing this concept. Now don’t get me wrong, many of the other safe practices were there but not for hand and finger jewelry. I would hear when I asked why, “the Air Force had too many rules; how did you have get work done?”
I wonder if the employee listed above is thinking that today?
Lesson of the day: Share and utilize good practices; do not wait until something bad happens.
D. All of the Above
E. No one wanted to watch the game…. (just kidding: typed by a Falcons fan)
F. None of the Above
“The inflatable roof of the Metrodome collapsed Sunday after a snowstorm that dumped 17 inches (43 cms) on Minneapolis. No one was hurt, but the roof failure sent the NFL scrambling to find a new venue for the Vikings’ game against the New York Giants.” (more…)
Okay. I often talk about the Doctors of Tomorrow will be the Pilots of Today. With the increase use of Aviation and Nuclear tools such as Crew Resource Management and the use of Checklists for Pre-Op or Post-OP, we are seeing changes in Medical Error every day. But then I see someone trying to take a short cut…..
“He seemed like Superman, able to guide jumbo jets through perilous skies and tiny tubes through blocked arteries. As a cardiologist and United Airlines captain, William Hamman taught doctors and pilots ways to keep hearts and planes from crashing.”
“His pilot qualifications do not appear to be in question — he holds the highest type of license a pilot can have, a Federal Aviation Administration spokeswoman said. However, United grounded him in August after his medical and doctoral degrees evaporated like contrails of the jets he flew.”
…and then here is one of the first responses after finding out, “Even after learning of Hamman’s deception, the American Medical Association was going to let him lead a seminar that had been in the works, altering his biography and switching his title from “Dr.” to “Captain” on course materials. It was canceled after top officials found out.”
“He really didn’t need to be a physician to do what he was doing. He could have been successful without titling himself,” said Weaver of the cardiology college. “He made a very serious mistake.”
Lesson learned: You can help people be successful with Truth. Something we do everyday with TapRooT® Root Cause Analysis in all industries.
What a great group of passionate safety and operation employees to work with this December in New Jersey. With Union Teamsters and Company Employees working together as one team, our instructors Michele Lindsay and Chris Vallee were able to hear great questions and answers from all.
Here are some excerpts in case the original article is taken down …
“A plane’s dramatic nosedive was caused by a co-pilot accidentally pushing a button while adjusting his seat, a report by India’s Directorate General of Civil Aviation stated on Monday.”
“But the captain managed to save the plane by taking the controls back – only after using an emergency code to enter the cockpit again, since his co-pilot panicked and was unable to let him back in.”
“The clumsy 25-year-old co-pilot, working aboard an Air India Express flight from Dubai to Pune in India on 26 May, had ‘inadvertently [pressed] the control column forward’, according to the official report into the incident.”
“The report also says that the co-pilot “probably had no clue how to tackle this kind of emergency”, adding: ‘Appropriate action shall be taken against the involved crew’.”
Do you think that Air India Express missed opportunities to improve?
Was a “clumsy co-pilot” the root cause of this incident?
Are other 737′s configured the same way so that it is easy to push the wrong button when adjusting your seat?
Has security been compromised since the fact that there is an “emergency code” to enter the cockpit became common knowledge as part of the reporting on this incident?
What training should a co-pilot have before they are qualified to fly?
Is taking action against the crew really going to solve this problem?
Should the press look harder at accident reports and point out the nonsense of blaming those involved rather than fixing system problems?
Look closely into India until you get to Mumbai. What do you see?
A 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training Course Open to all companies; similar to the New Delhi Onsite Course shown below held for BW Fleet Management.
The benefits:
1. You get the benefit of our course in India without needing 10 of your people trained at the same time.
2. You do not have to fly your India based employees to another country to be trained.
3. If you are one of our international customers, you do not have send one of your trained investigators to India to complete an Investigation for defects, incidents or sentinel events.
4. Because the students will receive individual software to document their findings, you will receive a consistent report.
Register today to make sure your employee does not lose a seat in the course.
(Editor’s Note: This is reprinted with permission from our partners in the UK, Matrix Risk Control.)
We doubt whether you will have missed the HMS Astute incident off Skye where the Royal Navy’s newest, largest and “stealthiest” submarine grounded in shallow waters. A huge embarrassment for the Royal Navy and one that should be easily avoided considering the area is well used and marked both on charts and with red and green buoys. There will be an investigation and we may hear of the cause which will most likely be a series of “system failures” that may include inexperience, lack of training, change of watch, lack of equipment/resources or even technical and/or human error. It is surprising that an incident like this can happen (and it is not the first) considering all the training the military undertake. Could a series of system failures cause a major incident in your line of business?
Recently the BBC Watchdog programme covered the story of an Airparks customer whose car had been hired out after he left it with them whilst he went on holiday! Airparks advised that a serious of “highly unusual system failures” led to the car being mistakenly identified as a hire car. We understand the “highly unusual” included them letting a section of their parking out to a hire car agency – perhaps unusual but as they knew about the hire car company using their car park, they should have identified the risk and adjusted their system to ensure it did not happen.
System Failures – avoidable or an acceptable risk?
Having procedures and processes in place is the first step in ensuring things run smoothly but how often should you “test” your procedures, how robust are they and how do the Directing Minds know they are being followed? Exercise and test, record and react is the simplest and most effective manner to reduce the risk of your systems failing.
Matrix Risk Control can help you Exercise and Test your systems “Just In Case” there is a chance of failure. Contact us on +44 (0) 7793 846567 to see how we can help.
The government says there were four planes that sat on the tarmac for more than three hours in September.
That’s up from one in August, but down from six in September a year ago.
and now the rest of the story:
Airlines canceled more flights in September than they did a year ago, but slightly less than they did in August when the peak summer travel season was winding down.
Overall, flights run by the nation’s biggest airlines were also delayed slightly more often in September from a year earlier. But airlines did a better job of getting passengers to their destinations on time than in August.
Did they really do a better job if they canceled more flights?
What would the people in our recent Pre-Summit Advanced Trending Techniques course say? (more…)
“International air safety officials are investigating what caused the engine failure that ripped metal on the left wing, littered debris on the ground far below and prompted the most serious safety scare yet on the world’s largest and newest airliner.”
and the article continues on to say,
“But Qantas CEO Alan Joyce told a news conference that the national carrier believed the plane’s Rolls-Royce-made engine was at fault, not the level of maintenance to the plane.”
“This is an engine issue and the engines have been maintained by Rolls-Royce since they were installed on the aircraft,” Joyce told a news conference in Sydney. “We believe this is probably most likely a material failure or some type of design issue. We don’t believe this is related to maintenance in any way.”
So the protective-redirection-I don’t want to get blamed-we don’t have facts yet policy is now in effect!
Wonder what this will do to the data collection phase…… (more…)
This question was posted on our TapRooT® LinkedIn Group and it be great for all with questions and examples to comment.
I have a question that I hope you can help a client with. Do you know of any organizations/companies who have a great lessons learned process, including communication of lessons learned?
The client is developing a formal process titled “Lessons Learned Communication”. This will become part of the Safety Management System (SMS) at the Business Line level of Exploration and Producing (E&P).
This document will drive all of the lessons learned and related communication that results from serious and potentially serious incidents within E&P. The client would like to get a few good inputs rather than creating something completely from scratch.
Please post online for all to learn. Also, send me your contact info offline or publicly and I will share it with the client.
We were invited once again to teach a 2 Plus 3 Day TapRooT® Root Cause Analysis Course in Rocanville, Canada. Pictured above are the Team Leaders/Facilitators that stayed for the remaining 3 Days of Advanced Analysis training after attending the 2-Day portion with key frontline investigators.
What makes PotashCorp a World Class Leader in Safety can be seen by who actually attended this course….
…AMC
…AMEC
…Bird Construction
…PotashCorp (operations and Safety)
Look at the pictures below to understand why this is so vital. Last year when I taught the course (With AMEC and PotashCorp), many of these buildings in construction were not there.
If interested in reducing injuries, project delays or improving contractor, sub-contractor and client relations contact us at System Improvements, Inc. at info@taproot.com or chris@taproot.com. We are just a call away at 865.539.2139.
Thank you PotashCorp, AMC, AMEC and Bird Construction for your continued drive to produce a safe and effective environment.
