Dialogue Mapping: Building a Shared Understanding of Wicked Problems

Years ago I met Paul Culmsee. He and I were speaking at a SharePoint best practices conference and we became fast friends – even though he lives halfway across the planet in Perth, Australia. Over the years we’ve had numerous early morning/late night conversations – depending upon whose side of the conversation you were on since we’re literally 12 time zones apart. Paul and I talk about quite a few topics including technology and sense making topics. However, the thing that Paul has a passion for is Dialogue Mapping. So when he suggested Dialogue Mapping: Building a Shared Understanding of Wicked Problems – I knew I had to read it. Paul describes the author, Jeff Conklin, as his mentor. To explain the book, I have to explain the struggle with wicked problems, what they are, and how my thinking works.

Something Wicked This Way Comes

Horst Rittel is the father of both a particular schema for dialog mapping, called IBIS that we’ll get to in a moment, and the idea of a ‘wicked problem’. A wicked problem, in Rittel’s explanation, is: A problem you don’t understand until you have a solution and one which is ill structured involving a set of interlocking constraints. (In other words, the interactions are not able to be completely known.) Wicked problems also have not stopping rule – that is, since you can’t precisely define the problem you can scarcely say that the problem has been resolved.

Living in technology I’m used to problems that are what would be called tame. If you provide more resources performance improves. If you scale out the server farm you can service more users. I’m not saying that some of the solutions that I create aren’t necessarily complicated – but they’re relatively known quantities. For instance, my blog post, Computer Hard Disk Performance – From the Ground Up talks about a bunch of details about computer hard disk performance – but they’re all known. That post is a more detailed echo of an earlier blog post, Fundamentals of SharePoint Performance – Disk, SQL, and Network. That came from work I did a dozen years ago. I talked about the fundamentals of performance testing back in 2006. There are tons of details but they’re just that details – they’ve not fundamentally changed in dozens of years.

Wicked problems, by contrast, make understanding the details and the relationships difficult – because the relationships aren’t stable. When you make a change to one thing it impacts another. This means that you need a different approach than a linear approach. Since there is no stopping rule, you don’t stop when you solve a wicked problem, you stop when you run out of time, money, resources, or energy to work on the wicked problem.

The idea that you are working a linear process is a fallacy anyway. In reality we’re building a mental model for how the problem works. That mental model has us sometimes designing solutions and sometimes trying to figure out if the mental model is complete enough to be valuable. (For more about mental models see: Sources of Power, Thinking, Fast and Slow and Compelled to Control) The diagram – taken from the book – shows a typical case where we believe that there’s a linear progression (red) although what we really do is bounce between problem and solution (green).

Mapping the Wicked Problem with IBIS

If it’s hard to define a wicked problem and if our models of how we solve all problems isn’t right, then how do we get our arms around a wicked problem? This is where simplicity helps. Rittel created an approach he called issue-based information system (IBIS). IBIS has only four elements so the vocabulary is simple. Those are:

Question – These are unanswered questions posed to the group for answer
Idea – An idea is any potential answer to a question; it’s a statement
Pro – This is a statement which supports an idea; it’s a reason why the idea is valid or “right”
Con – This is a statement which minimizes, detracts, or removes support for an idea; a reason why the idea may not be the “right” solution

Fundamental to the approach is that you start with a big question and from there you attach ideas, and additional questions. On the ideas you attach Pros and Cons. From this simple framework you can map out a multitude of issues and get clarity in a conversation that most meetings never reach. The power of IBIS is in its simplicity. It’s easy enough for everyone to understand and rich enough to map out any problem. The heart of IBIS is an attempt to define the real question. In fact, Conklin describes seven different question types.

The Seven Questions and Snow White

We’re quite used to questions being split up by who, what, when, where, and why. We’re less familiar with approaches that break questions into categories about the context of the question. Take a look at these seven question types:

Deontic – What should we do?
Instrumental – How should we do it?
Criteria – What are the criteria?
Meaning/Conceptual – Do we define the term (or problem) the same way?
Factual – What are the facts here?
Background – What is the context of the situation?
Stakeholder – Who are the stakeholders of this problem?

Of course, these archetypes aren’t the only way to define questions. There’s still the fact that questions can be either open or closed. Closed questions lead to a fixed set of answers. Open questions can lead to any answer. As it turns out the more open ended questions lead to better results when discussing problems because they don’t prematurely constrain the discussion. They allow the conversation to diverge before bringing it back together through convergence.

While the four elements are the grammar of IBIS, asking the right questions are the heart and soul of IBIS.

Dialogue Mapping

Oversimplifying it a bit, dialogue mapping is using the IBIS notation and a shared display to facilitate a meeting. The shared display is simply using a projector or TV to allow everyone in the meeting to see what the dialogue mapper is recording. It holds everyone together and ensures that everyone feels their point is heard. If it’s on the map, then it’s been recorded, and they’ve been heard.

However, that is an over simplification. The dialogue mapper isn’t a passive automaton transcribing what is said into a set of pretty pictures. The dialogue mapper is an active part of the discussion. They’re leading the discussion through clarification, summary, and questioning. They’re leading the discussion in the same way you herd a cow – you can’t tell the cow exactly where to go but you can encourage more productive paths.

In addition to IBIS, Conklin discusses a listening cycle where the dialogue mapper focuses on one person at a time to ensure that person is on board. By serially ensuring that every party is heard you can ensure that the group is heard.

The output of the dialogue mapping exercise is group memory. It’s the diagram which is the outline of the discussion and a way for people who weren’t even in the discussion to understand the framework of what was discussed. It allows for the formation of common mental models.

Mental Models

I’ve talked about mental models quite a bit. However, the most powerful conversation about mental models came from Sources of Power. The conversation is powerful in revealing the way that mental models are so invisible to us. They’re like trying to describe air. It just is. The beauty of dialogue mapping is that it helps to illuminate the spaces where my reality – my mental models – aren’t aligned with the mental models of the rest of the group. Those alignment problems may be in the way that I misperceive reality – or in the way that others misperceive reality.

The great part about being aware of these differences is that we can resolve them – or at the very least, acknowledge their existence. By adjusting our perceptions and mental models to be more in line with reality we’re able to see things more clearly and creating solutions gets easier. Indeed, many are quoted as saying that understanding the problem is more than half of the solution.

Dialogue Mapping as a Tool

At the end of the day, Dialogue Mapping is a powerful tool to add to your toolbox if you’re ever confronted with a meeting that never seems to end about topics that people don’t understand and can’t define. Even if your problems are less wicked, the clarity of being able to describe a problem with a few simple building blocks is very freeing.

I mentioned my friend Paul Culmsee at the opening of this post. He’s got a four part blog post series on Dialogue Mapping. I recommend that as well. It’s not as rich as the book – but like most things that Paul does, its solid work and a great start.