Two ways of knowing

I usually don’t pick up calls from unknown numbers but that day, for some reason, I did.

“It’s Raj,” he said, “from your decision-making class.”

As we exchanged pleasantries, I wondered what he was calling about.

“I’m sorry to call out of the blue, but I wanted to tell you about something that happened at work. It relates to what you talked about in last week’s class – using sensemaking techniques to help surface and resolve diverse perspectives on wicked problems.”

[Note: wicked problems are problems that are difficult to solve because stakeholders disagree on what the problem is. A good example of contemporary importance is climate change]

Naturally, I asked Raj to tell me more.

It turned out that he worked for a large IT consulting firm where his main role was to design customised solutions for businesses.  The incident he related had occurred at a pre-sales meeting with a potential customer. During the meeting it had become clear that the different stakeholders from the customer side had differing views on what they wanted from the consulting firm. 

On the spur of the moment, Raj decided to jump in and help them find common ground.

To do so, he adapted a technique I had discussed at length in class – and I’ll say more about the technique later. It worked a treat – he helped stakeholders resolve their differences and thereby reframe their problem in a more productive way. Ironically, this led to the customer realising that they did not need the solution Raj’s company was selling. However, a senior manager on the customer’s side was so impressed with Raj’s problem framing and facilitation skills that he was keen to continue the dialogue with Raj’s company.

“We think we know our customers through the data we have about them,” said Raj, “but understanding them is something else altogether.”

–x–

In his book, Ways of Attending, Iain McGilchrist draws attention to the asymmetry in the human brain and its consequences for the ways in which we understand the world. His main claim is that the two hemispheres of the brain perceive reality very differently: the left hemisphere sees objects and events through the lens of theories, models and abstractions whereas the right sees them as embedded in and thus related to a larger world.  As he puts it:

“The left hemisphere tends to see things more in the abstract, the right hemisphere sees them more embedded in the real-world context in which they occur. As a corollary, the right hemisphere seems better able to appreciate actually existing things in all their uniqueness, while the left hemisphere schematises and generalises things into categories.”

McGilchrist emphasises that both hemispheres are involved in reasoning and emotion, but in very different ways. 

“In the left hemisphere, we “experience” our experience in a special way: a “re-presented” version of it, containing now static, separable, bounded, but essentially fragmented entities, grouped into classes on which predictions can be based. This kind of attention isolates, fixes and makes each thing explicit by bringing it under the spotlight of attention. In doing so it renders things inert, mechanical, lifeless. In the other, that of the right hemisphere, we experience the live, complex, embodied world of individual, always unique, beings, forever in flux, a net of interdependencies, forming and reforming wholes, a world with which we are deeply connected.”

It struck me that Raj’s epiphany was deeply connected with McGilchrist’s distinction between the ways in which the two hemispheres of our brains attend to the world.

–x–

The data we collect on our customers (or anything else for that matter) focuses on facts, attributes that are easy to classify or measure.  However, such data has its limitations. As McGilchrist notes in his magnum opus, The Master and His Emissary:

“…there is [a] kind of knowledge that comes from putting things together from bits. It is a knowledge of what we call facts. This is not usually well-applied to knowing people. We could have a go – for example, ‘born on 16 September 1964’, ‘lives in New York’, ‘5ft 4inches tall’, ‘red hair’ …, and so on. Immediately you get a sense of somebody who you don’t actually know….What’s more, it sounds as though you’re describing an inanimate object…”

Facts by themselves do not lead to understanding.

–x–

Understanding something requires one to connect the dots between facts, to build a mental model of what is going on. This is a creative act that requires a blend of imaginative and logical thinking.

Since mental models we build are necessarily influenced our beliefs and past experiences, it is unreasonable to expect any two individuals will understand a given situation in exactly the same way. Understanding is a mental process, not a thing, and knowledge (as in knowing something) is an ever-evolving byproduct of the process. Education is not about conveying knowledge, rather it is about helping students expand and refine their individual processes of understanding.

As Heinz von Foerster put it:

“No wonder that an educational system that confuses the process of creating new processes with the dispensing of goods called ‘knowledge’ may cause some disappointment in the hypothetical receivers, for the goods are just not forthcoming: there are no goods.

Historically, I believe, the confusion by which knowledge is taken as substance comes from a witty broadsheet printed in Nuremberg in the Sixteenth Century. It shows a seated student with a hole on top of his head into which a funnel is inserted. Next to him stands the teacher who pours into this funnel a bucket full of “knowledge,” that is, letters of the alphabet, numbers and simple equations.”

The entire business of education is predicated on the assumption that knowledge is transferable and is assimilated by different individuals in exactly the same way. But this cannot be so. As von Foerster so eloquently noted, “the processes [of assimilating knowledge] cannot be passed on… for your nervous activity is just your nervous activity and, alas, not mine”

Since assimilating knowledge (understanding, by another name) is a highly individual activity, it should not be surprising that individuals perceive and understand situations in very different ways. This is precisely the problem that Raj ran into: two stakeholders on the client’s side had different understandings of the problem.

Raj adapted a sensemaking technique called dialogue mapping to help the two stakeholders arrive at a shared understanding of the problem. The technique itself is not as important as the rationale behind it. And that is best conveyed through another story.

—x–

Many years ago, when I worked as a data architect at a large multinational, I was invited to participate in a regional project aimed at building a data warehouse for subsidiaries across Asia. The initiative was driven by the corporate IT office located in Europe. Corporate’s interest in sponsoring this was to harmonize a data landscape that was – to put it mildly – messy. On the other hand, the subsidiaries thought their local systems were just fine. They were suspicious of corporate motives which they saw as a power play that would result in loss of autonomy over data and reporting.

The two parties had diametrically opposite understandings of the problem.

Around that time, I stumbled on the notion of a wicked problem and was researching ways to manage such problems in work contexts. It was clear that the solution lay in getting the two parties on the same page. The question was how.

The trick is to find a way to surface and reconcile diverse viewpoints in a way that takes the heat out of the discussion.  One therefore needs a means to make multiple perspectives explicit in a manner that separates opinions from individuals and thus enables a group to develop a shared understanding of contentious issues. There is a visual notation called Issue Based Information System or IBIS that can help facilitators do this.  Among other things, IBIS enables one to capture the informal logic of a conversation using a visual notation that has just four node types (see Figure 1).

Figure 1: IBIS node types

In brief: questions (also called issues) capture the problem being discussed; ideas are responses offered to questions; pros and cons are arguments for and against ideas. The claim is that the informal logic of conversations can be captured using just these four node types.

After playing around a bit with the notation, I was convinced it would be of great value in the discussion about the corporate data warehouse.  A day prior to the meeting, I met the project lead to canvass the possibility of using IBIS to map the discussion. After seeing a brief demo, he was quite taken by the idea and was happy to have me use it, providing the other participants had no objections.

The discussion took place over the course of a day, with participants drawn from three groups of stakeholders: corporate IT, local IT and business reps from the subsidiaries.

Mapping the conversation using IBIS enabled the group to:

1. Agree on the root (key) question – what approach should we take?
2. Surface different ideas (options) in response to the question.
3. Capture arguments for and against ideas.

As the conversation progressed, I noticed that IBIS took the heat out of the discussion by objectifying discussion points. It did this by separating opinions from their holders.   This made it possible for participants to understand (if not quite accept) the rationale behind opposing perspectives. This led them to a more nuanced appreciation of the problem and the proposed solutions.

As the morning wore on, the group gradually converged to a shared understanding of the problem.

By the end of the discussion, it was clear to everyone in the meeting that a subsidiary-focused design that enabled a consistent roll up of data for corporate would be the best option. 

Those interested in the details of what I did and how I did it may want to have a look at this paper. However, I should emphasise that the technique is not the point. What happened is that the parties involved changed their minds even though the facts of the matter remained unchanged, and the point is to create the conditions for that to happen.

–x–

The event occurred over a decade ago but has gained significance for me over the years. As we drown in an ever increasing deluge of facts, we are fast losing the capacity to understand. The most pressing problems of today will not be solved by knowing facts, they will be solved by knowing of the other kind.

–x–x–

Improving decision-making in projects

An irony of organisational life is that the most important decisions on projects (or any other initiatives) have to be made at the start, when ambiguity is at its highest and information availability lowest. I recently gave a talk at the Pune office of BMC Software on improving decision-making in such situations.

The talk was recorded and simulcast to a couple of locations in India. The folks at BMC very kindly sent me a copy of the recording with permission to publish it on Eight to Late. Here it is:

Based on the questions asked and the feedback received, I reckon that a number of people found the talk  useful. I’d welcome your comments/feedback.

Acknowledgements: My thanks go out to Gaurav Pal, Manish Gadgil and Mrinalini Wankhede for giving me the opportunity to speak at BMC, and to Shubhangi Apte for putting me in touch with them. Finally, I’d like to thank the wonderful audience at BMC for their insightful questions and comments.

The Risk – a dialogue mapping vignette

Foreword

Last week, my friend Paul Culmsee conducted an internal workshop in my organisation on the theme of collaborative problem solving. Dialogue mapping is one of the tools he introduced during the workshop.  This piece, primarily intended as a follow-up for attendees,  is an introduction to dialogue mapping via a vignette that illustrates its practice (see this post for another one). I’m publishing it here as I thought it might be useful for those who wish to understand what the technique is about.

Dialogue mapping uses a notation called Issue Based Information System (IBIS), which I have discussed at length in this post. For completeness, I’ll begin with a short introduction to the notation and then move on to the vignette.

—

A crash course in IBIS

The IBIS notation consists of the following three elements:

1. Issues(or questions): these are issues that are being debated. Typically, issues are framed as questions on the lines of “What should we do about X?” where X is the issue that is of interest to a group. For example, in the case of a group of executives, X might be rapidly changing market condition whereas in the case of a group of IT people, X could be an ageing system that is hard to replace.
2. Ideas(or positions): these are responses to questions. For example, one of the ideas of offered by the IT group above might be to replace the said system with a newer one. Typically the whole set of ideas that respond to an issue in a discussion represents the spectrum of participant perspectives on the issue.
3. Arguments: these can be Pros (arguments for) or Cons (arguments against) an issue. The complete set of arguments that respond to an idea represents the multiplicity of viewpoints on it.

Compendium is a freeware tool that can be used to create IBIS maps– it can be downloaded here.

In Compendium, IBIS elements are represented as nodes as shown in Figure 1: issues are represented by blue-green question marks; 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.

Figure 1: IBIS node types

The IBIS grammar can be summarized in three 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

…and that’s pretty much all there is to it.

The interesting (and powerful) aspect of IBIS is that the essence of any debate or discussion can be captured using these three elements. Let me try to convince you of this claim via a vignette from a discussion on risk.

—

 The Risk – a Dialogue Mapping vignette

“Morning all,” said Rick, “I know you’re all busy people so I’d like to thank you for taking the time to attend this risk identification session for Project X.  The objective is to list the risks that we might encounter on the project and see if we can identify possible mitigation strategies.”

He then asked if there were any questions. The head waggles around the room indicated there were none.

“Good. So here’s what we’ll do,”  he continued. “I’d like you all to work in pairs and spend 10 minutes thinking of all possible risks and then another 5 minutes prioritising.  Work with the person on your left. You can use the flipcharts in the breakout area at the back if you wish to.”

Twenty minutes later, most people were done and back in their seats.

“OK, it looks as though most people are done…Ah, Joe, Mike have you guys finished?” The two were still working on their flip-chart at the back.

“Yeah, be there in a sec,” replied Mike, as he tore off the flip-chart page.

“Alright,” continued Rick, after everyone had settled in. “What I’m going to do now is ask you all to list your top three risks. I’d also like you tell me why they are significant and your mitigation strategies for them.” He paused for a second and asked, “Everyone OK with that?”

Everyone nodded, except Helen who asked, “isn’t it important that we document the discussion?”

“I’m glad you brought that up. I’ll make notes as we go along, and I’ll do it in a way that everyone can see what I’m writing. I’d like you all to correct me if you feel I haven’t understood what you’re saying. It is important that  my notes capture your issues, ideas and arguments accurately.”

Rick turned on the data projector, fired up Compendium and started a new map.  “Our aim today is to identify the most significant risks on the project – this is our root question”  he said, as he created a question node. “OK, so who would like to start?”

Figure 3: The root question

“Sure,” we’ll start, said Joe easily. “Our top risk is that the schedule is too tight. We’ll hit the deadline only if everything goes well, and everyone knows that they never do.”

“OK,” said Rick, “as he entered Joe and Mike’s risk as an idea connecting to the root question. “You’ve also mentioned a point that supports your contention that this is a significant risk – there is absolutely no buffer.” Rick typed this in as a pro connecting to the risk. He then looked up at Joe and asked,  “have I understood you correctly?”

“Yes,” confirmed Joe.

Figure 4: Map in progress

“That’s pretty cool,” said Helen from the other end of the table, “I like the notation, it makes reasoning explicit. Oh, and I have another point in support of Joe and Mike’s risk – the deadline was imposed by management before the project was planned.”

Rick began to enter the point…

“Oooh, I’m not sure we should put that down,” interjected Rob from compliance. “I mean, there’s not much we can do about that can we?”

…Rick finished the point as Rob was speaking.

Figure 5: Two pros for the idea

“I hear you Rob, but I think  it is important we capture everything that is said,” said Helen.

“I disagree,” said Rob. “It will only annoy management.”

“Slow down guys,” said Rick, “I’m going to capture Rob’s objection as “this is a management imposed-constraint rather than risk. Are you OK with that, Rob?”

Rob nodded his assent.

Fig 6: A con enters the picture

I think it is important we articulate what we really think, even if we can’t do anything about it,” continued Rick. There’s no point going through this exercise if we don’t say what we really think. I want to stress this point, so I’m going to add honesty  and openness  as ground rules for the discussion. Since ground rules apply to the entire discussion, they connect directly to the primary issue being discussed.”

Figure 7: A “criterion” that applies to the analysis of all risks

“OK, so any other points that anyone would like to add to the ones made so far?” Queried Rick as he finished typing.

He looked up. Most of the people seated round the table shook their heads indicating that there weren’t.

“We haven’t spoken about mitigation strategies. Any ideas?” Asked Rick, as he created a question node marked “Mitigation?” connecting to the risk.

Figure 8: Mitigating the risk

“Yeah well, we came up with one,” said Mike. “we think the only way to reduce the time pressure is to cut scope.”

“OK,” said Rick, entering the point as an idea connecting to the “Mitigation?” question. “Did you think about how you are going to do this? He entered the question “How?” connecting to Mike’s point.

Figure 9: Mitigating the risk

“That’s the problem,” said Joe, “I don’t know how we can convince management to cut scope.”

“Hmmm…I have an idea,” said Helen slowly…

“We’re all ears,” said Rick.

“…Well…you see a large chunk of time has been allocated for building real-time interfaces to assorted systems – HR, ERP etc. I don’t think these need to be real-time – they could be done monthly…and if that’s the case, we could schedule a simple job or even do them manually for the first few months. We can push those interfaces to phase 2 of the project, well into next year.”

There was a silence in the room as everyone pondered this point.

“You know, I think that might actually work, and would give us an extra month…may be even six weeks for the more important upstream stuff,” said Mike. “Great idea, Helen!”

“Can I summarise this point as – identify interfaces that can be delayed to phase 2?” asked Rick, as he began to type it in as a mitigation strategy. “…and if you and Mike are OK with it, I’m going to combine it with the ‘Cut Scope’ idea to save space.”

“Yep, that’s fine,” said Helen. Mike nodded OK.

Rick deleted the “How?” node connecting to the “Cut scope” idea, and edited the latter to capture Helen’s point.

Figure 10: Mitigating the risk

“That’s great in theory, but who is going to talk to the affected departments? They will not be happy.” asserted Rob.  One could always count on compliance to throw in a reality check.

“Good point,”  said Rick as he typed that in as a con, “and I’ll take the responsibility of speaking to the department heads about this,” he continued entering the idea into the map and marking it as an action point for himself. “Is there anything else that Joe, Mike…or anyone else would like to add here,” he added, as he finished.

Figure 11: Completed discussion of first risk (click to view larger image)

“Nope,” said Mike, “I’m good with that.”

“Yeah me too,” said Helen.

“I don’t have anything else to say about this point,” said Rob, “ but it would be great if you could give us a tutorial on this technique. I think it could be useful to summarise the rationale behind our compliance regulations. Folks have been complaining that they don’t understand the reasoning behind some of our rules and regulations. ”

“I’d be interested in that too,” said Helen, “I could use it to clarify user requirements.”

“I’d be happy to do a session on the IBIS notation and dialogue mapping next week. I’ll check your availability and send an invite out… but for now, let’s focus on the task at hand.”

The discussion continued…but the fly on the wall was no longer there to record it.

—

Afterword

I hope this little vignette illustrates how IBIS and dialogue mapping can aid collaborative decision-making / problem solving by making diverse viewpoints explicit. That said, this is a story, and the problem with stories is that things  go the way the author wants them to.  In real life, conversations can go off on unexpected tangents, making them really hard to map. So, although it is important to gain expertise in using the software, it is far more important to practice mapping live conversations. The latter is an art that requires considerable practice. I recommend reading Paul Culmsee’s series on the practice of dialogue mapping or <advertisement> Chapter 14 of The Heretic’s Guide to Best Practices</advertisement> for more on this point.

That said, there are many other ways in which IBIS can be used, that do not require as much skill. Some of these include: mapping the central points in written arguments (what’s sometimes called issue mapping) and even decisions on personal matters.

To sum up: IBIS is a powerful means to clarify options and lay them out in an easy-to-follow visual format. Often this is all that is required to catalyse a group decision.