Category: Investigations

Are You Writing the Same Corrective Actions?

April 17th, 2017 by

Repeating the same corrective actions over and over again defeats the purpose of a quality root cause analysis investigation. If you spend the time investigating and digging deeper to find the REAL root cause, you should write the most effective corrective actions you can to ensure it was all worth the resources put into it. Instructor & Equifactor® and TapRooT® Expert, Ken Reed, talks about corrective actions and how to make them new and effective for each root cause.

 

Take a TapRooT® Root Cause Analysis course today to learn our effective and efficient RCA methodology. 

How to Interpret Body Language In Your Incident Investigation Interviews

April 10th, 2017 by

TapRooT® Instructor and Non-Verbal Communication Expert, Barb Phillips, explains how to interpret common body language cues with an example investigative interview. Watch here for some investigative interviewing tips!

Want to know more? Take a TapRooT® Effective Interviewing and Evidence Collection course.

Root Cause Tip: What is the minimum investigation for a simple incident?

March 20th, 2017 by

NewImage

What is the minimum investigation for a simple incident?

Before you can answer this question, you need to decide the outcome you are looking for. For example:

  • Do you just want to document the facts?
  • Would you be happy with a simple corrective action that may (or may not) be effective?
  • Do you need effective corrective actions to prevent repeats of this specific incident?
  • Do you want to prevent similar types of incidents?

The answers to these questions depend on two factors that determine risk:

  1. What were the consequences of this incident and could things have happened slightly differently and had much worse consequences?
  2. What is the likelihood that this type of incident will happen again?

Of course, before you start an investigation, answering these two questions may be difficult. Before you start an investigation, you don’t really know what happened! But in spite of this lack of knowledge, someone must decide if an incident is worth investigating and the resources to dedicate to the investigation.

I’ve seen simple incidents that, when investigated, revealed complex problems that could have caused a serious accident. Therefore, if a thorough investigation is not performed, the investigator may never know what they could have discovered. That’s why I caution management that something that seems simple may not be simple.

However, some incidents ARE simple. I’ve seen many incidents that people were investigating that were similar to this one:

An employee stumbles, falls, and sprains
his wrist while walking down a flat sidewalk.
He had on simple shoes with adequate tread.
He was not particularly preoccupied
nor was he entirely paying attention to each step
(just normal walking).

How much can be learned by investigating this incident? Probably not much. I would suggest that even though the person sprained his wrist, this incident should not be investigated beyond a simple recording of the facts so that the incident could be recorded for safety records (OSHA logs in the USA) and included in future incident trending.

You might ask:

“But what if the employee had stumbled and fell in front of an oncoming car and the employee killed?”

In that case, because of the consequences, a detailed major investigation would be required.

In either case, the TapRooT® Root Cause Analysis System could be used to complete the investigation.

The TapRooT® Root Cause Analysis System is a robust, flexible system for analyzing and fixing problems. The complete system can be used to analyze and fix complex accidents, quality problems, hospital sentinel events, and other issues that require a complete understanding of what happened and effective corrective actions.

Learn more about when to investigate a simple incident by attending our 2-Day TapRooT® Root Cause Analysis training.  Click here to view the upcoming schedule.

 

Carnival Pride NTSB Allision Report – Causal Factor Challenge

March 7th, 2017 by

collision, allision, carnival

The NTSB released their report on the allision of the Carnival Pride cruise ship with the pier in Baltimore last may. It caused over $2 million in damages to the pier and the ship, and crushed several vehicles when the passenger access gangway collapsed onto them. Luckily, no one was under or on the walkway when it fell.  You can read the report here.

Pride

The report found that the second in command was conning the ship at the time.  He had too much speed and was at the wrong angle when he was approaching the pier.  The report states that the accident occurred because the captain misjudged the power available when shifting to an alternate method of control to stop the ship.  It states there may have been a problem with the controls, or maybe just human error.  It also concluded that the passenger gangway was extended into the path of the ship, and that it did not have to be extended until ready for passengers to debark.

collision, allision, carnival

Gangway collapse after allision

While I’m sure these findings are true, I wonder what the actual root causes would be?  If the findings are read as written, we are really only looking at Causal Factors, and only a few of those to boot.  Based on only this information, I’m not sure what corrective actions could be implemented that would really prevent this in the future.  As I’m reading through the report, I actually see quite a few additional potential Causal Factors that would need to be researched and analyzed in order to find real root causes.

YOUR CHALLENGES:

  1. Identify the Causal Factors you see in this report.  I know you only have this limited information, but try to find the mistakes, errors, or equipment failures that lead directly to this incident (assuming no other information is available)
  2. What additional information would you need to find root causes for the Causal Factors you have identified?
  3. What additional information would you like in order to identify additional Causal Factors?

Reading through this incident, it is apparent to me that there is a lot of missing information.  The problems identified are not related to human performance-based root causes; there are only a few Causal Factors identified.  Unfortunately, I’m also pretty sure that the corrective actions will probably be pretty basic (Train the officer, update procedure, etc.).

BONUS QUESTION:

For those that think I spelled “collision” wrong, what is the meaning of the word “allision”?  How many knew that without using Google?

Remembering an Accident: Montana Coal and Iron Company

February 27th, 2017 by

Two small communities in Montana were tragically touched by a mining accident this day in 1943.

smith-mine-disaster-sign

The Montana Coal and Mine Company employed most men living in Washoe and Bearcreek, Montana. There had never been any major accidents like the one that took place on February 27, 1943. That morning, a massive explosion in mine #3 occurred. It was so powerful that families in both local communities heard and felt it. As the supervisors tried to find the cause of the explosion, they couldn’t find anything. No exact root cause. No evidence to tie together to ensure it doesn’t happen again. Sadly, all they could do was inform the families of their losses and shut down for good. The final fatality count was 74 out of 77 miners. All but 3. It was the largest accident they had ever had.

It’s stories like these that we can learn from. How could they have investigated better to find the root cause? What kind of corrective actions could have been implemented to keep these sort of explosions of happening again?

Top 3 Reasons for Bad Root Cause Analysis and How You Can Overcome Them…

February 7th, 2017 by

NewImage

I’ve heard many high level managers complain that they see the same problems happen over and over again. They just can’t get people to find and fix the problems’ root causes. Why does this happen and what can management do to overcome these issues? Read on to find out.

 

1. BLAME

Blame is the number one reason for bad root cause analysis.

Why?

Because people who are worried about blame don’t fully cooperate with an investigation. They don’t admit their involvement. They hold back critical information. Often this leads to mystery accidents. No one knows who was involved, what happened, or why it happened.

As Bart Simpson says:

“I didn’t do it.”
“Nobody saw me do it.”
“You can’t prove anything.”

Blame is so common that people take it for granted.

Somebody makes a mistake and what do we do? Discipline them.

If they are a contractor, we fire them. No questions asked.

And if the mistake was made by senior management? Sorry … that’s not how blame works. Blame always flows downhill. At a certain senior level management becomes blessed. Only truly horrific accidents like the Deepwater Horizon or Bhopal get senior managers fired or jailed. Then again, maybe those accidents aren’t bad enough for discipline for senior management.

Think about the biggest economic collapse in recent history – the housing collapse of 2008. What senior banker went to jail?

But be an operator and make a simple mistake like pushing the wrong button or a mechanic who doesn’t lock out a breaker while working on equipment? You may be fired or have the feds come after you to put you in jail.

Talk to Kurt Mix. He was a BP engineer who deleted a few text messages from his personal cell phone AFTER he had turned it over to the feds. He was the only person off the Deepwater Horizon who faced criminal charges. Or ask the two BP company men who represented BP on the Deepwater Horizon and faced years of criminal prosecution. 

How do you stop blame and get people to cooperate with investigations? Here are two best practices.

A. Start Small …

If you are investigating near-misses that could have become major accidents and you don’t discipline people who spill the beans, people will learn to cooperate. This is especially true if you reward people for participating and develop effective fixes that make the work easier and their jobs less hazardous. 

Small accidents just don’t have the same cloud of blame hanging over them so if you start small, you have a better chance of getting people to cooperate even if a blame culture has already been established.

B. Use a SnapCharT® to facilitate your investigation and report to management.

We’ve learned that using a SnapCharT® to facilitate an investigation and to show the results to management reduces the tendency to look for blame. The SnapCharT® focuses on what happened and “who did it” becomes less important.

Often, the SnapCharT® shows that there were several things that could have prevented the accident and that no one person was strictly to blame. 

What is a SnapCharT®? Attend any TapRooT® Training and you will learn how to use them. See:

TapRooT® Training

NewImage

2. FIRST ASK WHAT NOT WHY

Ever see someone use 5-Whys to find root causes? They start with what they think is the problem and then ask “Why?” five times. Unfortunately this easy methods often leads investigators astray.

Why?

Because they should have started by asking what before they asked why.

Many investigators start asking why before they understand what happened. This causes them to jump to conclusions. They don’t gather critical evidence that may lead them to the real root causes of the problem. And they tend to focus on a single Causal Factor and miss several others that also contributed to the problem. 

How do you get people to ask what instead of why?

Once again, the SnapCharT® is the best tool to get investigators focused on what happened, find the incidents details, identify all the Causal Factors and the information about each Causal Factor that the investigator needs to identify each problem’s root causes.

NewImage

3. YOU MUST GO BEYOND YOUR CURRENT KNOWLEDGE

Many investigators start their investigation with a pretty good idea of the root causes they are looking for. They already know the answers. All they have to do is find the evidence that supports their hypothesis.

What happens when an investigator starts an investigation by jumping to conclusions?

They ignore evidence that is counter to their hypothesis. This problem is called a:

Confirmation Bias

It has been proven in many scientific studies.

But there is an even bigger problem for investigators who think they know the answer. They often don’t have the training in human factors and equipment reliability to recognize the real root causes of each of the Causal Factors. Therefore, they only look for the root causes they know about and don’t get beyond their current knowledge.

What can you do to help investigators look beyond their current knowledge and avoid confirmation bias?

Have them use the SnapCharT® and the TapRooT® Root Cause Tree® Diagram when finding root causes. You will be amazed at the root causes your investigators discover that they previously would have overlooked.

How can your investigators learn to use the Root Cause Tree® Diagram? Once again, send them to TapRooT® Training.

THAT’S IT…

The TapRooT® Root Cause Analysis System can help your investigators overcome the top 3 reasons for bad root cause analysis. And that’s not all. There are many other advantages for management and investigators (and employees) when people use TapRooT® to solve problems.

If you haven’t tried TapRooT® to solve problems, you don’t know what you are missing.

If your organization faces:

  • Quality Issues
  • Safety Incidents
  • Repeat Equipment Failures
  • Sentinel Events
  • Environmental Incidents
  • Cost Overruns
  • Missed Schedules
  • Plant Downtime

You need to be apply the best root cause analysis system: TapRooT®.

Learn more at: 

http://www.taproot.com/products-services/about-taproot

And find the dates and locations for our public TapRooT® Training at:

 http://www.taproot.com/store/Courses/

NewImage

Monday Accident & Lessons Learned: Railroad Bridge Structural Failure

December 12th, 2016 by

Screen Shot 2016 11 14 at 6 18 33 PM

A Report from the UK Rail Accident Investigation Branch:

Structural failure caused by scour at Lamington viaduct, South Lanarkshire, 31 December 2015

At 08:40 hrs on Thursday 31 December 2015, subsidence of Lamington viaduct resulted in serious deformation of the track as the 05:57 hrs Crewe to Glasgow passenger service passed over at a speed of about 110 mph (177 km/h). The viaduct spans the River Clyde between Lockerbie and Carstairs. Subsequent investigation showed that the viaduct’s central river pier had been partially undermined by scour following high river flow velocity the previous day. The line was closed for over seven weeks until Monday 22 February 2016 while emergency stabilisation works were completed.

The driver of an earlier train had reported a track defect on the viaduct at 07:28 hrs on the same morning, and following trains crossed the viaduct at low speed while a Network Rail track maintenance team was deployed to the site. The team found no significant track defects and normal running was resumed with the 05:57 hrs service being the first train to pass on the down line. Immediately after this occurred at 08:40 hrs, large track movements were noticed by the team, who immediately imposed an emergency speed restriction before closing the line after finding that the central pier was damaged.

The viaduct spans a river bend which causes water to wash against the sides of the piers. It was also known to have shallow foundations. These were among the factors that resulted in it being identified as being at high risk of scour in 2005. A scheme to provide permanent scour protection to the piers and abutments was due to be constructed during 2015, but this project was deferred until mid-2016 because a necessary environmental approval had not been obtained.

To mitigate the risk of scour, the viaduct was included on a list of vulnerable bridges for which special precautions were required during flood conditions. These precautions included monitoring of river levels and closing the line if a pre determined water level was exceeded. However, this process was no longer in use and there was no effective scour risk mitigation for over 100 of the most vulnerable structures across Scotland. This had occurred, in part, because organisational changes within Network Rail had led to the loss of knowledge and ownership of some structures issues.

Although unrelated to the incident, the RAIB found that defects in the central river pier had not been fully addressed by planned maintenance work. There was also no datum level marked on the structure which meant that survey information from different sources could not easily be compared to identify change.

As a result of this investigation, RAIB has made three recommendations to Network Rail relating to:

  • the management of scour risk
  • the response to defect reports affecting structures over water
  • the management of control centre procedures.

Five learning points are also noted relating to effective management of scour risk.

For more information, see:

R222016_161114_Lamington_viaduct

Monday Accident & Lessons Learned: Collision at Yafforth, UK, level crossing, 3 August 2016

November 28th, 2016 by

NewImage

For a report from the UK Rail Accident Investigation Branch, see:

www.gov.uk

The Blame Culture Hurts Hospital Root Cause Analysis

November 22nd, 2016 by

If you don’t understand what happened, you will never understand why it happened.

You would think this is just common sense. But if it is, why would an industry allow a culture to exist that promotes blame and makes finding and fixing the root causes of accidents/incidents almost impossible?

I see the blame culture in many industries around the world. Here is an example from a hospital in the UK. This is an extreme example but I’ve seen the blame culture make root cause analysis difficult in many hospitals in many countries.

Dr. David Sellu (let’s just call him Dr. Death as they did in the UK tabloids), was prosecuted for errors and delays that killed a patient. He ended up serving 16 months in high security prisons because the prosecution alleged that his “laid back attitude” had caused delays in treatment that led to the patient’s death. However, the hospital had done a “secret” root cause analysis that showed that systemic problems (not the doctor) had led to the delays. A press investigation by the Daily Mail eventually unearthed the report that had been kept hidden. This press reports eventually led to the doctor’s release but not until he had served prison time and had his reputation completely trashed.

Screen Shot 2016 11 22 at 11 09 45 AM

If you were a doctor or a nurse in England, would you freely cooperate with an investigation of a patient death? When you know that any perceived mistake might lead to jail? When problems that are identified with the system might be hidden (to avoid blame to the institution)? When your whole life and career is in jeopardy? When your freedom is on the line because you may be under criminal investigation?

This is an extreme example. But there are other examples of nurses, doctors, and pharmacists being prosecuted for simple errors that were caused by systemic problems that were beyond their control and were not thoroughly investigated. I know of some in the USA.

The blame culture causes performance improvement to grind to a halt when people don’t fully cooperate with initiatives to learn from mistakes.

TapRooT® Root Cause Analysis can help investigations move beyond blame by clearly showing the systemic problems that can be fixed and prevent (or at least greatly reduce) future repeat accidents.Attend a TapRooT® Root Cause Analysis Course and find out how you can use TapRooT® to help you change a blame culture into a culture of performance improvement.

Foe course information and course dates, see:

http://www.taproot.com/courses

Monday Accident & Lessons Learned: Pilot Error is Root Cause

November 14th, 2016 by

The Navy still likes to blame folks as a root cause. At least that’s what I see in this report about a “pilot error” keeping a F/A-18 Hornet making it back to the carrier USS Theodore Roosevelt.

Seems there were lot’s of Causal Factors that contributed to the loss of an $86 million dollar aircraft that are described in this article on Military.com:

http://www.military.com/daily-news/2016/10/27/debris-pilot-error-caused-2015-jet-crash-persian-gulf-navy.html

I haven’t found the report of the video on line.

What do you think of the report of the investigation?

 

Starting Your Investigations: The Power of the SnapCharT®

November 7th, 2016 by

Beginning your investigation can sometimes be quite a challenge. Deciding on who to talk to, what documents you need, what questions you need to ask, etc. can lead to feeling slightly overwhelmed. As General Creighton Abrams said,

When eating an elephant, take one bite at a time.

In other words, you just need to get started with the first step, and then methodically work your way through to the end.

In TapRooT®, that first bite is the SnapCharT®. The rest of your investigation is going to depend on the data you gather in that SnapCharT®, so it is critical that you begin in a simple, methodical manner.

Let’s say you get that initial notification phone call (usually at 3:00 am). You don’t get much information. Maybe all you know is, “Ken, we had a pipe rupture this morning during a hydrostatic test. Looks like the mechanics didn’t know what they were doing.  They had hooked up a test pump to the piping, started the pump, and almost immediately ruptured the piping.  We’ve cleaned up the water, and no one was hurt.  We need you to investigate this.”  This is a pretty common initial report.  Not a lot of data, some opinions thrown in, and a request for answers.  Without a structured process, most investigations would now start off with some interviews, asking pretty generic questions.  It would be really nice if we could start off with some detailed, intelligent questions.

This is where the SnapCharT® comes in.  Once you receive that initial phone call, just build your SnapCharT® with the information you have.  It honestly won’t have much data, but that’s OK; it’s only your starting point:

Initial SnapCharT®

Initial SnapCharT®

However, with this initial SnapCharT®, it is now easier to visualize what you already know, and what you still need to know.  For example, I’d have a lot of questions about the pump, the mechanics themselves, recovery actions, etc.  I’d use the Root Cause Tree® to help me figure out what questions to ask.  I’d take each Event and ask, “What do I already know about this Event, and what questions do I have about it?”  These would all be added to the SnapCharT®.  It might look more like this:

Questions to ask

Questions to ask

Keep in mind that these questions were developed before I even went to the scene or questioned anybody about the facts.  I still need to interview people, but I now have a much better set of questions to begin my investigations.  Many more questions will arise as I ask this initial set of questions, but I’ll feel much better prepared to start talking to people about the issue.

The SnapCharT® is a simple yet effective tool to help the investigator get started with the investigation.  It may seem like an inconsequential step, easy to dismiss.  However, using the SnapCharT® as your very first tool, before you start gathering data, can greatly speed up the investigation.  It allows you to start on the right path, with a set of intelligent questions to ask.  Once you have this moving, you’ll find the rest of the investigation falls into place in a logical, easy to follow format.  ALWAYS START WITH A SNAPCHART®!

LEARN MORE about TapRooT® essentials in our 2-day course (View schedule and register!)

 

Monday Accident & Lessons Learned: Lessons Learned from Overspeed Incidents in the UK

November 7th, 2016 by

ExcessSpeed

Lessons learned from six trains passing through an emergency speed restriction at excessive speed. For the complete story. see this post from the UK Rail Accident Investigation Branch:

https://www.gov.uk/government/publications/blatchbridge-safety-digest/overspeed-incidents-somerset-19-july-2016

Navy Root Cause Analysis Focused on Blame Vision, Crisis Vision, or Opportunity to Improve Vision?

November 3rd, 2016 by

NewImage

In a short but interesting article in SEAPOWER, Vice Admiral Thomas J. Moore stated that Washing Navy Yard had just about completed the root cause analysis of the failure of the main turbine generators on the USS Ford (CVN 78). He said:

The issues you see on Ford are unique to those particular machines
and are not systemic to the power plant or to the Navy as a whole.

Additionally, he said:

“…it is absolutely imperative that, from an accountability standpoint, we work with Newport News
to find out where the responsibility lies. They are already working with their sub-vendors
who developed these components to go find where the responsibility and accountability lie.
When we figure that out, contractually we will take the necessary steps to make sure
the government is not paying for something we shouldn’t be paying for.”

That seems like a “Blame Vision” statement.

That Blame Vision statement was followed up by statement straight from the Crisis Mangement Vision playbook. Admiral Moore emphasized that would get a date set for commissioning of the ship that is behind schedule by saying:

“Right now, we want to get back into the test program and you’ll see us do that here shortly.
As the test program proceeds, and we start to development momentum, we’ll give you a date.
We decided, ‘Let’s fix this, let’s get to the root cause, let’s get back in the test program,’ and
when we do that, we’ll be sure to get a date out. I expect that before the end of the year
we will be able to set a date for delivery.”

Press statements are hard to interpret. Perhaps the Blame and Crisis Visions were just the way the reporters heard the statements or the way I interpreted them. An Opportunity to Improve Vision statement would have been more along the lines of:

We are working hard to discover the root causes of the failures of the main turbine generators
and we will be working with our suppliers to fix the problems discovered and apply the
lessons learned to improve the reliability of the USS Ford and subsequent carriers of this class,
as well as improving our contracting, design, and construction practices to reduce the
likelihood of future failures in the construction of new, cutting edge classes of warships.

Would you like to learn more about the Blame Vision, the Crisis Management Vision, and the Opportunity to Improve Vision and how they can shape your company’s performance improvement programs? The watch for the release of our new book:

The TapRooT® Root Cause Analysis Philosophy – Changing the Way the World Solves Problems

It should be published early next year and we will make all the e-Newsletter readers are notified when the book is released.

To subscribe to the newsletter, provide your contact information at:

http://www.taproot.com/contact-us#newsletter

OSHA/EPA “Fact Sheet” About Root Cause Analysis & Incident Investigation

November 1st, 2016 by

Screen Shot 2016 11 01 at 1 49 05 PM

Above is the start of an OSHA/EPA Fact Sheet titled: “The Importance of Root Cause Analysis During Incident Investigation.”

OSHA and EPA want companies to go beyond fixing immediate cause (which may eliminate a symptom of a problem) and instead, find and fix the root causes of the problems (the systemic/underlying causes). This is especially important for process safety incidents. 

The fact Sheet explains some of the basic of root cause analysis and suggests several tools for root cause analysis. 

UNFORTUNATELY, many of the tools suggested by the fact sheet are not really suited to finding and fixing the real root causes of process safety incidents. They don’t help the investigator (or the investigative team) go beyond their current knowledge. Thus, the suggested techniques produce the same ineffective investigations that we have all seen before.

Would you like to learn more about advanced root cause analysis that will help your investigators learn to go beyond their current investigative methods and beyond their current knowledge to discover the real root causes of equipment reliability and human performance related incidents? These are techniques that have been proven to be effective by leading companies around the world. 

Yes? Then see: http://www.taproot.com/products-services/about-taproot

And choose one of our upcoming public TapRooT® Courses to learn more about the TapRooT® Root Cause Analysis System. See:

http://www.taproot.com/store/Courses/

 

 

Monday Accident & Lessons Learned: How Can Automation Get You Into Trouble?

October 24th, 2016 by

NewImage

Automation dependency is an interesting topic. Here’s what a recent CALLBACK from the Aviation Safety Reporting System had to say about the topic…

http://asrs.arc.nasa.gov/docs/cb/cb_440.pdf

Monday Accident & Lessons Learned: Aviation Safety Reporting System CALLBACK Notice About Ramp Safety

October 17th, 2016 by

CALLBACK Report Ramp Safety

Here’s the start of the report …

This month CALLBACK features reports taken from a cross-section of ramp experiences. These excerpts illustrate a variety of ramp hazards that can be present. They describe the incidents that resulted and applaud the “saves” made by the Flight Crews and Ground Personnel involved.

For the complete report, see:

http://asrs.arc.nasa.gov/docs/cb/cb_439.pdf

Monday Accident & Lessons Learned: UK RAIB Report on Derailment at Paddington Station in London

October 10th, 2016 by

NewImage

Summary from the UK Rail Accident Investigation Branch …

At 18:12 hrs on Thursday 16 June 2016, a two-car diesel multiple unit train, operated by Great Western Railway (GWR), was driven through open trap points immediately outside Paddington station and derailed. It struck an overhead line equipment (OLE) mast, damaging it severely and causing part of the structure supported by the mast to drop to a position where it was blocking the lines. There were no passengers on the train, and the driver was unhurt. All the the lines at Paddington were closed for the rest of that evening, with some services affected until Sunday 19 June.

For causes and lessons learned, see: https://www.gov.uk/government/publications/paddington-safety-digest/derailment-at-paddington-16-june-2016

Monda Accident & Lessons Learned: US CSB Report on 2014 Freedom Industries Contamination of Charleston, West Virginia Drinking Water

October 3rd, 2016 by

Here is the press release from the US Chemical Safety Board …

NewImage

CSB Releases Final Report into 2014 Freedom Industries Mass Contamination of Charleston, West Virginia Drinking Water; Final Report notes Shortcomings in Communicating Risks to Public, and Lack of Chemical Tank Maintenance Requirements Report Includes Lessons Learned and Safety Recommendations to Prevent a Similar Incident from Occurring

September 28, 2016, Charleston, WV, — The CSB’s final report into the massive release of chemicals into this valley’s primary source of drinking water in 2014 concludes Freedom Industries failed to inspect or repair corroding tanks, and that as hazardous chemicals flowed into the Elk River, the water company and local authorities were unable to effectively communicate the looming risks to hundreds of thousands of affected residents, who were left without clean water for drinking, cooking and bathing.

On the morning of January 9, 2014, an estimated 10,000 gallons of Crude Methylcyclohexanemethanol (MCHM) mixed with propylene glycol phenyl ethers (PPH Stripped) were released into the Elk River when a 46,000-gallon storage tank located at the Freedom Industries site in Charleston, WV, failed. As the chemical entered the river it flowed towards West Virginia American Water’s intake, which was located approximately 1.5 miles downstream from the Freedom site.

The CSB’s investigation found that Freedom’s inability to immediately provide information about the chemical characteristics and quantity of spilled chemicals resulted in significant delays in the issuance of the “Do Not Use Order” and informing the public about the drinking water contamination. For example, Freedom’s initially reported release quantity was 1,000 gallons of Crude MCHM.  Over the following days and weeks, the release quantity increased to 10,000 gallons. Also, the presence of PPH in the released chemical was not made public until 13 days after the initial leak was discovered.

The CSB’s investigation found that no comprehensive aboveground storage tank law existed in West Virginia at the time of the release, and while there were regulations covering industrial facilities that required Freedom to have secondary containment, Freedom ultimately failed to maintain adequate pollution controls and secondary containment as required.

CSB Chairperson Vanessa Allen Sutherland said, “Future incidents can be prevented with proper communication and coordination.  Business owners, state regulators and other government officials and public utilities must work together in order to ensure the safety of their residents. The CSB’s investigation found fundamental flaws in the maintenance of the tanks involved, and deficiencies in how the nearby population was told about the risks associated with the chemical release.” 

An extensive technical analysis conducted by the CSB found that the MCHM tanks were not internally inspected for at least 10 years before the January 2014 incident. However, the CSB report notes, since the incident there have been a number of reforms including passage of the state’s Aboveground Storage Tank Act.  Among other requirements, the new regulations would have required the tanks at freedom to be surrounded by an adequate secondary containment structure, and require proper maintenance and corrosion prevention, including internal inspections and a certification process.

The CSB’s investigation determined that nationwide water providers have likely not developed programs to determine the location of potential chemical contamination sources, nor plans to respond to incidents such as the one in Charleston, WV. 
Supervisory Investigator Johnnie Banks said, “The public deserves and must demand clean, safe drinking water. We want water systems throughout the country to study the valuable lessons learned from our report and act accordingly. We make specific recommendations to a national association to communicate these findings and lessons.” 

(more…)

Monday Accident & Lessons Learned: Fatigue

September 26th, 2016 by

Here is a link (click of picture below) to a Callback publication about accidents and Fatigue …

Fatigue Callback

Here is a quote:

“The NTSB 2016 “Most Wanted List” of Transportation Safety Recommendations leads with, ‘Reduce Fatigue-Related Accidents.” It states, “Human fatigue is a serious issue affecting the safety of the traveling public in all modes of transportation.’”

Monday Accident & Lessons Learned: Overspeed at Fletton Junction

September 19th, 2016 by

This incident notice is from the UK Rail Investigation Branch about an overspeed incident at Fletton Junction, Peterborough on 11 September 2015.

At around 17:11 hrs on 11 September 2015, the 14:25 hrs Virgin Trains East Coast passenger train service from Newcastle to London King’s Cross passed through Fletton Junction, near Peterborough at 51 mph (82 km/h) around twice the permitted speed of 25 mph (40 km/h). This caused the carriages to lurch sideways resulting in minor injuries to three members of staff and one passenger.

It is likely that the train driver had forgotten about the presence of the speed restriction because he was distracted and fatigued due to issues related to his family. Lineside signs and in-cab warnings may have contributed to him not responding appropriately as he approached the speed restriction and engineering controls did not prevent the overspeeding. Neither Virgin Trains East Coast, nor the driver, had realised that family-related distraction and fatigue were likely to be affecting the safety of his driving. Virgin Trains East Coast route risk assessment had not recognised the overspeeding risks particular to Fletton Junction and Network Rail had not identified that a speed limit sign at the start of the speed restriction was smaller than required by its standards.

Screen Shot 2016 08 01 at 4 32 25 PM

The incident could have had more serious consequences if the train had derailed or overturned. The risk of this was present because the track layout was designed for a maximum speed of 27 mph (43 km/h).
As a consequence of this investigation, RAIB has made five recommendations. Two addressed to Virgin Trains East Coast relate to enhancing the management of safety critical staff with problems related to their home life, and considering such issues during the investigation of unsafe events.

A recommendation addressed to Virgin Trains East Coast and an associated recommendation addressed to Network Rail relate to assessing and mitigating risks at speed restrictions.

A further recommendation to Network Rail relates to replacement of operational signage when this is non-compliant with relevant standards.

RAIB report also includes learning points relating to managing personal problems that could affect the safety performance of drivers. A further learning point, arising because of a delay in reporting the incident, stresses the importance of drivers promptly reporting incidents which could have caused track damage. A final learning point encourages a full understanding of the effectiveness of safety mitigation provided by infrastructure and signalling equipment.

For more information see:

R142016_160801_Fletton_Jn

Monday Accident & Lessons Learned: Baby Dies After Oxygen Mix-Up at Hospital in Australia

September 12th, 2016 by

Image008

Here’s a link to the story: http://www.abc.net.au/news/2016-07-25/baby-dies-at-bankstown-lidcombe-hospital-after-oxygen-mix-up/7659552

An Oxygen line had been improperly installed in 2015. It fed nitrous oxide to a neonatal resuscitation unit rather than oxygen.

The Ministry of Health representative said that all lines in all hospitals in New South Wales installed since the Liberal government took over in 2011 will be checked for correct function. 

What can you learn from this?

Think about your installation and testing of new systems. How many Safeguards are in place to protect the targets?

Monday Accident & Lessons Learned: Freight train collision near Logan, UK

September 5th, 2016 by

Screen Shot 2016 07 21 at 5 02 52 PM

From the UK Rail Accident Investigation Branch

On 1 August 2015 at about 11:11 hrs, a freight train travelling within a work site collided with the rear of a stationary freight train at 28 mph (45 km/h).

Engineering staff had authorised the driver of the moving freight train to enter the work site at New Cumnock station, travel about 3 miles (4.8 km) to the start of a track renewal site, and bring the train to a stand behind the stationary train.

There were no injuries but the locomotive and seven wagons from the moving train and eleven wagons from the stationary train were derailed; the locomotive and derailed wagons were damaged. One wagon came to rest across a minor road. There was also substantial damage to the track on both railway lines.

The immediate cause was that the moving train was travelling too fast to stop short of the rear of the stationary train when its driver first sighted the train ahead. This was due to a combination of the train movement in the work site not taking place at the default speed of 5 mph (8 km/h) or at caution, as required by railway rules, and the driver of the moving train believing that the stationary train was further away than it actually was.

An underlying cause was that drivers often do not comply with the rules that require movements within a work site to be made at a speed of no greater than 5 mph (8 km/h) or at caution.

As a consequence of this investigation, RAIB has made four recommendations addressed to freight operating companies.

One relates to the monitoring of drivers when they are driving trains within possessions and work sites.
Two recommendations relate to implementing a method of formally recording information briefed to drivers about making train movements in possessions and work sites.

A further recommendation relates to investigating the practicalities of driving freight trains in possessions and work sites for long distances at a speed of 5 mph (8 km/h) or at other slow speeds, and taking action to address any identified issues.

RAIB has also identified three learning points including:

the importance of providing drivers with all of the information they need to carry out movements in possessions and work sites safelya reminder to provide drivers (before they start a driving duty) with information about how and when they will be relievedthe importance of engineering staff giving instructions to drivers through a face to face conversation when it is safe and practicable to do so.

R132016_160713_Logan

 

Monday Accident & Lessons Learned: Passenger Trapped & Dragged by Train

August 29th, 2016 by

Screen Shot 2016 06 30 at 1 44 46 PM

From the Rail Accident Investigation Branch …

At around 13:10 hrs on 25 July 2015, a passenger was dragged along the platform at Hayes & Harlington station, London, when the 11:37 hrs First Great Western service from Oxford to London Paddington departed while her hand was trapped in a door. The passenger, who had arrived on the platform as the doors were about to close, had placed her hand between the closing door leaves.

The train driver did not identify that the passenger was trapped and the train moved off, dragging the passenger along the platform. After being dragged for about 19 metres, the passenger lost her footing and fell onto the platform. The passenger suffered head, hand and back injuries.

RAIB’s investigation found that the passenger had deliberately placed her hand in the closing door in the expectation that it would re-open as a consequence. RAIB has concluded that after closing the doors of the train, the driver either did not make a final check that it was safe to depart, or that the check was insufficiently detailed to allow him to identify the trapped passenger. The driver may have been misled into thinking that it was safe to depart because a door interlock light in his cab had illuminated, indicating that the doors were closed and locked and he was able to take power.

Our investigation identified that the train driver and other railway staff held the same misunderstanding: if someone had a hand trapped in a door it would not be possible for the door interlock light to illuminate and a driver to take power. This is not the case, and the door was found to be compliant with all applicable standards after the accident.

As a consequence of this investigation, RAIB has made two recommendations.
The first, addressed to RSSB to review, and if necessary extend, its research into the passenger/train interface to understand passenger behaviour and identify means for deterring members of the public from obstructing train doors.

The second recommendation is addressed to operators and owners of trains similar to the one involved in the accident at Hayes & Harlington, is intended to continue and expand upon a current review into the practicability of fitting sensitive door edge technology to this type of train.
RAIB has also identified three learning points. The first concerns improving awareness among train drivers of the limitations of train door interlocking technology and the importance of the final safety check when dispatching a train.

The second concerns the potential for drivers to be distracted by the use of mobile communication devices while driving.

The third is aimed at train operators to have the necessary processes in place to identify drivers who are showing signs of sub-standard performance or not engaging positively with measures agreed as part of a Competence Development Plan and the provision of briefing and guidance material for driver managers to enable them to identify behaviours and attitudes which are inconsistent with those expected of train drivers.

For the complete report, see:

https://assets.publishing.service.gov.uk/media/577395aded915d622c0000c9/R122016_160630_Hayes_and_Harlington.pdf

Monday Accident & Lessons Learned: CORROSION COUPON PLUG EJECTED FROM PRESSURIZED PIPELINE

August 22nd, 2016 by

The following is a IOPG Safety Alert from the International Association of Oil & Gas Producers…

IOGP SAFETY ALERT

CORROSION COUPON PLUG EJECTED FROM PRESSURISED PIPELINE

Target audience:

Personnel accountable or responsible for pipelines and piping fitted with corrosion coupons.

What happened:

A routine corrosion coupon retrieval operation was being conducted on a 28” crude oil pipeline. Two retrieval technicians were located in a below ground access pit, to perform the operation. The operation involved removal of the corrosion coupon carrier ‘plug’ from its threaded 2” access fitting on the pipeline. The plug was ejected at high velocity from the access fitting (pipeline pressure 103 bar), during the operation to ease the plug using a ring spanner to a maximum of ¼ turn (as per procedure) and before the service valve and retrieval tool were installed. A high volume of crude oil spilled from the pipeline via the access fitting. Fortunately, the two technicians escaped the access pit without injury from the plug projectile or crude oil release.

What Went Wrong?

The Venture is still in the process of conducting the incident investigation. Based on their findings to date, the most probable cause is that the threads of the access fitting were worn down to such an extent, that they were unable to restrain the plug upon minor disturbance (the ¼ turn of the plug).

  • The access fitting was installed during pipeline construction in 1987. It is estimated to have been subject to over 140 coupon retrieval and installation cycles.
  • Bottom-of-pipeline debris can cause galling of threads on stainless steel plugs, which in turn can damage the threads of carbon steel access fittings.
  • The repair (chasing) of worn threads on access fittings is performed using an original equipment manufacturer supplied thread tap assembly service tool.
  • In the presence of bottom-of-pipeline debris and thread damage, the repetitive removal of internal thread material, can lead to ever smaller contact surfaces, increasing contact stress, increasing wear rates and/or galling.
  • Smaller thread contact surfaces reduce the ability of the access fittings to restrain plugs.
  • In this incident, the original equipment manufacturer supplied thread tap assembly service tool had been used routinely for every plug coupon retrieval and installation cycle without the use of flushing oil to remove debris from the threads.

Corrective Actions and Recommendations:

Lessons Learned –

  • As yet, there is no standard method to determine internal thread condition of on-line corrosion probe/coupon original equipment manufacturer access fittings. Thread condition is not easily inspected.
  • The risk posed by long term use of thread tap assembly service tools on access fittings, has not been previously identified.

Action taken in originating company –

Temporarily suspend all corrosion coupon retrieval operations on pressurised lines furnished with threaded access fittings in the 6 o’clock position (bottom of pipeline). This provides time to complete the investigation and complete work with the original equipment manufacturer to develop clear guidance on the maximum number of retrieval cycles.

  • A subsequent notification will be issued based on the completed investigation and original equipment manufacturer tests*. In this alert any changes to guidance or maintenance routines (i.e. how and when these type operations can be recommenced) will be advised.
  • The temporary suspension does not cover retrieval operations on lines which are depressurised.

* the use of ‘no go’ gauges for checking access fittings after every use of a thread tap assembly service tool or access fitting body seat reamer, is being explored.

Disclaimer

Whilst every effort has been made to ensure the accuracy of the information contained in this publication, neither the IOGP nor any of its members past present or future warrants its accuracy or will, regardless of its or their negligence, assume liability for any foreseeable or unforeseeable use made thereof, which liability is hereby excluded. Consequently, such use is at the recipient’s own risk on the basis that any use by the recipient constitutes agreement to the terms of this disclaimer. The recipient is obliged to inform any subsequent recipient of such terms.This document may provide guidance supplemental to the requirements of local legislation. Nothing herein, however, is intended to replace, amend, supersede or otherwise depart from such requirements. In the event of any conflict or contradiction between the provisions of this document and local legislation, applicable laws shall prevail.

Safety Alert Number: 273 

IOGP Safety Alerts http://safetyzone.iogp.org

Monday Accident & Lessons Learned: Five Items To Remember When Using a Checklist

August 15th, 2016 by

Another great article from NASA’s Aviation Safety Reporting System that applies to a much broader audience than just aviation folks. If you use checklists, there something to be learned from this article. Click on the picture of the article below to read more…

Screen Shot 2016 06 28 at 4 01 44 PM

Connect with Us

Filter News

Search News

Authors

Angie ComerAngie Comer

Software

Barb PhillipsBarb Phillips

Editorial Director

Chris ValleeChris Vallee

Six Sigma

Dan VerlindeDan Verlinde

VP, Software

Dave JanneyDave Janney

Safety & Quality

Gabby MillerGabby Miller

Marketing

Garrett BoydGarrett Boyd

Technical Support

Ken ReedKen Reed

VP, Equifactor®

Linda UngerLinda Unger

Co-Founder

Mark ParadiesMark Paradies

Creator of TapRooT®

Per OhstromPer Ohstrom

VP, Sales

Shaun BakerShaun Baker

Technical Support

Steve RaycraftSteve Raycraft

Technical Support

Wayne BrownWayne Brown

Technical Support

Success Stories

In 1995, BellSouth Telecommunications noticed an increase in the number of service interruptions or outages…

Bell South

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

Canyon Fuel Company
Contact Us