FEATURED BLOG

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

Every organisation has unresolved problems. Some are greater than others.

The prospect of undertaking an RCA usually arises because there has been a persistent problem, a repetition of a failure or other “significant” event.

A problem which has never been “solved” will continue to cause headaches within the organisation and may well have very significant financial consequences. The question arises, why has it never been resolved?

• Is it a matter of scarce resources?
• A lack of expertise?
• or, fear of the unknown?

More pressing priorities often take the lion’s share of available resources and this particular problem continually falls down the list. Those ‘other’ problems are more important because, generally, they have greater or more immediate impacts.

Recognition that there is a lack of expertise in the organisation to properly tackle the problem is not uncommon. This leads to a lack of confidence that an analysis will be productive or “successful” so why allocate already scarce resources? Will it just amplify the frustration? If it requires the engagement of external investigators, the whole gamut of decision-making about “who?” and “which method?” and “who’s paying?” confronts the organisation.

Work-around’s for managed problems

Perhaps the problem has actually become manageable. The consequences or impacts may already have been limited by some measures which contain or control the problem. Typically, this method of limiting the impacts becomes the norm and in no time at all the expression: “it’s always been like that” will be the standard response to queries about the persistent fault. This is the signal that we are coping in spite of the problem – a “work-around” is feasible.

Kick starting the process

These scenarios can be resolved quite simply. A single person can begin to determine whether an RCA is warranted by actually beginning the process. That requires the problem to be simply stated as the name or title of the ‘supposed’ problem. For example, two or three word expressions such as “broken pump shaft” or “repeated reportable emissions” or “declining customer satisfaction”. This simple focal point can generate a useful discussion about the “real” problem and that discussion can either begin to narrow towards causes or broaden towards the “big picture”.

But it’s best to first identify the simple facts about the location and time of the problem or incident and then to thoroughly quantify the impacts or consequences. Remember that this person is trying to determine whether an RCA is warranted and that necessitates measurement. Typical types of impacts; are Reputation, Financial, Safety, Legal, and Shareholder Confidence.  In fact, the initial problem may well be replaced by one of the negative impacts as the “real” problem of which it becomes a cause.

Once these have been calculated (or estimated) and the problem quantified, you can then justify a recommendation for the analysis to continue and be formalised by the establishment of a team, a facilitator and a timetable or to suspend the analysis on the grounds that it hasn’t (yet) replaced other “issues” on the list.

Activation of Triggers

In a mature organisation, the decision whether or not to conduct a “formal” RCA is determined by the activation of triggers which are particular to that enterprise or organisation. In other words, the impacts such as Reputation, Financial, Safety, Legal and Shareholder Confidence are being felt and are more or less measurable.

For Reputation, the trigger might be more than five negative media references in the preceding twelve months. For Safety it may be any “Lost Time Injury” or “First Aid Event” and/or “Near Miss’’. For Legal, it might a predetermined number or value of litigations and fines incurred.

There is no definitive level or standard. The definition of triggers for an organisation is the recognition of its own threshold or degree of tolerance for negative consequences, its own “lines in the sand”.

In summary

The question of when to do an RCA is most easily answered by the response:

“when you will no longer tolerate the consequences of the problem and are therefore determined to prevent its recurrence or, at the very least to minimise any negative consequences”.

And that will only happen if a thorough and methodical process is undertaken to discover all the causes of the problem and to clearly illustrate the relationships between them. Clearly, there are causes you have not identified yet. There is something you don’t understand about the problem. Otherwise you’d have already identified effective solutions.

Keep in mind that sometimes the cost of prevention outweighs the cumulative total of historical and anticipated losses and a business case for the implementation of a particular solution doesn’t pass the ROI test. In other words, after the implementation of what are considered to be “reasonable” corrective actions and controls, management will be prepared to “self-insure”, to tolerate the risk of recurrence. 

This can be done confidently after the RCA has revealed all the causes and all the possible solutions have been evaluated but not before.

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

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.

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.

Having watched one of the best Olympic Games ever this summer in London, with some jaw dropping performances being witnessed, it left me thinking about the reasons behind the athlete’s success. What is it that makes an athlete want to win, what gives them the desire to train every day for a chance of winning an Olympic medal?

Whilst listening to British Cycling’s performance director Dave Brailsford, he discussed the success of the British cycling team. “The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improved it by 1%, you will get a significant increase when you put them all together”, he said. According to Dave it was these ‘marginal gains’ that underpinned the team’s success.

All of the athletes now need to build on the success of the London Olympics and prepare for Brazil in 2016. How will they recreate the success? How will the athletes break down their achievements into its smaller parts just like the British cycling team?

Do these athletes understand the ‘root causes’ of their success?

Let’s look at the definition of “root cause”:

“Any cause in the cause continuum that is acted upon by a solution such that the problem does not recur” (Dean Gano, A New Way of Thinking, Apollo Root Cause Analysis)

Whilst this definition is valid for solving problems that we don’t want to happen again, we may need to identify root causes of success, just like the Olympic athletes as they prepare for Brazil.

So instead of the term “Problem Definition” traditionally used in the Apollo Root Cause Analysis methodology, we can replace it with the term “Success Definition”.

The Realitychart that results from following the Apollo Root Cause Analysis methodology will no doubt have many conditions such as ‘tenacity’, ‘perseverance’, and ‘dedication’, along with actions such as ‘up at 5am’ and ‘run 10 miles’.

So whilst we do need to solve problems in the workplace and break them down into their smaller parts to achieve the marginal gains for improved plant performance; we also need to understand when our targets have been achieved and performances have exceeded last year’s requirements. Why did we achieve what we set out to achieve? Or, what went well? In this case, it’s not about preventing a problem from recurring but rather repeating a success.

Performing Root Cause Analysis on success is quite possibly a new concept but one that should not be ignored.

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.