Archive for the ‘Issue Mapping’ Category
To accept or to decline: mapping life’s little dilemmas using IBIS
Introduction
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:
- It is a one-shot operation.
- It is unique.
- One is liable to face the consequences of whatever choice one makes (one has no right to be wrong)
- Since one can make only one choice, one has no opportunity to test the correctness of ones choice.
- 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:
- Better pay (30% more than current)
- Greater responsibility compared to current job.
- Good learning opportunity (new domain)
- 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:
- He was in his comfort zone – he knew what was expected of him and was able to deliver it with ease.
- The working environment in his company was excellent.
- 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:
- No prospects for career advancement; the job was a dead end.
- 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.
Afterword
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.
Visualising content and context using issue maps – an example based on a discussion of Cox’s risk matrix theorem
Introduction
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:
- Create an issue map visualising the content of my post on Cox’s paper.
- 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:
- Poor resolution: risk matrices use qualitative categories (typically denoted by colour – red, green, yellow). Risks within a category cannot be distiguished.
- 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.
- 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.
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:
- 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.
- 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)
- 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:
- Weak consistency – which states that all risks in the highest category (red) must represent quantitatively higher risks than those in the lowest category (green).
- Consistent colouring – As far as possible, risks with the same quantitative value must have the same colour.
- 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:
- 2×2 matrices cannot satisfy the theorem.
- 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: 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.
Acknowledgements:
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.
The Approach: a dialogue mapping story
Jack could see that the discussion was going nowhere: the group been talking about the pros and cons of competing approaches for over half an hour, but they kept going around in circles. As he mulled over this, Jack got an idea – he’d been playing around with a visual notation called IBIS (Issue-Based Information System) for a while, and was looking for an opportunity to use it to map out a discussion in real time (Editor’s note: readers unfamiliar with IBIS may want to have a look at this post and this one before proceeding). “Why not give it a try,” he thought, “I can’t do any worse than this lot.” Decision made, he waited for a break in the conversation and dived in when he got one…
“I have a suggestion,” he said. “There’s this conversation mapping tool that I’ve been exploring for a while. I believe it might help us reach a common understanding of the approaches we’ve been discussing. It may even help facilitate a decision. Do you mind if I try it?”
“Pfft – I’m all for it if it helps us get to a decision.” said Max. He’d clearly had enough too.
Jack looked around the table. Mary looked puzzled, but nodded her assent. Rick seemed unenthusiastic, but didn’t voice any objections. Andrew – the boss – had a here-he-goes-again look on his face (Jack had a track record of “ideas”) but, to Jack’s surprise, said, “OK. Why not? Go for it.”
“Give me a minute to get set up,” said Jack. He hooked his computer to the data projector. Within a couple of minutes, he had a blank IBIS map displayed on-screen. This done, he glanced up at the others: they were looking at screen with expressions ranging from curiosity (Mary) to skepticism (Max).
“Just a few words about what I’m going to do, he said. “I’ll be using a notation called IBIS – or issue based information system – to capture our discussion. IBIS has three elements: issues, ideas and arguments. I’ll explain these as we go along. OK – Let’s get started with figuring out what we want out of the discussion. What’s our aim?” he asked.
His starting spiel done, Jack glanced at his colleagues: Max seemed a tad more skeptical than before; Rick ever more bored; Andrew and Mary stared at the screen. No one said anything.
Just as he was about to prompt them by asking another question, Mary said, “I’d say it’s to explore options for implementing the new system and find the most suitable one. Phrased as a question: How do we implement system X?”
Jack glanced at the others. They all seemed to agree – or at least, didn’t disagree – with Mary, “Excellent,” he said, “I think that’s a very good summary of what we’re trying to do.” He drew a question node on the map and continued: “Most discussions of this kind are aimed at resolving issues or questions. Our root question is: What are our options for implementing system X, or as Mary put it, How do we implement System X.”
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
“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
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
“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
“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
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
“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
“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
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
“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
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
“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
“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.
Eight to Late 