Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Issue Mapping’ Category

Unforeseen consequences – an unexpected sequel to my previous post

with 4 comments

Introduction – a dilemma resolved?

Last week I published a post about how a friend and I used the Issue-based Information System (IBIS) notation to map out a dilemma he was facing – whether to accept or decline a job offer.  The final map  of that discussion is reproduced in Figure 1 below.

Figure 1: Final map from previous post

The map illustrates how we analysed the pros and cons of the options before him.

As I’d mentioned in the post, a couple of days after we did the map, he called to tell me that he had accepted the offer. I was pleased that it had worked out for him and was pretty sure that the dilemma was essentially resolved: he’d accepted the job, so that was that.

..or so I thought.

An unforeseen consequence

Last Saturday I happened to meet  him again.  Naturally,  I asked him how things were going – how his current employer had reacted to his resignation etc.

“You’re not going to believe this,” he said. “After he heard that I had resigned, the CEO (who is many levels above me in the org chart) asked to see me immediately.”

“Wow!”  I couldn’t help interjecting.

“…Yeah. So, I met him and we had a chat. He told me that management had me marked for a role at a sister organization, at a much higher level than I am at now. So he asked me to hold off for a day or two, until I’d heard what was on offer. When I told him I’d signed the contract already, he said that I should hear what they had to say anyway.”

Wow, indeed –   we couldn’t have anticipated this scenario… or could we?

An expert’s observations

In a comment on that post Tim van Gelder makes two important points:

  1. The options explored in the map (accept/decline) are in fact the same point – one is simply the negation of the other.  So this should be represented as a single option (either accept or decline), with the pros arguing for the represented option and the cons arguing for the unrepresented one.
  2. Options other than the obvious one (accept or decline) should have been explored.

In my response I pointed out that although representing the two options as separate points causes redundancies, it can help participants “see” arguments that may not be obvious immediately.  One is drawn to consider each of the actions separately because they are both represented as distinct options, each with their own consequences (I’ll say more about this later in this post). The downside, as Tim mentions,  is more clutter and superfluity. This is not necessarily a problem for small maps but can be an issue in larger ones.

However, it is the second point that is more relevant here. In my response to Tim’s comment I stated:

For completeness we ought to have explored options other than the two (one?) that we did, and had we more time we may have done so. That said, my mate viewed this very much as an accept/decline dilemma (precluding other options) because he had only a day to make a decision.

Clearly, in view of what happened, my argument about not having enough time is a complete cop out:  we should have made the time to explore the options because it is precisely what had come back to bite us.

Choice and consequence

In hindsight it’s all very well to say that we could have done this or should have done that. The question is: how could we have given ourselves the best possible chance to have foreseen the eventuality that occurred (and others ones that didn’t)?

One way to do this is to explore other ideas in response to the root question: what should I do? (see Figure1).  However, it can be difficult for the person(s) facing the dilemma to come up with new ideas when one option looms so much larger than all others. It is the facilitator’s job to help the group come up with options when this happens, and I had clearly failed on this count.

Sure, it can be difficult to come up with options out of the blue – especially when one is not familiar with the context and background of the problem. This highlights the importance of getting a feel for things before the discussion starts. In this case, I should have probed my friends current work situation, how he was regarded at his workplace and his motivations for moving before starting with the map. However, even had I  done so, it is moot whether we would have foreseen the particular consequence that occurred.

So,  is there any way to get participants thinking about consequences of their choices?  Remember, in IBIS one “evaluates” an  idea in terms of its pros and cons. Such an analysis  may not include consequences .

In my opinion, the best way to get folks thinking about consequences is to ask the question explicitly: “What are the consequences of this idea/option?”

Figure 2 illustrates how this might have worked in the case of my friend’s dilemma. Had we brainstormed the consequences of accepting, he may well have come up with the possibility that actually eventuated.

Figure 2: Exploring consequences (branch highlighted in yellow

The branch highlighted in yellow shows how we might have explored the consequences of accepting the job. For each consequence one could then consider how one might respond to it. The exploration of responses could be done on the same map or hived off into its own map as I’ve shown in the figure. Note that clicking on a map node in Compendium (the free software tool used to create IBIS maps)  simply opens up a new map. Such sub-maps offer a convenient way to organise complex discussions into relatively self-contained subtopics.

I emphasise that the above is largely a  reframing of pros and cons: all the listed consequences  can be viewed as  pros or cons (depending on whether the consequence is perceived as a negative or a positive one). However asking for consequences explicitly prompts participants to think in terms of what could happen, not just known pros and cons.

Of course, there is no guarantee that this process would have enabled us to foresee the situation that actually occurred. This deceptively simple dilemma is indeed wicked.


On Sunday I happened to re-read Rittel and Webber’s classic paper on wicked problems. In view of what had occurred, it isn’t surprising that the following lines in the paper had a particular resonance:

With wicked problems…. any solution, after being implemented, will generate waves of consequences over an extended–virtually an unbounded– period of time. Moreover, the next day’s consequences of the solution may yield utterly undesirable repercussions which outweigh the intended advantages or the advantages accomplished hitherto. In such cases, one would have been better off if the plan had never been carried out.

The full consequences cannot be appraised until the waves of repercussions have completely run out, and we have no way of tracing all the waves through all the affected lives ahead of time or within a limited time span.

I can’t hope to put it any better than that.

Written by K

August 20, 2010 at 5:50 am

To accept or to decline: mapping life’s little dilemmas using IBIS

with 8 comments


Last weekend I met up with a friend I hadn’t seen for a while. He looked a bit preoccupied so I asked him what the matter was. It turned out he had been offered a job and was mulling over whether he should accept it or not. This dilemma is fairly representative of some of the tricky personal decisions that we are required to make at various junctures in our lives: there’s never enough information to be absolutely certain about the right course of action, and turning to others for advice isn’t particularly helpful because their priorities and motivations are likely differ from ours.

The question of whether or not to accept a job offer is a wicked problem because it has the following characteristics:

  1. It is a one-shot operation.
  2. It is unique.
  3. One is liable to face the consequences of whatever choice one makes (one has no right to be wrong)
  4. Since one can make only one choice, one has no opportunity to test the correctness of ones choice.
  5. The choice one makes (the solution) depends on which aspects of the two choices one focuses on (i.e. the solution depends on ones explanation of the issue).

Admittedly, there are some characteristics of wickedness that the job dilemma does not satisfy. For example, the problem has a definitive formulation (specified by the choices) and there are an enumerable number of choices (accept or decline). Nevertheless, since it satisfies five criteria, one can deem the problem as being wicked. No doubt, those who have grappled with this question in real life will probably agree.

Horst Rittel, the man who coined the term wicked problem also invented the Issue-based Information System (IBIS) notation to document and manage such problems (note that I don’t use the word “solve” because such problems can’t be solved in the conventional sense). The notation is very easy to learn because it has just three elements and a simple grammar – see this post for a quick introduction.  Having used IBIS to resolve work related issues before (see this post, for example), I thought it might help my friend if we could used it to visualize his problem and options. So, as we discussed the problem,   I did a pencil and paper IBIS map of the issue (I didn’t have my computer handy at the time).   In the remainder of this post, I reconstruct the map based on my recollection of the conversation.

Developing the map

All IBIS maps begin with a root question that summarises the issue to be resolved.  The dilemma faced by my friend can be summarized by the question:

What should I do (regarding the job offer)?

Questions are represented by blue-green question marks in IBIS (see Figure 1).

There are two possible responses to the question– accept or decline. Responses are referred to as ideas in IBIS, and are denoted by yellow lightbulbs.  The root question and the two ideas responding to it are shown in Figure 1.

Figure 1

An IBIS map starts with the root questions and develops towards the right as the discussion progresses.

The next step is to formulate arguments for and against each idea.  These are referred to as pros and cons in IBIS, and are denoted by a green + and red – sign respectively (See Figures 2 and 3 for examples of these).

We focused on the “accept” option first. The pros were quite easy to see as the offer was generous and the new role a step up from where he was now. I asked him to describe list all the pros he could think of.  He mentioned the following:

  1. Better pay (30% more than current)
  2. Greater responsibility compared to current job.
  3. Good learning opportunity (new domain)
  4. Better career prospects

These points have been depicted in Figure 2.

I felt the second point needed clarification, so I asked him to elaborate on what he meant by “Greater responsibility.” Now,  any node in IBIS can be elaborated by asking appropriate questions and responding to them. He mentioned that he would be managing a bigger team which was responsible for a wider range of functions. I broke these up into two points elaborating on the “greater responsibility” point. The elaborations are on the extreme right in Figure 2.

Figure 2

“Do you see any downside to taking the job?” I asked.

“A big one,” he said, “there are all the unknowns that go with a new working environment: the need to build relationships from scratch, greater pressure and possibly longer working hours until I establish my credibility.”

I mapped these points with “New working environment” as the main point and the others as elaborations of it.

I then asked him if there were any other cons he could think of.

“Just one,” he said, “From what I hear,  the company may not be as stable as my current employer.”

I added this in and   asked him to check if the map was an accurate representation of what he meant. “Yes,” he said, “that’s a good summary of my concerns.”

The map at this stage is shown in Figure 3.

Figure 3

He seemed to be done with the “accept” option, so I suggested moving on to outlining arguments for and against staying with his present employer.

Tellingly, he outlined the pros first:

  1. He was in his comfort zone – he knew what was expected of him and was able to deliver it with ease.
  2. The working environment in his company was excellent.
  3. The company was doing very well and the outlook for the foreseeable future was good.

I mapped these as he spoke. After he was done, I asked him to outline the cons of staying. Almost right away he mentioned the following:

  1. No prospects for career advancement; the job was a dead end.
  2. After five odd years, he was getting a bit bored.

The map at this stage is shown in Figure 4.

Figure 4

Through the conversation, he was watching me sketch out the map on paper, but he hadn’t been looking too closely (perhaps because my handwriting is pure chicken scrawl). Nevertheless, at this point he turned the paper around to have a closer look, and said, “Hey, this isn’t bad – my options and reasons for and against them in one glance.”

I asked him if the analysis thus far suggested a choice.

“No,” he said shaking his head.

To make progress, I suggested looking at the cons for both options, to see if these could be mitigated in some way.

We looked at the “stay with the current employer option” – there was really nothing that could be done about the issue of career stagnation or the fact that the work was routine. The company couldn’t create a new position just for him, and the work was all routine because  he had done it for so long.

Finally, we turned our attention to the cons of the “move to the new employer” option.

After a while, he said “The uncertainty regarding a new work environment isn’t specific to this employer. It applies to any job – including the ones I may consider in future.”

“That’s an excellent point,” I said, “So we should disregard it, right?”

“Yes. So we’re left with only the stability issue.”

“Perhaps you can search the Web for some information on the company and may be even ask around.”

“I think things are a lot clearer now,” he said as I  added the points we’d just discussed to the map.

Figure 5

Figure 5 shows the final result of our deliberations.


A few days later he called to tell me that he had accepted the job, but only after satisfying himself  that the company was sound.  He had to rely on information that he found on the web because no one in his network of accquaintances knew anything about the company.  But that’s OK, he said –   absolute certainty is impossible when dealing with life’s little dilemmas.

Written by K

August 12, 2010 at 10:34 pm

Visualising content and context using issue maps – an example based on a discussion of Cox’s risk matrix theorem

with 2 comments


Some time ago I wrote a post on a paper by Tony Cox which describes some flaws in risk matrices (as they are commonly used) and proposes an axiomatic approach to address some of the problems.  In a recent comment on that post, Tony Waisanen suggested that someone take up the challenge to map the content of the  post and the ensuing discussion using issue mapping.   Hence my motivation to write the present post.

My main aims  in this post are to:

  1. Create an issue map visualising the content of my post on  Cox’s paper.
  2. Incorporate points raised in the comments into the map,  and show how they relate to Cox’s arguments.

A quick word about the notation and software before proceeding. I’ll use the IBIS (Issue-based information system) notation to map the argument.  Those unfamiliar with IBIS will find a   quick introduction here.  The mapping is done using Compendium, an open source issue mapping tool (that can do other things too).   I’ll provide a commentary as I build the map, because the detail behind the map cannot be seen in the screenshot

First map: the flaws in risk matrices and how to fix them

Cox ask’s the question: “What’s wrong with risk matrices?” – this is, in fact, the title of the paper in which he describes his theorem. The question is therefore an excellent starting point for our map.

As an answer to the question, Cox lists the following points as problems/flaws in risk matrices:

  1. Poor resolution: risk matrices use qualitative categories (typically denoted by colour – red, green, yellow). Risks within a category cannot be distiguished.
  2. Incorrect ranking of risks: In some cases, risks can end up in the wrong qualitative category – i.e. a quantitatively higher risk can be mistakenly categorised as a low risk and vice versa. In the worst case, this can lead to suboptimal resource allocation – i.e. a lower risk being given a higher priority.
  3. Subjective inputs: Often, the criteria used to rank risks are based on subjective inputs. Such subjective inputs are prone to cognitive bias. This leads to inaccurate and unreliable risk rankings.
  4. See my posts limitations of scoring methods in risk analysis and cognitive biases as project meta-risks for more on the above points.

The map with the root question, problems (ideas or responses, in IBIS terminology)  and their consequences is shown in Figure 1. Note that I’ve put numbers (1), (2) etc. against the points so that I can refer to them by number in other nodes.

Figure 1: What's wrong with risk matrices?

The next question suggests itself:   we’ve asked “What’s wrong with risk matrices?” so an obvious follow-up question is, “What can be done to fix risk matrices?”  There are a few approaches available to address the problems. These are dicussed in my post and the discussion following it. The approaches can be summarised as follows:

  1. Statistical approach:  This involves obtaining the correct statistical distributions for probability of the risk occuring and the impact of the risk. This is generally hard to do because of the lack of data. However, once this is done, it obviates the need for risk matrices. Furthermore, it warns us about situations in which risk matrices may mislead.   In Cox’s words, “One (approach) is to consider applications in which there are sufficient data to draw some inferences about the statistical distribution of (Probability, Consequence) pairs. If data are sufficiently plentiful, then statistical and artificial intelligence tools … can potentially be applied to help design risk matrices that give efficient or optimal (according to various criteria) discrete approximations to the quantitative distribution of risks. In such data-rich settings, it might be possible to use risk matrices when they are useful (e.g., if probability and consequence are strongly positively correlated) and to avoid them when they are not (e.g., if probability and consequence are strongly negatively correlated).”  This is, in principle,  the best approach.
  2. Qualitative approach: This approach was discussed by Glen Alleman in this comment. It essentially involves characterising impact using qualitative information –  i.e. narrative descriptions of impact. To quote from Glen’s comment, “...the numeric value of impacts are replaced by narrative descriptions of the actual operational impacts from the occurrence of the risk. These narratives are developed through analysis of the system…the quantitative risk as a product is abandoned in place of a classification of response to a predefined consequence.” This approach side steps a couple of the issues with risk matrices. Further, many risk aware organisations have used this method with great success (Glen mentions that NASA and the Department of Defense use such an approach to analyse risks on spaceflight/aviation projects)
  3. Axiomatic approach: This is the approach that Tony Cox discusses in his paper. It has the advantage of being simple – it assumes that the risk function (defined as probability x impact, for example) is continuous whilst also ensuring consistency to the extent possible (i.e. ensuring a correct quantitative ranking of risks). The downside, as Glen emphasises in his comments, is that risk functions are actually discrete, as discussed in (1) above.  Cox’s arguments hinge on the continuity of the risk function, so they do not apply to the discrete case.

The map with these approaches added in is depicted in Figure 2. Note that I’ve added Cox’s theorem in as a map node, indicating that a detailed discussion of the theorem is presented in a separate map.

Figure 2: ...and what can be done to fix them.

Note also, that I have added an idea node representing how the issue regarding subjective inputs can be addressed. I will not pursue this point further in the present post as it did not come up in the discussion. That said, I have discussed this point in some detail in an article on cognitive bias in project risk management.

Second map: Cox’s risk matrix theorem

Since the entire discussion is based on Cox’s arguments, it is worth looking into his paper in some detail – in particular, at the axioms  and the theorem itself. It is convenient to hive this material off into a separate map, but one connected to the original map  (see the map node representing the theorem in Figure 2 above).

The root question  of the new map would be,  “What is the basis of Cox’s theorem?” Answer: the theorem is based on the axioms and other (tacit) assumptions.

Now, my earlier post on Cox’s theorem contains a very detailed treatment of the axioms, so I’ll offer only a one-line explanation for each here. The axioms are:

  1. Weak consistency – which states that all risks in the highest category (red) must represent quantitatively higher risks than those in the lowest category (green).
  2. Consistent colouring – As far as possible, risks with the same quantitative value must have the same colour.
  3. Between-ness – small changes in probability or impact (i.e. the risk function) should not cause a risk to move from the highest (red) to lowest (green) or vice versa.

The axioms are intuitively appealing – they express a basic  consistency that one would expect risk matrices to satisfy.  The secondary map, with the three axioms shown is depicted in Figure 3.

Figure 3: Cox's Axioms

Cox’s theorem, which  essentially follows from these axioms, can be stated as follows: In a risk matrix that satisfies the three axioms, all cells in the bottom row and left-most column must be green and all cells in the second from bottom row and second from left column must be non-red.

The theorem has two corollaries:

  1. 2×2 matrices cannot satisfy the theorem.
  2. 3×3 and 4×4 matrices which satisfy the theorem have a unique colouring scheme.

These are rather surprising conclusions, arrived at from some very intuitive axioms. The secondary map, with the theorem and corollaries added in is shown in Fig. 4.

Figure 4: Cox's risk matrix theorem

Figure 4: The theorem, corollaries and axioms

That completes the map of the theorem. However, in this comment Glen Alleman pointed out that the assumption of a continuous function to describe risk  (such as risk = probability x impact, where both quantities on the right hand side are continuous functions) is questionable. He also makes the point the probability is specified by a distribution, and numerical values that come out of distributions  cannot be combined via arithmetic operations. The reason that folks make the simplifying assumptions  (of continutity and ignoring the probabilistic nature of the variables)   is that it is intuitive and easy to work with. As I mentioned in one of my responses to the comments, one can choose to define risk this way although it isn’t logically sound.  Cox’s theorem essentially specifies consistency conditions that need to be satisfied when such ad-hoc approaches are used. The map with this discussion included is shown in Figure 5 (click anywhere on figure to view a full-sized image)

Figure 5: The theorem in context (Axioms and assumptions made explicit)

That completes the mapping exercise: Figures 2 and 5 represent a fairly complete map of the post and the discussion around it.

Caveats and conclusions

At the risk of belaboring the obvious, the maps represent my interpretation of Cox’s work and my interpretation of others’ comments on my post on Cox’s work. Further, the discussion on which the maps are based is far from comprehensive because it did not cover other limitations of risk matrices. Please see my post on limitations of scoring methods in risk analysis for a detailed discussion of these.

Before closing, it is worth looking at the Figures 2 and 5 from a broader perspective: the figures make clear the context of the discussion in a way that is simply not possible through words. As an example, Figure 2 lays bare the context of Cox’s theorem –  it emphasises, for example, that Cox’s approach  isn’t the only  method to fix what’s  wrong with risk matrices. Further, Figure 5 distinguishes between explicitly declared and tacit assumptions.  Examples of the former are the three axioms and that of the latter is the assumption of continuity.

In this post  I’ve  summarised the content and context of Cox’s risk matrix theorem via issue mapping. The maps  provide an “at a glance” summary of the theorem alongwith supporting assumptions and axioms.  Further,  the maps also incorporate key elements of readers’  reaction regarding the post. I hope this example clarifies the content and context of my earlier post on Cox’s risk matrix theorem, whilst also serving as a demonstration of the utility of the IBIS notation in mapping complex arguments.


Thanks go out to Tony Waisanen for suggesting that the post and comments be issue mapped, and to Glen Alleman, Robert Higgins and Prakash Vaidhyanathan for their contributions to the discussion.

Written by K

December 18, 2009 at 11:16 pm

The Approach: a dialogue mapping story

with 18 comments

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 notereaders 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.”

Figure 1

Figure 1

“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:

Figure 2

Figure 2

“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?”

Figure 3

Figure 3

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.

Figure 4

Figure 4

“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?”

Figure 5

Figure 5

“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.”

Figure 6

Figure 6

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?”

Figure 7

Figure 7

“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.

Figure 8

Figure 8

“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.

Figure 9

Figure 9

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.

Figure 10

Figure 10

“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.

Figure 11

Figure 11

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.

Figure 12

Figure 12

“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.”

Figure 13

Figure 13

“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.

IBIS, dialogue mapping, and the art of collaborative knowledge creation

with 23 comments


In earlier posts  I’ve described a notation called IBIS (Issue-based information system), and demonstrated its utility in visualising reasoning and resolving complex issues through dialogue mapping.  The IBIS notation consists of just three elements (issues, ideas and arguments) that can be connected in a small number of ways. Yet, despite these limitations, IBIS has been found to enhance creativity when used in collaborative design discussions.  Given the simplicity of the notation and grammar, this claim is surprising,  even paradoxical.  The present post  resolves this paradox by viewing  collaborative knowledge creation as an art, and considers the aesthetic competencies required to facilitate this art.

Knowledge art

In a position paper entitled, The paradox of the “practice level” in collaborative design rationale, Al Selvin draws an analogy between design  discussions using Compendium (an open source IBIS-based argument mapping tool)  and art.  He uses the example of the artist Piet Mondrian, highlighting the difference in  style between Mondrian’s earlier and later work. To quote from the paper,

Whenever I think of surfacing design rationale as an intentional activity — something that people engaged in some effort decide to do (or have to do), I think of Piet Mondrian’s approach to painting in his later years. During this time, he departed from the naturalistic and impressionist (and more derivative, less original) work of his youth (view an image here) and produced the highly abstract geometric paintings (view an image here) most associated with his name…

Selvin points out that the difference between the first and the second paintings is essentially one of abstraction: the first one is almost instantly recognisable as a depiction of dunes on a beach whereas the second one, from Mondrian’s minimalist period, needs some effort to understand and appreciate, as it uses a very small number of elements to create a specific ambience. To quote from the paper again,

“One might think (as many in his day did) that he was betraying beauty, nature, and emotion by going in such an abstract direction. But for Mondrian it was the opposite. Each of his paintings in this vein was a fresh attempt to go as far as he could in the depiction of cosmic tensions and balances. Each mattered to him in a deeply personal way. Each was a unique foray into a depth of expression where nothing was given and everything had to be struggled for to bring into being without collapsing into imbalance and irrelevance. The depictions and the act of depicting were inseparable. We get to look at the seemingly effortless result, but there are storms behind the polished surfaces. Bringing about these perfected abstractions required emotion, expression, struggle, inspiration, failure and recovery — in short, creativity…”

In analogy, Selvin contends that a group of people who work through design issues using a minimalist notation such as IBIS can generate creative new ideas. In other words:  IBIS, when used in a group setting such as dialogue mapping,  can become a vehicle for collaborative creativity. The effectiveness of the tool, though, depends on those who wield it:

“…To my mind using tools and methods with groups is a matter of how effective, artistic, creative, etc. whoever is applying and organizing the approach can be with the situation, constraints, and people. Done effectively, even the force-fitting of rationale surfacing into a “free-flowing” design discussion can unleash creativity and imagination in the people engaged in the effort, getting people to “think different” and look at their situation through a different set of lenses. Done ineffectively, it can impede or smother creativity as so many normal methods, interventions, and attitudes do…”

Although Selvin’s discussion is framed in the context of design discussions using Compendium,  this is but dialogue mapping by another name.  So,  in essence, he  makes a case for viewing the collaborative generation of knowledge (through dialogue mapping or any other means) as an art.  In fact, in another article, Selvin uses the term knowledge art to describe both the process and the product of creating knowledge as discussed above.   Knowledge Art as he sees it, is a marriage of the two forms of discourse that make up the term. On the one hand, we have knowledge which, “… in an organizational setting, can be thought of as what is needed to perform work; the tacit and explicit concepts, relationships, and rules that allow us to know how to do what we do.” On the other, we have art which “… is concerned with heightened expression, metaphor, crafting, emotion, nuance, creativity, meaning, purpose, beauty, rhythm, timbre, tone, immediacy, and connection.”   

Facilitating collaborative knowledge creation

In the business world, there’s never enough time to deliberate or think through ideas (either individually or collectively): everything is done in a hurry and the result is never as good as it should or could be; the picture never quite complete.  However, as Selvin says,

“…each moment (spent discussing or thinking through ideas or designs) can yield a bit of the picture, if there is a way to capture the bits and relate them, piece them together over time. That capturing and piecing is the domain of Knowledge Art. Knowledge Art requires a spectrum of skills, regardless of how it’ practiced or what form it takes. It means listening and paying attention, determining the style and level of intervention, authenticity, engagement, providing conceptual frameworks and structures, improvisation, representational skill and fluidity, and skill in working with electronic information…”

So,  knowledge art requires a wide range of technical and non-technical skills.  In previous posts  I’ve discussed some of  technical skills required – fluency with IBIS, for example.  Let’s now look at  some of the non-technical competencies.

What are the competencies needed for collaborative knowledge creation?  Palus and Horth offer some suggestions in their paper entitled, Leading Complexity; The Art of Making Sense.  They define the concept of  creative leadership as making shared sense out of complexity and chaos and the crafting of meaningful action.  Creative leadership is akin to dialogue mapping, which Jeff Conklin describes as  a means to achieve a shared understanding of wicked problems  and a shared commitment to solving them.  The connection between creative leadership and dialogue mapping is apparent once one notices the similarity between their definitions.  So the  competencies  of creative leadership should apply to dialogue mapping (or collaborative knowledge creation)  as well.

Palus  and Horth describe  six basic competencies of creative leadership. I outline these below, mentioning  their relevance to dialogue mapping:

Paying Attention:  This refers to the ability to slow down discourse  with the aim of  achieving a deep understanding of the issues at hand. A skilled dialogue mapper has to be able to listen; to pay attention to what’s being said.

Personalizing:  This refers to the ability to draw upon personal experiences, interests and passions whilst engaged in work. Although the connection to dialogue mapping isn’t immediately evident, the point Palus and Horth make is that the ability to make connections between work and one’s interests and passions helps increase involvement, enthusiasm and motivation in tackling work challenges.

Imaging:  This refers to the ability to visualise problems so as  to understand them better,  using metaphors, pictures stories etc to stimulate imagination, intuition and understanding. The connection to dialogue mapping is clear and needs no elaboration.

Serious play: This refers to the ability to experiment with new ideas; to learn by trying and doing in a non-threatening environment. This is something that software developers do when learning new technologies. A group engaged in a dialogue mapping must have a sense of play; of trying out new ideas, even if they seem somewhat unusual.

Collaborative enquiry: This refers to the ability to  sustain productive dialogue in a diverse group of stakeholders. Again, the connection to dialogue mapping is evident.

Crafting: This refers to the ability to synthesise issues, ideas, arguments and actions into coherent, meaningful wholes. Yet again, the connection to dialogue mapping is clear – the end product is ideally a shared understanding of the problem and a shared commitment to a meaningful solution.

Palus and Horth suggest that these competencies have been ignored in the business world because:

  1. They are seen as threatening the status quo (creativity is to feared because it invariably leads to changes).
  2. These competencies are aesthetic, and the current emphasis on scientific management devalues competencies that are not rational or analytical.

The irony is that creative scientists have these aesthetic competencies (or qualities) in spades. At the most fundamental level science is an art – it is about constructing theories or designing experiments that make sense of the world. Where do the ideas for these new theories or experiments come from? Well, they certainly aren’t out there in the objective world; they come from the imagination of the scientist. Science, in the real sense of the word, is knowledge art. If these competencies are useful in science, they should be more than good enough for the business world.

Summing up

To sum up:  knowledge creation in an organisational context is best viewed as an art – a collaborative art.  Visual representations such as IBIS provide a medium to capture snippets of knowledge and relate them, or  piece them together over time. They provide the canvas, brush and paint to express knowledge as art  through the process of dialogue mapping.

The what and whence of issue-based information systems

with 22 comments

Over the last few months I’ve written a number of posts on IBIS (short for Issue Based Information System), an argument visualisation technique invented in the early 1970s by Horst Rittel and Werner Kunz.  IBIS is best known for its use in dialogue mapping – a collaborative approach to tackling wicked problems – but it has a range of other applications as well (capturing project knowledge is a good example).    All my prior posts on IBIS focused on its use in specific applications.   Hence the present piece,  in which I discuss the “what” and “whence”  of IBIS:  its practical aspects – notation, grammar etc. –   along with  its origins, advantages and limitations

I’ll begin with a brief introduction to the technique (in its present form) and then move on to its origins and other aspects.

A brief introduction to IBIS

IBIS  consists of three main elements:

  1. Issues (or questions): these are issues that need to be addressed.
  2. Positions (or ideas): these are responses to questions. Typically the set of ideas that respond to an issue represents the spectrum of perspectives on the issue.
  3. Arguments: these can be Pros (arguments supporting) or Cons (arguments against) an issue. The complete  set of arguments that respond to an idea represents the multiplicity of viewpoints on it.

The best IBIS mapping tool is Compendium – it can be downloaded here.  In Compendium, the IBIS elements described above are represented as nodes as shown in Figure 1: issues are represented by green question nodes; positions by yellow light bulbs; pros by green + signs and cons by red – signs.  Compendium supports a few other node types,  but these are not part of the core IBIS notation. Nodes can be linked only in ways specified by the IBIS grammar as I discuss next.

IBIS Elements

Figure 1: IBIS Elements

The IBIS grammar can can be summarized in a few simple rules:

  1. Issues can be raised anew or can arise from other issues, positions or arguments. In other words, any IBIS element can be questioned.  In Compendium notation:  a question node can connect to any other IBIS node.
  2. Ideas can only respond to questions – i.e.  in Compendium “light bulb” nodes  can only link to question nodes. The arrow pointing from the idea to the question depicts the “responds to” relationship.
  3. Arguments  can only be associated with ideas –  i.e in Compendium + and –  nodes can only link to “light bulb” nodes (with arrows pointing to the latter)

The legal links are summarized in Figure 2 below.

Figure 2: Legal Links in IBIS

Figure 2: Legal Links in IBIS

The rules are best illustrated by example-   follow the links below to see some illustrations of IBIS in action:

  1. See this post for a simple example of dialogue mapping.
  2. See this post or this one for examples of argument visualisation .
  3. See this post for the use IBIS  in capturing project knowledge.

Now that we know how IBIS works and have seen a few examples of it in action, it’s time to trace its history from its origins to the present day.

Wicked origins

A good place to start is where it all started. IBIS was first described in a paper entitled, Issues as elements of Information Systems; written by Horst Rittel (who coined the term “wicked problem”) and Werner Kunz in July 1970. They state the intent behind IBIS in the very first line of the abstract of their paper:

Issue-Based Information Systems (IBIS) are meant to support coordination and planning of political decision processes. IBIS guides the identification, structuring, and settling of issues raised by problem-solving groups, and provides information pertinent to the discourse.

Rittel’s preoccupation was the area of public policy and planning – which is also the context in which he defined wicked problems originally.  He defined the term in his landmark paper of 1973 entitled, Dilemmas in  a General Theory of Planning. A footnote to the paper states that it  is based on an article that he   presented at an AAAS meeting in 1969. So it is clear that he had already formulated his ideas on wickedness when he wrote his paper on IBIS in 1970.

Given the above background it is no surprise that Rittel and Kunz foresaw IBIS to be the:

…type of information system meant to support the work of cooperatives like governmental or administrative agencies or committees, planning groups, etc., that are confronted with a problem complex in order to arrive at a plan for decision…

The problems tackled by such  cooperatives are paradigm-defining examples of wicked problems. From the start, then, IBIS was intended as a tool to facilitate a collaborative approach to solving such problems.

Operation of early systems

When Rittel and Kunz wrote their paper, there were three IBIS-type systems in operation: two in governmental agencies (in the US, one presumes) and one in a university environment (possibly, Berkeley, where Rittel worked). Although it seems quaint and old-fashioned now, it is no surprise that they were all manual, paper-based systems- the effort and expense involved in computerizing such systems in the early 70s would have been prohibitive, and the pay-off questionable.

The paper also offers a short description of how these early IBIS systems operated:

An initially unstructured problem area or topic denotes the task named by a “trigger phrase” (“Urban Renewal in Baltimore,” “The War,” “Tax Reform”). About this topic and its subtopics a discourse develops. Issues are brought up and disputed because different positions (Rittel’s word for ideas or responses) are assumed. Arguments are constructed in defense of or against the different positions until the issue is settled by convincing the opponents or decided by a formal decision procedure. Frequently questions of fact are directed to experts or fed into a documentation system. Answers obtained can be questioned and turned into issues. Through this counterplay of questioning and arguing, the participants form and exert their judgments incessantly, developing more structured pictures of the problem and its solutions. It is not possible to separate “understanding the problem” as a phase from “information” or “solution” since every formulation of the problem is also a statement about a potential solution.

Even today, forty years later, this is an excellent description of how IBIS is used to facilitate a common understanding of complex (or wicked) problems. The paper contains an overview of the structure and operation of manual IBIS-type systems. However, I’ll omit these because they are of little relevance in the present-day world.

As an aside, there’s a  term that’s conspicuous by its absence in the Rittel-Kunz paper: design rationale. Rittel must have been aware of the utility of IBIS in capturing design rationale: he was a professor of design science at Berkley and design reasoning was one of his main interests. So it is somewhat odd that  he does not mention this term  even once  in his IBIS  paper.

Fast forward a couple decades (and more!)

In a paper published in 1988 entitled, gIBIS: A hypertext tool for exploratory policy discussion, Conklin and Begeman describe a prototype of a graphical, hypertext-based  IBIS-type system (called gIBIS) and its use in capturing design rationale (yes, despite the title of the paper, it is more about capturing design rationale than policy discussions). The development of  gIBIS represents a key step between the original Rittel-Kunz version of IBIS and its  present-day version as implemented  in Compendium.  Amongst other things, IBIS was finally off paper and on to disk, opening up a new world of possibilities.

gIBIS aimed to offer users:

  1. The ability to capture design rationale – the options discussed (including the ones rejected) and the discussion around the pros and cons of each.
  2. A platform for promoting computer-mediated collaborative design work  – ideally in situations where participants were located at sites remote from each other.
  3. The ability to store a large amount of information and to be able to navigate through it in an intuitive way.

Before moving on, one point needs to be emphasized: gIBIS was intended to be used in collaborative settings; to help groups achieve a shared understanding of central issues, by mapping out dialogues in real time. In present-day terms – one could say that it was intended as a tool for sense making.

The gIBIS prototype proved successful enough to catalyse the development of Questmap, a commercially available software tool that supported IBIS. However, although there were some notable early successes in the real-time use of IBIS in industry environments (see this paper, for example), these were not accompanied by widespread adoption of the technique. Other graphical, IBIS-like methods to capture design rationale were proposed (an example is Questions, Options and Criteria (QOC) proposed by MacLean et. al. in 1991), but these too met with a general reluctance in adoption.

Making sense through IBIS

The reasons for the lack of traction of IBIS-type techniques in industry are discussed in an excellent paper by Shum et. al. entitled, Hypermedia Support for Argumentation-Based Rationale: 15 Years on from gIBIS and QOC.  The reasons they give are:

  1. For acceptance, any system must offer immediate value to the person who is using it. Quoting from the paper, “No designer can be expected to altruistically enter quality design rationale solely for the possible benefit of a possibly unknown person at an unknown point in the future for an unknown task. There must be immediate value.” Such immediate value is not obvious to novice users of IBIS-type systems.
  2. There is some effort involved in gaining fluency in the use of IBIS-based software tools. It is only after this that users can gain an appreciation of the value of such tools in overcoming the limitations of mapping design arguments on paper, whiteboards etc.

The intellectual effort – or cognitive overhead, as it is called in academese – in using IBIS in real time involves:

  1. Teasing out issues, ideas and arguments from the dialogue.
  2. Classifying points raised into issues, ideas and arguments.
  3. Naming (or describing) the point succinctly.
  4. Relating (or linking) the point to an existing node.

This is a fair bit of work, so it is no surprise that beginners might find it hard to use IBIS to map dialogues. However, once learnt, a skilled practitioner can add value to design (and more generally, sense making) discussions in several ways including:

  1. Keeping the map (and discussion) coherent and focused on pertinent issues.
  2. Ensuring that all participants are engaged in contributing to the map (and hence the discussion).
  3. Facilitating useful maps (and dialogues) – usefulness being measured by the extent to which the objectives of the session are achieved.

See this paper by Selvin and Shum for more on these criteria. Incidentally, these criteria are a qualitative measure of how well a group achieves a shared understanding of the problem under discussion.  Clearly, there is a good deal of effort involved in learning and becoming proficient at using IBIS-type systems, but the payoff is an ability to facilitate  a shared understanding of wicked problems – whether in public planning or in technical design.

Why IBIS is better than conventional modes of documentation

IBIS has several advantages over conventional documentation systems. Rittel and Kunz’s 1970  paper contains a nice summary of the advantages, which I paraphrase below:

  1. IBIS can bridge the gap between discussions and records of discussions (minutes, audio/video transcriptions etc,). IBIS sits between the two, acting as a short term memory. The paper thus foreshadows the use of issue-based systems as an aid to organizational or project memory.
  2. Many elements (issue, ideas or arguments) that come up in a discussion have contextual meanings that are different from any pre-existing definitions. In discussions, contextual meaning is more than formal meaning. IBIS  captures the former in a very clear way – for example a response to a question “What do we mean by X? elicits the meaning of X in the context of the discussion, which is then subsequently captured as an idea (position)”.
  3. Related to the above, the commonality of an issue with other, similar issues might be more important than its precise meaning. To quote from the paper, “…the description of the subject matter in terms of librarians or documentalists (sic) may be less significant than the similarity of an issue with issues dealt with previously and the information used in their treatment…”  With search technologies available, this is less of an issue now. However, search technologies are still limited in terms of finding matches between “similar” items (How is “similar” defined? Ans: it depends on context). A properly structured, context-searchable IBIS-based project archive may still be more useful than a conventional document archive based on a document management system.
  4. The reasoning used in discussions is made transparent, as is the supporting (or opposing) evidence. (see my post on visualizing argumentation for example)
  5. The state of the argument (discussion) at any time can be inferred at a glance (unlike the case in written records). See this post for more on the advantages of visual documentation over prose.

Issues with issue-based information systems

Lest I leave readers with the impression that IBIS is a panacea, I should emphasise that it isn’t. According to Conklin, IBIS maps have the following limitations:

  1. They atomize streams of thought into unnaturally small chunks of information thereby breaking up any smooth rhetorical flow that creates larger, more meaningful chunks of narrative.
  2. They disperse rhetorically connected chunks throughout a large structure.
  3. They are not is not chronological in structure (the chronological sequence is normally factored out);
  4. Contributions are not attributed (who said what is normally factored out).
  5. They do not convey the maturity of the map – one cannot distinguish, from the map alone, whether one map is more “sound” than another.
  6. They do not offer a systematic way to decide if two questions are the same, or how the maps of two related questions relate.

Some of these issues (points 3, 4) can be addressed by annotating nodes;  others are not so easy to solve.

Concluding remarks

My aim in this post has been to introduce readers to the IBIS notation, and also discuss its origins, development and limitations.  On one hand, a knowledge of the origins and development  is valuable because it  gives  insight into the rationale behind the technique, which leads to a better understanding of the different ways in which it can be used. On the other, it is also important to know a technique’s limitations,  if for no other reason than to be aware of these so that one can work around them.

Before signing off, I’d like to mention an observation from my experience with IBIS. The real surprise for me has been that the technique can capture most written arguments and discussions,  despite having only three distinct elements and a very simple grammar. Yes, it does require some thought to do this, particularly when mapping discussions in real time. However,  this cognitive “overhead”  is good because  it forces the mapper to think  about what’s being said  instead of just writing it down blind. Thoughtful transcription is the aim of the game. When done right, this results in a map that truly reflects a  shared understanding of the complex  (and possibly wicked) problem under discussion.

There’s no better coda to this post on IBIS than the following quote from  this paper by Conklin:

…Despite concerns over the years that IBIS is too simple and limited on the one hand or too hard to use on the other, there is a growing international community who are fluent enough in IBIS to facilitate and capture highly contentious debates using dialogue mapping, primarily in corporate and educational environments…

For me that’s reason enough to improve my understanding of IBIS and its applications,  and to look for opportunities to use it in ever more challenging situations.

Visualising arguments using issue maps – an example and some general comments

with 16 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.

Figure 1: Issue Map Stage 1

Figure 1: Issue Map Stage 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:

  1. 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:

  1. 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.
  2. IT is highly replicable. This is point needs no further elaboration, I think.
  3. IT is a transport mechanism for digital information. This is true, at least as far as network and messaging infrastructure is concerned.
  4. 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.

Figure 2: Issue Map Stage 2

Figure 2: Issue Map Stage 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.

Figure 3: Issue Map Stage 3

Figure 3: Issue Map Stage 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:

  1. IT is ubiquitous – it is everywhere, at least in the business world.
  2. 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:

  1. Doomed to economic obsolescence. This idea is supported by the argument that these apps are too expensive and are hard to maintain.
  2. 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.

Figure 4: Issue Map Stage 4

Figure 4: Issue Map Stage 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:

  1. Reduce IT spend.
  2. Buy only proven technology – follow don’t lead.
  3. 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).

Figure 5: Final Issue Map

Figure 5: Issue Map Stage 5

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.

%d bloggers like this: