If you attend a TapRooT® class you will hear the instructor promote proactive improvement including proactive use of root cause analysis tools. The instructors will show you how to find and fix the root causes of problems before a major accident occurs.
It seems that the Navy has a chance to act proactively. A recent audit (called an INSURV Inspection) turned up a litany of serious operational and safety problems on two Navy surface ships. Now the question is … Will the Navy find and fix the root causes or just fix the symptoms?
A fresh coat of paint and a haircut (tried and true Navy solutions) won’t solve these problems. Cracked gun barrels, degraded engines, and inoperable radars are signs of improper or inadequate maintenance. And poor maintenance is only an indicator of where the bigger problems lie.
My guess is that these ships and their crews have been run hard and underfunded. It would be interesting to see data that may shed light on my guess.
Support for the troops shouldn’t be just a political slogan. The real measure of support is funding to maintain equipment and to train those who go in harms way. Politics shouldn’t get in the way of the proper tools that our brave sailors, airmen, and solders need to fight a difficult war.
The FBI concluded that the crash of Senator Joe Lieberman’s web site WAS NOT a dirty trick from the opposing camp (Ned Lamont).
According to the FBI the data logging indicates a simple overload of the site combined with a misconfiguration of the server by the administrator. The FBI concludes that:
“The system administrator misinterpreted the root cause…”
For the complete story see The New York Times article:
OGP SAFETY ALERT
SAFETY ALERT NO. 189:
SIKORSKY S76A+ AND S76A++ HELICOPTERS
Country: null
Location: —
Release Date: —
Time incident occurred: —
Type of Activity: Transport - Air
Type of Injury: null
Function: null
Applicabale Filter Categories: Air transport
Applies to BHP Billiton contracted Sikorsky S76A+ and S76A++ helicopters fitted with Turbomeca Ariel 1S or 1S1 engines.
Sikorsky S76 twin engine helicopters equipped with Turbomeca Ariel 1S or 1S1 engines are fitted with engine overspeed sensors designed to shutdown an engine to prevent catastrophic damage in the event of an engine overspeed. Once an engine has been shutdown by this protection system it cannot be restarted in flight as the overspeed protection system is inaccessible to the flight crew and can only be reset on the ground. The overspeed protection is incorporated into a component known as the Tachometer Box with two installed on each helicopter, one for each engine.
What Went Wrong?:
BHP Billiton has experienced two separate over water in flight engine shutdowns resulting from false overspeed indications. In both events the helicopter was flown back to an onshore location and landed safely with the one remaining operative engine. Investigation by the engine manufacturer, Turbomeca, revealed that failures of the overspeed protection system resulted from ingress of moisture and internal corrosion.
Corrective Actions and Recommendations:
In response to the failures on BHP Billiton contracted aircraft and other known events, Turbomeca has developed a replacement Tachometer Box with improved sealing to address the issue of moisture ingress and internal corrosion. The replacement of existing Tachometer Boxes with the improved part is recommended by Turbomeca in Service Bulletin 292 77 0330 for helicopters operating in humidity saturated environments which is typical of BHP Billiton offshore petroleum operations.
Sikorsky S76A+ and S76A++ helicopters that are not compliant with Service Bulletin 292 77 0330 Incorporation of Modification TU 330) by 10 July 2008 shall not be used by BHP Billiton.
BHP Billiton assets using or are likely to use Sikorsky S76A+ or S76A++ helicopters are to verify helicopter operators have incorporated Modification TU 330 before using these helicopters beyond 10 July 2008.
Click here to download entire alert including Turbomeca service bulletins (pdf 155kb).
The results of thousands of “lost” bags are called a “Luggage Mountain.”
They have had to fly jumbo jets loaded with just bags across the ocean to try to unite travelers with their luggage.
And news outlets say the problem could get WORSE!
The cost of this “incident” is more than just the immediate costs to the airlines and travelers. Some say it has caused damage to the whole British reputation.
What is the “cause?” Everyone has an opinion. Most are looking for someone to blame.
But instead of looking for someone to blame, they should try advanced root cause analysis.
TapRooT® has been applied by many major airlines. Alaska Airlines even used it to analyze delayed flights and improve on-time departure statistics.
Perhaps British Air should try TapRooT® to stop the baggage meltdown and improve customer service?
And next time they should use root cause analysis as a PROACTIVE tool to improve performance BEFORE they open a new terminal and thus avoid a major quality of service incident.
For those that aren’t aware, I am the Summit Chair and with the help of the TapRooT® Advisory Board, the Track Chairs, the staff at System Improvement, and previous year Summit participants (that a lot of help!), I plan the TapRooT® Summit.
I also hand pick the courses that are offered prior to the Summit - this year on June 23-24. I pick these courses based on the experience I have with performance improvement programs around the world. My goal is to put together a world-class selection of courses that will help people solve their toughest problems.
Each year I bring back some old favorites and some brand new courses.
The old favorites are based on previous attendance and feedback.
The new courses are based on requests from participants and problems that I observe in my extensive travels.
This year there are three new courses:
1. Hazard Recognition Best Practices
2. Engineering Equipment Reliability Techniques
3. TapRooT® and FMEA for Healthcare Root Cause Analysis
There are also, eight returning veterans:
1. Advanced Trending Techniques (10th year)
2. Innovation & Creative Solutions (2nd year)
3. Stopping Human Error (5th year)
4. Risk Management Best Practices (5th year)
5. Interviewing and Evidence Collection (3rd year)
6. Getting the Most from Your TapRooT® Software (2nd year)
The FAA is proposing $10,2 million in fines. The article says:
The FAA alleged that between June 18, 2006, and March 14, 2007, Southwest operated more than 59,000 flights without complying with a 2004 order requiring repetitive inspections of fuselage areas to detect fatigue cracking.
Further, the FAA charged that the airline flew nearly 1,500 more flights using the same planes in March 2007, even after it determined that it had not done the necessary inspections.
“The FAA is taking action against Southwest Airlines for a failing to follow the rules that are designed to protect passengers and crew,” Nicholas Sabatini, the FAA’s associate administrator for aviation safety, said in a prepared statement.
The fine is the largest levied against an air carrier, FAA spokeswoman Laura Brown said.
The missed inspections were discovered by Southwest and self-reported to the FAA. The missed inspections were then performed in the month of March 2007. Cracks were found and corrected in 6 or the 46 jets that were inspected.
What were the root causes of the missed inspections and have they been corrected?
Fines do little good if the problems root causes aren’t effectively addressed.
My hope is that both the FAA and Southwest thought of this. Why didn’t the reporter dig deeper to find this out and include it in the story?
Reporting on the politics of a fine is one thing, but assuring passengers of their safety by verifying that an effective root cause analysis was performed is quite another.
When you are intimately involved with TapRooT® and Equifactor® the way I am, you sometimes take for granted that people understand exactly what Equifactor® is and how it relates to the rest of the TapRooT® system. At one of my recent Equifactor® classes, a long-time TapRooT® user attended, and he was surprised to learn what Equifactor® actually does. I thought I’d put out a quick description of the overall philosophy of equipment troubleshooting using the Equifactor® module of the TapRooT® system.
When you start an investigation into an equipment failure, you may find yourself heading in a couple of specific directions:
1. Your troubleshooting team has found the “root cause” of the failure. For example, they have discovered that the bearing failed due to inadequate lubrication.
2. Your troubleshooting team is stumped, and has run out of ideas.
For the first option, take a look at this particular “root cause.” This sounds an awful lot like a causal factor. In fact, with a little change in the wording (Mechanic does not lubricate the bearing at the required periodicity), it now becomes a “who did what incorrectly”, and is actually a Casual Factor. What do you do with a Causal Factor? That’s right. Add it to your SnapCharT® gather any additional information to complete building your Summer SnapCharT® (mechanic training and experience? supervision? procedure correct? etc), and then analyze the CF using the Root Cause Tree®.
For the second option, your Spring SnapCharT® is probably pretty sparse. It probably says something like, “Operator started machine,” “Operator operated machine,” “Operator smelled something hot,” “Pump Bearing Failed (incident)”, “Operator secured machine.” Not very useful, and your troubleshooting team is stuck. This is where Equifactor® comes in.
Equifactor® is now used to give your troubleshooters some new ideas as to what would cause the bearing to fail. They would use these possible causes to put together a troubleshooting plan, check each of those possible causes, and find what actually happened. They might then discover that the bearing failed due to improper lubrication. Again, at this point, you do EXACTLY what we did in #1 above. This is only a Causal Factor, and a full root cause analysis is now required to figure out why the bearing was improperly lubricated.
Equifactor® is NOT used separately from TapRooT®. Equifactor® is used as an additional information gathering tool, just like Change Analysis, CHAP, or Safeguards Analysis. It is used to help you fill in your Spring SnapCharT® when you are not sure where to go. And, once you discover the problem using Equifactor®, you are now ready to bring the rest of the TapRooT® system to bear to find and correct the Root Causes of the equipment failure.
Don’t short-change yourself. Use the Equifactor® module to get to the Causal Factor, and then the rest of the TapRooT® system to fix the failure for good.
People ask me where they can get knowledge that will help them improve their equipment reliability. My first answer is that they can analyze their current equipment failure problems using TapRooT® and Equifactor® and get real insight into their failure causes.
If you would like to see a PDF of a presentation about TapRooT® and Equifactor®, click here.
But reactive use of Equifactor® is just the start. The new TapRooT® Book has three different ways that you can use Equifactor® proactively to improve equipment reliability:
1) Installation problem prevention.
2) Preventive/predictive maintenance development.
3) Equipment monitoring capability and routine operation surveillance development.
For more information about the new TapRooT® Book, click here.
To order your copy of the TapRooT® Book, click here.
Equifactor® was based on Heinz Bloch’s book, Machinery Failure Analysis and Troubleshooting. You can buy the book on-line at many of the on-line book sales sites or by calling the System Improvements at 865-539-2139.
If you would like to learn more from Heinz in a face-to-face meeting, plan to attend the TapRooT® Summit in Las Vegas on June 25-27. There is a special track on Equipment Reliability and Maintenance Best Practices. Part of the track is “Bloch Day.” In four best practice sessions, Heinz Bloch and Ken Bloch will share their latest knowledge to improve equipment reliability and help you achieve best-in-class equipment reliability.
For more information about the Equipment Reliability and Maintenance Best Practices Track at the TapRooT® Summit, click of the “Equipment Reliability & Maintenance Best Practices” button at:
Before the Summit, you can also attend a Special 2-Day Equifactor® Equipment Troubleshooting and Root Cause Analysis Course or the Engineering Equipment Reliability Techniques Course. For information about these courses, scroll down the page at:
These ideas should provide you with more than enough knowledge to get your equipment reliability improvement program into high gear. So don’t hesitate. Start your learning today! And get signed up for the TapRooT® Summit so that you can experience all the learning, networking, and benchmarking that will help you define and refine your equipment reliability improvement strategies.
The following accident took place in Denmark during a storm on 2/22/08.
Here’s the first view:
Here’s the second:
Yes - that is a truck at the base of the windmill when it self-destructs. I’m not sure if I can see people near the truck in the video or not.
The “cause” of the accident was the failure of the brake that limits the speed of the windmill during a storm. The speed of the blades were approaching the speed of sound when they failed.
If your improvement ideas include improving equipment reliability and maintenance at your facility, then you should plan to be in Las Vegas on June 25-27 at the TapRooT® Summit.
Why?
Because the Summit has a track focussed on that topic and the track includes “Bloch Day.”
What is Bloch Day?
Heinz Bloch is a worldwide recognized equipment reliability expert with over 20 books on equipment reliability and maintenance topics. For example:
Heinz Bloch, and his son, Ken Bloch, equipment reliability engineer at Flint Hills Refining, will share their latest ideas for improving equipment reliability and investigating equipment failures.
Their sessions will fill all four Equipment Reliability and Maintenance Best Practice Sessions on Thursday of the Summit. That makes Thursday … Bloch Day!
Their talks include:
How to Become Best of Class in Equipment Reliability by Maximizing Uptime - Heinz Bloch, Consulting Engineer, Process Machinery Consulting
Best of Class in Equipment Reliability: Part II - Heinz Bloch, Consulting Engineer, Process Machinery Consulting
Examples of Extreme Equipment Failure Investigations - Ken Bloch, Reliability Engineer, Flint Hills Refining & Heinz Bloch, Consulting Engineer, Process Machinery Consulting
Using TapRooT® to Solve Complex Equipment Problems - Ken Bloch, Reliability Engineer, Flint Hills Refining
And this day is just one day of the three day Summit. Other Equipment Reliability and Maintenance Best Practice Sessions at the Summit include:
Engineering Methods to Improve Equipment Reliability - Dave Thompson, President, RAMsoft Ltd., UK
Maintenance Best Practices - Mark Olson, Reliability Consultant; & Ken Reed, Senior Associate, System Improvements
Culture Shift Secrets - Changing Systems to Shift Cultures Towards High Performance - Kevin McManus, President, Great Systems!
Evaluating the Effectiveness of Corrective Actions - Brian Hennesey, First Energy, & Michele Lindsay, Principal Consultant, P2, Canada
Planning Your Improvements (facilitated by TapRooT® Instructors)
(Keynote Speaker Nikki Stone - Olympic Gold Medalist)
But there is even more…
Before the Summit, you can attend a special 2-Day TapRooT®/Equifactor® Equipment Troubleshooting and Root Cause Analysis Course by Ken Reed. This course teaches a combination of TapRooT® and Heinz Bloch’s best equipment troubleshooting techniques. For more information about this course, see:
Or you can attend the Equipment Reliability Techniques Course by Dave Thompson, President, RAMsoft Ltd., UK. For more information about this course see:
A seal failure led to a small oil spill in the Terra Nova oil field. The immediate cause reported in the article was a seal failure. This seems like a good opportunity to apply Equifactor® to help analyze the root causes of the seal failure.
Exelon, a long-time Licensed TapRooT® User, was honored when their CEO, John Rowe, was named Best Electric Utility CEO by Institutional Investor.
John said: “Exelon has been one of the most consistently profitable companies in the electricity industry, having grown our operating earnings an average of about 12 percent per year over the past seven years. I’m honored to be recognized by the financial community and Institutional Investor for our success. It’s my job and the job of Exelon’s management team to deliver sustainable value to our shareholders, and I believe Exelon is uniquely positioned to continue on a successful path in the years ahead.”
To arrive at its list of Best U.S. CEOs, Institutional Investor surveyed portfolio managers, analysts and other investment professionals. It asked these individuals to name the best U.S. CEOs in the sectors in which they invest. Some 900 people at 425 institutions responded, offering first, second and third place votes in each of the sectors with which they were familiar. These votes were weighted to produce a score for each executive that Institutional Investor used to compile the rankings.
Additional information can be found at www.iimagazine.com and in the January issue of the magazine.
Exelon Corporation is one of the nation’s largest electric utilities with more than $15 billion in annual revenues. The company has one of the industry’s largest portfolios of electricity generation capacity, with a nationwide reach and strong positions in the Midwest and Mid-Atlantic. Exelon distributes electricity to approximately 5.4 million customers in northern Illinois and Pennsylvania and natural gas to approximately 480,000 customers in the Philadelphia area. Exelon is headquartered in Chicago.
Part of Exelon’s success is due to their efforts to improve performance both reactively and proactively by finding the root causes of human performance and equipment problems. As part of the TapRooT® Summit, Exelon will be sharing one of their performance improvement programs - Exelon’s Error Free Performance Tool.
For more information about the TapRooT® Summit, see:
The food processing industry is a great place to put TapRooT® to work finding the causes of all sorts of events including industrial safety issues, food safety issues, and equipment reliability problems.
In this case, there was a combination of equipment reliability and industrial safety issues.
For more information about learning about TapRooT® in Australia, see these two web sites:
I read the following in the trade publication Machinery Lubrication (November 2007): A multi-industry study published by the National Research Council of Canada showed that particle contamination was the root cause of 82 percent of wear-related failures.
My first thought was … Where did they get these statistics? Very few companies do a formal root cause analysis of every equipment failure.
My second thought was … Particle contamination isn’t a root cause!
Particle contamination would be a Causal Factor - just the start of the root cause analysis process in the TapRooT® System. There could be many causes of the contamination.
Want to learn a systematic process for finding the root causes of equipment failures? Attend the 3-Day TapRooT®/Equifactor® Equipment Troubleshooting and Root Cause Analysis Course.
You can schedule a course at your site for 10 or more attendees or send folks to one of our public courses:
Galveston, TX January 15-17
Lake Charles, LA January 23-25
Aberdeen, Scotland January 30-February 1
Edmonton, Canada February 20-22
Perth, Australia February 20-22
Melbourne, Australia February 27-29
Bogota, Columbia March 5-7
Calgary, Canada March 10-12
Houston, TX March 26-28
Christchurch, New Zealand March 31-April 2
Equipment troubleshooting requires a very logical though-process. You have to understand the operation of the equipment not only by itself, but also in the context of the rest of the system. A thorough knowledge of the equipment design specifications and the operating environment is required.
Most companies, when faced with a particularly stubborn problem, get their experts together in one room, discuss the problem, and then start listing the possible causes of the issue. Fault trees and troubleshooting tables are referenced, and component technical manuals are available. Then the fun begins. Possible causes are listed up on the board, and then a troubleshooting plan is put together.
But where do these possible causes come from? How do your troubleshooting experts arrive at their possibilities? Invariably, this list is a compilation of the experiences of the troubleshooting team. Each individual thinks back to when he’s seen these symptoms before, remembers what caused it that time, and then lists that problem as a possible cause. This is the natural method of finding problems, and it is fundamental to good troubleshooting.
But what happens when a problem is outside the experience of the troubleshooters? What if this particular fault is not caused by something familiar to the team? How can they possibly find the cause? If nobody has ever seen this problem before, it is very difficult to try to think of new possibilities. Usually, this is discovered after many hours (days? weeks?) of troubleshooting, and all expected possibilities are proven wrong. That can be a significant amount of wasted effort.
What we really need is a reference that will give you a list of possible causes for the symptom you are seeing. Where would we get a magic reference like that? Hey, that’s what Equifactor® does! Instead of only looking for the “normal” reasons for a particular symptom, Equifactor® lists a whole range of “unusual” reasons for the failure. At the end of a difficult troubleshooting effort, ever hear your team say, “That’s a new one on me!” Using Equifactor®, you would no longer be surprised by these “unknown” failure modes.
Start out your troubleshooting sessions with a complete list of possible causes. Use Equifactor right from the beginning, and reduce your downtime!
So who needs Equifactor®, anyway? Discussions with reliability experts and maintenance technicians have made it clear to me that there are a whole range of people who can benefit from the TapRooT® Equipment Troubleshooting software module.
–Troubleshooting teams who are stumped when it comes to the root cause of a particularly tough failure analysis
–Reliability experts who need help instituting a preventive maintenance, operating, and PdM plan for new equipment installations
–Maintenance managers wishing to capture equipment troubleshooting techniques from retiring experts
–Facilities managers working to reduce costs due to unscheduled, frequent equipment downtime
Equifactor® should be used by experts who are tired of finding “root causes” that don’t seem to prevent repeat failures. Don’t settle for “Improper Bearing Lubrication” as your root cause. Once you have determined a symptom like this, feed it back into the rest of the TapRooT® Root Cause Analysis system to find and correct actual root causes of the equipment failures.
Many of us have had experience working with fault trrees. We have worked throught the painstaking process of determining how a particular material failure will get us to a specific observed failure. It is an excellent tool to structure your thinking when you need to see exactly what could possibley have caused the failure we are investigating.
Too often, we seem to focus only on the material failures. The fault tree will have items such as “Relief Valve Fails”, Vessel Wall Fatigue Failure”, “Overpressure”, “Power Supply Fails.” This is very comfortable, because it is only a piece of “stuff” that failed, and I can easily lay the blame for the failure on an inanimate object. The fault tree will use the basic event (or equivalent) symbol, signifying that we need look no deeper than this event.
The more realistic investigator may add in a set of events that include “Human Error” into the mix. More often than not, however, these events are catagorized as Incomplete Events, or those that we just don’t have enough information to further develop. It is easier to just leave these events on our fault trees as incomplete, and we just accept that the human error is just going to occur. After all, I can’t replace the human like I can a part. And parts don’t get their feelings hurt or complain about the result!
Yet, deep down we know (and studies have proven over and over again) that these “human errors” are at the root of over 90% of equipment failures. Therefore, although our fault trees may eventually get you to the point of discovering what part or condition contributed to the final failure, we still never seem to get to the bottom of 90% of our failures.
It is important that, when conducting a fault tree analysis, we include and run down the human errors that lead to the failure conditions. The failure conditions that we discover should be considered Causal Factors (“Relief Valve did not lift”), and then a proper root cause analysis can be conducted on the reasons why the relief valve did not lift. Use Equifactor® to help populate your fault trees. Then take the results of your fault tree, plug them into your SnapCharT®, and finish your investigation. Using the rest of the TapRooT® system to assist in your equipment troubleshooting process, you will get much further beyond where the fault tree drops you.
A Failure Mode Effect Analysis (FMEA) is used to determine the relative risks of a failure causing a specific effect, and then determining the priority of mitigating that particular failure mode. It is used as a risk management tool to help determine where resources should most efficiently be spent. Although usually used as a proactive tool, it can be applied after an accident during a root cause analysis to help determine what failure modes could have caused the effect seen.
One of the very first steps in conducting an FMEA is to know what failure modes are available. You must know how the piece of equipment or the process can fail. Where do you get this information? There are several sources that are available:
System Experts at your facility
Equipment technical manuals
ISO standards (ISO-9000, QS-9000, ISO-16949, Mil-Std-1629A, etc)
Equipment troubleshooting tables
Another great source of information is the Equifactor® troubleshooting section of the TapRooT® Software. For example, take a look through the Conveyor Belt tables, and start with the Possible Causes of failures. This can lead you to failure modes that you may not have initially considered, including the causes of those modes. By combining Equifactor® with other sources of information, you can ensure you have a complete list of possible problems to use during the FMEA process.
I came home from work the other day, and saw contractors working on my new garage. They were just about finished putting up cinder block walls. It was about 95F, and I was thinking that I’m glad they were doing this, and not me!
They came to a corner, and needed to put in a partial block. The lead mason had his worker cut him a block of just the right size. The worker was wearing sneakers, shorts, and a ball cap (nothing else). He perched a fresh block on a pile of rubble and held it steady with his foot. He then picked up the electric-powered rotary masonry saw, squinted his eyes, and turned his head slightly to the side (I guess to protect his eyes). Starting the saw, he started cutting the cinder block.
I couldn’t stand it. “Hey!! Hold on a minute!” I asked the mason (the guy in charge) if that was the best method to cut a cinder block. “Don’t you guys have eye and hearing protection? What about long pants and boots? Can’t we set up a clear area for cutting?
He shrugged and said, “That’s how I’ve always done it. I haven’t cut myself in a long time. He’ll learn pretty quick the right way and the wrong way to cut block. It’s too hot to wear that stuff, anyway.”
I told them that they would have to stop until they got adequate safety gear. It so happens they had everything they needed in their truck (except for long pants). I cleared out an area for cutting off to the side. They finished the job, and that’s the last I saw of them.
– I wonder how much extra time it really took to do the job right. Just clearing the cutting area actually speeded the process up.
– I wonder how much time, wages, and production was lost by injuries to this guy’s crew.
– I noticed that the mason walked with a limp. I wonder how many toes he has…
Save time & money when learning advanced equipment troubleshooting. Prior TapRooT® Course attendees can attend just the last day of a 3-Day TapRooT®/Equifactor® Equipment Troubleshooting and Root Cause Analysis Course to learn Equifactor® for equipment troubleshooting. These skills help you find the root causes of equipment problems and improve equipment reliability. Even non-equipment experts can learn to investigate equipment problems. Plus, take these extras back to work:
• Machinery Failure Analysis and Troubleshooting by Heinz Bloch.
• The TapRooT® Software that includes computerized troubleshooting tables.
The book and the software cost $1615 without the course. If you attend this course, you get the book, the software, and the training for only $995.
If your company has a TapRooT® Software network license, you save $400 more (attend for only $595).
Sign up 3 or more people at once and save $100 more.
1. You are interested in fixing the root causes of equipment failures.
AND
2. You live or work in Asia.
THEN
3. You should consider the 3-Day TapRooT®/Equifactor Equipment Troubleshooting & Root Cause Analysis Class on October 31 - November 2 in Kuala Lumpur, Malaysia.
The main thrust of a comment by Mayor Daley in Chicago seems to be that if you punish enough people, future accidents will be prevented - or so an article in the Chicago Tribune implies…
At a news conference the paper quotes Major Daley saying:
“I don’t manage the CTA, [CTA President] Ron Huberman does. Any time you have an accident, you have an investigation. Then you have the proper penalties for the individual, and discipline, and that’s what they have done. They have allowed this to be thoroughly investigated, and they are not afraid of the outcome. The outcome shows there were deficiencies, and they have corrected it.”
The article states that Huberman, who appeared with Daley at a South Side news conference on an unrelated subject, said that heads rolled after the accident. He is quoted as saying:
“The director in charge of this group has been replaced. The manager in charge of this group has been replaced. The supervisor has been replaced. And the foreman has been replaced. Everyone was held ultimately accountable for this.”
The article says that the NTSB’s investigation concluded that the derailment in a stretch of Blue Line subway was caused by the CTA’s “ineffective management and oversight of its track inspection and maintenance program and its system safety program, which resulted in unsafe track conditions.” Bob Chipkevich, Director of the the NTSB’s office of railroad, pipeline and hazardous materials investigations, said the CTA’s track inspection and maintenance were the worst he had ever seen at a U.S. transit agency.
The article also mentioned that Huberman stated that:
“Significant changes have been put into place, new auditing functions have been put into place … and new technology has been put in place.”
He also said:
“You have a brand new team. This was the result of the 2006 derailment. … We have accelerated many changes, and they are in place today, making it a safe system.”
So what’s the answer? Replacing people or accelerating changes and new technology? Was it the people (who are now gone) or the politics that caused the problems? Was the poor maintenance, faked reports, and bad surveys caused by four bad people or was their a culture that caused poor performance? Did the culture change or did we just put new people into the old culture?
More stories about this accident are available at:
We only have a few more Equifactor® courses scheduled for this year. Pick the option that best meets your needs:
1. Attend a 3–Day Equifactor® course. This course includes our normal 2–Day Incident Investigator course, PLUS a third day dedicated to finding and correcting the root causes of equipment failures.
A Failure Mode Effect Analysis (FMEA) is used to determine the relative risks of a failure causing a specific effect, and then determining the priority of mitigating that particular failure mode. It is used as a risk management tool to help determine where resources should most efficiently be spent. Although usually used as a proactive tool, it can be applied after an accident during a root cause analysis to help determine what failure modes could have caused the effect seen.