Category: Root Causes

Budapest Conference on EHS

September 29th, 2012 by

Mark Paradies and Linda Unger attended the Budapest Conference on EHS in Emerging Markets.

Mark gave a talk: Solving Root Cause Analysis Problems by Using Advanced Root Cause Analysis. Here’s some pictures of Mark Speaking …

Budapest_Conference_09292012

Budapest_Conference_b_09292012

Budapest_Conference_c_09292012

Linda talked to prospective TapRooT® Root Cause Analysis System users and explained how they could learn about and implement TapRooT® at their sites across Europe.

Budapest_Conference_d_09292012

 

Root Cause Tip: Root Cause Tree Q&A

July 18th, 2012 by

TapRooT® Instructor, Michele Lindsay, answers a great question from one of the attendees of the 2-day TapRooT® Root Cause Analysis training course held at the 2012 Global TapRooT® Summit in Las Vegas, Nevada.

********************

Question from attendee:

I am presently using the techniques I learned to conduct my own RCA of the same incident we presented during the class and I had a question:

After grouping the conditions under each causal factor and working your way through the RCA tree on each causal factor, are you to only use the conditions grouped under that particular causal factor or are you allowed to use a condition that was grouped under a different causal factor?

My understanding is that you are to only use the conditions grouped under that specific causal factor and not reach out to other conditions from other “groups” as supporting evidence for the RCA.  I found during the class that the practice of using other conditions from other groups as supporting evidence to say either “yes” or “no” was occurring very often and that puzzled/troubled me.  In my opinion, if you were allowed to reach for other conditions not grouped under the causal factor in question, this negates the purpose of grouping conditions in the first place.  Am I wrong in my understanding of the purpose for grouping conditions?

Michele’s answer:

You are quite right that once conditions are grouped and Causal Factors identified, you really should stay within your “grouping” as you work through the RCA process.

Exceptions:
– if the condition was put in under one Causal Factor, but applies better to the another, consider moving the condition (the “so What” test helps with this) or put it both places if it applies in both. Theoretically, if it supports a Root Cause, the condition should be associated with that Causal Factor.

– if one is wandering out of a Causal Factor and “poaching” conditions to support the current Causal Factor being analyzed, when you read the question from the dictionary that you want to answer “yes” to, then add “and that’s why … (then insert Causal Factor here). If the answer is “no,” you are wandering off, if “yes,” move the condition over, if “no,” then don’t select the Root Cause.

If a team does wander off and poach conditions from another Causal Factor, you may see duplicated Root Cause, for the same reason (answered “yes” to the same question) in 2 RCA for different Causal Factors. During your sanity check at end of the process you should catch it.

So the purist in me agrees with your conclusion, but the tool is robust enough to handle good use and weaker use.

********************

Thanks for sending in the question and answer to share with others, Michele!

Monday Accident and Lessons Learned: When High Reliability Systems Fail

June 25th, 2012 by

What if you had a system with two regular power supplies, two back-up power supplies (diesels), and a battery back up with a separate diesel to keep it charged?

Wow!  This should be highly reliable right?

Read about how this system failed here:

feed://status.aws.amazon.com/rss/ec2-us-east-1.rss

Now here’s the question …

What did they miss in their “root cause analysis”?

I think they had great troubleshooting.

They even had actions to address generic problems.

But I don’t think they found the root causes of the “cloud failure” incident.

What do you think? Leave your comments here…

Root Cause Network Newsletter: Major Accident Types that Produce Fatalities on the Job

June 21st, 2012 by

We recently distributed the Root Cause Network Newsletter which included many interesting hot topics:

Major Accident Types that Produce Fatalities on the Job

Errors:  Looking for Blame or Opportunities?

Human Factors

Energy Safeguards Target

Fastest Growing LinkedIn Root Cause Analysis Group

Can We Agree on a Worldwide Definition of “Root Cause”?

and more!

View and download a copy of the June Root Cause Network Newsletter.

Why Your Root Cause Analysis Report May Have Been Rejected

June 18th, 2012 by

There is an interesting article in the June 2012 edition of Maintenance Technology about Kübler-Ross concepts and management response to root cause analysis reports.  You may be familiar with Kübler-Ross’s book, “On Death and Dying,” where she introduced the “Five Stages of Grief” concept.  Randall Noon, the author of the Maintenance Technology article, compared these stages to the stages a committee reviewing a root cause analysis report moves through when a serious problem is uncovered. Noon writes:

“The committee typically includes at least some managers whose departments were involved in the adverse event.  Some of them may even have made decisions that set up conditions for the event, exacerbated its consequences or directly caused it.  Some might have had an opportunity to prevent the event, but didn’t act.  Thus, the committee isn’t impartial:  It’s like a patient with a stake in his/her doctor’s diagnosis of a serious condition.”

Read the article:  Kübler-Ross And Root-Cause Evaluations

Could the initial rejection of a root cause analysis report mean that the committee just needs more time to assimilate the findings on their own terms?  Tell us what you think.

 

Mark Paradies Spoke at the IIE Conference About the “7 Secrets of Root Cause Analysis” this Week

May 25th, 2012 by

P1030850-1

Mark Paradies spoke at the IIE Conference about the “7 Secrets of Root Cause Analysis” this week. The Industrial Engineers present were very interested in going beyond common problem solving tools like 5-Whys and Cause and Effect and asked some great questions.

To see the paper the talk is based on, CLICK HERE.

Take a Survey and Rate Your Root Cause Analysis Efforts

May 4th, 2012 by

Is your Root Cause Analysis program doing the job?  Ever wondered how you stack up to others?  Go online now and start the process of benchmarking your program.

The Good, the Bad, the Ugly:  a comparative analysis from the creators of TapRooT®.

Where does your Root Cause Analysis program rank?  Let us measure your program against hundreds of others.  You’ll see how you compare to others in the following areas:

Measurement systems
Trending techniques
Corrective action effectiveness
Staff knowledge of root cause analysis and performance techniques and more …

Get your FREE comparative analysis now. It only takes minutes to start the process.

Just access our special website to start the process to benchmark your program against others. It’s fast. It’s free. And it’s a valuable way to validate your program or identify areas for improvements.

Take the survey at this link …

http://www.rcacomparison.com/

Monday Accident & Lessons Learned: If You Make a Hole in the Deck, Someone Will Fall Through It!

April 30th, 2012 by

Screen Shot 2012-04-24 At 4.42.03 Pm

Here is an accident report from the BSEE (Bureau of Safety & Environmental Enforcement of the US Department of the Interior):

http://bsee.gov/uploadedFiles/BSEE/Enforcement/Accidents_and_Incidents/Panel_Investigation_Reports/BSEE%202012-01.pdf
How many times have you seen similar accidents with unprotected holes on construction sites, oil platforms, or in other locations with work that makes “temporary” openings?

It would seem that anyone supervising work should know better.

Yet the report says that the company blamed the roustabout who fell to his death through the hole because he was, “…distracted by concern for a family issue at home.”

The report says:

This same story that the accident was caused by a lack of concentration by a distracted Roustabout, was repeated in the initial report to BOEMRE, in interviews by Supervisor, Company Man, and by management of Alliance, and was written into the accident investigation report by Contractor and Operator. The only reason given in statements for this conclusion was that the Roustabout had spoken of it at breakfast and had tried to rearrange his shift to accommodate the family issue.

OK TapRooT® Users, what do you think. Is “lack of concentration” a root cause? Did the company do a thorough investigation? Could they tell everyone to “be more careful” and resume work as usual? Was the BSEE right to question the adequacy of the contractor and the operator?

Read the report and let me know what you think.

Monday Accident & Lessons Learned: Is Fatigue an Issue?

April 2nd, 2012 by

 Professional Blog Wp-Content Uploads 2011 01 Sleepy-Person-Coffee-Cups

I was reviewing an industry study on the causes of accidents and noticed that fatigue was nowhere on their list. Since other studies where people actually observed performance show that fatigue is a major issue in real world accidents, I wondered why fatigue did not show up on the industry sponsored list.

The easy answer is … If you don’t ASK about fatigue and look into fatigue as a potential cause, you will never find it.

That reminded me of an investigation into a barge crash. The operator couldn’t find a reason why the First Mate had gone “brain dead” and made a totally inappropriate approach to a bend in the river. It was very important to be lined up correctly because the river was running near flood stage and there was little room for error. But once he was lined up wrong, he had little choice. He tried to “power through” the turn and ended up crashing the barges into a bridge after the turn.

One of the questions I asked the investigator was, “Did you consider fatigue?” (The accident happened at about 5 AM and the tug and barges were on the second day of the trip.)

The reply was interesting … the investigator said:

“He was working a standard schedule.”

That seemed to be enough for him to dismiss fatigue as a cause.

I asked, “What is a standard schedule.” The answer, “6 on and 6 off.”

So the first mate would normally work from midnight to 6 AM, have six hours “off” to rest or work, then be back piloting from noon to 6 PM, get off, eat dinner, and go to bed and get back up to work from midnight to 6 AM again.

I asked if he knew if the First Mate had been well rested before starting the journey. The answer? “No, I didn’t ask about that.”

Even after this questioning, the investigator just couldn’t see that fatigue could be a potential cause that should be looked into. After all, the schedule was a standard industry practice.

That’s one of the reasons that I started adding sessions about fatigue to the TapRooT® Summit.

It’s also one of the reasons that we collaborated with Circadian Technologies to produce a tool for investigators to assess fatigue with a proved diagnostic tool call FACTS (Fatigue Accident/Incident Causation Testing System). (Click on the link to subscribe to the on-line system for free.)

It’s also why I recommend Circadian Technologies seminars on fatigue risk management and shift work scheduling.

If you are interested about learning more about fatigue, there are two seminars coming up that you should consider. The first is “Designing and Implementing an Effective Fatigue Risk Management System” and will be held in Salt Lake City on May 23-24. For more information, see:

http://www.circadianstore.com/catalog/frms-seminar.html

The second is “Successfully Expanding from 5- to 7-Day Continuous Operation” and will be held in Chicago, IL on June 13-14. For more information, see:

http://www.circadianstore.com/catalog/5-to-7-shiftwork-expansion-seminar.html

We should not overlook fatigue as a potential cause. TapRooT® includes a question about fatigue as one of the 15 questions in the Human Performance Troubleshooting Guide on the front of the Root Cause Tree®. So you should consider fatigue for every human error. Ask about fatigue and perform an assessment using FACTS if there seems to be a potential for a fatigue issue. Don’t accept “standard industry practice” as ruling out fatigue as an issue.

Day one of Nalco’s interstate 2-Day TapRooT® Root Cause Analysis Course

March 8th, 2012 by

Brian Dolin, teaching below, and I had the great opportunity to work with Nalco employees from different states here in Illinois this week.

Why Are We Failing To Prevent Sentinel Events? By Mark Paradies

February 16th, 2012 by

Med

DEATH TOLL

What kills more people in the US than industrial accidents, highway accidents, and airline accidents combined?

Mistakes in hospitals.

The technical term for these mistakes is “Sentinel Events.”

Estimates of the deaths caused vary. We use estimates because there are no accurate statistics on the total number of deaths caused by mistakes in hospitals. There is no national reporting requirement.

Even though there is no national reporting requirement, studies show that despite over a decade of effort to stop sentinel events, no progress is being made. Some studies actually show the problem getting worse. And this problem isn’t unique

WHY NO IMPROVEMENT

Why can’t we improve? There are a number of factors that make improvement difficult:

1. Healthcare Complexity

2. Poor Root Cause Analysis (RCA)

3. Inadequate Corrective Actions

4. Not Enough Management Attention

We will review all of these factors and what we can do about them in the following sections.

HEALTHCARE COMPLEXITY

Medical practice keeps getting more complex. More complex technology. More drugs with more interactions. More pressure to work faster and be more efficient. The result? More chances to make errors with catastrophic consequences. At the same time, downsizing means less staff to catch errors.

Healthcare complexity calls for increased, proactive application of system reliability and human factors solutions to improve health¬care delivery.  Intelligent, resilient design can make complex systems reliable. Plus, staffing needs to be assessed to ensure adequate coverage to apply error-catching activities.

POOR ROOT CAUSE ANALYSIS

After a decade of using RCA to analyze sentinel events, the lack of progress indicates a failure of healthcare root cause analysis.

What’s wrong? A majority of healthcare facilities use inadequate RCA systems including fishbone diagrams, 5-Whys, and healthcare derived root cause checklists. These “simple” techniques are inadequate to analyze complex healthcare sentinel events.

Not only are the RCA systems inadequate, the RCA training is also inadequate. People are assigned to investigate healthcare sentinel events with little or no training. They are lucky to attend a free one to eight hour session provided at a professional society meeting or sponsored by an insurance provider.

But healthcare investigators face another factor that makes root cause analysis even more difficult: BLAME. More than your everyday blame that comes with every accident. Medical malpractice seems designed to make people less open – less willing to cooperate wholeheartedly with investigators.

Furthermore, doctors who are independent contractors are naturally suspicious of investigators who seem to question their judgment and put their credentials at risk. Is it any wonder that we haven’t made progress?

Despite some of the factors that are difficult to address, picking an advanced root cause analysis system and getting people trained shouldn’t be hard. After all, there is TapRooT®!

The TapRooT® System was designed to be used for simple and complex investigations. It has been applied successfully in healthcare settings and has improved performance of complex systems. The 2-Day and 5-Day TapRooT® Courses have been customized for on-site training of healthcare investigators to help them with demanding investigations. Problems solved!

POOR CORRECTIVE ACTIONS

Inadequate root cause analysis is just the start. Typically, we see the weakest corrective actions applied to prevent repeat sentinel events.

Those familiar with the terminology “hierarchy of controls” applied in industrial and process safety may know what I am pointing out. Healthcare corrective actions often include the application of new standards that depend on human reliability. When these fail, investigators recommend some of the “re” corrective actions, including: re-train, re-mind, and re-emphasize (discipline).

But these are the weakest possible corrective actions (see pages 127 -129 in your 2008 TapRooT® Book.) More effective corrective actions include another type of “re” corrective action. Removing the hazard or the target. Or, re-engineering the process to improve system reliability and decrease human error without adding additional tasks for people to cope with.

These types of corrective actions and more are the result of a TapRooT® investigation when investigators apply the suggestions in the Corrective Action Helper® and apply Safeguards Analysis as part of the development of their solutions.

MANAGEMENT ATTENTION

One might say that the cause of all the previous problems is inadequate management attention to performance improvement at healthcare facilities. Part of this inattention can probably be attributed to the fact that most healthcare administrators aren’t trained in advanced performance improvement techniques. Even the few who have had Six Sigma training don’t know about advanced root cause analysis and, therefore, don’t know about the action they could take to make performance improvement happen.

Plus, hospital administrators need to become more involved in the analysis, review, and approval of sentinel event investigations. Involvement can bring them face-to-face with the challenges people are experiencing in the field. Trained managers reviewing a SnapCharT® can see beyond blame to real action to improve performance. They can see their contribution to errors that come from understaffing and fatigue. They can become a knowledgeable part of the team fighting sentinel events.

SIMPLE PLAN TO IMPROVE

Each day, hundreds of lives are lost because we haven’t won the battle to defeat sentinel events. Don’t wait for the entire healthcare industry to wake up to the problems and solutions. Don’t wait for regulatory requirements to force your facility into action. Start today with the tools that are at hand.

1. Bring the message to management. Get them involved. They should feel that EVERY sentinel event at their facility is a personal failure to address the causes!

2. Adopt an advanced root cause analysis system – TapRooT® – including the latest root cause analysis software and database to help you learn from small incidents to prevent major sentinel events.

3. Get the training that your facility needs in root cause analysis. This includes training for hospital administrators, staff, and your performance improvement experts.

Start with a customized 2-Day TapRooT® Course for senior management. Follow that with a 2-Day TapRooT® Course for those who are frequently involved in sentinel event investigations and a 5-Day TapRooT® Course for those who facilitate sentinel event investigations.

4. Once you complete steps 1-3, you are ready to start continuous improvement efforts. Start by attending the TapRooT® Summit healthcare track to find out what other leaders in the field of healthcare are doing to continue improvement efforts.

Don’t wait. People are dying waiting for improvement to occur. Start today!

(Reprinted by permission from the February Root Cause Network™ Newsletter, Copyright © February, 2012)

Great Human Factors: Wrong Tools, Bad Access by Design, Per “Ingenuity” or All of the Above?

January 19th, 2012 by

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.

cone-wrench-mod

DSC08955

Oil Cooler Line Wrench #2 009 (Medium)

Monday Accident & Lessons Learned: Equipment Guard NI

December 5th, 2011 by

Img 1484

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.

Monday Accident & Lessons Learned: Equipment Guard NI

November 28th, 2011 by

Img 1484

The picture above is from a airport jet bridge in Frankfurt, Germany.

If yopu look at the ground level you can just make out the wheels that cary 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.

Root Cause Analysis Tip: Keep Your Facility Safe with the "Dread Factor"

November 16th, 2011 by

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.

To see the full 25-page report click here.

Improve Training and Increase Risk Perception

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®.

Photo Courtesy of:

Monday Accident & Lessons Learned: NTSB Investigation of the Disney Monorail Accident

November 14th, 2011 by

Screen Shot 2011-11-01 At 10.33.34 Am

Here a quote from a report by WESH Orlando:

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:

http://www.orlandosentinel.com/the-daily-disney/os-disney-monorail-crash-report-20111031,0,4139169.story

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?

Economics and Root Cause Analysis

September 29th, 2011 by

 Multimedia Archive 01661 Becker 1661979C

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:

www.taproot.com/courses.

Orlando 5-Day TapRooT® Root Cause Analysis Course Class Pictures

August 5th, 2011 by

SAM_0343.JPGSAM_0344.JPG

SAM_0345.JPGSAM_0346.JPG

SAM_0347.JPGSAM_0348.JPGSAM_0349.JPG

SAM_0350.JPGSAM_0352.JPGSAM_0358.JPG

After an intensive but fun two days of work invested already in the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training (as seen in the photos above), the students needed a duck break at the Peabody Hotel in Orlando.

SAM_0354.JPG201108052108SAM_0355.JPG

Solar Blast Hits Earth – Root Cause … Natural Disaster?

August 5th, 2011 by

Here’s the story about the solar blast that could cause grid, communications, and GPS problems:

http://online.wsj.com/article/SB10001424053111903454504576490641577134256.html?mod=rss_US_News

Truck spills 14 million bees on Idaho highway… how would you have responded?… Would you have planned for it?

July 13th, 2011 by

article-2013995-0CFBB8DB00000578-755_468x392
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.

http://news.yahoo.com/truck-spills-14-million-bees-idaho-highway-142147287.html

http://www.dailymail.co.uk/news/article-2013995/Truck-spills-14-MILLION-bees-honey-Idaho-road-crash.html

Calgary 2-Day TapRooT® Public Course… EVENT SOLD OUT

July 12th, 2011 by

Day One of our 2-Day TapRooT® Incident Investigation and Root Cause Analysis in Calgary, Canada.

SAM_0331.JPG
SAM_0329.JPG
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.

SAM_0327.JPG SAM_0326.JPG
SAM_0325.JPGSAM_0324.JPG

Monday Accident Lessons and Learned: A review of the Mangalore Air India Crash.. when do you reopen an investigation?

July 11th, 2011 by

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?

For More Reading:

Indian Aviation News 6/14/11

Indian Aviation News 6/08/11

Connect with Us

Filter News

Search News

Authors

Barb PhillipsBarb Phillips
Editorial Director
Chris ValleeChris Vallee
Human Factors & Six Sigma
Dan VerlindeDan Verlinde
Information Technology
Dave JanneyDave Janney
Safety & Quality
Ed SkompskiEd Skompski
Medical Issues
Ken ReedKen Reed
Equifactor®
Linda UngerLinda Unger
Vice President
Mark ParadiesMark Paradies
Creator of TapRooT®
Megan CraigMegan Craig
Media Specialist
Steve RaycraftSteve Raycraft
Technical Support

Success Stories

TapRooT® is a key part of our safety improvement program that has helped us stop injuries and save lives.

Canyon Fuel Company

In March of 1994, two of our investigators were sent to the TapRooT 5-day Incident Investigator Team…

Fluor Fernald, Inc.
Contact Us