Archive for the ‘Argumentation’ Category
The Approach: a dialogue mapping story
Jack could see that the discussion was going nowhere: the group been talking about the pros and cons of competing approaches for over half an hour, but they kept going around in circles. As he mulled over this, Jack got an idea – he’d been playing around with a visual notation called IBIS (Issue-Based Information System) for a while, and was looking for an opportunity to use it to map out a discussion in real time (Editor’s note: readers unfamiliar with IBIS may want to have a look at this post and this one before proceeding). “Why not give it a try,” he thought, “I can’t do any worse than this lot.” Decision made, he waited for a break in the conversation and dived in when he got one…
“I have a suggestion,” he said. “There’s this conversation mapping tool that I’ve been exploring for a while. I believe it might help us reach a common understanding of the approaches we’ve been discussing. It may even help facilitate a decision. Do you mind if I try it?”
“Pfft – I’m all for it if it helps us get to a decision.” said Max. He’d clearly had enough too.
Jack looked around the table. Mary looked puzzled, but nodded her assent. Rick seemed unenthusiastic, but didn’t voice any objections. Andrew – the boss – had a here-he-goes-again look on his face (Jack had a track record of “ideas”) but, to Jack’s surprise, said, “OK. Why not? Go for it.”
“Give me a minute to get set up,” said Jack. He hooked his computer to the data projector. Within a couple of minutes, he had a blank IBIS map displayed on-screen. This done, he glanced up at the others: they were looking at screen with expressions ranging from curiosity (Mary) to skepticism (Max).
“Just a few words about what I’m going to do, he said. “I’ll be using a notation called IBIS – or issue based information system – to capture our discussion. IBIS has three elements: issues, ideas and arguments. I’ll explain these as we go along. OK – Let’s get started with figuring out what we want out of the discussion. What’s our aim?” he asked.
His starting spiel done, Jack glanced at his colleagues: Max seemed a tad more skeptical than before; Rick ever more bored; Andrew and Mary stared at the screen. No one said anything.
Just as he was about to prompt them by asking another question, Mary said, “I’d say it’s to explore options for implementing the new system and find the most suitable one. Phrased as a question: How do we implement system X?”
Jack glanced at the others. They all seemed to agree – or at least, didn’t disagree – with Mary, “Excellent,” he said, “I think that’s a very good summary of what we’re trying to do.” He drew a question node on the map and continued: “Most discussions of this kind are aimed at resolving issues or questions. Our root question is: What are our options for implementing system X, or as Mary put it, How do we implement System X.”
“So, what’s next,” asked Max. He still looked skeptical, but Jack could see that he was intrigued. Not bad, he thought to himself….
“Well, the next step is to explore ideas that address or resolve the issue. So, ideas should be responses to the question: how should we implement system X? Any suggestions?”
“We’d have to engage consultants,” said Max. “We don’t have in-house skills to implement it ourselves.”
Jack created an idea node on the map and began typing. “OK – so we hire consultants,” he said. He looked up at the others and continued, “In IBIS, ideas are depicted by light bulbs. Since ideas respond to questions, I draw an arrow from the idea to the root question, like so:
“I think doing it ourselves is an option,” said Mary, “We’d need training and it might take us longer because we’d be learning on the job, but it is a viable option. ”
“Good,” said Jack, “You’ve given us another option and some ways in which we might go about implementing the option. Ideally, each node should represent a single – or atomic – point. So I’ll capture what you’ve said like so.” He typed as fast he could, drawing nodes and filling in detail.
As he wrote he said, “Mary said we could do it ourselves – that’s clearly a new idea – an implementation option. She also partly described how we might go about it: through training to learn the technology and by learning on the job. I’ve added in “How” as a question and the two points that describe how we’d do it as ideas responding to the question.” He paused and looked around to check that every one was with him, then continued. “But there’s more: she also mentioned a shortcoming of doing it ourselves – it will take longer. I capture this as an argument against the idea; a con, depicted as red minus in the map.”
He paused briefly to look at his handiwork on-screen, then asked, “Any questions?”
Rick asked, “Are there any rules governing how nodes are connected?”
“Good question! In a nutshell: ideas respond to questions and arguments respond to ideas. Issues, on the other hand, can be generated from any type of node. I can give you some links to references on the Web if you’re interested.”
“That might be useful for everyone,” said Andrew. “Send it out to all of us.”
“Sure. Let’s move on. So, does anyone have any other options?”
“Umm..not sure how it would work, but what about co-development?” Suggested Rick.
“Do you mean collaborative development with external resources?” asked Jack as he began typing.
“Yes,” confirmed Rick.
“What about costs? We have a limited budget for this,” said Mary.
“Good point,” said Jack as he started typing. “This is a constraint that must be satisfied by all potential approaches.” He stopped typing and looked up at the others, “This is important: criteria apply to all potential approaches, so the criterial question should hang off the root node,” he said. “Does this make sense to everyone?”
“I’m not sure I understand,” said Andrew. “Why are the criteria separate from the approaches?”
“They aren’t separate. They’re a level higher than any specific approach because they apply to all solutions. Put another way, they relate to the root issue – How do we implement system X – rather than a specific solution.”
“Ah, that makes sense,” said Andrew. “This notation seems pretty powerful.”
“It is, and I’ll be happy to show you some more features later, but let’s continue the discussion for now. Are there any other criteria?”
“Well, we must have all the priority 1 features described in the scoping document implemented by the end of the year,” said Andrew. One can always count on the manager to emphasise constraints.
“OK, that’s two criteria actually: must implement priority 1 features and must implement by year end,” said Jack, as he added in the new nodes. “No surprises here,” he continued, “we have the three classic project constraints – budget, scope and time.”
The others were now engaged with the map, looking at it, making notes etc. Jack wanted to avoid driving the discussion, so instead of suggesting how to move things forward, he asked, “What should we consider next?”
“I can’t think of any other approaches,” said Mary. Does anyone have suggestions, or should we look at the pros and cons of the listed approaches?”
“I’ve said it before; I’ll say it again: I think doing it ourselves is a dum..,.sorry, not a good idea. It is fraught with too much risk…” started Max.
“No it isn’t,” countered Mary, “on the contrary, hiring externals is more risky because costs can blowout by much more than if we did it ourselves.”
“Good points,” said Jack, as he noted Mary’s point. “Max, do you have any specific risks in mind?”
“Time – it can take much longer,” said Max.
“We’ve already captured that as a con of the do-it-ourselves approach,” said Jack.
“Hmm…that’s true, but I would reword it to state that we have a hard deadline. Perhaps we could say – may not finish in allotted time – or something similar.”
“That’s a very good point,” said Jack, as he changed the node to read: higher risk of not meeting deadline. The map was coming along nicely now, and had the full attention of folks in the room.
“Alright,” he continued, “so are there any other cons? If not, what about pros – arguments in support of approaches?”
“That’s easy, “ said Mary, “doing it ourselves will improve our knowledge of the technology; we’ll be able to support and maintain the system ourselves.”
“Doing it through consultants will enable us to complete the project quicker,” countered Max.
Jack added in the pros and paused, giving the group some time to reflect on the map.
Rick and Mary, who were sitting next to each other, had a whispered side-conversation going; Andrew and Max were writing something down. Jack waited.
“Mary and I have an idea,” said Rick. “We could take an approach that combines the best of both worlds – external consultants and internal resources. Actually, we’ve already got it down as a separate approach – co-development, but we haven’t discussed it yet..” He had the group’s attention now. “Co-development allows us to use consultants’ expertise where we really need it and develop our own skills too. Yes, we’d need to put some thought into how it would work, but I think we could do it.”
“I can’t see how co-development will reduce the time risk – it will take longer than doing it through consultants.” said Max.
“True,” said Mary, “but it is better than doing it ourselves and, more important, it enables us to develop in-house skills that are needed to support and maintain the application. In the long run, this can add up to a huge saving. Just last week I read that maintenance can be anywhere between 60 to 80 percent of total system costs.”
“So you’re saying that it reduces implementation time and results in a smaller exposure to cost blowout?” asked Jack.
“Yes,” said Mary
Jack added in the pros and waited.
“I still don’t see how it reduces time,” said Max.
“It does, when compared to the option of doing it ourselves,” retorted Mary.
“Wait a second guys,” said Jack. “What if I reword the pros to read – Reduced implementation time compared to in-house option and Reduced cost compared to external option.”
He looked at Mary and Max. – both seemed to OK with this, so he typed in the changes.
Jack asked, “So, are there any other issues, ideas or arguments that anyone would like to add?”
“From what’s on the map, it seems that co-development is the best option,” said Andrew. He looked around to see what the others thought: Rick and Mary were nodding; Max still looked doubtful.
Max asked, “how are we going to figure out who does what? It isn’t easy to partition work cleanly when teams have different levels of expertise.”
Jack typed this in as a con.
“Good point,” said Andrew. “There may be ways to address this concern. Do you think it would help if we brought some consultants in on a day-long engagement to workshop a co-development approach with the team? ”
Max nodded, “Yeah, that might work,” he said. “It’s worth a try anyway. I have my reservations, but co-development seems the best of the three approaches.”
“Great,“ said Andrew, “I’ll get some consultants in next week to help us workshop an approach.”
Jack typed in this exchange, as the others started to gather their things. “Anything else to add?” he asked.
Everyone looked up at the map. “No, that’s it, I think,” said Mary.
“Looks good,” said Mike . “Be sure to send us a copy of the map.”
“Sure, I’ll print copies out right away,” said Jack. “Since we’ve developed it together, there shouldn’t be any points of disagreement.”
“That’s true,” said Andrew, “another good reason to use this tool.” Gathering his papers, he asked, “Is there anything else? He looked around the table. “ Alright then, I’ll see you guys later, I’m off to get some lunch before my next meeting.”
Jack looked around the group. Helped along by IBIS and his facilitation, they’d overcome their differences and reached a collective decision. He had thought it wouldn’t work, but it had.
“ Jack, thanks for your help with the discussion. IBIS seems to be a great way to capture discussions. Don’t forget to send us those references,” said Mary, gathering her notes.
“I’ll do that right away,” said Jack, “and I’ll also send you some information about Compendium – the open-source software tool I used to create the map.”
“Great,” said Mary. “I’ve got to run. See you later.”
“See you later,” replied Jack.
————
Further Reading:
1. Jeff Conklin’s book is a must-read for any one interested in dialogue mapping. I’ve reviewed it here.
2. For more on Compendium, see the Compendium Institute site.
3. See Paul Culmsee’s series of articles, The One Best Practice to Rule Them All, for an excellent and very entertaining introduction to issue mapping.
4. See this post and this one for examples of how IBIS can be used to visualise written arguments.
5. See this article for a dialogue mapping story by Jeff Conklin.
Visualising arguments using issue maps – an example and some general comments
The aim of an opinion piece writer is to convince his or her readers that a particular idea or point of view is reasonable or right. Typically, such pieces weave facts , interpretations and reasoning into prose, wherefrom it can be hard to pick out the essential thread of argumentation. In an earlier post I showed how an issue map can help in clarifying the central arguments in a “difficult” piece of writing by mapping out Fred Brooks’ classic article No Silver Bullet. Note that I use the word “difficult” only because the article has, at times, been misunderstood and misquoted; not because it is particularly hard to follow. Still, Brooks’ article borders on the academic; the arguments presented therein are of interest to a relatively small group of people within the software development community. Most developers and architects aren’t terribly interested in the essential difficulties of the profession – they just want to get on with their jobs. In the present post, I develop an issue map of a piece that is of potentially wider interest to the IT community – Nicholas Carr’s 2003 article, IT Doesn’t Matter.
The main point of Carr’s article is that IT is becoming a utility, much like electricity, water or rail. As this trend towards commoditisation gains momentum, the strategic advantage offered by in-house IT will diminish, and organisations will be better served by buying IT services from “computing utility” providers than by maintaining their own IT shops. Although Carr makes a persuasive case, he glosses over a key difference between IT and other utilities (see this post for more). Despite this, many business and IT leaders have taken his words as the way things will be. It is therefore important for all IT professionals to understand Carr’s arguments. The consequences are likely to affect them some time soon, if they haven’t already.
Some preliminaries before proceeding with the map. First, the complete article is available here – you may want to have a read of it before proceeding (but this isn’t essential). Second, the discussion assumes a basic knowledge of IBIS (Issue-Based Information System) – see this post for a quick tutorial on IBIS. Third, the map is constructed using the open-source tool Compendium which can be downloaded here.
With the preliminaries out of the way, let’s get on with issue mapping Carr’s article.
So, what’s the root (i.e. central) question that Carr poses in the article? The title of the piece is “IT Doesn’t Matter” – so one possible root question is, “Why doesn’t IT matter?” But there are other candidates: “On what basis is IT an infrastructural technology?” or “Why is the strategic value of IT diminishing?” for example. From this it should be clear that there’s a fair degree of subjectivity at every step of constructing an issue map. The visual representation that I construct here is but one interpretation of Carr’s argument.
Out of the above (and many other possibles), I choose “Why doesn’t IT matter?” as the root question. Why? Well, in my view the whole point of the piece is to convince the reader that IT doesn’t matter because it is an infrastructural technology and consequently has no strategic significance. This point should become clearer as our development of the issue map progresses.
The ideas that respond to this question aren’t immediately obvious. This isn’t unusual: as I’ve mentioned elsewhere, points can only be made sequentially – one after the other – when expressed in prose. In some cases one may have to read a piece in its entirety to figure out the elements that respond to a root (or any other) question.
In the case at hand, the response to the root question stands out clearly after a quick browse through the article. It is: IT is an infrastructural technology.
The map with the root question and the response is shown in Figure 1.
Moving on, what arguments does Carr offer for (pros) and against (cons) this idea? A reading of the article reveals one con and four pros. Let’s look at the cons first:
- IT (which I take to mean software) is complex and malleable, unlike other infrastructural technologies. This point is mentioned, in passing, on the third page of the paper: “Although more complex and malleable than its predecessors, IT has all the hallmarks of an infrastructural technology…”
The arguments supporting the idea that IT is an infrastructural technology are:
- The evolution of IT closely mirrors that of other infrastructural technologies such as electricity and rail. Although this point encompasses the other points made below, I think it merits a separate mention because the analogies are quite striking. Carr makes a very persuasive, well-researched case supporting this point.
- IT is highly replicable. This is point needs no further elaboration, I think.
- IT is a transport mechanism for digital information. This is true, at least as far as network and messaging infrastructure is concerned.
- Cost effectiveness increases as IT services are shared. This is true too, providing it is understood that flexibility is lost when services are shared.
The map, incorporating the pros and cons is shown in Figure 2.
Now that the arguments for and against the notion that IT is an infrastructural technology are laid out, lets look at the article again, this time with an eye out for any other issues (questions) raised.
The first question is an obvious one: What are the consequences of IT being an infrastructural technology?
Another point to be considered is the role of proprietary technologies, which – by definition – aren’t infrastructural. The same holds true for custom built applications. So, this begs the question, if IT is an infrastructural technology, how do proprietary and custom built applications fit in?
The map, with these questions added in is shown in Figure 3.
Let’s now look at the ideas that respond to these two questions.
A point that Carr makes early in the article is that the strategic value of IT is diminishing. This is essentially a consequence of the notion that IT is an infrastructural technology. This idea is supported by the following arguments:
- IT is ubiquitous – it is everywhere, at least in the business world.
- Everyone uses it in the same way. This implies that no one gets a strategic advantage from using it.
What about proprietary technologies and custom apps?. Carr reckons these are:
- Doomed to economic obsolescence. This idea is supported by the argument that these apps are too expensive and are hard to maintain.
- Related to the above, these will be replaced by generic apps that incorporate best practices. This trend is already evident in the increasing number of enterprise type applications that offered as services. The advantages of these are that they a) cost little b) can be offered over the web and c) spare the client all those painful maintenance headaches.
The map incorporating these ideas and their supporting arguments is shown in Figure 4.
Finally, after painting this somewhat gloomy picture (to a corporate IT minion, such as me) Carr asks and answers the question: How should organisations deal with the changing role of IT (from strategic to operational)? His answers are:
- Reduce IT spend.
- Buy only proven technology – follow don’t lead.
- Focus on (operational) vulnerabilities rather than (strategic) opportunities.
The map incorporating this question and the ideas that respond to it is shown in Figure 5, which is also the final map (click on the graphic to view a full-sized image).
Map completed, I’m essentially done with this post. Before closing, however, I’d like to mention a couple of general points that arise from issue mapping of prose pieces.
Figure 5 is my interpretation of the article. I should emphasise that my interpretation may not coincide with what Carr intended to convey (in fact, it probably doesn’t). This highlights an important, if obvious, point: what a writer intends to convey in his or her writing may not coincide with how readers interpret it. Even worse, different readers may interpret a piece differently. Writers need to write with an awareness of the potential for being misunderstood. So, my first point is that issue maps can help writers clarify and improve the quality of their reasoning before they cast it in prose.
Issue maps sketch out the logical skeleton or framework of argumentative prose. As such, they can help highlight weak points of arguments. For example, in the above article Carr glosses over the complexity and malleability of software. This is a weak point of the argument, because it is a key difference between IT and traditional infrastructural technologies. Thus my second point is that issue maps can help readers visualise weak links in arguments which might have been obscured by rhetoric and persuasive writing.
To conclude, issue maps are valuable to writers and readers: writers can use issue maps to improve the quality of their arguments before committing them in writing, and readers can use such maps to understand arguments that have been thus committed.
Dialogue Mapping: a book review
I’ll say it at the outset: once in a while there comes along a book that inspires and excites because it presents new perspectives on old, intractable problems. In my opinion, Dialogue Mapping : Building a Shared Understanding of Wicked Problems by Jeff Conklin falls into this category. This post presents an extensive summary and review of the book.
Before proceeding, I think it is only fair that I state my professional views (biases?) upfront. Some readers of this blog may have noted my leanings towards the “people side” of project management (see this post , for example). Now, that’s not to say that I don’t use methodologies and processes. On the contrary, I use project management processes in my daily work, and appreciate their value in keeping my projects (and job!) on track. My problem with processes is when they become the only consideration in managing projects. It has been my long-standing belief (supported by experience) that if one takes care of the people side of things, the right outcomes happen more easily; without undue process obsession on part of the manager. (I should clarify that I’m not encouraging some kind of a laissez-faire, process-free approach, merely one that balances both people and processes). I’ve often wondered if it is possible to meld these two elements into some kind of “people-centred process”, which leverages the collective abilities of people in a way that facilitates and encourages their participation. Jeff Conklin’s answer is a resounding “Yes!”
Dialogue mapping is a process that is aimed at helping groups achieve a shared understanding of wicked problems – complex problems that are hard to understand, let alone solve. If you’re a project manager that might make your ears perk up; developing a shared understanding of complex issues is important in all stages of a project: at the start, all stakeholders must arrive at a shared understanding of the project goals (eg, what are we trying to achieve in this project?); in the middle, project team members may need to come to a common understanding (and resolution) of tricky implementation issues; at the end, the team may need to agree on the lessons learned in the course of the project and what could be done better next time. But dialogue mapping is not restricted to project management – it can be used in any scenario involving diverse stakeholders who need to arrive at a common understanding of complex issues. This book provides a comprehensive introduction to the technique.
Although dialogue mapping can be applied to any kind of problem – not just wicked ones – Conklin focuses on the latter. Why? Because wickedness is one of the major causes of fragmentation: the tendency of each stakeholder to see a problem from his or her particular viewpoint ignoring other, equally valid, perspectives. The first chapter of this book discusses fragmentation and its relationship to wickedness and complexity. Fragmentation is a symptom of complexity- one would not have diverse, irreconcilable viewpoints if the issues at hand were simple. According to Conklin, fragmentation is a function of problem wickedness and social complexity, i.e. the diversity of stakeholders. Technical complexity is also a factor, but a minor one compared to the other two. All too often, project managers fall into the trap of assuming that technical complexity is the root cause of many of their problems, ignoring problem complexity (wickedness) and social complexity. The fault isn’t entirely ours; the system is partly to blame: the traditional, process driven world is partially blind to the non-technical aspects of complexity. Dialogue mapping helps surface issues that arise from these oft ignored dimensions of project complexity.
Early in the book, Conklin walks the reader through the solution process for a hypothetical design problem. His discussion is aimed at highlighting some limitations of the traditional approach to problem solving. The traditional approach is structured; it works methodically through gathering requirements, analysing them, formulating a solution and finally implementing it. In real-life, however, people tend to dive headlong into solving the problem. Their approach is far from methodical – it typically involves jumping back and forth between hypothesis formulation, solution development, testing ideas, following hunches etc. Creative work, like design, cannot be boxed in by any methodology, waterfall or otherwise. Hence the collective angst on how to manage innovative product development projects. Another aspect of complexity arises from design polarity; what’s needed (features requested) vs. what’s feasible(features possible) – sometimes called the marketing and development views. Design polarity is often the cause of huge differences of opinion within a team; that is, it manifests itself as social complexity.
Having set the stage in the first chapter, the rest of the book focuses on describing the technique of dialogue mapping. Conklin’s contention is that fragmentation manifests itself most clearly in meetings – be they project meetings, design meetings or company board meetings. The solution to fragmentation must, therefore, focus on meetings. The solution is for the participants to develop a shared understanding of the issues at hand, and a shared commitment to a decision and action plan that addresses them. The second chapter provides an informal discussion of how these are arrived at via dialogue that takes place in meetings. Dialogue mapping provides a process – yes, it is a process – to arrive at these.
The second chapter also introduces some of the elements that make up the process of dialogue mapping. The first of these is a visual notation called IBIS (Issue Based Information System). The IBIS notation was invented by Horst Rittel, the man who coined the term wicked problem. IBIS consists of three elements depicted in Figure 1 below – Issues (or questions), Ideas (that generally respond to questions) and Arguments (for and against ideas – pros and cons) – which can be connected according to a specified grammar (see this post for a quick introduction to IBIS or see Paul Culmsee’s series of posts on best practices for a longer, far more entertaining one). Questions are at the heart of dialogues (or meetings) that take place in organisations – hence IBIS, with its focus on questions, is ideally suited to mapping out meeting dialogues.

Figure 1: IBIS Elements
The basic idea in dialogue mapping is that a skilled facilitator maps out the core points of the dialogue in real-time, on a shared display which is visible to all participants. The basic idea is that participants see their own and collective contributions to the debate, while the facilitator fashions these into a coherent whole. Conklin’s believes that this can be done, no matter how complex the issues are or how diverse and apparently irreconcilable the opinions. Although I have limited experience with the technique, I believe he is right: IBIS in the hands of a skilled facilitator can help a group focus on the real issues, blowing away the conversational chaff. Although the group as a whole may not reach complete agreement, they will at least develop a real understanding of other perspectives. The third chapter, which concludes the first part of the book, is devoted to an example that illustrates this point.
The second part of the book delves into the nuts and bolts of dialogue mapping. It begins with an introduction to IBIS – which Conklin calls a “tool for all reasons.” The book provides a nice informal discussion, covering elements, syntax and conventions of the language. The coverage is good, but I have a minor quibble : one has to read and reread the chapter a few times to figure out the grammar of the language. It would have been helpful to have an overview of the grammar collected in one place (say in a diagram, like the one shown in Figure 2). Incidentally, Figures 1 and 2 also show how an IBIS map is structured: starting from a root question (placed on the left of the diagram) and building up to the right as the discussion proceeds.
A good way to gain experience with IBIS is to use it to create issue maps of arguments presented in articles. See this post for an example of an issue map based on Fred Brooks’ classic article, No Silver Bullet.
Dialogue mapping is issue mapping plus facilitation. The next chapter – the fifth one in the book – discusses facilitation skills required for dialogue mapping. The facilitator (or technographer, as the person is sometimes called) needs to be able to listen to the conversation, guess at the intended meaning, write (or update) the map and validate what’s written; then proceed through the cycle of listening, guessing, writing and validating again as the next point comes up and so on. Conklin calls this the dialogue mapping listening cycle (see Figure 3 below). As one might imagine, this skill, which is the key to successful dialogue mapping, takes lots of practice to develop. In my experience, a good way to start is by creating IBIS maps of issues discussed in meetings involving a small number of participants. As one gains confidence through practice, one shares the display thereby making the transition from issue mapper to dialogue mapper.
One aspect of the listening cycle is counter-intuitive – validation may require the facilitator to interrupt the speaker. Conklin emphasises that it is OK to do so as long as it is done in the service of listening. Another important point is that when capturing a point made by someone, the technographer will need to summarise or interpret the point. The interpretation must be checked with the speaker. Hence validation – and the interruption it may entail – is not just OK, it is absolutely essential. Conklin also emphasises that the facilitator should focus on a single person in each cycle – it is possible to listen to only one person at a time.
A side benefit of interrruption is that it slows downs the dialogue. This is a good thing because everyone in the group gets more time to consider what’s on the screen and how it relates (or doesn’t) to their own thoughts. All too often, meetings are rushed, things are done in a hurry, and creative creative ideas and thoughts are missed in the bargain. A deliberate slowing down of the dialogue counters this.
The final part of the book – chapters six through nine – are devoted to advanced dialogue mapping skills.
The sixth chapter presents a discussion of the types of questions that arise in most meetings. Conklin identifies seven types of questions:
Deontic: These are questions that ask what should be done in order to deal with the issue at hand. For example: What should we do to improve our customer service? The majority of root questions (i.e. starting questions) in an IBIS map are deontic.
Instrumental: These are questions that ask how something should be done. For example: How can we improve customer service? These questions generally follow on from deontic questions. Typically root questions are either deontic or instrumental.
Criterial: These questions ask about the criteria that any acceptable ideas must satisfy. Typically ideas that respond to criterial questions will serve as a filter for ideas that might come up. Conklin sees criterial and instrumental questions as being complementary. The former specify high-level constraints (or criteria) for ideas whereas the latter are nuts-and-bolts ideas on how something is to be achieved. For example, a criterial question might ask: what are the requirements for improving customer service or how will we know that we have improved customer service.
Conklin makes the point that criterial questions typically connect directly to the root question. This makes sense: the main issue being discussed is usually subject ot criteria or constraints. Further, ideas that respond to criterial questions (in other words, the criteria) have a correspondence with arguments for and against the root questions. This makes sense: the pros and cons that come up in a meeting would generally correspond to the criteria that have been stated. This isn’t an absolute requirement – there’s nothing to say that all arguments must correspong to at least one criterion – but it often serves as a check on whether a discussion is taking all constraints into account.
Conceptual: These are questions that clarify the meaning of any point that’s raised. For example, what do we mean by customer service? Conklin makes the point that many meetings go round in circles because of differences in understanding of particular terms. Conceptual questions surface such differences.
Factual: These are questions of fact. For example: what’s the average turnaround time to respond to customer requests? Often meetings will debate such questions without having any clear idea of what the facts are. Once a factual question is identified as such, it can be actioned for someone to do research on it thereby saving a lot of pointless debate
Background: These are questions of context surrounding the issue at hand. An example is: why are we doing this initiative to improve customer service? Ideas responding to such questions are expected to provide the context as to why something has become an issue.
Stakeholder: These are the “who” questions. An example: who should be involved in the project? Such questions can be delicate in situations where there are conflicting interests (cross-functional project, say), but need to be asked in order to come up with a strategy to handle differences opinion. One can’t address everyone’s concerns until one knows who all constitute “everyone”.
Following the classification of questions, Conklin discusses the concept of a dialogue meta-map – an overall pattern of how certain kinds of questions naturally follow from certain others. The reader may already be able to discern some of these patterns from the above discussion of question types. Also relevant here are artful questions – open questions that keep the dialogue going in productive directions.
The seventh chapter is entitled Three Moves of Discourse. It describes three conversational moves that propel a discussion forward, but can also upset the balance of power in the discussion and evoke strong emotions. These moves are:
- Making an argument for an idea or proposal (a Pro)
- Making an argument against an idea (a Con)
- Challenging the context of the entire discussion.
Let’s look at the first two moves to start with. In an organisation, these moves have a certain stigma attached to them: anyone making arguments for or against an idea might be seen as being opinionated or egotistical. The reason is because these moves generally involve contradicting someone else in the room. Conklin contends that dialogue mapping takes removes these negative connotations because the move is seen as just another node in the map. Once on the map, it is no longer associated with any person – it is objectified as an element of the larger discussion. It can be discussed or questioned just as any other node can.
Conklin refers to the last move – challenging the context of a discussion – as “grenade throwing.” This is an apt way of describing such questions because they have the potential to derail the discussion entirely. They do this by challenging the relevance of the root question itself. But dialogue mapping takes these grenades in its stride; they are simply captured as any another conversational move – i.e. a node on the map, usually a question. Better yet, in many cases further discussion shows how these questions might connect up with the rest of the map. Even if they don’t, these “grenade questions” remain on the map, in acknowledgement of the dissenter and his opinion. Dialogue mapping handles such googlies (curveballs to baseball aficionados) with ease, and indicates how they might connect up with the rest of the discussion – but connection is neither required nor always desirable. It is OK to disagree, as long as it is done respectfully. This is a key element of shared understanding – the participants might not agree, but they understand each other.
Related to the above is the notion of a “left hand move”. Occasionally a discussion can generate a new root question which, by definition, has to be tacked on to the extreme left of the map. Such a left hand move is extremely powerful because it generally relates two or more questions or ideas that were previously unrelated (some of them may even have been seen as a grenade).
By now it should be clear that dialogue mapping is a technique that promotes collaboration – as such it works best in situations where openness, honesty and transparency are valued. In the penultimate chapter, the author discusses some situations in which it may not be appropriate to use the technique. Among these are meetings in which decisions are made by management fiat. Other situations in which it may be helpful to “turn the display off” are those which are emotionally charged or involve interpersonal conflict. Conklin suggests that the facilitator use his or her judgement in deciding where it is appropriate and where it isn’t.
In the final chapter, Conklin discusses how decisions are reached using dialogue mapping. A decision is simply a broad consensus to mark one of the ideas on the map as a decision. How does one choose the idea that is to be anointed as the group’s decision? Well quite obviously: the best one. Which one is that? Conklin states, the best decision is the one that has the broadest and deepest commitment to making it work. He also provides a checklist for figuring out whether a map is mature enough for a decision to be made. But the ultimate decision on when a decision (!) is to be made is up to group. So how does one know when the time is right for a decision? Again, the book provides some suggestions here, but I’ll say no more except to hint at them by paraphrasing from the book: “What makes a decision hard is lack of shared understanding. Once a group has thoroughly mapped a problem (issues) and its potential solutions (ideas) along with their pros and cons, the decision itself is natural and obvious.”
Before closing, I should admit that my experience with dialogue mapping is minimal – I’ve done it a few times in small groups. I’m not a brilliant public speaker or facilitator, but I can confirm that it helps keep a discussion focused and moving forward. Although Conklin’s focus is on dialogue mapping, one does not need to be a facilitator to benefit from this book; it also provides a good introduction to issue mapping using IBIS. In my opinion, this alone is worth the price of admission. Further, IBIS can also be used to augment project (or organisational) memory. So this book potentially has something for you, even if you’re not a facilitator and don’t intend to use IBIS in group settings.
This brings me to the end of my long-winded summary and review of the book. My discussion, as long as it is, does not do justice to the brilliance of the book. By summarising the main points of each chapter (with some opinions and annotations for good measure!), I have attempted to convey a sense of what a reader can expect from the book. I hope I’ve succeeded in doing so. Better yet, I hope I have convinced you that the book is worth a read, because I truly believe it is.





















