Have you ever had to facilitate a meeting where a large number of people was asked to solve a complex problem? It’s stressful and the outcome isn’t necessarily the resolution of the problem. Every time you think you’ve discovered a solution and apply it, the nature of the problem seems to shift. Depending on your skill as a facilitator—and the patience of your participants—you may at least be able to capture some of the sub-problems on a white board and start to build some commitment around solving them. And since most people can’t talk and type at the same time, you better hope that someone else writes down some notes and action items.
Over two days last week, I had the opportunity to attend an issue mapping master class at my place of work. Together with six colleagues and a couple of outside participants, I was trained in issue mapping by Australian trainer and facilitator Paul Culmsee of Seven Sigma Business Solutions.
Issue mapping is a subset of the discipline of dialogue mapping developed by Jeff Conklin, a facilitation process that creates a dialogue map as a live artifact while the meeting takes place. This is typically done on a laptop connected to a projector so that all meeting participants can see the map as it is developed by the facilitator. The map, in turn, may influence the direction of the conversation and helps keep the group on track (for example, it almost completely eliminates repetition). The process creates a shared understanding of the problem, a great, visual set of notes—and may point towards a solution to the problem. An ideal outcome would be for all participants to leave the meeting with a shared commitment to a collaboratively developed solution.
To clearly differentiate dialogue mapping from issue mapping, the latter primarily focuses on creating great maps (you can create maps by yourself, for example to map out a complex argument that has already been captured in text or on video) while the former places additional emphasis on the facilitation aspect (basically, dialogue mapping is a longer course).
Conklin thinks that there’s a particular type of complex problem which he calls a wicked problem (after Horst Rittel, a German design scientist (1930-1990)). If any of the following apply in your context, you might be dealing with a wicked problem:
- You don’t understand the problem until you have developed a solution.
- Wicked problems don’t have clearly defined boundaries and don’t stop being problems when you’ve found a solution.
- You can’t really say a solution to a wicked problem is either right or wrong.
- Wicked problems seem unique.
- The problem changes when you apply a (partial) solution.
- Wicked problems are wicked because of social complexity and diversity of opinion.
(The above points are my summary of information on Jeff Conklin’s website. You may also find his white paper on wicked problems useful.)
To give you a sense of what an issue map might look like, here is an example (click on it to see a larger version):
Obviously, this is a fictitious argument that I have made up. But the map clearly shows the map’s nodes, grammar and structural patterns that connect them. These rules are based on the Issue Based Information System (IBIS) notation and grammar, originally described by Rittel (good background information in this post). There are four types of nodes on an issue map:
- Questions
- Ideas (Answers)
- Pros
- Cons
Your leftmost question should state the problem as broadly as possible to facilitate capturing a broad first ‘layer’ of ideas/answers (a yes/no question isn’t a good starting point for a meeting that’s trying to tackle a wicked problem). If you’re interested in asking better ‘starting questions,’ this blog post by Paul Culmsee is a worthwhile read.
As your meeting gets started, you capture the starting question and ask your participants for ideas in response to the question. Each idea is captured on the screen and explored further. What are some points in support of the idea (pros)? What speaks against the idea (cons)? Does the idea raise another question?
There are a few simple rules of issue mapping grammar: Ideas can only be captured in response to questions (ideas cannot follow ideas). An idea, a pro or a con can be followed by another question (but not another idea without asking another question first). It’s useful to remember certain handy ‘transition questions,’ such as “Really?” or “To what end?” or “Why is that?” or “Such as?”
The software used to map the meeting in this way is called Compendium. Compendium is available for free from the Open University in the UK and works on Windows, Mac OS X and Linux. There is a slight learning curve involved but it’s not terribly steep, and some of the initial frustrations eventually reveal themselves as handy features. (There certainly remain some usability issues that I’m hoping a future release will address.)
After the meeting has ended, most maps need to be refactored to ensure they properly capture and develop all ideas (spelling needs to be checked, repetitions may be eliminated and/or combined into a single point, IBIS grammar needs to be cleaned up). Compendium then allows you to share the map by exporting it to JPEG (for the general user) or XML (for other Compendium users).
My colleague Ruven Gotz is an avid user of MindJet’s MindManager mind-mapping software which I have recently started to use myself for collecting and structuring my thoughts before writing documents. Ruven has in fact created an IBIS-compliant issue-mapping template for MindManager that he’s been using to map meetings. While I love how slick and full-featured MindManager is, I do see the advantages of using Compendium for a variety of other reasons—for example, the fact that it is specific to the IBIS grammar and symbols (and I like its XML export and import feature).
At a basic level, I think I will enjoy using issue mapping to facilitate meetings where groups are trying to resolve complex, open-ended problems, such as determining a strategy or setting business objectives for an IT initiative. I’m not sure that issue mapping would help in meetings that are more oriented towards answering specific questions about software features, or during project execution.
At another level, I’m intrigued by what the patterns of larger issue maps could tell us. Data maps (info graphics) have become all the rage on the social web (sometimes they really serve to illuminate an otherwise hard-to-grasp subject; most times they’re just a clever ideological construct to deliver somebody’s partisan point). I wonder how issue maps from large meetings can help us analyze the ebb and flow of discussions afterwards to discover truths that nobody saw during the meeting itself. Issue maps might close the gap between the world of structured and unstructured data: if we can capture the trajectories and patterns of our conversations by using a universal grammar, can we then data-mine the results in the same way that we analyze a data warehouse to establish meaning and linkages we couldn’t see before?
Even maps from meetings that didn’t seem to result in a solution could remain useful and might yield new insights later.
Interesting. I’m wondering if its useful in teaching, i.e., not necessarily to solve problems but to reconstruct how problems have been formulated, and solutions arrived at in the past.
For example, teaching German idealism to graduate students. The problem = if you think you understand the world through rational models alone, you are forgetting about the importance of evidence; but if you think evidence is prime, you forget the need for models to organize & explain the evidence. But how doe these two activities of the mind fit together. Kant tried a certain explanation, so did Fichte. Schelling another, etc.etc. This is where they arrived at, and these are the new problems that arose.
Alternatively, it could be quite interesting in the classroom to arrive at a different teaching model. E.g., start with a problem, such as Why did the Romantic poets like to write in fragment form? Then work through possible answers???
Not sure… what do you think?
I think that’s an interesting idea. My guess is there are some philosophical problems with the IBIS approach that one would need to be aware of. As a taste, the Wikipedia article about IBIS notes “the danger of getting lost in the web of cross-references, the lack of a ‘synoptic’ overview of the state of resolution, and the ‘logic of the next question”, i.e. the problem of prestructuring the possibilities for guiding the [participants’] deliberations into plausible directions.”
But why not? Perhaps the visual nature of the approach (as opposed to the linearity of text or lecture) outweighs the challenges it poses. It would also be an interesting thing to ask students to map an argument from a text to see what their comprehension of it was. The resulting artifacts would be interesting to compare in a seminar to see where people differed, and why.