Archive for the ‘Issue Mapping’ Category
Capturing decision rationale on projects
Introduction
Most knowledge management efforts on projects focus on capturing what or how rather than why. That is, they focus on documenting approaches and procedures rather than the reasons behind them. This often leads to a situation where folks working on subsequent projects (or even the same project!) are left wondering why a particular technique or approach was favoured over others. How often have you as a project manager asked yourself questions like the following when browsing through a project archive?
- Why did project decision-makers choose to co-develop the system rather than build it in-house or outsource it?
- Why did the developer responsible for a module use this approach rather than that one?
More often than not, project archives are silent on such matters because the reasoning behind decisions isn’t documented. In this post I discuss how the Issue Based Information System (IBIS) notation can be used to fill this “rationale gap” by capturing the reasoning behind project decisions.
Note: Those unfamiliar with IBIS may want to have a browse of my post on entitled what and whence of issue-based information systems for a quick introduction to the notation and its uses. I also recommend downloading and installing Compendium, a free software tool that can be used to create IBIS maps.
Example 1: Build or outsource?
In a post entitled The Approach: A dialogue mapping story, I presented a fictitious account of how a project team member constructed an IBIS map of a project discussion (Note: dialogue mapping refers to the art of mapping conversations as they occur). The issue under discussion was the approach that should be used to build a system.
The options discussed by the team were:
- Build the system in-house.
- Outsource system development.
- Co-develop using a mix of external and internal staff.
Additionally, the selected approach had to satisfy the following criteria:
- Must be within a specified budget.
- Must implement all features that have been marked as top priority.
- Must be completed within a specified time
The post details how the discussion was mapped in real-time. Here I’ll simply show the final map of the discussion (see Figure 1).
Figure 1: IBIS map for Example 1
Although the option chosen by the group is not marked (they chose to co-develop), the figure describes the pros and cons of each approach (and elaborations of these) in a clear and easy-to-understand manner. In other words, it maps the rationale behind the decision – a person looking at the map can get a sense for why the team chose to co-develop rather than use any of the other approaches.
Example 2: Real-time updates of a data mart
In another post on dialogue mapping I described how IBIS was used to map a technical discussion about the best way to update selected tables in a data mart during business hours. For readers who are unfamiliar with the term: data marts are databases that are (generally) used purely for reporting and analysis. They are typically updated via batch processes that are run outside of normal business hours. The requirement to do real-time updates arose from a business need to see up-to-the-minute reports at specified times during the financial year.
Again, I’ll refer the reader to the post for details, and simply present the final map (see Figure 2).
Figure 2: IBIS Map for Example 2.
Since there are a few technical terms involved, here’s a brief rundown of the options, lifted straight from my earlier post (Note: feel free skip this detail – it is incidental to the main point of this post) :
- Use our messaging infrastructure to carry out the update.
- Write database triggers on transaction tables. These triggers would update the data mart tables directly or indirectly.
- Write custom T-SQL procedures (or an SSIS package) to carry out the update (the database is SQL Server 2005).
- Run the relevant (already existing) Extract, Transform, Load (ETL) procedures at more frequent intervals – possibly several times during the day.
In this map the option chosen by the group decision is marked out – it was decided that no additional development was needed; the “real-time” requirement could be satisfied simply by running existing update procedures during business hours (option 4 listed above).
Once again, the reasoning behind the decision is easy to see: the option chosen offered the simplest and quickest way to satisfy the business requirement, even though the update was not really done in real-time.
Summarising
The above examples illustrate how IBIS captures the reasoning behind project decisions. It does so by:
- Making explicit all the options considered.
- Describing the pros and cons of each option (and elaborations thereof).
- Providing a means to explicitly tag an option as a decision.
- Optionally, providing a means to link out to external source (documents, spreadsheets, urls). In the second example I could have added clickable references to documents elaborating on technical detail using the external link capability of Compendium.
Issue maps (as IBIS maps are sometimes called) lay out the reasoning behind decisions in a visual, easy-to-understand way. The visual aspect is important – see this post for more on why visual representations of reasoning are more effective than prose.
I’ve used IBIS to map discussions ranging from project approaches to mathematical model building, and have found them to be invaluable when asked questions about why things were done in a certain way. Just last week, I was able to answer a question about variables used in a market segmentation model that I built almost two years ago – simply by referring back to the issue map of the discussion and the notes I had made in it.
In summary: IBIS provides a means to capture decision rationale in a visual and easy-to-understand way, something that is hard to do using other means.
What should I do now? A bedtime story about dialogue mapping
It was about half past eight in the evening a couple of weeks ago; I was sitting at my computer at home, writing up some notes for a blog post on issue mapping.
“What are you drawing?” asked my eight year old, Rohan. I hadn’t noticed him. He had snuck up behind me quietly, and was watching me draw an IBIS map. (Note: see my post entitled, the what and whence of issue-based information systems for a quick introduction to IBIS)
“Go to bed,” I said, still looking at the screen. It was past his bedtime.
“…but what are you drawing. What are those questions and arrows and stuff?”
A few minutes won’t hurt, I thought. I turned to him and explained the basics of the notation and how it worked.
“But what good is it,” he asked.
“Good question,” I said. “It has many uses, but one of the most important ones is that it can help people make good decisions.”
“Decisions about what?”
“Anything, I said, “for example: you may want to decide what you should do right now. Well, IBIS can help you make that decision.”
“How?”
“I’ll have to show you,” I said, “and I can’t because you have to go to bed now.” What a cop out, I thought to myself, as I said those words.
“Come on, dad – just a few minutes. I really want to know how it can help me make a decision about what I should do now.”
“You should go to bed.”
“How do I know that’s a good decision? Let’s see what IBIS says,” said the boy.
Brilliant! It was checkmate. I relented.
———
“OK, “ I said, opening a new map in Compendium and drawing a question node. “Every IBIS map begins with a question – we call it the root question. Our root question is: What should I do now?”
I typed in the root question and asked him: “So, tell me: what are the different things you could do now.”
He thought for a bit and said, “I could go to sleep but that’s boring.”
“Good. There are actually two things you’ve said there – an idea (go to sleep) and an argument against it (its boring). Let’s put that down in the map. In an IBIS map, an idea is shown as a light-bulb (as in a comic) and an argument against it by a minus sign.”
The map with the root question along with Rohan’s first response and argument is shown in Figure 1.
Figure 1
He looked at the map and said, “There’s another minus I can think of – it is hard to sleep so early.”
I put that point in and said, “I’m sure you could also think of some plus points for sleeping early.”
“Yes,” he said, “I can get up early and do stuff.”
“What stuff?”
“I can play Wii before I go to school.”
“OK let’s put all that into the map,” I said. “See, an argument supporting an idea is shown as a plus sign. Then, I asked you to explain a bit more about why getting up early is a good thing. Your answer goes into the map as another idea. Notice, also, that the map develops from right to left, starting from the root question.”
The map at this point of the discussion is shown in Figure 2.
Figure 2
“What else can you do now?”
“I can talk to you,” said Rohan.
“And what are the plus points of that?” I asked.
“It is interesting to talk to you.” Ah, the boy has the makings of a diplomat…
“The minus points?”
“You are tired and crabby”
OK, may be he isn’t a diplomat…
The map at this point is shown in Figure 3.
Figure 3
“What else can you do,” I asked, as I cleaned up the map a bit.
“I could spend some time with Vikram.” (Vikram is Rohan’s 4 month old brother).
“What are the plus points of doing that?”
“He does funny things and he’s cute.”
“That’s two points, ” I said, adding them to the map. Then I asked, “What kinds of funny things?”
“He gurgles, smiles and blows spit bubbles.”
“Great,” I said, adding those points as elaborations of “does funny things”.
Rohan said, “I forgot. Vik is asleep so I can’t play with him.”
“OK, so that’s a minus point that rules out the choice,” I said, adding it as an argument against the idea. The map at this point is shown in Figure 4.
Figure 4
“Can you think of anything else you can do?” I asked.
He thought for a while and replied, “I could read.”
“OK,” I said. “What are the plus and minus points of that.”
“It’s interesting,” he said, and then in the same breath added, “but I have nothing to new to read.”
I put these points in as arguments for and against reading. The map at this point is shown in Figure 5.
Figure 5
After finishing I asked, “Anything else you want to add.”
“I could just stay up and watch a movie,” he said.
I stopped myself from vetoing that outright. Instead, I put the point in and asked,” Why do you want to stay up and watch a movie?”
“It’s fun,” he said.
“May be so, but a movie would take too long and you have school tomorrow.”
“School’s boring.”
“I’ll note your point,” I said, “but I’m afraid I have to veto that option.”
“I was just trying it out, dad.”
“I know,” I said, as I updated the map (see Figure 6).
Figure 6
“Can you think of anything else you could do?”
“No.”
“OK, let’s look at where we are. Have a look at the map and tell me what you think.”
Rohan looked at the map for a bit and said, “It shows me all my choices and gives me reasons to choose or not to choose them.”
“Does that help you decide what you should do now?”
“Sort of,” he said, “I know I can’t spend time with Vik because he’s asleep. I can’t talk to you because you’re tired and might get crabby. I can’t stay up and watch a movie because you won’t let me.”
“So what can you do?”
“I can read or go to sleep”
“But you have nothing new to read.,” I pointed out.
“Yes, but I think I could find something that I would like to read again…Yes, I know what I will do – I’ll read for a while and then go to sleep.”
“Sounds like a good idea – that way you get to do two of the things on the list.” I said.
“This IBIS stuff is cool. I think I’ll talk about it at my news this Thursday. It is free choice.” (News is a 2-3 minute presentation that all kids in class get to do once a week. Most often the topic is assigned beforehand, but there’s one free-choice session per term where the kids can talk about anything they want to)
“Great idea,” I said, “I’ll help you make some notes and map images tomorrow. Now you’d really better go off to bed before your mum comes in and gets upset at us both.”
”Good night, dad”
“’night, Rohan”
Unforeseen consequences – an unexpected sequel to my previous post
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:
- 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.
- 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.
Epilogue
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.
Eight to Late 