User:Charlesbaldo/Cause Mapping

Cause Mapping is a method of Root Cause Analysis, incident investigation and problem solving. The method is built on systems and process-mapping techniques, as well as the traditional logic tree. It can be described as a logic tree built horizontally.

The problem solving method draws out, visually, the multiple chains of interconnecting causes that lead to an incident. The method, which breaks problems down specific cause-and-effect relationships, can be applied to a variety of problems and situations. Cause Mapping represents one among many problem solving and root cause analysis tools, including 5 Whys, Pareto analysis, fault tree analysis, Ishikawa fishbone diagram, and many others.

Defining the Cause Map
Most problems have many interrelated causes, and cause mapping is designed to physically map out, on paper, those relationships. But before creating a cause map, an organization’s goals must be well-defined and clearly communicated. Deviations from these overall goals define the problem and, thus, determine how a cause map should start.

Overall goals could include on-time delivery, a workplace free of safety hazards, and so forth. Most important, they should be easily quantifiable so that everyone immediately knows when these goals aren’t met. Delivery time can be quantified; “friendly” customer service, on the other hand, can be more difficult to measure.

Cause Mapping resembles problem solving tools such as the Ishikawa fishbone diagram, but with several differences. The fishbone defines one problem and finds its causes. Cause Mapping, on the other hand, defines problems within the context of an organization’s overall goals. The overall goals, not the problem, give the starting point. Problems are defined by how they deviate from these overall goals. The fishbone diagram reads right to left, Cause Mapping left to right. The fishbone diagram groups similar causes into categories: methods, machines, materials, etc., while the Cause Map does not, instead depicting how individual causes and effects relate.

Creating a Cause Map
An organization can create a Cause Map using three steps:

 Outline the Issue. A cause map first requires an accurate, comprehensive definition of the problem by asking what, where, and when questions, and, most important, determining how the problem affects the organization’s overall goals.

Consider a worker carrying boxes who trips on a barrier and breaks his ankle. Here, the team defines the issue, discussing the “what,” “where” and “when.” The tripping led to the organization not meeting one of its overall goals: to eliminate safety hazards in the workplace.

Map the Causes. A Cause Map starts from the left, with a box describing an organization’s overall goal. To the left, a box is placed describing a problem that led to the organization not meeting this goal. This isn’t a solitary activity, but a team approach involving as many people involved with the incident as practical. People see things differently, and their perspectives bring different causes to light. Almost all incidents may be linked to more than one cause. If the team identifies three events that directly caused the incident, the team draws three boxes, describe the event within each, and links all three to the final event. From here, the team uncovers what caused these three events, and then links those to each. Ultimately, this creates a “map,” reading from left to right, with the problem on the left and an array of causes and effects on the right.

Regarding the tripping example, one person may think the person tripped because of the barrier. Another might think he tripped because he was carrying boxes. These two perspectives both represent causes, so both are drawn on the cause map, both with lines linking them to the problem on the left. From here, the team uncovers the causes behind these two events: Carrying boxes and the barrier present on the floor.

Find the Solutions. Using a Cause Map, solutions come not from trying to solve the overall issue, but focusing on solutions for the individual cause on the map. And just like causes, there is rarely just one solution for each mapped cause. For the most effective solution, the team chooses the solution that best fits the organization’s overall goals.

Continuing the tripping example, team members may both remove the barrier and prevent the worker from carrying the box, making it less likely that the problem would occur again. But to bring about these solutions, the team must address solutions to earlier causes. Why does the worker carry the box in the first place? Two work processes are placed far apart from each other on the floor (this could be marked in a box, “far apart processes,” in a box to the left of “worker carrying box.”). A solution might be to move work processes closer together, so the box wouldn’t have to be moved in the first place. 

The Cause Mapping method has no adjectives, no types of causes (such as main cause, true cause, direct cause, condition cause, latent cause), no lingo, no terminology, no acronyms, no buzzwords and no software to purchase. The Cause Mapping method focuses on the basic principle of cause-and-effect and shows people how to use paper and dry erase boards and common software tools (such as Microsoft Excel) to thoroughly analyze, document, communicate and solve problems.

The Cause Mapping method focuses on the details of the incident and the best solutions, not “the root cause.” The Cause Mapping method explains how cause-and-effect relationships can layout as a map, creating a visual dialogue that improves the way people solve problems. The most common feedback on the Cause Mapping method is that it's simple and effective.