Category Archives: Uncategorized

bigstock-Leadership-74184-729682b9cb0364ac262296318d3a053ad39d4920

bigstock-Leadership-74184760.jpgThe previous article in our blog series described the recommended training strategy for your RCA program development. The next step in achieving a successful RCA program is to ensure leadership understands their role and has the tools in place to ensure the longevity of the program and its effectiveness.

To ensure the success of your root cause analysis program leadership must have a vested interest and take responsibility not only for developing and overseeing the functions of the RCA effort, but also monitoring the status of the individual analyses and associated solutions. This monitoring is typically done by the Steering Committee in conjunction with its other strategic responsibilities.  

The critical elements to track in relation to conducting the root cause analysis include

  • Incident date
  • RCA assignment date and lead
  • Estimated RCA completion date
  • Days past due
  • Escalation activity
  • Actual completion date

The critical elements to track in relation to the solutions that are to be implemented include

  • RCA completion date
  • Solution assignment date and lead
  • Estimated solution completion date
  • Days past due
  • Escalation activity
  • Actual completion date
  • Frequency of incident recurrence
  • Annual savings/HSE incident reduction

steering committee.jpgOnce a root cause analysis has been completed, a list of potential solutions will be developed by the RCA team and submitted to the Steering Committee via the Program Champion or his/her designee for approval. The Steering Committee then assigns these solutions to individuals for completion and puts them into an action plan format with assigned due dates. These actions should be completed in the shortest time possible, otherwise the process will quickly fade away. The Steering Committee must track the status of open RCAs, the progress of implementing the solutions to ensure timely completion, and the effectiveness of previously implemented solutions (as measured by recurrences of the original incidents). New analyses should not be started if a large number of solutions remain to be implemented. 

An appropriate person needs to be assigned the responsibility of tracking progress and recurrence.  The right person for this responsibility may be different for different organizations. Progress is tracked by showing the number or percentage of completed solutions. Recurrence will be tracked by measuring repetition of the incident. 

Some organization will already have software and methods for tracking tasks, such as a CMMS. If this is the case, it can be considered for RCA and solution tracking as well. However, if a system does not currently exist or does not fulfill all the organization’s RCA tracking needs, then we would recommend considering RCProTM enterprise RCA software. It allows for the generation of an action list, due dates, and comments of each analysis to be shared with team members. It will also provide detailed reports on current investigation status, action tracking, outstanding Items, and view systemic issues across the organization. 

This is where the Steering Committee review and support really comes in to play. The leadership team should review RCA status and solution implementation and final results as a regular part of Steering Committee business. The Steering Committee’s main role is to ensure that RCAs are completed in a timely fashion and that resulting solutions are implemented and tracked for effectiveness.

So far, this blog series has covered:

The Key Steps of Designing Your Program

Defining Goals and Current Status

Setting KPIs and Establishing Trigger Thresholds

RCA and Solution Tracking and Roles and Responsibilities

Recommended RCA Team Structure

Responsibilities of the Six Roles

RCA Program Development Training Strategy

And, Oversight and Management.

Stay tuned for our next installment on RCA Process Mapping. 

bigstock-Worker-in-cautio-c5a9f030be84f91768db6dc92fe28465c23388ff

Author: Jack Jager

While there are three main reasons organizations typically perform Root Cause Analysis (RCA) following an issue with their asset or equipment, there are a whole host of other indicators that RCA should be performed. bigstock-Worker-in-caution-sign-icon-th-92706563

Odds are, you’re recording a lot of valuable information about the performance of your equipment – information that could reveal opportunities to perform root cause analysis, find causes, and implement solutions that will solve recurring problems and improve operations. But are you using your recorded information to this extent?

First, let’s quickly talk about three reasons why root cause analysis is typically performed. 

1. Because you have to

There may be a regulatory requirement to demonstrate that you are doing something about a problem that’s occurred.                                    

2. You have breached a trigger point

Your own company has identified the triggers for significant incidents that warrant root cause analysis. 

3. Because you want to

An opportunity has presented itself to make changes for the better. Or perhaps you’ve decided you simply don’t want to lose so much money all the time.

At the core of all industry is the desire to make money. Anything that negatively impacts this goal is usually attacked by performing root cause analysis.

I was having a conversation with a reliability engineer at an oil and gas site, and I asked him what lost opportunity or downtime might cost that company over the course of a year. He said it was in the vicinity of three quarters of a billion dollars. $750,000,000. Is this a good enough reason to perform root cause analysis? Even a 10% change would have a huge impact on bottom line figures.

The monetary impact to the business was of course not due to any single event, but to a multitude of events both large and small.

Each event presents itself as an opportunity to learn and to make any changes necessary to prevent its reoccurrence. Once can be written off as happenstance… things happen, serious or minor, and that’s life. But to let it happen continuously means that something is seriously wrong.

While these are all valid reasons to perform root cause analysis, there are at least ten more tell-tale equipment-related clues that an RCA needs to happen – most of which can be identified through the information you’re probably already recording.

Here are ten tell-tale signs that your organization needs to perform Root Cause Analysis:

  1. Increased downtime to plant, equipment or process.
  2. Increase in recurring failures.
  3. Increase in overtime due to unplanned failures.
  4. Increase in the number of trigger events.
  5. Less availability of equipment.
  6. High level of reactive maintenance.
  7. Lack of time… simply can’t do everything that needs doing.
  8. Increase in the number of serious events… nearing the top of the pyramid.
  9. Longer planned “shut” durations.
  10. More frequent “shut” requirement.

These indicators imply that we need to be doing more in the realm of root cause analysis before these issues snowball.

If you can identify with some of these pain points, download our eBook “11 Problems With Your RCA Process and How to Fix Them” in which we provide best practice advice on using RCA to help eliminate some of these problems.

11Problems_Ebook_banner

stop-circle-hand1-6b70e9a39ed67702740461e9910a14af9316ab65

Author: Jack Jager

An effective root cause analysis process can improve business outcomes significantly. Why is it then that few organisations have a functioning root cause analysis process in place? 

Here are the top 6 sure-fire ways to kill off a Root Cause Analysis program

1. Don’t use it.

stop-hand

The company commits to the training, creates an expectation of use and then doesn’t follow through with commitment, process and resources! Now come on, how easy is it to devalue the training and deliver a message that the training was just to tick someone’s KPI box and that the process doesn’t really need to be used.

2. Don’t support it.

Success in Root Cause Analysis would be the ultimate goal of each and every defect elimination program. To achieve success however, requires a bit more than just training people in how to do it. It requires structures that initially support the training, that mentor and provide feedback on the journey towards application of excellence and thereafter have structures that delineate exactly when an investigation needs to take place and that delivers clear support in terms of time and people to achieve the desired outcome. Without support for the chosen process the expected outcomes are rarely delivered.  

3. Don’t implement solutions.

To do all of the work involved in an investigation and then notice that there have been no corrective actions implemented, that the problem has recurred because nothing has changed, has got to be one of the easiest ways to kill off a Root Cause Analysis process. What happens when people get asked to get involved in RCAs or to facilitate them when the history indicates that nothing happens from the efforts expended in this pursuit? “I’m too busy to waste my time on that stuff!”  

 

4. Take the easy option and implement soft solutions.

Why are the soft controls implemented instead of the hard controls? Because they are easy and they don’t cost much and we are seen to be doing something about the problem. We have ticked all the boxes. But will this prevent recurrence of the problem? There is certainly no guarantee of this if it is only the soft controls that we implement. We aren’t really serious about problem solving are we, if this is what we continue to do?   

5. Continue to blame people.

The easy way out! Find a scapegoat for any problem that you don’t have time to investigate or that you simply can’t be bothered to investigate properly. But will knowing who did it, actually prevent rectraining your staff urrence of the problem?

Ask a different question! How do you control what people do? You control them or more correctly their actions by training them, by putting in the right procedures and protocols, by providing clear guidelines into what they can or can’t do, by creating standard work    instructions for everyone to follow and by clearly establishing what the rules are in the work place that must be adhered to.

What sort of controls are these if we measure them against the hierarchy of controls? They are all administrative controls, deemed to be soft controls that will give you no certainty that the problem will not happen again. We know this! So why do we implement these so readily? Because it is the easy way out! It ticks all the boxes, except the one that says “will these corrective actions prevent recurrence of the problem?”

We all understand the hierarchy of controls but do we actually use it to the extent that we should?  

6. We don’t know if we are succeeding because we don’t measure anything.

You get what you measure! When management don’t implement or audit a process for completed RCAs it sends a strong message that there is no interest, or little, in the work that is being done to complete the analysis.

Tracking KPIs like, how many RCAs have been raised against the triggers set? How many actions have been raised in the month as a result and, of those actions raised, how many have been completed? If management is not interested in reviewing these things regularly along with the number of RCAs subsequently closed off in a relevant period, then it won’t be long before people notice that no one is interested in the good work being done.

The additional work done to complete RCAs will not be seen as necessary, as it’s not important enough to review and the work or the effort in doing this will then drop away until it’s no longer done at all.

measuring success

Another interesting point is that if only the number of investigations is reported, and there is no check on the quality of the analysis being completed, then anything can be whipped up as no one is looking! If a random audit is completed on just one of the analyses completed in a month then this implies that the quality of the analysis is important to the organisation. 

What message do we send if we don’t measure anything?

 

 

In closing, the first step on the road to implementing an effective and sustainable Root Cause Analysis program is to pinpoint what’s holding it back. These Top 6 sure-fire ways to kill off a Root Cause Analysis program will help you identify your obstacles, and allow you to develop a plan to overcome them. 

 

Webinar Elements to Sustain a RCA Program
 

 

 

bigstock-Blank-checklist--1c621593672bb97b8e31cc33af2bb40f0a1646ea

Author: Kevin Stewart

 
This question was posed to a discussion group and it got me thinking how do you grade an investigation?

The overall success will be whether the solution actually prevents recurrence of the problem.  One definition of Root Cause Analysis is: “A structured process used to understand the causes of past events for the purpose of preventing recurrence.” So a reasonable assessment of the quality of the analysis would be to determine whether the RCA addressed the problem it set out to fix by ensuring that it never happens again (this may be a lengthy process to prove if the MTBF of the problem is 5 years, or has only happened once). bigstock-Blank-checklist-on-whiteboard--68750128.jpg

Are there some other tangibles that can help you assess the quality of an RCA?  RCAs use some sort of process to accomplish their task. If this is the case then it would stand to reason that there will be some things you can look for in order to gauge the quality of the process followed. While this is no guarantee of a correct analysis, ensuring that due diligence was followed in the process  would lend more credibility to the solutions.

What are some of these criteria by which you can judge an analysis?

  • Are the cause statements ‘binary’? By this we mean unambiguous or explicit. A few words only and precise language use without vague adjectives like “poor” since they can be very subjective.

 

  • Are the causes void of conjunctions? If they have conjunctions there may be multiple causes in the statement. Words such as: and, if, or, but, because.

 

  • Is there valid evidence for each cause? If causes don’t have evidence they may not belong in the analysis or worse yet solutions may be tied to them and be ineffective.

 

  • Does each cause path have a valid reason for stopping that makes sense? It is easy to stop too soon and is sometimes obvious. For example, if a cause of “no PM” has no cause for it so that the branch stops, it would seem that an analyst in most cases would want to know why there was no PM.

 

  • Does the structure of the chart meet the process being used? If it is a principle-based process then it should be easy to check the causal elements to verify that they satisfy those principles. These might be causal logic checks or space time logic checks or others that were associated with the particular process.

 

  • Is the chart or analysis completed? Does it have a lot of unfinished branches or questions that need to be answered or action items to complete?

 

  • Is the chart or analysis completed? Does it have a lot of unfinished branches or questions that need to be answered or action items to complete?

 

  • Are the solutions SMART (Specific, Measurable, Actionable, Relevant, and Timely)? Or do they include words like: investigate, review, analyze, gather, contact, observe, verify, etc.

 

  • Do the solutions meet a set of criteria against which they can be judged?

 

  • Do the solutions address specific causes or are they general in nature?  Even though they may be identified against specific causes if they don’t directly address those causes then it may still be a guess.

 

  • If there is a report, is it well written, short, specific and cover just the basics that an executive would be interested in? Information such as cost, time to implement, when will it be completed, a brief causal description and solutions that will solve the identified problem are the requisites.

 

These are some of the things that I currently look at when I review the projects submitted by clients. I’d be interested to know about other things that may be added to the list.

describe the image