Author Archives: Mark Paradies

The Best Incident Investigation Performance Indicator

Posted: July 18th, 2018 in Investigations, Performance Improvement, Root Cause Analysis Tips

NewImage

If an incident investigation and the corrective actions are effective, it will prevent, or significantly reduce the likelihood or consequences of, a repeat incident.

If we want to monitor the effectiveness of our incident investigation, root cause analysis, and corrective action processes, probably the best performance indicator is monitoring the rate of repeat incidents.

If an incident (or even a Causal Factor) is a repeat, it indicates that there was a problem with the previous investigation. For example:

  • Was the root cause analysis inadequate?
  • Were the corrective actions ineffective?
  • Why didn’t management or peer review catch the problem with the previous investigation?

Of course, the question that is tough to answer is … What is a repeat incident (or Causal Factor).

Judging repeat incidents takes some soul searching. The real question is, should have the previous incident investigation prevented the current incident.

Here are two examples:

  • Should the investigation and corrective actions for the Challenger Space Shuttle accident have prevented the Columbia Space Shuttle accident?
  • Should the BP Texas City fire and explosion accident investigation have prevented the BP Deepwater Horizon accident?

You be the judge.

What is the rate for your facility? Do you have 80% repeats? 10%? 0.1%?

Each repeat incident provides a learning opportunity to improve your incident investigation, root cause analysis, corrective action, and incident review processes. Are you using these opportunities to improve your system?

Management System

Posted: July 11th, 2018 in RCA Tip Videos, Root Causes, TapRooT

Screen Shot 2018 05 24 at 10 02 52 PM

Back in 1985, my boss suggested I (Mark Paradies) look at better ways to analyze and trend root causes. I already understood human factors (from training for my master’s degree from the University of Illinois) and equipment reliability (from my experience in the Nuclear Navy). Therefore, I had a good start on the knowledge I needed to develop a system for root cause analysis.

The very first system I developed had a category (today we would call it a Basic Cause Category) of Leadership.

When I showed the system to my boss and he saw the Leadership category, he said:

“You have to take that out.”

He explained that senior management would go nuts if we said there was a leadership issue. We argued for quite a while. I said that management would just have to accept that they, too, could improve. He explained that I had done such a good job NOT having blame categories in the system that I shouldn’t have a blame category for leadership and that’s how the company’s management would view a Leadership category.

Eventually, he convinced me that we could come up with a better name. He wanted to call it “Organizational Factors.” I said that it should be “Management.” He said that was just as bad as Leadership. He wanted to call it “Systems.” I thought that clouded the responsibility for where the changes needed to be made. Finally I suggested “Management System.” It took a while, but he finally agreed.

After several management presentations and several discussions with senior management, we finally got approval for the “Management System” category.

Little did I know that we had invented a term that would be used around the world.

The first place it spread to was INPO (Institute of Nuclear Power Operation). I had interviewed for a job there and they had tried to hire me but I had already taken another job. However, I stayed in contact with Joe Bishop who was in charge of developing the HPES (Human Performance Evaluation System) system for INPO. When they had a version of the system ready, he sent me a copy for review. I commented that they had missed the Management System causes. Sure enough, my work on Management System made it into INPO’s HPES system.

From there, the terminology spread throughout the U.S. nuclear industry and to nuclear plants around the world.

Once I started System Improvements in 1988, the terminology started spreading to other industries. Refining, chemicals, oil exploration and production, and other industries. By the early 1990s, TapRooT® was adopted by industry leaders around the world. And the terminology “Management System” went with it.

Then, I began hearing the term at professional society meetings. People started insisting that to find root causes you needed to find “management system” causes. I thought this was interesting. Where had the term “management system” come from?

I researched the term on the internet and couldn’t find any references prior to the meeting I had with my boss back in 1986. In fact, it looked like the terminology had started to be used in the mid-1990s.

I can’t prove it but I think the terminology came from that meeting with my boss, Rod Satterfield. And that is how the Management System terminology got started.

If you would like to learn more about the Management System, all you need to do is read about it in the TapRooT® Root Cause Tree® Dictionary. You will receive a copy of the dictionary and will learn how to use it in any of our TapRooT® 2-Day or 5-Day Courses.

Monday Accident & Lessons Learned: Fatal Accident While Unloading a Truck

Posted: July 9th, 2018 in Accidents, Current Events, Pictures, Video

WKBW TV reported that two employees were killed when a stack of Corian counter tops that weighed 800 pounds per slab (11 slabs total) fell on them. The accident occurred at 1:30 a.m. and the employees were pronounced dead at the scene.

The company issued a statement that said:

“We’re saddened to report that a tragic accident occurred this morning at our facility in Lockport, NY that resulted in the death of two of our colleagues. We’re working with our safety team and local law enforcement to understand the circumstances under which this tragedy occurred. Our deepest sympathies are with their families and our Lockport team members.”

OSHA will be conducting an investigation of the deaths. OSHA has investigated two other serious injuries at XPO facilities elsewhere in New York state.

What was the Hazard in this accident?

The heavy, high-piled load.

Who were the targets?

The two employees.

What were the Safeguards?

From the newspaper articles, we don’t know.

We also don’t know any of the reasons for the Safeguard’s failure.

The root cause analysis will have to determine the Safeguards, why they failed, and if they were sufficient. (Do we need additional Safeguards?)

In the TapRooT® System, a SnapCharT® would be used to collect and organize the information about what happened.

Then the failed Safeguards would be identified.

Next, the failed Safeguards (Causal Factors) would be analyzed to find their root causes using the Root Cause Tree® Diagram.

Once the root causes for all the Safeguards were found, the team would start developing corrective actions.

The Safeguards would be reviewed to see if after they were strengthened, if they would be adequate. If they would not be adequate, either additional Safeguards would be developed or the process could be modified to reduce or remove the hazard. For example, stack the counter tops no more that 16 inches high.

To improve the Safeguards that failed, you would address each of the root causes by developing SMARTER corrective actions using the Corrective Action Helper® Module of TapRooT® Software.

What is a SMARTER corrective action?

Specific

Measurable

Accountable

Reasonable

Timely

Effective

Reviewed

To learn more about the TapRooT® System, SnapCharT®, Safeguard Analysis, Causal Factors, the Root Cause Tree® Diagram, the Corrective Action Helper® Module, the TapRooT® Software, and SMARTER, attend one of our 2-Day or 5-Day TapRooT® Courses. Here is a list of the dates and locations of the courses being held around the world:

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

Happy 4th of July

Posted: July 4th, 2018 in Current Events, Pictures

4th

In the US we celebrate declaring our independence from The British crown on the 4th of July. It was a great risk for a minor colony to stand up to the world’s mightiest power. Perhaps were were foolish or you might say reckless … but the outcome was a system without a king and with a constitution that affirmed and guaranteed our God given rights.

So today when you are celebrating somewhere in the US, remember those who risked all for the freedoms we enjoy today and those who stand ready to do that today.

Happy Independence Day!

One Safeguard Eliminated = Death

Posted: July 3rd, 2018 in Accidents, Current Events, How Far Away Is Death?, Video

Watch the video and see what could have been done to avoid a fatality…

I think there was an obvious Safeguard missing. What was it?

Practice, Feedback, & Improve (Develop Skills)

Posted: June 27th, 2018 in Courses, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT, Training

With any new skill that you learn, you need practice to implant the skill into long term memory. To get better at the skill, you need more practice and feedback (coaching).

The same is true of the skills you learn in a TapRooT® Course. You need to practice your new investigation and root cause analysis skills and get feedback (coaching) on ways to improve what you are doing.

Who will provide you with that feedback? Here are some ideas:

  1. Set up a peer review group. The members of this group should attend the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training and have experience doing investigations.
  2. Have a senior manager become an expert in root cause analysis and provide feedback on investigations when performing senior manager reviews.
  3. Have experts from System Improvements review your incident investigations as they progress, CONTACT US to find out how to get these reviews scheduled.

If you have only attended the 2-Day TapRooT® Root Cause Analysis Course, consider attending the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. You will get more practice with the essential TapRooT® Techniques and learn the advanced techniques including:

  • Cognitive interviewing techniques
  • Critical Human Action Profile (CHAP)
  • Change Analysis
  • Proactive use of Safeguard Analysis
  • Equifactor® Equipment Troubleshooting

Plus you will discuss human error and ways to improve human performance.

Here is a link to the upcoming public 5-Day TapRooT® Training schedule for courses held around the world:

http://www.taproot.com/store/5-Day-Courses/

For anyone interested in advanced root cause analysis training, CLICK HERE for more information.

Monday Accident & Lessons Learned: What Does a Human Error Cost? A £566,670 Fine in the UK!

Posted: June 25th, 2018 in Accidents, Current Events, Human Performance, Performance Improvement, TapRooT

Dump truck(Not actual truck, For illustration only.)

The UK HSE fined a construction company £566,670 after a dump truck touched (or came near) a power line causing a short.

No one was hurt and the truck suffered only minor damage.

The drive tried to pull forward to finish dumping his load and caused a short.

Why did the company get fined?

“A suitable and sufficient assessment would have identified the need to contact the Distribution Network Operator, Western Power, to request the OPL’s were diverted underground prior to the commencement of construction. If this was not reasonably practicable, Mick George Ltd should have erected goalposts either side of the OPL’s to warn drivers about the OPL’s. “

That was the statement from the UK HSE Inspector as quoted in a hazarded article.

What Safeguards do you need to keep a simple human error from becoming an accident (or a large fine)?

Performing a Safeguard Analysis before starting work is always a good idea. Learn more about using Safeguard Analysis proactively at our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. See the upcoming public course dats around the world at:

http://www.taproot.com/store/5-Day-Courses/

The History of the Definition of a Root Cause

Posted: June 20th, 2018 in Performance Improvement, Root Cause Analysis Tips, TapRooT

 

When I started digging into problem-solving back in 1985, people used the term “root cause” but I couldn’t find a definition for the term. I knew some pretty knowledgable people so I asked them for their definition. They explained what they called a root cause but I found significant variation between these experts’ definitions.

Therefore, David Busch and I (Mark Paradies) started doing research to develop a definition for a root cause. And this is the definition we created back in late 1985 or early 1986:

ROOT CAUSE

The most basic cause(s) that can reasonably be identified
and that management has control to fix.

As TapRooT® was being developed by Mark Paradies and Linda Unger in the early 1990’s, we added to this early definition and the definition was “improved” to:

ROOT CAUSE

A root cause is
the most basic cause (or causes)
that can reasonably be identified
that management has control to fix
and, when fixed, will prevent
(or significantly reduce the likelihood of)
the problem’s recurrence.

That definition was starting to be a mouthful.

Some have added our terminology “management system” into the definition to show that the most basic cause must be a management system cause. We never really thought that was necessary.

By 2005, Linda Unger and Mark Paradies realized that the definition that they had developed for a root cause made an incident investigation look negative. We were looking for causes of problems. People would get into arguments about “management’s ability to fix a problem” when what we really meant was that the problem was fixable. We needed a better definition that was focused on improvement. Therefore, in 2006, we published this version of a definition of a root cause:

ROOT CAUSE

A Root Cause is
the absence of a best practice
or the failure to apply knowledge
that would have prevented the problem.

What is the difference between our old (and some would say industry standard) definition and our 2006 definition?

The new definition focuses more on the positive. We are searching for best practices and knowledge to prevent problems. We aren’t looking for people to blame or management failures. We are going to find ways to perform work more reliably. This is a focus on improvement.

One more note … The new definition is rather absolute. The words “would have prevented” should probably also include the phrase “or significantly reduced the likelihood of” because, in real life, it is probably impossible to guarantee that a problem will be prevented from EVER happening again. But we have’t modified the definition because we wanted the emphasis to remain as definite as possible even though we realize that a 100% guarantee probably is NOT possible.

So, now when you see the definition of a root cause and it looks very similar to the first two definitions, you will know who the original authors were and where the ideas came from.

You will also know that there is a more advanced definition that focuses on improvement.

TapRooT® Users have always been a step (or maybe many steps) ahead of other problem solvers. Even when it comes to the definition of a root cause.

Want to learn more about the TapRooT® Root Cause Analysis System? Attend one of our courses:

http://www.taproot.com/courses

Monday Accident & Lessons Learned: Why is Right of Way Maintenance Important?

Posted: June 18th, 2018 in Accidents, Current Events, Equipment/Equifactor®, Investigations, Pictures

Here is another example of why right of way maintenance is important for utility transmission and distribution departments …

Wildfires

An article on hazardex reported that the California Department of Forestry and Fire Protection (Cal Fire) said in a press release that 12 of the wildfires that raged across California’s wine country were due to tree branches touching PG&E power lines.

Eight of the 12 fires have been referred to county District Attorney’s offices for potential criminal prosecution for alleged violations of California laws.

The fires last October killed 44 people, burned more than 245,000 acres, and cost at least $9.4 billion dollars of insured losses. PG&E has informed it’s shareholders that it could be liable costs in excess of the $800 million in insurance coverage that it has for wildfires.

PG&E is lobbying state legislators for relief because they are attributing the fires to climate change and say they should not be held liable for the damage.

What lessons can you learn from this?

Sometimes the cost of delayed maintenance is much higher than the cost of performing the maintenance.

Can you tell which maintenance is safety critical?

Do you know the risks associated with your deferred maintenance?

Things to think about.

TapRooT® Users – Use It ALL

Posted: June 13th, 2018 in Performance Improvement, Pictures, Root Cause Analysis Tips, Summit, TapRooT

NewImage

I had an interesting question from a TapRooT® user the other day.

“When will you be adding something to TapRooT® to deal with human performance issues?”

I had to stop and think. Of course, our whole design effort was to make TapRooT® the world’s best system for analyzing and fixing problems due to human error. But I realized that we had made the use of TapRooT® so transparent that this user, and probably others, didn’t know what they had.

They might not know that TapRooT® can them help fix:

  • human errors
  • human performance issues
  • company culture problems
  • behavior issues
  • management system failures
  • simple incidents
  • complex accidents
  • audit findings

TapRooT® can be used reactively (after an accident) or proactively (before a major accident). The application of TapRooT® is really flexible.

We’ve made this flexibility and applicability completely transparent. You don’t have to be a human performance expert (a Certified Ergonomist – like I am) to use the system and get great results.

We’ve made difficult analysis so easy that people don’t know all the power they have.

How can a TapRooT® User learn more about what they have?

  1. Read the blog and the weekly TapRooT® Friends & Experts Newsletter. Sign up for the newsletter HERE.
  2. Join the TapRooT® LinkedIn discussion group HERE.
  3. Attend advanced TapRooT® Training – the 5-Day TapRooT® Advanced Team Leader Training.
  4. Attend the annual Global TapRooT® Summit.
  5. Read TapRooT® Root Cause Analysis Leadership Lessons.

That’s a good start and two of the ideas are free.

Get as much as you can from the tools and processes that you already know – TapRooT®.

And if you have any questions, leave them as a comment here or contact us by CLICKING HERE.

New Study Suggests Poor Officer Seamanship Training Across the Navy – Is This a Generic Cause of 2017 Fatal Navy Ship Collisions?

Posted: June 7th, 2018 in Accidents, Current Events, Human Performance, Investigations, Pictures

BLAME IS NOT A ROOT CAUSE

It is hard to do a root cause analysis from afar with only newspaper stories as your source of facts … but a recent The Washington Times article shed some light on a potential generic cause for the fatal collisions last year.

The Navy conducted an assessment of seamanship skills of 164 first-tour junior officers. The results were as follows

  • 16% (27 of 164) – no concerns
  • 66% (108 of 164) – some concerns
  • 18% (29 of 164) – significant concerns

With almost 1 out of 5 having significant concerns, and two thirds having some concerns, it made me wonder about the blame being placed on the ship’s Commanding Officers and crew. Were they set up for failure by a training program that sent officers to sea who didn’t have the skills needed to perform their jobs as Officer of the Deck and Junior Offiicer of the Deck?

The blame heavy initial investigations certainly didn’t highlight this generic training problem that now seems to be being addressed by the Navy.

Navy officers who cooperated with the Navy’s investigations faced court martials after cooperating.

NewImage

According to and article in The Maritime Executive Lt j.g. Sarah Coppock, Officer of the Deck during the USS Fitzgerald collision, pled guilt to charges to avoid facing a court martial. Was she properly trained or would have the Navy’s evaluators had “concerns” with her abilities if she was evaluated BEFORE the collision? Was this accident due to the abbreviated training that the Navy instituted to save money?

Note that in the press release, information came out that hadn’t previously been released that the Fitzgerald’s main navigation radar was known to be malfunctioning and that Lt. j.g. Coppock thought she had done calculations that showed that the merchant ship would pass safely astern.

NewImage

In other blame related news, the Chief Boatswains Mate on the USS McCain plead guilty to dereliction of duty for the training of personnel to use the Integrated Bridge Navigation System, newly installed on the McCain four months before he arrived. His total training on the system was 30 minutes of instruction by a “master helmsman.” He had never used the system on a previous ships and requested additional training and documentation on the system, but had not received any help prior to the collision.

He thought that the three sailors on duty from the USS Antietam, a similar cruiser, were familiar with the steering system. However, after the crash he discovered that the USS McCain was the only cruiser in the 7th fleet with this system and that the transferred sailors were not familiar with the system.

On his previous ship Chief Butler took action to avoid a collision at sea when a steering system failed during an underway replenishment and won the 2014 Sailor of the Year award. Yet the Navy would have us believe that he was a “bad sailor” (derelict in his duties) aboard the USS McCain.

NewImage

Also blamed was the CO of the USS McCain, Commander Alfredo J. Sanchez. He pleaded guilty to dereliction of duty in a pretrial agreement. Commander Sanchez was originally charged with negligent homicide and hazarding a vessel  but both other charges were dropped as part of the pretrial agreement.

Maybe I’m seeing a pattern here. Pretrial agreements and guilty pleas to reduced charges to avoid putting the Navy on trial for systemic deficiencies (perhaps the real root causes of the collisions).

Would your root cause analysis system tend to place blame or would it find the true root and generic causes of your most significant safety, quality, and equipment reliability problems?

The TapRooT® Root Cause Analysis System is designed to look for the real root and generic causes of issues without placing unnecessary blame. Find out more at one of our courses:

http://www.taproot.com/courses

Is Blame Built Into Your Root Cause System?

Posted: June 6th, 2018 in Human Performance, Performance Improvement, Pictures, Root Cause Analysis Tips, Root Causes, TapRooT

Blame

If you want to stop good root cause analysis, introduce blame into the process.

In recent years, good analysts have fought to eliminate blame from root cause analysis. But there are still some root cause systems that promote blame. They actually build blame into the system.

How can this be? Maybe they just don’t understand how to make a world-class root cause analysis system.

When TapRooT® Root Cause Analysis was new, I often had people ask:

“Where is the place you put ‘the operator was stupid?'”

Today, this question might make you laugh. Back in the day, I spent quite a bit of time explaining that stupidity is not a root cause. If you hire stupid people, send them through your training program, and qualify them, then that is YOUR problem with your training program.

The “stupid people” root cause is a blame-oriented cause. It is not a root cause.

Logo color no lines no text copy

What is a root cause? Here is the TapRooT® System definition:

Root Cause
The absence of best practices
or the failure to apply knowledge
that would have prevented the problem. 

Are there systems with “stupid people” root causes? YES! Try these blame categories:
    • Attitude
    • Attention less than adequate
    • Step was omitted due to mental lapse
    • Individual’s capabilities to perform work less than adequate
    • Improper body positioning
    • Incorrect performance due to a mental lapse
    • Less than adequate motor skills
    • Inadequate size or strength
    • Poor judgment/lack of judgment/misjudgment
    • Reasoning capabilities less than adequate
    • Poor coordination
    • Poor reaction time
    • Emotional overload
    • Lower learning aptitude
    • Memory failure/memory lapse
    • Behavior inadequate
    • Violation by individual
    • Inability to comprehend training
    • Insufficient mental capabilities
    • Poor language ability
    • In the line of fire
    • Inattention to detail
    • Unawareness
    • Mindset

You might laugh at these root causes but they are included in real systems that people are required to use. The “operator is stupid” root cause might fit in the “reasoning capabilities less than adequate,” the “incorrect performance due to mental lapse,” the “poor judgment/lack of judgment,” or the “insufficient mental capabilities” categories.

You may ask:

“Couldn’t a mental lapse be a cause?”

Of course, the answer is yes. Someone could have a mental lapse. But it isn’t a root cause. Why? It doesn’t fit the definition. It isn’t a best practice or a failure to apply knowledge. We are supposed to develop systems that account for human capabilities and limitations. At best, a memory lapse would be part of a a Causal Factor.

To deal with human frailties, we implement best practices to stop simple memory lapses from becoming incidents. In other words, that’s why we have checklists, good human engineering, second checks when needed, and supervision. The root causes listed on the back side of the TapRooT® Root Cause Tree® are linked to human performance best practices that make human performance more reliable so that a simple memory lapse doesn’t become an accident.

What happens when you make a pick list with blame categories like those in the bulleted list above? The categories get overused. It is much easier to blame the operator (they had less than adequate motor skills) than to find out why they moved the controls the wrong way. Its easy to say there was a “behavior issue.” It is difficult to understand why someone behaved the way they did. TapRooT® looks beyond behavior and simple motor skill error to find real root causes.

We have actually tested the use of “blame categories” in a system and shown that including blame categories in an otherwise good system causes investigators to jump to conclusions and select these “easy to pick” blame categories rather than applying the investigative effort required to find real root causes.

You may think that if you don’t have categories, you have sidestepped the problem of blame. WRONG! Blame is built into our psyche. Most cause-and-effect examples I see have some blame built into the analysis.

If you want to successfully find the real, fixable root causes of accidents, precursor incidents, quality issues, equipment failures, cost overruns, or operational failures, don’t start by placing blame or use a root cause system with built-in blame categories. Instead, use advanced root cause analysis – TapRooT®.

The best way to learn about advanced root cause analysis is in a 2-Day TapRooT® Root Cause Analysis Course or a 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. See the list of upcoming public courses here: http://www.taproot.com/store/Courses/.

Why do we still have major process safety accidents?

Posted: May 30th, 2018 in Accidents, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT

I had an interesting argument about root cause analysis and process safety. The person I was arguing with thought that 5-Whys was a good technique to use for process safety incidents that had low consequences.

Let me start by saying that MOST process safety incidents have low actual consequences. The reason they need to be prevented is that they are major accident precursors. If one or more additional Safeguards had failed, they would become a major accident. Thus, their potential consequences are high.

From my previous writings (a sample of links below), you know that I consider 5-Whys to be an inferior root cause analysis tool.

If you don’t have time to read the links above, then consider the results you have observed when people use 5-Whys. The results are:

  • Inconsistent (different people get different results when analyzing the same problem)
  • Prone to bias (you get what you look for)
  • Don’t find the root causes of human errors
  • Don’t consistently find management system root causes

And that’s just a start of the list of performance problems.

So why do people say that 5-Whys is a good technique (or a good enough technique)? It usually comes down to their confidence. They are confident in their ability to find the causes of problems without a systematic approach to root cause analysis. They believe they already know the answers to these simple problems and that it is a waste of time to use a more rigorous approach. Thus, their knowledge and a simple (inferior) technique is enough.

Because they have so much confidence in their ability, it is difficult to show them the weaknesses in 5-Whys because their answer is always:

“Of course, any technique can be misused,
but a good 5-Whys wouldn’t have that problem.”

And a good 5-Whys is the one THEY would do.

If you point out problems with one of their root cause analyses using 5-Why, they say you are nitpicking and stop the conversation because you are “overly critical and no technique is perfect.”

Of course, I agree. No technique is perfect. But some are much better than others. And the results show when the techniques are applied.

And that got me thinking …

How many major accidents had precursor incidents
that were investigated using 5-Whys and the corrective
actions were ineffective (didn’t prevent the major accident)?

Next time you have a major accident, look for precursors and check why their root cause analysis and corrective actions didn’t prevent the major accident. Maybe that will convince you that you need to improve your root cause analysis.

If you want to sample advanced root cause analysis, attend a 2-Day or a 5-Day TapRooT® Course.

The 2-Day TapRooT® Root Cause Analysis Course is for people who investigate precursor incidents (low-to-moderate consequences).

The 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course is for people who investigate precursor incidents (low-to-moderate consequences) AND perform major investigation (fatalities, fires, explosions, large environmental releases, or other costly events).

See the schedule for upcoming public courses that are held around the world HERE. Just click on your continent to see courses near you.

Why is TapRooT® Root Cause Analysis Software the Best Choice?

Posted: May 23rd, 2018 in Software, TapRooT

Screen Shot 2018 05 04 at 12 23 16 PM

If you are looking for the best root cause analysis software, here are some things to consider:

  1. How the software works is important, but the root cause analysis system that the software uses is probably THE MOST IMPORTANT part of picking your software. No matter how well a bad root cause tool is implemented in software … it is still a bad root cause analysis tool. Therefore, you should look for a world-class root cause analysis tool.
  2. It’s all in the cloud, baby! The days of software just working on one operating system are over. Now your software should be cloud-based and available on a multitude of devices. Mac or PC, laptop or tablet, even phones should be supported.
  3. Able to connect with other software. Does the software play well with others? The root cause analysis software should be able to connect with other ESHQ (Environment, Safety, Health, Quality), human resource, or performance monitoring systems.
  4. Custom reports. Reports the way that you and your management want them. Easy to develop and save. No special software required.
  5. Trends. Advanced trending techniques that help you measure and predict performance.

Sounds great. But where can you find these features? The TapRooT® Version VI Software (of course).

Screen Shot 2018 05 04 at 12 33 50 PM

First, the TapRooT® VI Software is based on the world-class TapRooT® Root Cause Analysis System. If you don’t know why TapRooT® stands head and shoulders above other root cause systems, you should attend our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training and find out. Learn to use SnapCharT® to investigate what happened and organize your evidence. Use Equifactor® to troubleshoot equipment failures. Use Safeguard Analysis to find all the Causal Factors. Use the Root Cause Tree® to find the real, fixable causes of human performance and equipment issues. and use the Corrective Action Helper® Module to develop effective fixes.

Screen Shot 2018 05 04 at 12 34 46 PM

Second, TapRooT® VI Software is cloud-based. You can subscribe as an individual; you can host the TapRooT® VI Software on your network; or we can host the software for your whole company. TapRooT® VI is device independent. Mac, tablet, smartphone. No problem. CONTACT US for more information.

Third, TapRooT® VI Software has an API. This allows easy connections to other software. Talk to our IT guys to find out more. Call 865-357-0080 or CLICK HERE.

Fourth, need a custom report? No problem when you are using TapRooT® VI Software. Have a look at this link to get some ideas … http://www.taproot.com/?s=custom+report.

Fifth, we have been teaching advanced trending techniques for 20 years and they are built into the TapRooT® VI Software. Here’s a short video on exporting trending data to Excel.

But there is more to consider when picking your root cause analysis software. Consider this:

How good is the training?

How good is the software support?

TapRooT® Training is highly rated by students around the world. See samples of what they have to say HERE.

What abut our software support? Outstanding! Our knowledgeable support staff is happy to help you figure things out.

Want more information about TapRooT® VI Software? Let’s do an online demo. CONTACT US to learn more.

Two Incidents in the Same Year Cost UK Auto Parts Manufacturer £1.6m in Fines

Posted: May 22nd, 2018 in Accidents, Investigations, Performance Improvement, Pictures

Screen Shot 2018 05 22 at 4 37 39 PM

Faltec Europe manufactures car parts in the UK. They had two incidents in 2015 related to health and safety.

The first was an outbreak of Legionnaires’ Disease due to a cooling water system that wasn’t being properly treated.

The second was an explosion and fire in the manufacturing facility,

For more details see:

http://press.hse.gov.uk/2018/double-investigation-leads-to-fine-for-north-east-car-parts-manufacturer-faltec-europe-limited/

The company was prosecuted by the UK HSE and was fined £800,000 for each incident plus £75,159.73 in costs and a victim surcharge of £120.

The machine that exploded had had precursor incidents, but the company had not taken adequate corrective actions.

Are you investigating your precursor incidents and learning from them to prevent major injuries/health issues, fires, and explosions?

Perhaps you should be applying advanced root cause analysis to find and fix the real root causes of equipment and human error related incidents? Learn more at one of our courses:

2-Day TapRooT® RooT® Cause Analysis Course

5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training

Want to see our courses in Europe? CLICK HERE.

You can attend our training at our public courses anywhere around the world. See the list by CLICKING HERE.

Would you like to sponsor a course at your site? Contact us for a quote by CLICKING HERE.

Avoid Big Problems By Paying Attention to the Small Stuff

Posted: May 16th, 2018 in Accidents, Courses, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT

Almost every manager has been told not to micro-manage their direct reports. So the advice above:

Avoid Big Problems By Paying Attention to the Small Stuff

may sound counter-intuitive.

Perhaps this quote from Admiral Rickover, leader of the most successful organization to implement process safety and organizational excellence, might make the concept clearer:

The Devil is in the details, but so is salvation.

When you talk to senior managers who existed through a major accident (the type that gets bad national press and results in a management shakeup), they never saw it coming.

A Senior VP at a utility told me:

It was like I was walking along on a bright sunny day and
the next thing I knew, I was at the bottom of a deep dark hole.

They never saw the accident coming. But they should have. And they should have prevented it. But HOW?

I have never seen a major accident that wasn’t preceded by precursor incidents.

What is a precursor incident?

A precursor incident is an incident that has low to moderate consequences but could have been much worse if …

  • One of more Safeguards had failed
  • It was a bad day (you were unlucky)
  • You decided to cut costs just one more time and eliminated the hero that kept things from getting worse
  • The sequence had changed just a little (the problem occurred on night shift or other timing changed)

These type of incidents happen more often than people like to admit. Thus, they give management the opportunity to learn.

What is the response by most managers? Do they learn? NO. Why? Because the consequences of the little incidents are insignificant. Why waste valuable time, money, and resources investigating small consequence incidents. As one Plant Manager said:

If we investigated  every incident, we would do nothing but investigate incidents.

Therefore, a quick and dirty root cause analysis is performed (think 5-Whys) and some easy corrective actions that really don’t change things that are implemented.

The result? It looks like the problem goes away. Why? Because big accidents usually have multiple Safeguards and they seldom fail all at once. It’s sort of like James Reason’s Swiss Cheese Model…

SwissCheese copy

The holes move around and change size, but they don’t line up all the time. So, if you are lucky, you won’t be there when the accident happens. So, maybe the small incidents repeat but a big accident hasn’t happened (yet).

To prevent the accident, you need to learn from the small precursor incidents and fix the holes in the cheese or add additional Safeguards to prevent the major accidents. The way you do this is by applying advanced root cause analysis to precursor incidents. Learn from the small stuff to avoid the big stuff. To avoid:

  • Fatalities
  • Serious injuries
  • Major environmental releases
  • Serious customer quality complaints
  • Major process upsets and equipment failures
  • Major project cost overruns

Admiral Rickover’s seventh rule (of seven) was:

The organization and members thereof must have the ability
and willingness to learn from mistakes of the past.

And the mistakes he referred to were both major accidents (which didn’t occur in the Nuclear Navy when it came to reactor safety) and precursor incidents.

Are you ready to learn from precursor incidents to avoid major accidents? Then stop trying to take shortcuts to save time and effort when investigating minor incidents (low actual consequences) that could have been worse. Start applying advanced root cause analysis to precursor incidents.

The first thing you will learn is that identifying the correct answer once is a whole lot easier that finding the wrong answer many times.

The second thing you will learn is that when people start finding the real root causes of problems and do real root cause analysis frequently, they get much better at problem solving and performance improves quickly. The effort required is less than doing many poor investigations.

Overall you will learn that the process pay for itself when advanced root cause analysis is applied consistently. Why? Because the “little stuff” that isn’t being fixed is much more costly than you think.

How do you get started?

The fastest way is by sending some folks to the 2-Day TapRooT® Root Cause Analysis Course to learn to investigate precursor incidents.

The 2-Day Course is a great start. But some of your best problem solvers need to learn more. They need the skills necessary to coach others and to investigate significant incidents and major accidents. They need to attend the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training.

Once you have the process started, you can develop a plan to continually improve your improvement efforts. You organization will become willing to learn. You will prove how valuable these tools are and be willing to become best in class.

Rome wasn’t built in a day but you have to get started to see the progress you need to achieve. Start now and build on success.

Would you like to talk to one of our TapRooT® Experts to get even more ideas for improving your root cause analysis? Contact us by CLICKING HERE.

Root Cause Analysis Tip: Why Did The Robot Stop? (Comparing 5-Why Results with TapRooT® Root Cause Analysis Results)

Posted: May 9th, 2018 in Pictures, Root Cause Analysis Tips, TapRooT

Find the Root Cause

I hear people say that 5-Whys is a good root cause analysis system for “simple” incidents. So, I thought I would show a simple incident that was provided as an example by a very experienced 5-Why user and compare it to the analysis that would be performed using TapRooT®.

Taiichi Ohno, the father of the Toyota Production System and the creator of the 5-Why method of root cause analysis, is the source of the example – a robot failure. He used the example to teach employees the 5-Why technique while he was at Toyota. Here is the example as he described it…

1.    Why did the robot stop?

–    The circuit has overloaded, causing a blown fuse.

2.    Why did the circuit overload?

–    There was insufficient lubrication on the bearings, so they locked up.

3.    Why was there insufficient lubrication on the bearings?

–    The oil pump on the robot is not circulating sufficient oil.

4.    Why is the pump not circulating sufficient oil?

–    The pump intake is clogged with metal shavings.

5.    Why is the intake clogged with metal shavings?

–    Because there is no filter on the pump.

For Mr. Ohno, that was the end of the root cause process: Install a filter and get back to work. But this isn’t even the start of the root cause analysis process in TapRooT®.

Let’s look at this incident using TapRooT® and see how 5-Whys compares to the advanced TapRooT® Root Cause Analysis System.

TapRooT® Root Cause Analysis

TapRooT® is more than a tool. It is a systematic process with embedded tools to help an investigator find and fix the root causes of a problem. It starts with either the TapRooT® 5-Step Process for low-to-medium risk incidents or the the TapRooT® 7-Step Process for major investigations. The 5-Step Process is shown below…

To start investigating the problem, one gathers evidence and draws a SnapCharT® (shown below being drawn by a team in a TapRooT® 2-Day Root Cause Analysis Course).

Notice that the 5-Whys that Mr. Ohno asked in the example above turned out to be mainly the sequence of events leading up to the failure in the  SnapCharT® (shown below).

The SnapCharT® makes the example event easier to understand than the 5-Why example above. Plus, the SnapCharT® goes beyond the 5-Whys by indicating that there was no low oil pressure alarm.

In TapRooT®, if the investigator decides that there is more to learn, the investigator continues to collect evidence (grows the SnapCharT®) to expand his/her understanding of what happened. A good TapRooT® Investigator would have several areas to look at.

First, what happened to the filter? Was it forgotten during maintenance or was it never designed into the system?

Next, where did the metal shavings come from? Metal shavings in a lube oil system are unusual. What was the source?

The new information provides a fairly complete understanding of what happened and is shown on the SnapCharT® below.

Notice that in TapRooT®, we complete the collection of evidence about what caused the metal filings and what caused the filter to be missing. These were significant issues that were left out of the 5-Why analysis. This type of omission is common in 5-Why analyses – even when experts apply 5-Whys. Thus the problem isn’t with the investigator or their training – it is embedded in the 5-Why system.

Causal Factors

Once one understands what happened, the third step is to identify the Causal Factors that, if eliminated, would have stopped the accident from occurring or reduced the seriousness of the incident. A simple technique called Safeguard Analysis is used to do this. The four Causal Factors for the Robot Stops incident were identified as:

  1. Mechanic A uses cloth to cover openings in system.
  2. Mechanic A does not report metal shaving contamination.
  3. Mechanic B does not install oil filter.
  4. Operator does not know oil pressure is low.

Where Mr. Ohno only had one root cause, TapRooT® has already identified four Causal Factors. Each of these Causal Factors could have multiple root causes so TapRooT® is already highlighting one of the weaknesses of 5-Whys: that it usually focuses on a single cause and misses additional causes (and the needed corrective actions for those root causes that aren’t identified).

TapRooT® Root Causes

In fourth step of the TapRooT® 5-Step Process, each Causal Factor is analyzed using the Root Cause Tree® to guide the investigator to the Causal Factor’s root causes. The tree is described in detail in the TapRooT® Book (CLICK HERE for info).

For this example, we won’t show the entire analysis of all four Causal Factors using the Root Cause Tree® and Dictionary. For people who would like to know more about the 15-question Human Performance Troubleshooting Guide and the way the tree is used to help investigators find causes beyond their current knowledge, we recommend  attending a 2-Day or 5-Day TapRooT® Course.

However, we will describe the analysis of the Causal Factor “Operator doesn’t know oil pressure is low.”

This starts out on the tree as a Human Performance Difficulty that leads us to the Human Performance Troubleshooting Guide. When asking the 15 Questions, two questions get a “yes” for this Causal Factor and guide us to the Human Engineering, Procedures, and Training Basic Cause Categories on the back side of the Root Cause Tree®.

Copyright © 2015 by System Improvements, Inc.
Used by permission. Duplication prohibited.

In analyzing these categories, no causes are found in the Procedures or Training Basic Cause Categories. However, two root causes are found to be applicable in the Human Engineering Basic Cause Category (above).

Thus, it was determined that if the operator needed an oil pressure display/alarm (displays NI root cause) to make the detection of a problem possible (errors not detectable root cause). If the display/alarm had been present, then the robot could have been stopped and fixed before damage to the bearings had occurred. Thus, the incident would have been made significantly less severe.

The corrective action for these two root causes would be to install a bearing lube oil pressure indicator and a low bearing lube oil pressure alarm to notify the operator of impending equipment problems before the bearing would lock up.

After analyzing just one Causal Factor using the TapRooT® Root Cause Tree® we have found that even an expert like Taiichi Ohno could miss important root causes when using 5-Whys. But there is more. There are still three more Causal Factors to analyze (and then Generic Causes – an optional technique in the 5-Step Process).

Why would you use a root cause tool with known, proven weaknesses? Why would you risk lives, your corporate reputation, and large sums of money on an inferior approach to problem solving? If something is worth fixing, it is worth fixing it right! Learn and apply TapRooT® Advanced Root Cause Analysis to find the real root causes of problems and effectively fix them. Attend an upcoming course to learn more.

Admiral Rickover’s 7 Rules

Posted: May 9th, 2018 in Performance Improvement, TapRooT

Hyman Rickover 1955

Rule 1. You must have a rising standard of quality over time, and well beyond what is required by any minimum standard.
Rule 2. People running complex systems should be highly capable.
Rule 3. Supervisors have to face bad news when it comes, and take problems to a level high enough to fix those problems.
Rule 4. You must have a healthy respect for the dangers and risks of your particular job.
Rule 5. Training must be constant and rigorous.
Rule 6. All the functions of repair, quality control, and technical support must fit together.
Rule 7. The organization and members thereof must have the ability and willingness to learn from mistakes of the past.

Are you using advanced root cause analysis to learn from past mistakes? Learn more about advanced root cause analysis by CLICKING HERE.

Newest Aircraft Carrier Breaks Down During Sea Trials

Posted: May 8th, 2018 in Current Events, Equipment/Equifactor®, Video

USS Ford underway for sea trials …

An article in Popular Mechanics said the the USS Ford had to return early from sea trials because of an overheating thrust bearing on one of the four main engines. Bloomberg reported that:

“inspection of the parts involved in the January 2018 incident revealed improperly machined gears at GE’s facility in Lynn, Massachusetts as the ‘root cause.'”

Is “improperly machined gears” a root cause? That would be a Causal Factor and the start of a root cause analysis in the TapRooT® System. And why wasn’t the “improper” machining detected prior to installation and sea trials?

Here is some footage of sea trials (including a brief glimpse of one main shaft turning).

Hazards and Targets

Posted: May 7th, 2018 in Accidents, Current Events, Human Performance, Performance Improvement, Pictures, Root Causes, TapRooT

Most of us probably would not think of this as a on the job Hazard … a giraffe.

Screen Shot 2018 05 07 at 9 40 49 AM

But African filmmaker Carlos Carvalho was killed by one while working in Africa making a film.

Screen Shot 2018 05 07 at 9 42 38 AM

 Do you have unexpected Hazards at work? Giant Asian hornets? Grizzly bears? 

Or are your Hazards much more common. Heat stroke. Slips and falls (gravity). Traffic.

Performing a thorough Safeguard Analysis before starting work and then trying to mitigate any Hazards is a good way to improve safety and reduce injuries. Do your supervisors know how to do a Safeguard Analysis using TapRooT®?

Cyber Attack Root Cause Analysis

Posted: May 4th, 2018 in Root Cause Analysis Tips, Root Causes, Video

(if you can’t see the video, here’s a link)

Yes .. It happened right here in Knoxville! A cyber attack on the county computer system on election night!

What is the root cause? The county is having an outside contractor look into it.

Can you use the TapRooT® Root Cause Analysis System to do a root cause analysis of a cyber security attack. Yes! People have been doing it for decades.

What is Senior Leadership’s Role in Root Cause Analysis

Posted: May 2nd, 2018 in Performance Improvement, TapRooT

Screen Shot 2018 04 30 at 3 40 59 PM

Senior leadership wants root cause analysis to uncover the fixable root causes of significant accidents and precursor incidents AND to recommend effective fixes to stop repeat incidents.

But what does senior leadership need to do to make sure the happens? What is their role in effective root cause analysis? Here’s a quick list:

  • Best root cause system
  • Insist that it is used
  • Be involved in reviews
  • Insist on timely implementation of fixes
  • Check status of the implementation of fixes
  • Use trends to manage
  • Steer system to be more proactive

Let’s look at these in slightly more detail.

Best root cause system: Because so much is riding on the effective performance of a root cause system, leaders knows that second best systems aren’t good enough. They don’t want to bet their company’s future on someone asking why five times. That’s why they feel assured when their team uses advanced root cause analysis to find and fix the real root causes of problems. CLICK HERE to find out more about advanced root cause analysis.

Insist that it is used: One common theme in companies that get the most from their performance improvement programs is that senior leaders ASK for investigations. When they see a problem, they insist that the advanced root cause analysis process is used to get to the root causes and develop effective fixes. When middle management and employees see senior leadership asking for investigations and root cause analysis, they want to be involved to help the company improve.

Be involved in the reviews: When senior leaders ask for investigations, it’s only logical that they would want to review the outcome of the investigation they asked for. But it goes beyond being present. Senior management knows what to look for and how to make the review process a positive experience. People often get rewarded for good investigations. When the review process is a positive experience, people want to participate and have pride in their work.

Insist on timely implementation of fixes/Check status of the implementation of fixes: You might not believe this but I’ve seen many examples of companies where they performed root cause analysis, developed fixes, and then were very slow to implement them. So slow that the incident repeated itself, sometimes several times, before any fix was implemented. Good senior leadership insists on prompt implementation of fixes and makes sure they are kept up to date on the progress of implementation.

Use trends to manage: Good root cause analysis efforts produce statistics that can help leaders manage. That’s why senior leadership understands the use of advanced trending techniques and gets reports on the latest root cause trends.

Steer system to be more proactive: Would you rather wait for an accident or incident to find your next improvement opportunity? Or would you rather target and audit or assessment and have them apply advanced root cause analysis to develop effective improvements? The best senior leaders know the right answers to these questions.

That’s it! Senior leaders use proactive improvement and investigations of precursor incidents and major accidents (which rarely happen) to find where improvement needs to happen. They are involved with the system and use it to keep their company ahead of the competition. They are updated about the status of fixes and current trends. They reward those who make the system work.

Does that sound like your facility? Or do you have an improvement opportunity?

Press Release: CSB to Investigate Husky Refinery Fire

Posted: April 26th, 2018 in Accidents, Current Events, Pictures

CSB

Washington, DC, April 26, 2018 –  A four-person investigative team from the U.S. Chemical Safety Board (CSB) is deploying to the scene of an incident that reportedly injured multiple workers this morning at the Husky Energy oil refinery in Superior, Wisconsin. The refinery was shutting down in preparation for a five-week turnaround when an explosion was reported around 10 am CDT.

According to initial reports, several people were transported to area hospitals with injuries. There have been no reports of fatalities. Residents and area schools near the refinery were asked to evacuate due to heavy smoke.

The CSB is an independent, non-regulatory federal agency charged with investigating serious chemical incidents. The agency’s board members are appointed by the president and confirmed by the Senate. CSB investigations look into all aspects of chemical accidents, including physical causes such as equipment failure as well as inadequacies in regulations, industry standards, and safety management systems.

The Board does not issue citations or fines but does make safety recommendations to plants, industry organizations, labor groups, and regulatory agencies such as OSHA and EPA. Visit the CSB website, www.csb.gov

Here is additional coverage of the fire …

NewImage

http://www.kbjr6.com/story/38049655/explosion-injuries-reported-at-husky-energy-superior-refinery?autostart=true

How many precursor incidents did your site investigate last month? How many accidents did you prevent?

Posted: April 25th, 2018 in Accidents, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT

A precursor incident is an incident that could have been worse. If another Safeguard had failed, if the sequence had been slightly different, or if your luck had been worse, the incident could have been a major accident, a fatality, or a significant injury. These incidents are sometimes called “hipos” (High Potential Incidents) or “potential SIFs” (Significant Injury or Fatality).

I’ve never talked to a senior manager that thought a major accident was acceptable. Most claim they are doing EVERYTHING possible to prevent them. But many senior managers don’t require advanced root cause analysis for precursor incidents. Incidents that didn’t have major consequences get classified as a low consequence event. People ask “Why?” five times and implement ineffective corrective actions. Sometimes these minor consequence (but high potential consequence incidents) don’t even get reported. Management is letting precursor incidents continue to occur until a major accident happens.

Perhaps this is why I have never seen a major accident that didn’t have precursor incidents. That’s right! There were multiple chances to identify what was wrong and fix it BEFORE a major accident.

That’s why I ask the question …

“How many precursor incidents did your site investigate last month?”

If you are doing a good job identifying, investigating, and fixing precursor incidents, you should prevent major accidents.

Sometimes it is hard to tell how many major accidents you prevented. But the lack of major accidents will keep your management out of jail, off the hot seat, and sleeping well at night.

Screen Shot 2018 04 18 at 2 08 58 PMKeep Your Managers Out of These Pictures

That’s why it’s important to make sure that senior management knows about the importance of advanced root cause analysis (TapRooT®) and how it should be applied to precursor incidents to save lives, improve quality, and keep management out of trouble. You will find that the effort required to do a great investigation with effective corrective actions isn’t all that much more work than the poor investigation that doesn’t stop a future major accident.

Want to learn more about using TapRooT® to investigate precursor incidents? Attend one of our 2-Day TapRooT® Root Cause Analysis Courses. Or attend a 5-Day TapRooT® Root Cause Analysis Course Team Leader Course and learn to investigate precursor incidents and major accidents. Also consider training a group of people to investigate precursor incidents at a course at your site. Call us at 865-539-2139 or CLICK HERE to send us a message.

Is April just a bad month?

Posted: April 24th, 2018 in Accidents, Courses, Pictures, Summit

I was reading a history of industrial/process safety accidents and noticed that all the following happened in April:

Texas city nitrate explosion

April 16, 1947 – 2,200 tons of ammonium nitrate detonates in Texas City, Teas, destroying multiple facilities and killing 581 people.

Deepwater horizon

April 20, 2010 – A blowout, explosions, and fire destroy the Deepwater Horizon, killing 11. This was the worst oil spill in US history.

West texas

April 17, 2013 – 10 tons of ammonium nitrate detonates in West, Texas, destroying most of the town and killing 15 people.

Maybe this is just my selective vision making a trend out of nothing or maybe Spring is a bad time for process safety? I’m sure it is a coincidence but it sure seems strange.

Do you ever notice “trends” that you make you wonder … “Is this really a trend?”

The best way to know is to apply our advanced trending techniques. Watch for our new book coming out this Summer and then plan to attend the course next March prior to the 2019 Global TapRooT® Summit.

Connect with Us

Filter News

Search News

Authors

Angie ComerAngie Comer

Software

Anne RobertsAnne Roberts

Marketing

Barb CarrBarb Carr

Editorial Director

Chris ValleeChris Vallee

Human Factors

Dan VerlindeDan Verlinde

VP, Software

Dave JanneyDave Janney

Safety & Quality

Garrett BoydGarrett Boyd

Technical Support

Ken ReedKen Reed

VP, Equifactor®

Linda UngerLinda Unger

Co-Founder

Mark ParadiesMark Paradies

Creator of TapRooT®

Michelle WishounMichelle Wishoun

Licensing Paralegal

Per OhstromPer Ohstrom

VP, Sales

Shaun BakerShaun Baker

Technical Support

Steve RaycraftSteve Raycraft

Technical Support

Wayne BrownWayne Brown

Technical Support

Success Stories

Many of us investigate accidents that the cause seems intuitively obvious: the person involved…

ARCO (now ConocoPhillips)

Investigation Detects Lack of Experience in Experienced Personnel And Leads To Job Simulation To Improve Performance Submitted by: Errol De Freitas Rojas, SHE Coordinator Company: ExxonMobil, Caracus, Venezuela Challenge We investigated a Marine incident where an anchor cable picked up tension during maneuvers and caused a job to be stopped. We needed to find the …

Contact Us