Three Simple RCA (Root Cause Analysis) Facilitation Tips

Three Simple RCA (Root Cause Analysis) Facilitation Tips

Ned Callahan, Apollo RCA Facilitator and Trainer, ARMS Reliability

“How long should an RCA take?”


This question about RCA 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 a Root Cause Analysis (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 RCA process 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 root cause analysis (RCA) 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 RCA method 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 roblem.

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 Reality Chart 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.


Ned Callahan, Apollo RCA Facilitator and Trainer, ARMS Reliability

Picture of idconadmin

idconadmin

Join the discussion

Click here to join the Maintenance and Reliability Information Exchange, where readers and authors share articles, opinions, and more.

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Get Weekly Maintenance Tips

delivered straight to your inbox

"*" indicates required fields

This field is for validation purposes and should be left unchanged.