Category: Root Causes
By Chris Vallee
I was an aircraft mechanic in USAF when this incident occurred. The aftermath of the F-15 Crash and Pilot Fatality continued with an Airman’s suicide was loss to many.
While, I knew the basics, I just recently found a follow up report and wanted to share it. The information is taken directly from the article as is without my paraphrase. Here is the website.
An Air Force review board has partly cleared the name of an F-15 mechanic who committed suicide in 1996 rather than face a court-martial for a fatal repair error.
Evidence showed that TSgt. XXXXXX did not perform the botched control rod maintenance at issue, although he did check the work and found nothing wrong.
In addition, several previous incidents in which other mechanics made the same mistakes should have alerted the Air Force to a potential problem, according to the board.
“We did not think XXXX was totally free of all responsibility,” said Lee Baseman, chairman of the correction board. “But it was our view that he was unduly carrying the burden for a series of missteps that went back at least 10 years.”
In May 1995, XXXX and TSgt. YYYYYY were carrying out maintenance on an F-15C based at Spangdahlem AB, Germany, when YYYYY accidentally crossed flight control rods while reinstalling them. XXXX did not catch the miscue, which made the airplane impossible to control in the air. It subsequently crashed, killing Maj. Donald G. Lowry Jr. (Great GUY!!)
Air Force authorities charged XXXX and YYYYY with dereliction of duty and negligent homicide. XXXXX shot himself in October 1996 during a break in court proceedings. Commanding officers then accepted YYYYY request for administrative separation, on grounds that the interests of the service would be best served by bringing the tragic case to a swift conclusion.
Similar crossed-rod cases occurred at least twice before the Spangdahlem crash, noted the review board-once in 1986 and again in 1991. But in both instances the problem was caught before takeoff.
In its conclusions, the board stated, “After the Black Hawk shootdown [in 1994], the demand for accountability for this accident may have been pursued with such zeal as to leave fairness and equity behind. The fatal crash was a tragedy waiting to happen, yet the decedent was singled out to pay for an accident that could have been prevented anywhere along the ‘chain of events’ had any of the numerous individuals involved made different decisions.
“Most disturbing was the way the Air Force leadership allowed this case to be handled. The Air Force’s representatives resisted the inclusion of potentially exculpatory evidence from the review and report and managed to have a good deal of it excluded from consideration in the pending trial.”
Following the death of Lowry, the Air Force took steps to prevent such a mix-up from happening again. The control rods are now color-coded to ensure proper installation, and the maintenance technical manual warns against the mistake. All flight control systems must now be checked any time the control rods undergo maintenance. ” “
Ref: Journal of the Air Force Association, June 1998 Vol. 81, No.5, Peter Grier
I know, it is too early for Friday’s Joke of the Day, but I could not help it. I saw this posted recently and had to share.
As you are laughing, look into your tool cabinet and tell me that you do not have these 2 items in it.
Now if you want to know how to troubleshoot equipment the right way to find the right what’s and why’s and want an Individual TapRooT® Software License (comes with the course), then join us at one of our Equifactor® courses.
Here is the current schedule: http://www.taproot.com/store/3-Day-Courses/
I’ll bring my WD-40 and Duct Tape for the classroom equipment.
What are the risks of setting a circuit breaker without knowing why it opened?
I just saw this local news article about a father teaching his daughter about the circuit breaker panel in their house after a ceiling fan stopped working. End result….. House on fire. Read more here.
With eighteen years in aviation and having worked on the C-141 Aircraft, this incident brought to mind the wrong pump replaced and reseting the circuit breaker during testing explosion. Read more here.
There are additional ways to gain equipment troubleshooting experience without starting a fire. The easiest way is to attend one of our upcoming Equifactor® Course coming up in your local area. See the schedule here: http://www.taproot.com/store/3-Day-Courses/
With community protests after losing school aged loved ones, the Indian Government is closing in on suspected causes to include suspects. But is this a sign of Systemic Food Quality Control or as TapRooT® calls them “Generic Causes”? Will the nature of the investigations detour looking for Generic Causes by looking for blame instead?
Read below and ask, how would this be investigated or analyzed if it were in your hometown? What would be the response of the lunch cafeterias and Food on Wheels programs for the elderly and sick?
In a months time…..
23 students in the southwestern coastal state of Goa were treated at a hospital after they got sick at lunch
23 students died and 25 people were hospitalized from food poisoning after a school lunch in northern India’s Bihar state
Schoolchildren falling sick after drinking contaminated water from hand pumps continued for the third consecutive day on Saturday with at least 35 more students taken ill in different parts of Bihar.
Arrests made in two of incidents with possible cause being insecticide poisoning; the water pump incident possibly criminal intent and the Bahir lunch room incident due to possible negligence. The Goa incident not so clear in details yet.
Due to fear, large lunch producers temporarily shut down their lunch kitchens resulting in children not getting their mandated free lunches during school.
See more at this link:
Whether in the medical device, pharmaceutical or the food manufacturing industry, a company usually has had many violation corrective action chances before they get a consent decree of permanent injunction. At this point a third party reviews current deviations and often identifies a weak or non-existent root cause analysis program.
Now don’t get me wrong, this is often when our TapRooT® Root Cause Process gets recommended as a possible option and we gain a new client. However, I would prefer working with an FDA regulated company to develop effective corrective actions before they get in trouble. Or at least when they get their first FDA Finding.
Often FDA findings are found by an external audit. To remain independent, the auditor turns over the findings through proper protocol and the company involved must provide proof that the causes were found and that the corrective action is effective. So if this protocol is followed, how did we get to a permanent injunction? Can the repeat findings be purely an Enforcement Needs Improvement Root Cause for policies not followed?
I suggest Enforcement needs improvement is not the only problem. To find out what your company might be missing in your RCA process. Find a course close to you and send one of your key quality or safety problem facilitators. Here is our upcoming courses link: http://www.taproot.com/store/Courses/
To get you thinking about possible gaps in your root cause analysis program, view this presentation given at our 2012 TapRooT® Summit. http://www.taproot.com/content/wp-content/uploads/2012/02/RileyandGorman.pdf
Then check out the quality track in the upcoming 2014 Summit in April. http://www.taproot.com/products-services/summit
The next time someone says they used 5-Whys to investigate an accident, just thing …
5-Whys = Root Cause Analysis Malpractice
Because 5-Whys is almost always root cause analysis malpractice. If you don’t believe it, assign someone who is good at 5-Whys to analyze a problem and someone who is good at using TapRooT® to analyze the same problem. Look at the results and you will see what I’m talking about.
That’s the lesson learned for today.
Everyone is interested in research statistics but the following infographic asserts that some scientists may make up the data, distort the data … even cook the data!
What would you guess is the root cause of bad science? The infographic suggests that one may be that the scientist changes results due to pressure from a funding source.
Monday Accident & Lessons Learned: Root Cause Analysis of San Onofre Nuclear Generating Station, Unit 2 & 3 Replacement Steam GeneratorsApril 1st, 2013 by Mark Paradies
This certainly sounds like an expensive incident and you would think they would use a state of the art root cause analysis system. Instead, they used cause-and-effect. See the report and see if you agree that the “root causes” of the incident are:
I think the lessons learned is to get a better root cause analysis tool!
Here’s the Meridian-Webster On-line Dictionary definition of “behavior”:
1. a : the manner of conducting oneself
b : anything that an organism does involving action and response to stimulation
c : the response of an individual, group, or species to its environment
2 : the way in which someone behaves; also : an instance of such behavior
3 : the way in which something functions or operates
Another definition that I think that management has in their heads is a “behavior” is:
“Any action or decision that an employee makes that management,
after the fact, decides was wrong.”
Why do I say that mangement uses this definition? Because I often hear about managers blaming the employee’s bad behavior for an accident.
For example, the employee was hurrying to get a job done and makes a mistake. That’s bad behavior!
What if an employee doesn’t hurry? Well, we yell at them to get going!
And what if they hurry and get the job done without an accident? We reward them for being efficient and a “go-getter.”
Management doesn’t usually see their role in making a “behavior” happen.
Behavior should NEVER be the end of a root cause analysis. Behavior is a fact. Just like a failed engine is a fact when a race car “blows it’s engine.”
Of course, a good root cause analysis should look into the causes for a behavior (a mistake) and uncover the reasons for the mistake and, if applicable, the controls that management has over behavior and how those controls failed when an accident occurred.
A bad decision or a human error that we call a “behavior” isn’t the end of the investigation … it is just the beginning!
TapRooT® helps investigator go beyond the symptoms (the behaviors) and find the root causes that management can fix. Some of the most difficult behaviors to fix are those so ingrained in the organization that people can’t see any other way to work.
For example, the culture of cost saving/cutting at BP was so ingrained, that even after the explosions and deaths at the Texas City Refinery, BP didn’t (couldn’t?) change it’s culture – at least not in the Gulf of Mexico exploration division – before they had the Deepwater Horizon accident. At least that is what I see in the reports and testimony that I’ve reviewed after the accident.
And with smaller incidents, it is even harder to get some managers’ attention and show them how they are shaping behavior. But at least in TapRooT® tries by providing guidance in analyzing human errors that leads to true root causes (not just symptoms).
Want to find out more about TapRooT® and behavior? Attend one of our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Courses. You’ll see how TapRooT® helps you analyze behavior issues in the exercises on the second day of the training. And you will learn much more. For a public 5-Day Course near you see:
Why Do People Have Problems Finding Root Causes? Read this Article – Under Scrutiny – from Quality Progress…February 25th, 2013 by Mark Paradies
Do you have problems finding the root causes of quality problems, safety incidents, or mechanical failures? It could be becuse of the root cause analysis tools you have chosen to use. Some tools have inherent weaknesses that are “built in.”
The article attached below (as first appeared in Quality Progress, the flagship magazine of the quality professional society ASQ), explains why some techniques commonly recommended for root cause analysis (like 5 Whys) will cause problems when applied by people in the field.
(click the link above to download the article)
Once you finished reading about the limitations of 5-Whys and Cause-and-Effect, sign up to learn about the advanced root cause analysis system that was intelligently designed to avoid those problems … TapRooT®.
The best way to keep your Valentine’s Day romantic and fun? Make food safety a priority!
A recent article on StateFoodSafety.com notes that the best restaurant to eat in on Valentine’s Day is a clean one. Here are a few of their food safety tips this Valentine’s Day:
- Take note of the dining area and restrooms. If they do not meet cleanliness standards, it’s probably a good sign that the kitchen is also in need of more than just a light dusting. You might consider eating elsewhere for your own safety.
- Only eat foods that are served to you hot. If the food is served to you at a lukewarm temperature, chances are that it was left sitting for too long and has allowed harmful bacteria to multiply.
- Make sure the staff does not touch your food or the tips of your silverware with their bare hands. It’s probably not a good idea to let them sample your drink either.
- Be wary of meat, eggs, oysters, or other raw foods that are undercooked.
- Wash your hands properly before and after eating.
Photo courtesy of NPR.
Based on client’s request, we have scheduled our ONLY Public India 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training for April 22 – April 26.
For those not familiar with the course, it includes the TapRooT® single user software (unless attendee’s company has a network software license), TapRoot® book, Corrective Action Helper®, Root Cause Dictionary & Laminated Root Cause Tree, Course Workbook.
Course Fee which includes a software individual license for each student is only $2,395 USD. Here is the registration link: Register
Please register 30 days prior to the course if you need a quote first to send to your billing department. Anything within 30 days or less must be paid for during registration. All course seats must be paid for prior to the course to hold the seat and attend the course.
We look forward to seeing our repeat clients and new clients in our only 5-Day public India course for 2013.
With many industries and natural resources located in Trinidad, System Improvements, Inc. teaches many onsite TapRooT® Root Cause Analysis Courses. In fact, I will be teaching a 3-Day TapRooT®/Equifactor® Equipment Troubleshooting & Root Cause Failure Analysis this November with contract instructor, Mark Olson. I will be scheduling another 5 Day Course in Trinidad this the summer of 2013.
We get so busy sometimes in performing root cause analysis facilitations, courses and just plain business, that it is nice to see a reminder about why we want to make all industries safer. Pictured above is Safraz Ali, a student from the Trinidad Course, whom I had the opportunity to meet with his family.
Family, friends and the community are why we love what we do when we get it right!
Valerie Johnson is now certifed to teach the TapRooT® 2-Day Course to the ConocoPhillips Aviation Division. Valerie flew in from Alaska to Houston to get trained and upon return will be co-teaching with long time certified instructor Michael Rodriguez.
As a Senior Associate with System Improvements, Inc. with 18 years in aviation, it was a pleasure to teach the course in the Aviation Hangar offices. David Camille, also pictured above, was instrumental in coordinating this course and giving me the tour of one of their Gulfstreams.
R.R. Donnelley & Sons Co. prematurely filed Google Inc.’s earnings report with the Securities and Exchange Commission on Thursday. Google’s earnings were supposed to be released after the stock markets closed at 3 p.m. Instead, they showed up on the SEC’s Edgar website about 11:30 a.m. Google’s stock dropped as much as 11 percent, to $676 a share, before trading was halted about 20 minutes later at the company’s request.
About an hour after the earnings release, Google issued a statement blaming Chicago-based R.R. Donnelley for the blunder.
(“Glitch on Google Earnings Report under Investigation,” Chicago Tribune, October 19, 2012.)
Why do people think that blame will stop incidents? Haven’t we tried that already? Don’t the incidents just continue? Share your comments below.
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 …
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.
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?
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.
– 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!
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:
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…
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?
Energy Safeguards Target
Fastest Growing LinkedIn Root Cause Analysis Group
Can We Agree on a Worldwide Definition of “Root Cause”?
View and download a copy of the June Root Cause Network Newsletter.
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. 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.
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:
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 …
Here is an accident report from the BSEE (Bureau of Safety & Environmental Enforcement of the US Department of the Interior):
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.
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:
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:
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.