Facilitating Cause-Consequence Diagrams: Hand Out the Notecards
Many root cause analysis sessions start with one person at the whiteboard asking "why" five times. The result is a single, tidy chain of causes that reflects one view of a failure that several people experienced differently. It’s incomplete, at best.
A cause-and-consequence diagram is a preferred technique that aims to show the full system of causes behind a failure. The fastest way to build one is to give every participant a notecard and ask them to write their own 5 Whys before anyone speaks.
From the Real World
Untreated wastewater reached a nearby creek after a lift station had overflowed during a summer thunderstorm. Seven utility staff members gathered in the conference room the following week: two operators, the maintenance supervisor, an electrician, the SCADA technician, the collection system engineer, and the utility director. I served as the facilitator.
We first worked on describing the problem. More specifically, we agreed on the two major consequences of the failure: a reportable overflow and a cost overrun of the budget for the cleanup. We decided to attack the reportable overflow issue first.
I then handed out index cards. "Write the problem at the top," I said. "Then ask why it happened and write down your answer. Ask why again. Keep going until you have five. No talking until everyone is finished."
After about five minutes, we went around the table.
"The pumps stopped because we lost utility power in the storm," the senior operator read. "The generator should have picked it up, and it didn't."
"The generator started," the electrician said. "It ran for forty minutes. The transfer switch never transferred."
"Nobody knew the wet well was rising," the SCADA technician added. "The high-level alarm went to the old on-call phone. That number was never updated after the reorganization."
"So who is right?" the director asked.
"All of you," I replied. "Each card is a branch. None of them is the whole map."
By the end of the morning, seven notecards had become one diagram on the whiteboard. Everyone understood the full set of issues that one simple 5 Whys could not.
What a Cause-Consequence Diagram Actually Shows
The version I use is built on ThinkReliability's Cause Mapping method. It starts with the consequence, not the cause. The problem is defined by its impacts on the organization's goals, such as safety, environmental compliance, customer service, and cost. That consequence sits at the left edge of the whiteboard.
Asking "why" moves the analysis to the right. Each answer becomes a box, and each box is both a cause of the box to its left and an effect of the box to its right. When an effect needs more than one cause, the map branches. Evidence goes beneath each box.
Reliability engineers may know a more formal cause-consequence diagram from nuclear and process safety, one that combines a fault tree and an event tree and carries probabilities. The facilitation version here is simpler and works backward from the consequence that actually happened. However, the discipline is the same. Causes connect to consequences through logic, not categories.
Why One Set of 5 Whys Is Not Enough
The 5 Whys is a good start. The problem is that it produces a straight line, and real failures are rarely straight lines.
Every participant sees the failure from where they sit. ThinkReliability makes the point well: an electrician, a mechanic, and an operator asking why about the same event should come up with different answers. That is not a disagreement to settle. It is information.
A single chain also invites anchoring. Once the first chain is on the board, everyone else edits it instead of challenging it. And a single chain tends to end at a generic label like "training" or "staffing," which feels like closure but rarely is the cause.
Use Notecards to Develop a Cause-Consequence Diagram
Handing out the cards is easy. Turning them into one map takes some facilitation. These are the five steps I use.
1. Define the Problem and Its Impacts Before Anyone Writes
Agree on what happened, when, where, and how it affected the organization's goals. Write it at the left edge of the whiteboard before the cards come out.
Skip this step and the cards will analyze different problems. One person writes about the overflow, another about the regulatory notice, and a third about the overtime bill.
2. Have Everyone Write Their Own 5 Whys in Silence
One card per person, with no discussion. Five minutes is a guide, not a rule (sometimes it takes ten minutes). Silence protects the quiet staffer from the confident manager.
Ask everyone to be as specific as possible. "The transfer switch did not transfer" is useful. "Equipment failure" is not.
3. Read Every Card to the Group
I normally read the cards to keep things anonymous and the focus on what is being said, not who said it. Use clarifying questions but no debate. Write each 5 Why on the whiteboard, or tape the cards if space doesn't allow you to write each one. The point is that everyone should feel included.
You can consolidate the information where the cards agree (and where the participants agree). Where they diverge, you have separate branches. The divergence is the most valuable thing in the room.
4. Causes Should End With Potential Mitigation
Rebuild a clean copy on the whiteboard. Shared causes go on the map once. At each box, ask whether that cause alone was enough to produce the effect. If it was not, add the other required cause beside it. Keep moving to the right until the causes are specific enough to act on.
5. Evidence Under Every Box
It is helpful to have evidence under every box. The texts and emails from the causal factor timeline and the steps from the work process diagram often supply good supporting evidence. Use one color for boxes backed by a record and another color for boxes based on recollection.
A box without evidence is an action item for the investigation, not a conclusion.
Everyone's 5 Whys is the Map!
A cause-consequence diagram is only as complete as the perspectives that go into it. Notecards put every perspective on the whiteboard before rank and personality shape the discussion. Define the problem first, write in silence, read and post every card, merge the chains, and put evidence under every box.
Additional Reading
Several practitioners have shaped how cause-and-effect analysis is facilitated in industry. Each brings a different emphasis.
Mark Galley (ThinkReliability). Galley developed Cause Mapping, the method this article builds on. It starts with impacts to the organization's goals and connects evidence-based causes in a visual map, and the ThinkReliability website offers free templates and many worked examples.
Bob Latino (Reliability Center, Inc.). Latino and his co-authors developed the PROACT methodology, described in Root Cause Analysis: Improving Performance for Bottom-Line Results. Its logic tree works down from the event through verified hypotheses to physical, human, and latent root causes.
Duke Okes. Okes wrote Root Cause Analysis: The Core of Problem Solving and Corrective Action for ASQ Quality Press. It is a practical, quality-oriented toolkit that focuses on the logic of finding causes rather than heavy statistics.
Brian Hughes (Sologic). Hughes writes and teaches on Sologic's causal analysis method, which looks beyond a straight line of causes to the contributors and conditions around them. His recent work connects root cause analysis with human and organizational performance and learning teams.
Dean Gano (Apollo Root Cause Analysis). Gano's book, Apollo Root Cause Analysis: A New Way of Thinking, offers one of the most thorough treatments of cause-and-effect principles in the RCA literature. His charting approach, later carried into RealityCharting, emphasizes that every cause is also an effect.
This article is the fourth in a series on the core tools of FAST root cause analysis: block diagrams, causal factor timelines, work process diagrams, and cause-consequence diagrams. Read the earlier installments, "Facilitating Reliability Block Diagrams: Follow the Drop," "Facilitating Causal Factor Timelines: Bring the Texts and Emails," and "Facilitating Work Process Diagrams: Start with a Checklist."
Need help getting started? JD Solomon Inc. provides practical solutions for root cause analysis and improving your system performance.
Comments