Creative organizations, teams and leaders often encounter problems, as they explore new frontiers.

In solving a problem, our biases can lead to a dysfunctional “fix”…

Completing a task may involve many people and many steps. If it fails, we often focus on the last people involved or the last steps taken (Availability Heuristic). If we don’t look deeper, our solutions could worsen our situation. For example, if bad news causes us to kill the messenger, we eliminate a good source of information (Shooting the Messenger).

All problems have many causes. If I crash my car into a tree, here are some causes: I wasn’t looking in front of me; the pavement was slick; the car behind me was honking; my passenger was yelling at me; it was raining so hard I couldn’t see; I had a lot on my mind, since my friend is sick; I didn’t get enough sleep; I’m easily distracted.

We can usually prevent recurrence by fixing just one or two systemic causes.  For example, I could drive more slowly, and I could ritually calm myself before driving. However, immediately following my crash, neither I nor my passenger will likely think of this subtle solution.

Forces

People have cognitive biases that prevent them from seeing causes. For example, confirmation bias prefers causes that agree with our initial assumptions. Ingroup bias prefers causes that implicate people outside our close associates. Sunk cost bias shuns causes that involve expensive investments. Recency illusion can prefer causes that have become recently visible, but were present and hidden before. The bandwagon effect prefers causes that other people mention. (List of Cognitive Biases)

A thoughtful analysis process can compensate for cognitive bias. By involving different types of people from outside our group in analyzing a problem, we can overcome confirmation and ingroup bias. Hosting a brainstorming session that allows a cause to be mentioned only once, can reduce the bandwagon effect. Reminding people that agile approaches allow redirecting budgets at any time can reduce sunk cost bias. Asking people to look for systemic causes can reduce recency illusion bias. (Cognitive Bias Mitigation)

People cannot simultaneously compare more than about 5 potential causes [Chunk Before Choosing]. Presenting causal relationships visually can improve our understanding.

When problems occur in highly political organizations, blame and fear are common concerns. People may be blamed by impatient leaders and fearful colleagues as “the cause” of problems, before analysis reveals deeper causes.

Group decision-making produces better outcomes when people:

• Communicate, facilitate and complete a well-planned analysis process
• Develop a thorough and correct understanding of the problem
• Evaluate negative and positive consequences of proposed solutions
• Choose one or more solutions with the best value/cost trade-off [gour1996][kolb2009]

Sakichi Toyoda advised Toyota employees to analyze a problem until they had identified at least one causal chain “five whys” long [ohno1988]. Fixing any of the causes could prevent the problem, and this gave employees many more options.

…therefore, invite stakeholders to jointly produce a cause map, identify root causes, and agree how to fix them.

Here’s how to create a thoughtful cause map for a problem, incorporating the perspectives of many parties:

1. Schedule an hour when most or all involved parties involved in the problem can meet. Be sure to invite people from diverse roles and perspectives, as this will improve the outcome.
2. If people can meet in-person, select a meeting room with a large white board or a high-resolution projector. Otherwise, use an online conferencing system, such as Zoom, Skype, or GoToMeeting
3. If you are using online conferencing or projection, install an application like OmniGraffle or Visio, that allows you to create directed graphs rapidly. Practice creating these graphs in conversation with other people well before the meeting (each of these tools have tricks to make graph construction fast, but the host must learn them in advance).
4. At the beginning of the meeting, write a very brief problem statement inside a node at the center of the board.
5. Call on any specific attendee to state something that caused a named problem on the screen. For the first person called, you might say, “Name one cause for the problem.”
6. Create a new node for the newly stated cause, and draw an arrow from the cause to the problem.  The cause now becomes another problem to consider.
7. Ask the next person to name only one new cause for any problem shown on the board, saying “<cause> caused <one of the nodes on the board>”. Draw the <cause> node (a circle with a very short description inside) with an arrow to the node already on the board.
8. Repeat step 7 until everyone has spoken once. After talking to each person once, a map starts to emerge. Sometimes something causes multiple problems, in which case that node has many arrows leaving it. Allow everyone to review for a moment.
9. Resume step 7 and ask each person in succession to name another cause, until a linear chain of five causes appears somewhere in the graph, or until attendees run out of causes.
10. Then help the team examine the map to find causes that could have been easily prevented. Using those preventable causes, put together a mitigation plan.
11. Take a picture of the cause map, summarize the mitigation plan, and send to all interested parties.

New Context

This approach overcomes many sources of cognitive bias. By forcing people to name an unstated cause for a problem, we avoid confirmation and bandwagon bias. By involving people from diverse roles and perspectives, we avoid ingroup bias and reduce sunk cost bias.

This approach also contributes to an agile base pattern [Embrace Collective Responsibility]. Non-agile companies and their leaders often “throw someone under the bus” when problems appear, diverting blame to avoid leaders having to take responsibility. In a root cause mapping party, however, it doesn’t last if the person is in the room. We can blame someone (“Jeff pushed the button”), but eventually that person gets to describe the cause that made him or her do it (“the documentation is confusing”).  The result is deep understanding of how things happened, and leads us to solutions that might fix more than the specific problem we’re investigating.

By graphing the causes on a board or screen, we reduce the cognitive load on participants, allowing us to consider more complex causes, and solutions that might prevent many causes at once.

When created with colleagues, the cause map becomes a social exercise that reinforces a culture of continuous improvement.

Example

The graph above shows a cause map my colleagues and I, in the Citrix Agile Program Office, made when we missed our 4th quarter goals in 2009. One chain has 7 links, more than the 5 “whys” we need.

• Original problem: Missed quarterly goals
• Split priorities [we were doing many important things at once]
• Took on survey (not aligned) [we decided to work on a huge survey project mid-quarter, with uncertain value]
• Erratic prioritization [we were randomly picking items to work on]
• We seem to like multitasking
• Not willing to say No [people ask us to do stuff, and we just interrupt our current work and do it, rather than thinking about whether it aligns with our quarterly goals]
• Not ranking by value [backlog items for this team didn’t seem to be ranked by return to the company]
• We don’t know how to measure our work’s value

We decided to focus on the cause “Not willing to say No” to distracting, unimportant work. We agreed that we would not take on new work independently, without consulting the team, but focus more on our shared efforts.

We also aligned our personal objectives for the quarter (“No related MBOs [goals] other than for Dan” in the diagram) to the Agile Program Office’s quarterly goals and overall mission. In doing this, we pioneered a new idea to frame every quarterly personal objective as a “stakeholder story.” The next quarter was much better. We accomplished most of our quarterly goals.

References

• [kolb2009] Michaela Kolbe & Margarete Boos, “Facilitating Group Decision-Making: Facilitator’s Subjective Theories on Group Coordination,” Forum: Qualitative Social Research, Volume 10, No. 1, Art. 28 – January 2009. http://www.qualitative-research.net/index.php/fqs/article/view/1244/2692
• [gour1996] Gouran, Danny S. & Hirokawa, Randy Y. (1996). Functional theory and communication in decision-making and problem-solving groups. An expanded view. In Randy Y Hirokawa & Marshall Scott Poole (Eds.), Communication and group decision making (pp.55-80). Thousand Oaks, CA: Sage.
• [ohno1988] Taiichi Ohno, Toyota production system: beyond large-scale production, Portland, Or,  Productivity Press. ISBN 0-915299-14-3 (1988).

Author

Dan Greening