An effective facilitator should begin collecting information as soon as they become aware an incident occurred. Answers to the following questions can typically be captured immediately after an incident occurs: what do people see as the problem, when did it happen, was anything being done differently, where did it happen, which equipment did it involve, which work process was being performed, was anyone injured, were there any environmental issues, any customer issues, any impact to production or schedule, any damaged property or materials, any additional labor costs because of this issue and has it happened before.

These questions, with appropriate space for responses, are part of the Problem Outline within the Cause Mapping method. The Problem Outline, within our Excel Cause Mapping template, can be carried as a hardcopy to wherever the information is located. This gives the facilitator the ability and direction to collect details right away. Notice the list of questions doesn’t even address the causes.

As the facilitator is collecting information for the Problem Outline, people will most likely explain some of the cause-and-effect relationships. The facilitator writes down all the causes and all the evidence people provide. Even though there may be limited information, what is known and what is unknown should be written on the Cause Map. The unknowns and uncertainties are designated with questions marks. Creating a visual map of the cause-and-effect relationships structures and organizes the entire analysis. As more information is collected, it’s added to the same Cause Map.

Many investigations begin fairly basic and a little blurry. As details are collected, the incident comes into focus. The ease of documentation using the Cause Mapping method, whether it’s with paper or in Excel, changes the rate at which an organization can investigate problems. Check the problem solving velocity of your organization and let us show you how to improve it.

David Allen’s book, Getting Things Done, is subtitled The Art of Stress-Free Productivity. He has a practical way or organizing work and life. Fast Company magazine refers to David as “the productivity guru.”

In Chapter 1 is a section called The Major Change: Getting It All Out of Your Head. David wrote, “The big difference between what I do and what others do is that I capture 100 percent of my “stuff” in and with objective tools at hand, not in my mind.” He writes down and organizes everything he needs to do so that he doesn’t have to keep it in his head. Trying to keep track of everything in our brain can be overwhelming. It’s also ineffective because people forget things.

While this is a great point from a personal productivity standpoint, it also applies to facilitating a root cause analysis. Problems at work typically involve a few people who are in different groups and even different locations. Everyone involved with the problem has some of the information, but no one knows all the details. Everyone sees the problem from their own, sometimes limited, point of view.

In a root cause analysis it’s important for everyone to understand the details within a problem. It’s not necessary to get everyone to agree on the one cause. It is, however, important for everyone to understand the causes. Within an incident, people see some cause-and-effect relationships as more important than others, but this information is kept inside their heads. No one can see what others are thinking, unless it’s written down. In a root cause analysis it’s not enough to just state the problem or the cause because there are too many causes even for small problems. When an organization confronts an important problem, it should write down the causes and organize them into a clear picture.

This is one of the advantages of the Cause Mapping method of root cause analysis. Capturing details on a Cause Map provides a visual record that everyone can see. It creates a visual dialogue that allows everyone to see the information. All the causes, effects and evidence are placed on a visual map that changes the way people communicate. It makes it easier to dissect complex, confusing problems. Improve your problem solving by mapping the causes. For more information about the Cause Mapping method of root cause analysis visit our website or attend one of our workshops.

Facilitating a root cause analysis can be done without having a group meeting.  Some problems involve people who are on different shifts or in completely different locations.  In these cases it may not be feasible to get everyone together at one time.  A facilitator can still collect and organize all of the related information into a coherent analysis by talking to people one-on-one.

The word “facilitate” means to make easier.  A root cause analysis facilitator is supposed to make the root cause analysis smoother.  If it’s more effective to collect the details by talking with people one-on-one than in a meeting, then forgo the meetings.  The facilitator can talk with people one-on-one over the phone, in person, via email or in a collaborative web meeting.  The visual dialogue created with the Cause Mapping method is an excellent way to accumulate all the information from these one-on-ones.

Regardless of how the information is collected, an effective root cause analysis must be accurate and thorough.  Once the analysis is completed the proposal and selection of solutions can either be done in a meeting or one-on-one.  Again, it depends on the particular situation.  In some cases it may be easier to get detailed causes and evidence by not having the meeting.  Some people are more willing to share specifics when talking with just one other person.  Some people will suggest more unconventional solutions when they’re not subjected to the norms of a group or their peers.

A root cause analysis facilitator should be effective at leading an investigation whether it’s in front of a large group or talking with individuals.  The details of the incident still reside with the individuals who have first-hand information.  The collection and organization of these details can be facilitated by an effective facilitator.

An organization has goals that define its ideal state.  Some of the goals relate to safety and compliance, some relate to the customer and some focus on production, property, equipment and labor.  The most effective solution may actually be a combination of several different solutions.  A problem doesn’t have to be limited to just one action item.  A thorough root cause analysis may produce multiple action items.  Sometimes implementing several simple actions can be more effective than one big solution.  When a particular solution costs too much there may be simpler, quicker ways of accomplishing the same result.  There truly isn’t a “right way” of preventing a problem at work.  There are many different ways - some of which are better than others.  Either way, all of the solutions must fall within the framework of that organization’s overall goals.

The first part of the solutions step is to propose ideas to control the individual causes.  Looking for solutions one cause at a time makes it easier to consider other possibilities.  Once an accurate analysis has been completed, possible solutions can be proposed for any one of the causes.  This is typically referred to as brainstorming.  The best solutions are selected from all the possible solutions.

If someone finds a solution that prevents the problem, but the implementation effort is beyond the impact and risk to the goals, then that solution will not be effective.  The overall goals distill possible solutions into the best ones.  If there is an impact or potential impact to personnel or a mandatory compliance requirement, the available solution set expands.  If a problem is purely an economic one with no risk to safety, then the cost-benefit ratio determines which solutions are best.  If a solution works well, but the effort in exceeds the results out, then it’s not the best solution.

The term “failure mode” defines the manner in which something can fail.  A failure mode is simply a way something can fail.  A single part can fail in different ways.  Therefore a system consisting of multiple parts can have many different failure modes.  FMEA helps prioritize the different failure modes (in terms of risk).

Failure analysis is different than failure modes effects analysis in one basic way.  Failure analysis is about why something “did” fail while FMEA is about how something “could” fail.  “Did” is in the past, “could” is in the future.  Anything in the past actually did occur a particular way.  People may speculate on different ways a failure “could” have happened, but there is only one set of causes for how it actually “did” happen.

For an incident the occurred in the past all of the causes are linked with AND relationships.  An incident in the past “did” happen in a particular way and all of the causes were required.  For an incident in the future, one that “could” happen, all of the different failure modes are linked with OR relationships.  It “could” fail several different ways.  FMEA identifies cause-and-effect relationships for something that “could” happen.  Failure analysis identifies the cause-and-effect relationships for something that “did” happen.  A failure mode is simply a cause.  It’s a cause of how something “could” fail.

Root cause analysis is a method for digging into the cause-and-effect relationships of any problem.  It can be used for problems that did happen or could happen.  It can also be used to explain why something went well.  The point is problem solving within any organization should be based on the cause-and-effect principle.  It’s more important to understand the underlying principle than to pick the “right tool.”  The more an organization focuses on the principle the better it becomes at understanding how to use the different tools and less effort is placed on chasing the program of the month.

In the particular case I’m thinking of an individual was injured while using an electric hand tool.  The tool was being used as it was intended, but the job was in an area that was difficult to reach so the user was in a body position that required the user’s arms to be fully extended away from his body.  The root cause analysis determined that this awkward position was a cause of the incident.

The manager of this group wrote up the incident report and sent it to all the employees as a lessons learned.  It was read during the next safety meeting.  There were some specifics about the incident in the write-up, but the message was a general precaution like “be careful when using hand tools.”

There’s a good chance that the manager who wrote the lessons learned on this particular hand tool has no experience with that hand tool.  This “lesson learned” is going out to 200 people who use these hand tools.  Some of these people were experienced employees who may have used that particular hand tool dozens and dozens of times.  How effective is a generic statement like “be careful”?

The tool was appropriate for the job, but how the tool was being used could have been improved.  After reviewing the owner’s manual for this tool there were several specific adjustments on the tool that, in this particular case, would have reduced the risk of this incident.  The warnings about body position and work surfaces in the manual could have been expanded for the incident.

The people who have experience with this tool - the users - are the ones who should be providing the insight for the lessons learned.  It’s the specific details within an incident that make the lessons learned valuable.  General statements like “be careful” may only erode relations between those who actually do the work and those who manage it – “those managers just don’t get it.”

The difference is pulling the lessons learned from the people closest to the work rather than pushing the lessons learned to them.  This also means having people with specific knowledge and experience with the hand tool, reviewing how the job should have been done.  This raises the accountability because it places the responsibility for the proper use of that hand tool with the people who use the hand tool.  The people closest to the work - the ones who use the hand tools – taking one extra minute to change body position and change the settings on the tool could prevent the incident from ever occurring.  This level of detail and participation provides the full value of lessons learned within an organization.

The lessons learned can be a root cause analysis discussion with all the users of this hand tool.  “How should this job have been done?  What should the settings have been on the tool?  What should we have done to improve body position?”  The discussion and potential debate with the users of the hand tools is what refines and defines the most effective way to do that job safely.  The most experienced front line users should be explaining to the managers how to use that tool.

It’s true that catering forgot the cups, but the problem could have also been prevented if the flight attendant would have checked for the cups while we were boarding. Explaining to others what we specifically could have done to prevent the problem is irritating, because it places responsibility on us. It’s lot easier to just blame catering. In a root cause analysis, a blamer can cherry pick the cause, placing the responsibility on another person or group. The language sounds like this, “If they would have just put the cups in the galley like they were supposed to, this problem never would have happened.” The statement is true, but it excuses the flight attendant from preventing the problem.

At work, if someone decides to eliminate blame from their language, their individual accountability actually increases. This approach requires people to think about what they could have done, within their work process, to prevent the issue. Ideally, problems should be less about who made the error and more about what are we going to improve our work processes to prevent it. Work processes must be based on the premise that people make errors. No one is perfect. A core element of the ThinkReliability root cause analysis training is “to err is human, to prevent is process.”

Ironically five feet from the galley, where the cups should be, is one of the best examples of highly reliable work processes in any industry. On the flight deck, the pilot and the co-pilot step through checklists, just like they do on every flight. They’re trained, not only on the checklists, but how to communicate when using the checklists. And, they have recurring training at least annually. The commercial airline industry in the United States has made 12,000 safe flights per day something we expect. Work processes are put in place to take something that is seemingly high risk and make it routine.

Some people might ask “Do you really want flight attendants and catering using checklists too?…ONLY if you want to have cups on each flight.

Problem solving at work is really about problem prevention. Companies are either trying to prevent a problem from occurring again or from occurring in the first place. To understand what can be done to prevent a problem it must be broken down into specific cause-and-effect relationships. Companies usually review their problems using general terms like procedure not followed or training inadequate. Just like the proverb, the devil is in the details, the solutions are there too. Root cause analysis is an investigation approach for digging into what’s beneath the surface. Continuing to pull the top off the weed just creates a recurring problem. To prevent the weeds in your business from growing back you have to get to the root. This discipline for dissecting a problem doesn’t change from one department to another or from big problems so small ones. The cause-and-effect principle can be applied consistently across all types of problems including injuries, delays, failures, outages, defects and rework.

Highly reliable organizations anticipate problems as part of their daily operations. They know little things are going to come up within the hundreds or thousands of tasks performed across a company in a day. The challenge is to keep all the little things little. This is the essence of risk mitigation. Highly reliable organizations begin with the premise that people sometimes make errors. A company can’t expect its people to be perfect. It is possible, however, to define work processes that prevent minor errors from becoming major incidents. Zero incidents don’t require zero risk.

Clearly defining work processes, conducting thorough and accurate investigations (root cause analysis)  and identifying specific solutions isn’t a secret for improving operations. What is unique about this approach is the focus on principles instead of terminology, acronyms or the program of the month. Keeping it simple and being consistent makes the implementation that much easier. Having success also doesn’t require a corporate wide roll out. This entire approach can be evaluated by investigating just one problem.

The more an organization focuses on the underlying principles the more effective they become. The opposite of this approach is called the program-of-the-month or acronym-of-the-month. Cause-and-effect analysis doesn’t change from big issues to small issues. The cause-and-effect principle is the same for a medication error as it is for the loss of the Columbia shuttle. The reason it’s called a principle is because it doesn’t change. A principle is independent of the problem, the industry and the magnitude of the issue.

When organizations focus on techniques and jargon they inadvertently create “method confusion.” We un-complicate things. Our approach helps organizations develop a clear understanding of the relationships between risk, reliability and root cause analysis. The people who are actually perform the work are the key. They are the experts on improving the reliability of healthcare processes. Tools such as FMEA, 5S, 8D, Six-Sigma, RCM, RCA, Kaizen etc. can be applied effectively and they can be applied ineffectively. The tools are sound, not because of the technique itself, but because of the underlying principles. When individuals believe that common cause analysis is different from root cause analysis which is different from problem solving and troubleshooting it creates unnecessary confusion, wastes huge amounts of time and unfortunately doesn’t improve the reliability of the system.

The focus of all problem solving should be to first understand the basics of cause-and-effect. From this point people realize that RCA is simply cause-and-effect analysis for what DID happen and FMEA or risk mitigation is cause-and-effect analysis for what COULD happen. Most organizations make their problem solving too complicated. Several intelligent individuals in a group doesn’t necessarily result in an intelligent group. An important aspect of an root cause analysis is how well the group communicates. This is why our clients consider the Cause Mapping method to be such a valuable tool, creating a visual dialogue, to utilize all of the knowledge within an organization.

Problems that organizations investigate using root cause analysis, don’t have right answers. As an example, if someone asks “Why did the Titanic sink?” people will respond with different answers. Some will say the Titanic sank because it hit an iceberg, others will say it sank because it filled with water and still others will say it was because of the strength of the rivets. Ironically these three different responses are all accurate. Each person is telling the truth, but they think they’re right. This is why disagreements and arguments are so prevalent in company problem solving sessions.

Some people may be emotionally connected to the rudder on the Titanic. They may argue that “if the rudder would have been bigger, the Titanic never would have sank.” They won’t move off that point because what they’re saying is true, however they believe they’re right. Anyone who provides an explanation different from theirs is perceived as disagreeing (or just wrong). An effective root cause analysis prevents these unnecessary miscommunications. This is not some new way of thinking, it’s simply accurate. Our clients have told us this is profound, not because it’s sophisticated, but because it’s simple.

Interestingly, when people believe the purpose of root cause analysis is to find the root cause they’re mistakenly imposing right-answer thinking on the incident. The analysis is flawed from the start which has a negative affect on the way the organization solves the problem.