Archive for the ‘Consulting’ Category
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.
A quick test of organisational culture
Organisational culture is defined by the values and norms that are shared by people and groups in an organisation. These values and norms, in turn, influence how people interact with each other and with outsiders. That’s well and good, but how does one determine an an organisation’s culture? In my opinion, this is best evaluated by looking at how people react in typical work situations. What follows is a quick quiz to test an organisation’s culture based on this principle.
Note that the test can also be applied to projects – as projects are temporary organisations. Typically project and team cultures simply reflect those of the organisations in which they exist. However, there can be differences: a good project or team leader can (to an extent) shield his or her team from the effects of a toxic organisational culture. But that’s fodder for another post. For now, let’s get on with the quiz.
A tip before starting: don’t over-think your answers; your initial response is probably the most accurate one.
Ready? Right, here we go…the sixty-second quiz on your workplace culture:
a) You make a mistake that no one notices. What do you do:
- Keep quiet about it and hopes it remains unnoticed.
- Own up because it is OK to make mistakes around here.
- Dream up a scheme to pin it someone else, preferably a rival for a promotion.
b) You have an idea that might lead to a new product. You
- Use workmates and manager as a sounding board for whether it is any good.
- Start to work it through yourself to see if it is any good.
- Forget about it
c) You have an idea which involves collaborating with someone from another department. You
- Approach the person directly.
- Go through the proper channels – approach your manager who approaches their manager and so on.
- Forget about it: inter-departmental politics would get in the way.
d) People at an organisation-wide event (company day or a project team day out, for example):
- Stick with folks from their departments.
- Mingle, and look like they’re enjoying it.
- Look like they want to be elsewhere. In fact many of them are – they’ve called in sick.
e) A project has gone horribly wrong. Do people
- Look for a scapegoat.
- Say, “I had nothing to do with it.”
- Work together to fix it.
f) Someone from another department approaches you for assistance relating to your area of expertise. Do you
- Help them right away, or as soon as you can.
- Ask them to speak to your manager first.
- Fob them off – you’re way too overworked and don’t really feel like doing a whit of work more than you absolutely have to.
g) What do people in your organisation do when they are annoyed by some aspect of their job? (Note: see this post for more on this question)
- They complain about it.
- They ignore it.
- They fix it.
h) The atmosphere in cross-departmental meetings in your organisation is generally:
- Cordial.
- Tense
- Neutral
i) An impossible deadline looms. In order to meet it you
- Work overtime because you have to.
- Work overtime because you want to.
- This question is inapplicable – you never have impossible deadlines.
j) You’ve done something brilliant that saves the organisation a packet. Your manager:
- Acknowledges your efforts publicly.
- Acknowledges your efforts privately.
- Grabs the glory.
k) You’ve worked overtime on a project and its all come good. You get
- A pat on the back.
- A pat on the back and something tangible (a bonus, a meal or at least a movie voucher)
- Nothing (We pay you a salary, don’t we?)
l) You’re feeling under the weather, but are not really sick (Put it this way: no doctor would give you a certificate). However, you honestly don’t think you can make it through the work day. What do you do?
- Thank God and take the day off.
- Go to work because you want to.
- Go to work because you have to.
Score:
The score for each response is the number in brackets against the choice you made.
a. 1 (5) 2(10) 3(0)
b. 1(10) 2(5) 3(0)
c. 1(10) 2(5) 3(0)
d. 1(5) 2(10) 3(0)
e. 1(0) 2(5) 3(10)
f. 1(10) 2(5) 3(0)
g. 1(0) 2(5) 3(10)
h. 1(10) 2(0) 3(5)
i. 1(0) 2(5) 3(10)
j. 1(10) 2(5) 3(0)
k. 1(5) 2(10) 3(0)
l. 1(0) 2(10) 3(5)
What does your score mean?
> 100 : Does your organisation have any vacancies for a PM/dev manager?
80-95 : I bet you enjoy working here.
60-75: Still on the right side of the divide, but things do get unpleasant occasionally
40 -55: Things could be a lot worse – but, they could also be better.
20-35: Things are a lot worse
< 20: Workplace hell?
A good organisational culture is one which encourages and enables people to do the right thing without coercion or fear of consequences. What’s right? Most people just know what is right and what’s not, without having to be told. I can think of no better way to end this post than by quoting from the start of Robert Pirsig’s classic, Zen and The Art of Motorcycle Maintenance:
And what is good, Phædrus,
And what is not good…
Need we ask anyone to tell us these things?
Beyond words: visualising arguments using issue maps
Anyone who has struggled to follow a complex argument in a book or article knows from experience that reasoning in written form can be hard to understand. Perhaps this is why many people prefer to learn by attending a class or viewing a lecture rather than by reading. The cliché about a picture being worth more than a large number of words has a good deal of truth to it: visual representations can be helpful in clarifying complex arguments. In a recent post, I presented a quick introduction to a visual issue mapping technique called IBIS (Issue Based Information System), discussing how it could be used on complex projects. Now I follow up by demonstrating its utility in visualising complex arguments such as those presented in research papers. I do so by example: I map out a well known opinion piece written over two decades ago – Fred Brooks’ classic article, No Silver Bullet, (abbreviated as NSB in the remainder of this article).
[Note: those not familiar with IBIS may want to read one of the introductions listed here before proceeding]
Why use NSB as an example for argument mapping? Well, for a couple of reasons:
- It deals with issues that most software developers have grappled with at one time or another.
- The piece has been widely misunderstood (by Brooks’ own admission – see his essay entitled No Silver Bullet Refired, published in the anniversary edition of The Mythical Man Month).
First, very briefly, for those who haven’t read the article: NSB presents reasons why software development is intrinsically hard and consequently conjectures that “silver bullet” solutions are impossible, even in principle. Brooks defines a silver bullet solution for software engineering as any tool or technology that facilitates a tenfold improvement in productivity in software development.
To set the context for the discussion and to see the angle from which Brooks viewed the notion of a silver bullet for software engineering, I can do no better than quote the first two paragraphs of NSB:
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.
The familiar software project, at least as seen by the non-technical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet—something to make software costs drop as rapidly as computer hardware costs do.
The first step in mapping out an argument is to find the basic issue that it addresses. That’s easy for NSB; the issue, or question, is: why is there no silver bullet for software development?
Brooks attempts to answer the question via two strands:
- By examining the nature of the essential (intrinsic or inherent) difficulties in developing software.
- By examining the silver bullet solutions proposed so far.
That gives us enough for us to begin our IBIS map …
The root node of the map – as in all IBIS maps – is a question node. Responding to the question, we have an idea node (Essential difficulties) and another question node (What about silver bullet solutions proposed to date). We also have a note node which clarifies what is meant by a silver bullet solution.
The point regarding essential difficulties needs elaboration, so we ask the question– What are essential difficulties?
According to Brooks, essential difficulties are those that relate to conceptualisation – i..e. design. In contrast, accidental (or non-essential) difficulties are those pertaining to implementation. Brooks examines the nature of essential difficulties – i.e. the things that make software design hard. He argues that the following four properties of software systems are the root of the problem:
Complexity: Beyond the basic syntax of a language, no two parts of a software system are alike – this contrasts with other products (such as cars or buildings) where repeated elements are common. Furthermore, software has a large number of states, multiplied many-fold by interactions with other systems. No person can fully comprehend all the consequences of this complexity. Furthermore, no silver bullet solution can conquer this problem because each program is complex in unique ways.
Conformity: Software is required to conform to arbitrary business rules. Unlike in the natural sciences, these rules may not (often do not!) have any logic to them. Further, being the newest kid on the block, software often has to interface with disparate legacy systems as well. Conformity-related issues are external to the software and hence cannot be addressed by silver bullet solutions.
Changeability: Software is subject to more frequent change than any other part of a system or even most other manufactured products. Brooks speculates that this is because most software embodies system functionality (i.e. the way people use the system), and functionality is subject to frequent change. Another reason is that software is intangible (made of “thought stuff”) and perceived as being easy to change.
Invisibility: Notwithstanding simple tools such as flowcharts and modelling languages, Brooks argues that software is inherently unvisualisable. The basic reason for this is that software – unlike most products (cars, buildings, silicon chips, computers) – has no spatial form.
These essential properties are easily captured in summary form in our evolving argument map:
Brooks’ contention is that software design is hard because every software project has to deal with unique manifestations of these properties.
Brooks then looks at silver bullet solutions proposed up to 1987 (when the article was written) and those on the horizon at the time. He finds most of these address accidental (or non-intrinsic) issues – those that relate to implementation rather than design. They enhance programmer productivity – but not by the ten-fold magnitude required for them to be deemed silver bullets. Brooks reckons this is no surprise: the intrinsic difficulties associated with design are by far the biggest obstacles in any software development effort.
In the map I club all these proposed solutions under “silver bullet solutions proposed to date.”
Incorporating the above, the map now looks like:
[For completeness here’s a glossary of abbreviations: OOP – Object-oriented programming; IDE – Integrated development environment; AI – Artificial intelligence]
The proposed silver bullets lead to incremental improvements in productivity, but they do not address the essential problem of design. Further, some of the solutions have restricted applicability. These points are captured as pros and a cons in the map (click on the map to view a larger image):
It is interesting to note that in his 1997 article, No Silver Bullet Refired , which revisited the questions raised in NSB, Brooks found that the same conclusions held true. Furthermore, at a twentieth year retrospective panel discussion that took place during the 22nd International Conference on Object-Oriented Programming, Systems, Languages, and Applications, panellists again concluded that there’s no silver bullet – and none likely.
Having made his case that no silver bullet exists, and that none are likely, Brooks finishes up by outlining a few promising approaches to tackling the design problem. The first one, Buy don’t build, is particularly prescient in view of the growth of the shrink-wrapped software market in the two decades since the first publication of NSB. The second one – rapid prototyping and iterative/incremental development – is vindicated by the widespread adoption and mainstreaming of agile methodologies. The last one, nurture talent, perhaps remains relatively ignored. It should be noted that Brooks considers these approaches promising, but not silver bullets; he maintains that none of these by themselves can lead to a tenfold increase in productivity.
So we come to the end of NSB and our map, which now looks like (click on the map to view a larger image):
The map captures the essence of the argument in NSB – a reader can see, at a glance, the chain of reasoning and the main points made in the article. One could embellish the map and improve readability by:
- Adding in details via note nodes, as I have done in my note explaining what is meant by a silver bullet.
- Breaking up the argument into sub-maps – the areas highlighted in yellow in each of the figures could be hived off into their own maps.
But these are details; the essence of the argument in NSB is captured adequately in the final map above.
In this post I have attempted to illustrate, via example, the utility of IBIS in constructing maps of complicated arguments. I hope I’ve convinced you that issue maps offer a simple way to capture the essence of a written argument in an easy-to-understand way.
Perhaps the cliche should be revised: a picture may be worth a thousand words, but an issue map is worth considerably more.
IBIS References on the Web
For a quick introduction, I recommend Jeff Conklin’s introduction to IBIS on the Cognexus site (and the links therein) or my piece on the use of IBIS in projects. If you have some time, I highly recommend Paul Culmsee’s excellent series of posts: the one best practice to rule them all.








