FEATURED BLOG

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 Ned Callahan

“How long should an RCA take?”

This question is similar to how long is a piece of string?

I have heard one manager in a plant that has stipulated a maximum of two hours for an RCA to be conducted in his organisation. Another expects at least “brainstormed” solutions before the conclusion of day one – within 6 or 7 hours.  It is not uncommon for a draft report to be required within 48 hours of the RCA.

The following three tips may assist to meet tight deadlines and when time expectations are short. One advantage of the Apollo Root Cause Analysis method is that it is a fast process but the “driver” has to be on the ball to achieve the desired outcomes – effective solutions.

1. YOU DEFINE THE PROBLEM

Imagine the RCA has been triggered by an unplanned incident or event which falls into any of the safety, environment, production, quality, equipment failure or similar categories. You have been appointed as the facilitator by a superior/manager who is responding to the particular event. Your superior/manager may understand the trigger mechanism and may well nominate the problem title.

For example, “upper arm laceration”, “ammonia spill”, “production delay” and so forth could be the offering you make to the team as the starting point for the analysis. Typically, as facilitator you will have gathered some of the “facts” from first responder reports, interviews, data sheets, photographs and so on.  So a good first step is to draft a problem definition statement, including the significance reflected by the consequences or impacts. The team then has a starting point to commence the analysis, albeit the problem statement may change as more detail is provided.

Ideally, you will have already created a file in RealityCharting™ and the Problem Definition table can be projected onto a screen or even onto the clear wall where your charting will be done with the Post-It™ notes. The team members’ information ought to have been entered and can be confirmed quickly in this display. You might even show the Incident Report format and focus on the disclaimer option you have selected deliberately: Purpose: To prevent recurrence, not place blame.

This preparatory work could save at least 20 minutes of the team members’ time and enable an immediate launch into the analysis phase.

NB: 
Save yourself hours of re-work and potential embarrassment by saving the file as soon as this first process is complete, if you haven’t already done so, and thereafter on a regular basis. Maintain some form of version control so that the evolution of the chart in the following day/s can be tracked if necessary.

If you are particularly well-resourced the chart development might be recorded on the software simultaneously as the hard copy is created on the wall space. A small team might choose to create the chart directly via the software and a decent projection medium.

2.    DIRECT THE ANALYSIS

It is critical that your initiative in preparing the problem definition is not considered by the team members as disenfranchising them. The analysis step whereby all have an opportunity to contribute should ensure that they feel they have “ownership” of the problem.

To reinforce this, it is advisable to choose a sequence of addressing each member, typically from left to right or vice-versa depending on the seating arrangements. This establishes the requirement that one person is speaking at a time, secondly, that each and every statement will be documented and thirdly, that every person has equal opportunity. Your prompt and verbatim recording of each piece of information will provide the discipline required to minimise idle chatter which can waste time because it distracts focus. When you have a series of “pass” comments from team members because the process has exhausted their immediate knowledge of events, launch the chart creation. 

It is worthwhile reminding the team that each information item that has been recorded and posted in the parking area, may not appear in their original form on the chart or at all, in some cases. Because the information gathering is a widespread net to capture as much knowledge regarding what happened, when and why, there will be no particular focus. But because they are coming from people with experience and expertise or initimate knowledge of events and
circumstances, they have some value. The precise value will be determined by where the information sits in the cause and effect logic that starts at the problem and is connected by “caused by” relationships. 

NB. Cause text should be written in CAPITAL LETTERS. It will be easier to read/decipher for the team at the time and perhaps from photographs of the chart later. Similarly using caps in the software itself means that projection of the chart is more effective and the printing of various views is enhanced.

3.    THE “HOW AND IF”  OF  CREATING A REALITYCHART™

Many proponents tap the existing understanding of the event by capturing as many of the action causes as possible. These may arrive via a 5 WHYS process, for example, which starts at the Primary Effect.

            Plant Stopped (Problem or Primary Effect)

            Why? Feed pump not pumping

            Why? Broken Coupling

            Why? Motor Bearing Seized

            Why? Bearing race Collapsed

            Why? Fatigue

The Apollo Root Cause Analysis methodology requires use of the expression “caused by?” to connect cause and effect relationships. Understanding that there must be at least one action and one condition helps  reveal the “hidden” causes and especially the condition causes which do not come to mind initially.

To support this expression and the essential “why”, consider asking “how”. This may be  employed initially by the most impartial member of your team who has been engaged specifically because of his/her lack of association with the problem and can sincerely ask the
supposedly “dumb” questions. Invariably these questions generate more causes or a more precise arrangement of the existing causes. A “How does that happen exactly?” question can drive the team to take the requisite “baby steps”.  This also often exposes differences between “experts” and the resolution of these differences is always illuminating.

The facilitator needs to be aware of the need to softly “challenge” the team’s understanding while ensuring the application of sufficient rigour to generate the best representation of causal relationships. This can be done in a neutral manner by using the “IF” proposition.

Given that every effect requires at least two causes, you can then address the team with the proposition: “If ‘one exists’ and ‘three exists’ (two conditions) then with ‘four added’ (the action) will the effect be “eight” every time?”. Using this technique on each causal element will generate the clarity and certainty being sought to understand the causes of the problem. If every “equation” (causal element) in the chart is “real” and the causes themselves are “real”
(substantiated by evidence) then the team is well-placed to consider the types of controls it could implement to prevent recurrence of the problem.

The more causes which are revealed the more opportunities the team has to identify possible solutions.

SUMMARY

To speed up the RCA process,

Step 1 Facilitator gathers event information and fills out Problem Definition Statement.

Step 2 Facilitator directs the Information gathering casting a wide net and systematically requests information from participants.

Step 3 Use information gathered to build a RealityChart™ with actions based on what happened then looking for other causes such as conditions which may initially be hidden. Use how and If to help validate that causal relationships are logical.

With a completed chart the solution finding step can begin.

RCA DISCUSSION

What are your thoughts on conducting an RCA facilitation and how much time have you spent preparing the analysis?  Do you have a successful tip worth sharing or discussing? We look forward to reading your feedback and perspective via comments below or let’s connect on our LinkedIn Group – ARMS Reliability - Apollo Root Cause Analysis for further discussion.

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.

By Jack Jager

An incident has occurred, and a Root Cause Analysis (RCA) is needed to find an effective solution. How do you ensure that the RCA delivers the best results – that is to say arriving quickly and accurately at the cause or causes of the problem?

At the start of any analysis, there are a number of simple things you can do to boost the likelihood of a successful outcome. These tips are not rocket science; yet they are important to get right.

Be prepared.

Make sure you do your homework before you start, and have everything ready. This includes:

• The workspace – have large white boards and lots of them. In the absence of whiteboards, use walls or windows with butchers paper. Stock up on markers and post-in notes. In other words, make sure you’ve got plenty of room – and the tools – to write down all ideas coming from the group.
   
• The information – collect all of the information available, and have someone assigned as custodian so you can call on it and don’t have to go looking for it.  Depending on the incident you are investigating, you should collect things like the maintenance history, reports, photos, design specs, eye witness statements and OEM recommendations.
   
• The timeframe – stipulate clear timeframes for the RCA, including the start time, breaks and finish time.
   
• The rules – set expectations around usage of mobile phones and email. It is also important to have rules around the discussion itself – such as “no put-downs”. In short, the less interruptions, the better. Encourage an “open” discussion and allow all information to be brought forward. Don’t argue about ownership of information – what matters is that it was brought to light. Focus on “why”, not “who”. This reduces the emotion in the room and minimises conflict or argument. If blame becomes a part of the RCA process then defensive attitudes will start to appear, and people get too afraid of the consequences to speak up and say what really happened.

Form your group.

For an RCA to be successful, you need the right people to be present for the investigation. In other words, people who have access to or knowledge of information relating to the problem. You may need to invite an independent “expert” to assist with your RCA.
Sometimes the people directly involved in an incident or accident may  be the “right” people to have in the room.  But if there are other agendas or emotions at play, then leave them out. The RCA team should be genuine seekers of effective solutions, who share a goal of preventing similar events happening again.

Be wary of inviting senior managers into the group – they could hinder open and truthful dialogue. It may be better to give senior managers a separate review and opportunity to challenge so that they stay engaged in the process and buy-in to the solution.
It’s also important to have the right number of people in the room. The “right” number is dependent upon the significance of the problem, but also upon the ability of the facilitator to handle the group. As a general rule, it is difficult to facilitate groups greater than 10. If the group size becomes too large, consider splitting the group and having two sessions.

Control the group.

This may prove difficult, yet the ability to control a group is an important skill to have. You should value all contributions from all group members. While people don’t necessarily have to agree with each other, it’s important to acknowledge that everyone is entitled to their opinion.
If there is any confusion about a person’s comment, ask them to explain it again. If there is still no agreement, then capture both sides of the story and let the evidence prove one or the other. Don’t tolerate an argument or a contest of wills – let the evidence determine the merit of following a particular cause path.

Use all of your non-verbal skills to assist you in controlling the group. Use direct eye contact and a hand gesture to indicate whom you wish to speak next. This lets everyone know who has the floor. When you shift your focus to someone else, in conjunction with the arm movement, you pass ownership of the right to speak to the new person.
Be the traffic cop. With a simple hand signal, you can control the person who is impatiently wanting to say something, by showing them an open palm that says “stop”. This will let the other person finish what they were saying.

Respect everyone’s right to be heard, and remember that everyone in the room has a reason for being there. Ensure they all have the opportunity to speak.
Use your body as a means of directing the flow of traffic. Turn your body to face someone in the group whom you wish to speak. When you couple this with strong eye contact and a hand signal toward them you are effectively giving control of the floor to them. The key here is that everyone else in the group sees these silent signals too. Don't think you’re being rude – rather, you are showing control. And the better you can control the group, the more effective your investigation will be.

Keep the group on-task.
The facilitator’s job is to be direct and to ask specific questions to keep people focussed. If the focus strays, then it’s a good idea to go back through the chart – starting at the beginning – to get everyone back on track.

The facilitator should be the prime-mover during the RCA, constantly asking questions –  along the “caused by” or “why” lines – to maintain focus. These questions demand responses and keep everyone engaged, involved and on-task. Your questions will also prevent the group going off on tangents, which lead to almost anything being added to your cause and effect chart.
If someone is having a side conversation, then pose the next question to them. Put them in the hot-seat. If you do this consistently, you will demand their attention and also the group’s attention.

Being animated or dynamic when you facilitate is also a great way to maintain focus. Modulate your voice to keep people’s attention. Avoid a boring monotone. Remember, if the facilitator is quiet then it follows that the group is also quiet. This is not what you want.

Schedule regular breaks – a few minutes on the hour and 10 -15 mins after 2 hours. This will help to ensure that the energy levels in the room remain high and also allows people to check emails and phone messages. This is important in maintaining the focus of the group.

Follow the process.

Some people seem to have a natural affinity for facilitating investigations, but anyone can become adept and successful at it. The art of facilitation is a skill that can be learned through practice and reflection. A good facilitator knows he can walk into any situation and find a solution. This is a very powerful and rewarding skill for both the individual and the organisation.

As a facilitator, if you can follow these suggestions then the likelihood of a successful outcome from your investigations will increase.

Learn about five critical skills that an RCA facilitator should possess.

To be, or not to be, that is the question:
Whether ’tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles…

“To be or not to be” is the opening phrase of a soliloquy in William Shakespeare’s play “Hamlet”. It is perhaps the most famous of all literary quotations, but there is deep disagreement on the meaning of both the phrase and the speech. Whilst we won’t be solving that disparity in this article, we will discuss the disagreements amongst the global engineering community as to whether the 5 Whys process is sufficient enough to effectively identify the root causes and ultimately, the solutions, for a particular problem.

Why – Why – Why – Why – Why?

The 5 Whys is a question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem.

The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. It is a critical component of problem-solving training, delivered as part of the induction into the Toyota Production System. The architect of the Toyota Production System, Taiichi Ohno, described the 5 Whys method as “the basis of Toyota’s scientific approach . . . by repeating why five times, the nature of the problem as well as its solution becomes clear.”

However, whilst the tool may have had success in the automotive industry it has received criticism from within other industries for being too basic and not complex enough to analyze root causes to the depth that is needed to ensure that solutions are identified and the problem is fixed.

There are several reasons for this criticism of the 5 Whys method:

• Tendency for investigators to stop at symptoms rather than going on to lower-level root causes
• Inability to go beyond the investigator’s current knowledge – cannot find causes that they do not already know
• Lack of support to help the investigator ask the right “why” questions
• Results are not repeatable – different people using 5 Whys come up with different causes for the same problem
• Tendency to isolate a single root cause, whereas each question could elicit many different root causes
• Considered a linear method of communication for what is often a non-linear event

Many companies we work with for training and engineering services successfully utilize the 5 Why technique for very basic incidents or failures. By utilizing the correct placement of triggers, organizations can use the 5 Why for its basic problem solving and then move to a form of Cause and Effect analysis like the Apollo RCA method for more complex problems.

A disciplined problem solving approach should push teams to think outside the box, identifying root causes and solutions that will prevent reoccurrence of the problem, instead of just treating the symptoms.

Any effective problem solving technique should meet the following six criteria:

1. Clearly defines the problem
2. Clearly delineates the known causal relationships that combined to cause the problem
3. Clearly establishes causal relationships between the root cause(s) and the defined problem
4. Clearly presents the evidence used to support the existence of identified causes
5. Clearly explains how the solutions will prevent recurrence of the identified problem
6. Clearly documents criteria 1 through 5 in a final RCA report so others can easily follow the logic of the analysis

RealityCharting has come up with a simple, free tool that can be used to help with a 5 Why investigation. RC Simplified™, the free to download version can be utilized on smaller issues as it allows the user to build a cause and effect chart that is no greater than 4 causes high and 5 causes deep. This means the user of a 5 Whys approach can create a Realitychart using the same thought process adopted in the Apollo Root Cause Analysis methodology. It also demonstrates a non-linear output to what was originally considered a linear type problem.

So when looking for problem solving tools or root cause methodologies, be willing to “think outside the box” and utilize a number of resources depending on the complexity of the problem and the significance of the incident. We believe that the 5 Why’s approach definitely has a time and place to be utilized. However, if the problem is more complex, don’t limit yourself to a 5 Why approach as you will likely not be satisfied with the solutions generated.