FEATURED BLOG

Author: Jack Jager

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

1. Don’t use it.

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 recurrence 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.

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. 

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). 


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.

By Kevin Stewart

With all the preparation work (Honing your Facilitation Skills: Part 1) behind you, you’re now ready to start facilitating an Apollo Root Cause Analysis. Follow the steps below to ensure a smooth process and successful outcome.

  
Step 1. Introductions  

First, do some simple introductions and housekeeping. Cover things like:  

• Introductions all around
• The meeting guidelines: when to take breaks, phone and email policy, and so on
• The objective: we’re here to fix the problem, not appoint blame
• A review of the Apollo Root Cause Analysis methodology for those who may not be familiar with it (spend 15 – 45 minutes depending on the audience)
• Your role as facilitator: you may need to ‘direct traffic’ or change the direction of discussions to help them discover more causes or to reach effective solutions

Step 2. Timeline

It’s now time to capture the ‘story’. What has happened that brought you all here? Get several people to provide a narrative, and develop a timeline of events as you go.  

This timeline will prove very useful. It should reveal the event or issue that becomes your primary effect or starting point – and ensures that all the items beyond this starting point capture the group’s issues.    

In the example below, if I start from T1 I’ll discover why I left my iPad in the bathroom.  However if I start at T7 I will also discover why my check process didn’t function as desired.

While the time that each event occurs is important, it might not always be known. In these instances, you can represent the time sequence as simply T1, T2 and so on.

Step 3. Define the problem

You’re now ready to define the problem. Often, the problem definition comes out easily and everyone agrees. However, sometimes you’ll find that the group can’t arrive at a Primary Effect. In this case, as facilitator, it’s your job to regroup and ask some questions about why everyone is interested. Often, it’s about money.

One thing you don’t want to do is get stuck trying to find the perfect starting point. I’m reminded of a saying I heard once:

Dear Optimist and Pessimist,

While you were trying to decide if the glass was half empty or half full, I drank it!

Sincerely,

The Realist

The Apollo Root Cause Analysis methodology is robust enough to handle an imperfect starting point. If the problem changes or evolves as you go, just put it down as the new starting point, adjust the chart and go on!

Now that you have a defined problem, with its significance well understood, you’re now ready to start the charting process. The team should also know by now why they’re here, and how much time and money can be spent on the investigation. 

If you missed Part 1 of this article, you can read it here.

Would you like to learn more about the Apollo Root Cause Analysis methodology? Our 2 Day Root Cause Analysis Facilitators course is perfect for anyone needing to understand fundamental problem solving processes and how to facilitate an effective investigation.

By Jack Jager

We are all problem solvers. Each and every one of us actively deals with problems on a regular, if not a daily basis. However, the crucial question is “Is everyone actually good at problem solving?”

Quality of investigations vary and the trend appears to be a practical application of the normal curve. There are some fantastic results from investigations and also some poor results. But, if your organisation is seeing  a whole pile of average investigations and average reports that result from them, then the effectiveness of your Investigation program can be improved.

Mediocrity occurs for a number of reasons. This article focuses on four aspects of your RCA program which, if not set up correctly, could be catalysts behind a consistent flow of mediocre root cause analysis investigations within your organization.

1)     A structure to support training

So, you’ve trained your employees in root cause analysis and you’re expecting to see some fantastic RCA results coming through. Right?

…Not so fast.

If there is little structure to support the training in terms of:

• a requirement to use the process,
• mentoring and feedback provided to trainees,
• or quality audits on their efforts,

Then you can expect to see a whole range in terms of the quality of investigations being submitted. If the majority of the investigations are average then the value of the training comes into question.

This has often been the stimulus to look for different training in an alternative methodology because the perception is that the process selected for use by the company is not meeting expectations, it’s not working, people are not using it, and people don’t like it, or it’s not getting the results…..and so on.

If any training is unsupported, the same outcome could occur. So is this a problem with the training or a problem with the structure that supports the training?

Two days of training or a week of training doesn’t make anyone an expert in anything. Each trainee sits somewhere along the learning curve at the start of the training and hopefully, if they have been paying attention, they move along the curve to a better place after the training. The purpose of the training is to skew the curve – to move the curve to the right so you have more investigations being completed to a higher standard.

The challenge for all companies is to work out how to move trainees from where each
individual sits on that learning curve after the training, to application of excellence within the discipline at which the training was directed.  Isn’t this what was originally intended?

For many individuals, this transition along the learning curve lacks clear structure and in many cases this structure simply does not exist. We train our people and then, figuratively speaking, throw them to the wolves expecting them to be the evangelists for the learning and the cure to all of our problems.

So what happens when we then get an average outcome? We don’t see the value in training more staff. And in this instance of problem solving, we will see a greater acceptance of mediocrity and of our inability to change this. It is essential that there is a feedback loop, whereby mediocre investigation reports are not accepted, or signed off.

Underpinning an effective investigation program requires managerial overview, whereby
managers are skilled in the RCA methodology and can challenge the outcome, provide positive recognition or insist on rework. If managers are not trained in the RCA method, then they are in the hands of the people who have been trained, and the danger is that mediocrity becomes the norm.

2)     Amount of time dedicated to investigations

How long does an investigation take? Should it be one hour?  Four hours? One day? One week?

There is no right answer.

If an investigation is warranted then it should be resourced to a point where an excellent result is possible. If that means you have 5 people in a room all day then so be it. The significance of the problem must warrant that level of support.  

Conducting a root cause analysis requires a dedication of time and resources to achieve a
desirable outcome. How much do your problems cost you after all? If you want your investigations to be effective, then you will need to support them to the level needed. A clear understanding of the organisation’s threshold limits that determine the level of response, is essential to ensure appropriate allocation of resources and time to attend or complete an investigation.

When you find yourself in a rush, ask yourself if you are simply satisfying the need to report, completing obligatory requirements, just meeting deadlines or is there a genuine opportunity to improve the business and make a difference.

3)     Involving the “right” people

If you don’t have the “right” people in the room – those with intimate knowledge or experience with the problem, then how good will the investigation will be?

Information is a key ingredient in all investigations and successful investigations require
that you have that information in the room in the form of the people who have the knowledge, data, evidence and reports.

Positive support and approval from management are necessary for people to be given the
time to attend the investigation.

4)     Having the “right” facilitator

Do you have the “right” person facilitating?

Good communication skills are important, both verbal and non-verbal. A willingness to be the facilitator should also be considered…someone who has the desire to do this job.

A good facilitator should be impartial, unbiased, willing to ask the dumb question, and arguably should not be the subject matter expert. A great facilitator recognises that the credit for a good investigation outcome belongs to the team, and he works deliberately to facilitate that outcome.

In summary

The cost of significant incidents has a direct impact on the bottom line. Incidents can cost a company hundreds-of-thousands or even multi-million dollars. Every incident or accident that occurs is an opportunity to learn. If we can learn effectively by doing a high quality RCA, then the goal of trying to prevent their reoccurrence is far more likely to be achieved.

The best results occur from investigations that are well supported, have the right facilitator, and have the right people involved who have been given sufficient time to understand the event so they can present the best report possible.

Getting these elements right will go a long way towards moving the quality of your RCA investigations away from mediocrity and towards excellence.

A key factor in establishing the framework for an effective RCA program is a common application standard, and easy to use reporting, and charting tools. The Apollo Root Cause Analysis methodology has been used for over 20 years to support effective Problem Solving. RealityCharting™ software has been developed to provide standardisation, as well as quality checks and help. RC Coach is an online support tool with easy to access refresher training to help individuals to keep learning beyond the classroom.

By Jack Jager

Understanding the root cause of a problem is the purpose of many or all investigations. However, the concept of “root cause” suggests that there is only one, singular cause that is at the “root” of any problem.

The root cause concept and how it is applied often leads to this perception of a singular cause. For example, the statement “What is the root cause of the problem?”

So what is “root cause” and how is it defined? It can be difficult to find a clear and precise definition. The following  well-defined description reveals something very simplistic;  “Root Cause can be described as that cause, which if it were controlled or eliminated would make the problem go away. Therefore it may be considered a root cause”.

This is an interesting concept as it can be applied to a number of causes within a cause and effect chart, therefore, it can be said that there are many “root causes”.

Cause and Effect analysis and Reality charting indicates that a problem doesn’t occur from a single cause, but for any problem there can be many cause and effect relationships that can trigger a problem. Therefore how do we know which of these causes is the root cause?

If you were to ask this question to various people, there may be a number of different answers.  One person may think the root cause is one thing, while another would consider the root cause to be something else. Each party may in fact be right. So how can a “root cause” be assigned unless we are certain that a solution will prevent the problem from recurring?

What are the causes of a fire? For a fire to occur there must be certain conditions present. Each of these conditions are a contributing cause of the fire.

• There must be oxygen present (a conditional cause)
• Fuel to burn (a conditional cause)
• An ignition source, such as a match or lighter (also a conditional cause)

All of these causes can exist in harmony with each other and can do so for some time.

It is only when an “action” cause occurs, such as the lighting of a match that the fire will actually occur.

So what is the “root cause” here?

If we apply the definition provided above for “root cause” here, then by eliminating the oxygen, there would be no fire. Therefore “oxygen” is a root cause of the fire.

If you were to remove the combustible material, fuel, then this too will satisfy the definition requirement. The problem would not reoccur. Therefore “fuel” is also the root cause of the fire.

If you were to also remove all of the ignition sources, then there would be no possibility of a fire. This too satisfies the definition requirements. Therefore the “ignition source” is the root cause of the fire.

If no match was to be lit, then there would be no fire. Therefore “the lighting of the match” must be the root cause of the fire as well.

Based on this example, there are potentially four root causes and each of them satisfies the root cause definition. This can be quite confronting in a sense to recognise that there are many potential root causes for a problem. It is, however, liberating too because now you have many potential corrective actions rather than just one.

How often have you heard someone ask “What is the root cause of the problem?” and “you can’t control the problem until you have identified what the root cause is”.

How do we determine which causes to control? In the fire example, who will determine the control or controls to put into place? It’s unlikely that oxygen will be eliminated, as this can be a very costly and difficult process (although we do use this concept in confined spaces).

Can we control the combustible material? If we were to eliminate the fuel then would we have an effective control? This is possible in some cases but not in others.

What about the ignition sources? If there were no lighters or matches present or available, then there would be no fire. Do we have the ability to remove these?

If we could stop the persons action from occurring then we would also have controlled the possibility of a fire happening.

Based on these rationales, which of these controls should be implemented? Is this decision governed by certain criteria? And then the question about what we can control also comes into play.

So what criteria can we use to determine our choices?

• Money - it needs to be cost effective
• Safety - it needs to be safe
• Easy - if possible it should be easy to do
• Quick - being able to do it quickly has merit
• Doesn’t cause other problems – at least not unacceptable problems
• Is an ongoing fix – and is not a band-aid. The solution will fix the problem for today and tomorrow, as well as next week and next year.

and other criteria may also be considered.

The above criteria are taken into consideration when making the decision about which solutions to implement. At the end of the day, it is important to have an understanding of the problem and how many of the causes you need to control to prevent recurrence.

Did the notion or understanding of what the “root cause” is come into consideration when making the decision about which solutions to implement?  No, therefore what is the value of identifying “root cause”?

In my mind, it is the concept of “root cause” that is important. Applying this concept requires us to understand the problem as completely as possible, before we make decisions about corrective actions. If we do this, then we are in the best possible position to make good decisions about which corrective actions to implement. 

The decision of which solutions to implement is a choice. It is a choice we make according to a set of criteria. It is based on the answers you acquire when applying the criteria questions that allow you to be objective in your decision making process to find the best solution.

In Summary

In many ways the concept of “root cause”, whilst being important in the broader application, is often a misnomer when used to describe the critical cause for a unique incident. It is not the only cause. Other causes must also exist.  

At the end of the day it is your choice about which causes you wish to control. Therefore it is important to remain objective in this decision making process, via utilising a set of criteria, and applying them to all possible solutions. Let the answers to the criteria questions determine what the best solutions are, and that will determine what you consider to be the “root cause” of the problem.

By Kevin Stewart

As is so often the case, sometimes we simply forget to wonder why. 

Have you heard the one about the daughter that saw her mother cut the ham in half before cooking it at the Christmas gathering and asked why?  “Well mom said we’ve always done it that way, but Grandma is here and I learned from her, so she can tell you why!”  So the daughter asks Grandma, “Why does mom cut the ham in half before cooking it?”  Grandma says, “Well Dear, I’ve always done it that way and I suppose your mother is just following suit. We’re in luck though, Great Granny is here and I learned from her, so why don’t you see if she knows.”  So she goes to Great Granny and asks, “Why does mom cut the ham in half before cooking it?”  “Oh dear!” says Great Granny.  “That is simple. When I was cooking Christmas dinner I didn’t have a pan big enough so I cut it in half and put it into two pans!!”

Perhaps we have forgotten to wonder why about 5 Whys?  I’m all for using the right tool for the right job, but what job was 5 Whys designed for? 

According to Wikipedia, it was developed by Sakichi Toyoda  and was adapted for the Toyota Production System (TPS) by Taiichi Ohno.  While not an expert on 5 Whys by any stretch, I do know the premise of TPS was to eliminate waste.  Everything was predicated on that simple notion, and all of the other tools were built to help them achieve that goal.  So I don’t think it is a giant leap to make the assumption that the 5 Whys was part of that.   I’m always interested in others thoughts, so I offer up that the 5 Whys was not designed as a tool to solve complicated problems that have many twists and turns to root cause, but rather as a simple tool that was supposed to help the operator on the floor become engaged in the problem solving methodology, and in the process, eliminate waste. 

If this is truly the case, then one can make the assertion that just because you have a hammer – everything isn’t a nail.

By this I mean that the 5 Whys can be used successfully in a simplified manner where the consequences are low, the time is short, and the tool is used close to the time of the incident.  This would mean that there would not be a lot of evidence or verification necessary because the consequences are low. In addition, suggested changes could be reviewed by supervisors and operators for validity before being put in place without a fear of major consequences.

So that leads us to the question – is the biggest problem with 5 Whys that in many cases we may be attempting to solve problems the tool wasn’t designed for? 

If it truly was designed for an operator to fix small problems that he recognized at the time they happened, then he wouldn’t have a lot of time. The problems wouldn’t be big and complicated, and the consequences were only that he would continue to waste time and money until the problem got fixed.  

In summary:

Let the consequence determine the need for validation. The 5 Whys are just “caused by…” statements that we don’t need to delve into when using the method for its intended purpose - analyzing a simple problem.

RC Simplified™ is the perfect tool to conduct 5 why investigations. It is free, readily available and simple to use. If the investigation requires a report or follow up, simply convert RC Simplified™ to an Apollo investigation in RealityCharting®. This provides for reporting, documenting actions and finding solutions. They are the perfect combo - 5 whys + RC Simplified™

By Jack Jager

Giving the right name to your problem – in other words, defining it clearly – is the first step towards fixing it.

The naming of a problem before you actually start investigating it is a critical first step. It gives the investigation a clear purpose, a clear starting point and a clear direction.

Think about it. If you can’t define your problem clearly, then how do you know if the solutions proposed in the investigation will actually prevent its reoccurrence? How will you know if you have achieved what you set out to do?

Not only that, but a clearly defined problem is essential for when you present your initial report on the investigation. You need a strong name for the problem to catch the reader’s attention and make it very clear what the report is setting out to solve. You need management to buy-in into your problem to secure the time and resources needed to conduct a more comprehensive analysis. A strong title is always the first step.

What makes a good name?

The name of the problem needs to be short and concise. It should have impact. It should avoid the use of generic or ambiguous language.

For example, a “Failed bearing” is generic in its description. The title is vague – I know I have a problem with the bearing, but I don’t really know what sort of problem it is. A generic heading opens the door to many different possibilities. If you ask yourself why you have a “failed” bearing, many new questions and options arise resulting from the many different failure modes that are possible. This is not really what you want.

Rather, you should convey the understanding that the particular failure of the bearing is a unique, single incident in its own right. It has specific causes. And it needs a specific name.

Root cause analysis vs failure modes effects analysis

What are you trying to do with your investigation? Are you performing a “failure modes effects” analysis, or a “root cause analysis” on a very specific issue? If it is the latter, then the language you use needs to reflect this. It needs to be specific.

If the problem’s causes are unknown when you first start an investigation, then an understanding of all possible failure modes has some merit. It’s a good place to start, as it will help to point you in the right direction. However, keep in mind that it’s a starting point only. Once you have found the evidence to determine which cause path needs to be pursued, your investigation should become very specific, with all alternative pathways eliminated.

Think about a generic problem title: “person injured”. To make it more specific, we ask “What is the injury?” The response tells us that the person received “second degree burns to left forearm”. This more specific title immediately conveys how serious the problem is, and also generates far more specific questions in the analysis of the incident. In turn, this leads to more precise responses and a better understanding of the issue.

Streamlining your cause and effect chart

A more specific and clear problem name will also make your cause and effect chart more specific. It will become more streamlined, with fewer possible cause path options and “OR” scenarios.

Going back to the earlier example, if you say that the problem is a “Failed bearing”, you will likely get responses like “That’s normal. It happens all the time.”

But if you call the problem: “Conveyor offline” (because of a failed bearing) then what sort of response do you get?

Or if you were to describe the problem as: “Can’t load the train” (because the conveyor is offline) what reaction would you get? Again, the response is likely to be ramped up even further.

The fundamental problem – a failed bearing – is still the same. The three ways to name the problem show how the events are connected, yet sit in different positions on the time continuum. Each is a possible starting point, but which one will give you the biggest buy-in factor?

You may want to choose the most significant event as your starting point, as this will surely obtain greater buy-in.

If unsure of where to start, try using a “so what” question to guide you – “So what if the bearing fails? What’s the impact?”

This may tell you: “Conveyor is stopped.” So what?  What’s the impact of the conveyor stopping?

“Cant load the train.”

In this scenario, this last issue – an inability to load the train – is arguably the best starting point as it will gain far more buy-in from people further up the chain of command, and hence be more likely to secure funding and resources.

All because of a name

When choosing an appropriate starting point for your investigation, consider your options carefully and then assign a name that will clearly articulate the problem you intend to solve – one that also echoes the significance of the problem itself.

Further food for thought

Remember:  You are never wrong when choosing a starting point as all causes are related. They are simply at different points in the timeline. Your choice may reflect your role or responsibility within the company.

You’ve investigated an incident, and now it’s time to write up your report. This report should document what you’ve found, and the corrective actions needed to prevent recurrence or mitigate the problem to an acceptable level.

At the heart of a good report is a strong, clear executive summary.

What does an executive summary look like? Is it a dot point affair? Is it a few one-liners that capture the critical elements of the issue? Or do you tell a story that recreates everything? Is it something in-between?

While it is certainly not the case that “one size fits all” – particularly given that different companies have different needs and policies – there are some golden rules that can be applied in crafting the perfect executive summary.

Be brief.

An executive summary should be brief and to the point. Yet it must still convey critical information, such as:

• The cause and effect paths identified in the investigation
• Lessons about the causal relationships culminating in the incident
• Rationale behind why certain corrective actions have been recommended

It should only take a few minutes to read. For a manager whose time is precious – and hence will likely not read the full report – the executive summary is their insight into the full investigation.

Be factual, but clear.

An executive summary should be factual, yet written for easy reading.

Everyone should be able to understand it, so avoid words that confuse people. Stick to clear, simple language that is easily read and interpreted.

Avoid ambiguity and generic language, which may lead to alternate interpretations of the information. For example, citing “mechanical failure” could refer to any or all mechanical failures. A root cause analysis targets a very specific failure – a seized motor, for instance – which has very specific causes.

An example: “… a temporary loss of cognitive function.”

An ore truck, fully laden with coal, was driving out of a mine. The engine “died” and the ore truck rolled backwards, hit a bank and flipped over. There was considerable damage but no injuries.

An investigation was launched, and a report produced. This report stated that “the driver had a temporary loss of cognitive function.”

This is not clear. What actually happened was that the driver fell asleep. Why didn’t they just say that in the report? Perhaps the report’s writer was trying to protect the driver from undue criticism. Yet, of course the driver didn’t mean to fall asleep.

The purpose of an investigation is not to point the finger, but to prevent a recurrence. So instead of focusing on “who”, a “why” question is needed in this example to elicit more specific, factual responses.

Avoid technical jargon.

Don’t fall into the trap of assuming that everyone will be able to follow your technical or task-specific jargon. Likewise with abbreviations or acronyms. Try to avoid this type of language.

Instead, write the report for a non-technical audience. This will make it easier for a broader readership to interpret and make sense of it, and reduce the number of questions you field once the report is published.

Use “caused by” language.

With reference to the cause and effect chart you created during the investigation, use “caused by” language to join the causes together. So A was caused by B and C; B is caused by D, E and F; and C was caused by G and H (where the letters represent the causes depicted in the chart).

This approach is simplistic, and deliberately so. It summarises the chart in a language that is easy to follow. It is factual and gets to the point. It avoids “storytelling” and the different interpretations that come from such an approach.

In summary

By following the advice above, you will find that an executive summary is quick and easy to read – and doesn’t take long to write, either.

Be aware that every organisation’s needs are different, and yours may have specific rules around what an executive summary should contain. If you have no template to follow, then use the advice above to craft the perfect executive summary for your investigation.

 By Jack Jager

The ability to demonstrate the success or failure of Root Cause Analysis (RCA) is a crucial stage of incident investigation that is often missed. After all, if you don’t measure, how do you (and others) know if your program is working and whether it’s worth the effort?

Measuring the success of an RCA program is important both for the short-term and the long-term. In the short term, you need to know if the changes implemented as a result of the RCA findings are effective. Longer term, you need the proof that your RCA program works – so that you gain ongoing support from management for this important tool.

Yet some companies fail to measure the success of their RCA programs. Here, we look at what’s stopping them, and how to overcome it.

First, why is measurement so important?

The goal of RCA is to improve processes or reduce the severity or impact of incidences. In RCA, you typically generate a raft of possible solutions and only implement some of them.

Implementing RCA solutions without measuring their effectiveness is akin to trial and error.

Measuring the changes caused by RCA solutions – good and bad – is critical to knowing whether your RCA efforts were successful. You need to know the “before” and “after” states of whatever the RCA is trying to improve, and assess how effective the solution is.

Measurement is probably more important for the “bad” results. You need to know if a solution isn’t working. A negative result will show you that the problem was not understood well enough (in which case you can go back to your cause and effect chart) or that poor choices were made in terms of which solutions to implement.

In this way, a “bad” measure still leads to a positive outcome. It allows positive decisions to be made to revisit the issue. After all, if the problem was significant enough to warrant an investigation in the first place, you need to know whether to revisit it or not.
 

What’s stopping you from measuring RCA success?

In some cases, the lack of measurement boils down to the fact that the RCA process is still relatively immature, and has not yet evolved into a complete process. In these instances, you need to deepen your commitment to grow your RCA program so that it captures this crucial step.

In other cases, unfortunately, measurement is simply shelved in the “too hard” basket.

Yet it doesn’t have to be hard. To measure the success of RCA, you simply need to set some parameters or criteria. Identify what you are trying to achieve – both the “big picture” goals and those relating to the RCA program itself.
 

What measures would indicate success of your RCA process?

The big picture will show:

• Improved availability of plant (less downtime) – either mobile plant or fixed plant (production infrastructure)
• Improved production data – weekly, monthly, per quarter, biannual and annual
• Less downtime when things go wrong
• Lower frequency of problem occurrence or similar types of problems
• Less impact of problems – problems are less severe or the ramification of these problems are less severe
• Less time spent reacting to problems and more time available for planning and making improvements

At a more local level, RCA program measures will show things like:

• Ratio of total number of incidents which should trigger an RCA against how many RCAs were performed
• Percentage of solutions generated against how many were implemented
• Percentage of people who have been trained in the process against those who have actually conducted RCAs or are using the process informally
• Indication of the timeframe needed to begin investigations (shorter is better)
• Indication of the timeframe required to implement solutions

By collecting information of this nature, you will be able to demonstrate how successful the RCA program is. In doing so, you will gain valuable support from management and co-workers.

Remember, you can easily tell someone a story of how good the RCA process is – but if you can’t show them the actual benefits in terms of production, availability or dollars, then the story counts for nothing. You have no evidence to prove it.

Instead, let the data from your measurement tell its own story. 

By Jack Jager

If you are investigating an incident using Root Cause Analysis (RCA), what are the critical skills that you should possess as an RCA facilitator?

Here are five key skills that will help to make you a more effective facilitator.

1. Value all ideas equally

First of all, it is important to acknowledge all ideas – nothing is unimportant. Something that seems trivial now may hold a great deal of value later in the process. Discourage any negative feedback from the group. This, too, is a disincentive to proffer suggestions or ideas.

The goal of information gathering is to capture everything known about a problem, no matter where it fits into cause and effect relationships. Just by watching you write a comment on a yellow “stickie” or type into the holding area, the participants can see that you are acknowledging what they know. Later, if it fits in the cause and effect chart then it has value; if it doesn’t, then it will naturally fall off the chart.

Secondly, value each and every response, regardless of where it comes from. First and foremost, this will encourage a positive flow of information from participants. If the facilitator starts saying “No, that’s not right”, then people may think before speaking and slow the whole process down. They may even stop contributing to the discussion, censoring the information in their own minds and preventing it from being evaluated on its own merits. Similarly, if someone offers a suggestion which is ignored then participants can switch off – you have to be able to work rapidly or say, “Hold that thought while I finish writing this one”.

So remember … no put-downs allowed, from you or any other member of the group. Positive affirmation is the mode for the facilitator to get a productive session.

2. Be dynamic

As facilitator, you need to guide the direction of the group and yet still be alert for other cause paths that may crop up. You are the prime mover, controlling the focus of the group. Don’t be a bystander to the process. You are the conduit through which the group is interacting.

Ask questions that are as precise as possible. This will elicit better, more concise responses which make it easier to identify causes. Good questioning will also eliminate unnecessary discussion and storytelling from the group.

Once the information has been recorded, get the group to help you organise the information and then challenge the logic of the way that information is linked together. Your cause and effect chart needs to make sense – or it risks being challenged and disregarded by those who look at it.

Remember … being dynamic may not come easy or naturally, but it’s important to give it a go. In this mode, you should continually ask “why” questions.

3. Keep the analysis moving

Don’t let the investigation get bogged down in detail too soon. Get the first pass of the chart out and then refine it. If the first pass is a linear connection of causes, then so be it. Remember, this is the start of the cause and effect chart, not the finish.

A timeline is often a good place to start – ordering key events according to “when” they happened. Such a timeline does not address the question of “why”, but it could certainly initiate a more comprehensive search for causes.

Do not waste time at this point trying to judge or evaluate each cause. Simply ask “why” immediately after placing the cause on the chart to keep people focused and moving down a productive path.

Try not to allow individuals to dominate the analysis. Everyone is there for a purpose, and has information to contribute to the investigation. Ensure that all people have the opportunity to speak. Keep redirecting and asking for other inputs. If one group member is dominant, set some ground rules – try giving each participant a chance to say what they know in turn, working your way around the group.

Remember … adding the finer detail can happen later, but then the devil is always in the detail. The onus is therefore still on you to do this.

4. Be a good listener

Attentive listening skills are critical. You need to be able to hear more than one response at a time. Your ears should be like radar, picking up on all signals. Don’t miss a response while recording another. You need to record everything.

Being a good listener means keeping an open mind, suspending judgment, and maintaining a positive bias.

It also requires the efforts of the whole group – ask the group not to have discussions on the side, as they might come up with causes that should be included but may not be shared with the group. This will also help you to hear all responses more clearly.

Remember … delegating the recording of information could be useful if it will help you to listen more effectively.

5. Don’t profess to be an expert

Don’t profess to be the expert about the problem at hand. You were appointed to be the facilitator, an independent guide, without a vested interest in the outcome. Ask the others in the group to explain what they know so that everyone can follow and understand it. That is why they are there. Remember … you don’t hold all the answers. That isn’t why you are the facilitator or it shouldn’t be. A good facilitator plays dumb whilst still directing traffic and working the cause and effects paths to a reasonable stop point.

Conclusion

Every incident comes with its own challenges. Each time you facilitate, you will no doubt come up against a range of human behaviours, which you will have to manage.

It’s a great idea to debrief the process and your role in it with some of the people involved. They will no doubt provide valuable feedback that will help you improve.

Finally, have faith in the RCA process, and learn from each experience to build on your skills as a facilitator.

Read about the key steps in preparing for RCA success.