Eight to Late

Introduction 

Conventional approaches to knowledge management on projects focus on  the cognitive (or thought-related) and mechanical  aspects of knowledge creation and capture. There is alternate view, one which considers knowledge as being created through interactions between people who –  through their interactions -  develop mutually acceptable interpretations of theories and facts in ways that suit their particular needs. That is, project knowledge is socially constructed. If this is true, then project managers need to pay attention to the environmental and social factors that influence knowledge construction.  This is the position taken by Paul Jackson and Jane Klobas in their paper entitled, Building knowledge in projects: A practical application of social constructivism to information systems development, which presents a  knowledge creation / sharing process model based social constructivist theory. This article is a summary and review of the paper.

 A social constructivist view of knowledge

Jackson and Klobas begin with the observation that engineering disciplines are founded on the belief that knowledge can be expressed in propositions that correspond to a reality which  is independent of human perception.  However, there is an alternate view that knowledge is not absolute, but relative – i.e.  it depends on the mental models and beliefs used to interpret facts, objects and events. A  relevant example is how a software product is viewed by business users and software developers. The former group may see an application in terms of its utility whereas the latter may see it as an instance of a particular technology. Such perception gaps can also occur within seemingly homogenous groups – such as teams comprised of software developers, for example. This can happen for a variety of reasons such as the differences in the experience and cultural backgrounds of those who make up the group. Social constructivism looks at how such gaps can be bridged.

The authors’ discussion relies on the work of Berger and Luckmann, who described how the gap between perceptions of different individuals can be overcome to create a socially constructed, shared reality. The phrase “socially constructed” implies that reality (as it pertains to a project, for example) is created via a common understanding of issues, followed by mutual agreement between all the players as to what comprises that reality. For me this view strikes a particular chord because of it is akin to the stated aims of dialogue mapping, a technique that I have described in several earlier posts (see this article for an example relevant to projects).

 Knowledge in information systems development as a social construct

 First up, the authors make the point that information systems development (ISD) projects are:

 …intensive exercises in constructing social reality through process and data modeling. These models are informed with the particular world-view of systems designers and their use of particular formal representations. In ISD projects, this operational reality is new and explicitly constructed and becomes understood and accepted through negotiated agreement between participants from the two cultures of business and IT

 Essentially, knowledge emerges  through interaction and discussion   as the project proceeds.  However, the methodologies used in design are typically founded on an engineering approach, which takes a positivist view rather than a social one. As the authors suggest,

Perhaps the social constructivist paradigm offers an insight into continuing failure, namely that what is happening in an ISD project is far more complex than the simple translation of a description of an external reality into instructions for a computer. It is the emergence and articulation of multiple, indeterminate, sometimes unconscious, sometimes ineffable realities and the negotiated achievement of a consensus of a new, agreed reality in an explicit form, such as a business or data model, which is amenable to computerization.

With this in mind, the authors aim to develop a model that addresses the shortcomings of the traditional, positivist view of knowledge in ISD projects. They do this by representing Berger and Luckmann’s theory of social constructivism in terms of a knowledge process model. They then identify management principles that map on to these processes. These principles form the basis of a survey which is used as an operational version of the process model. The operational model is then assessed by experts and tested by a project manager in a real-life project.

The knowledge creation/sharing process model

The process model that Jackson and Klobas describe is based on Berger and Luckmann’s work.

The model  describes how personal knowledge is created – personal knowledge being what an individual knows. Personal knowledge is built up using mental models of the world – these models are frameworks that individuals use to make sense of the world.

According to the Jackson-Klobas process model, personal knowledge is built up through a number of process including:

 Internalisation: The absorption of knowledge by an individual

 Knowledge creation: The construction of new knowledge through repetitive performance of tasks (learning skills) or becoming aware of new ideas, ways of thinking or frameworks. The latter corresponds to learning concepts and theories, or even new ways of perceiving the world. These correspond to a change in subjective reality for the individual.

 Externalisation: The representation and description of knowledge using speech or symbols so that it can be perceived and internalized by others. Think of this as explaining ideas or procedures to other individuals.

 Objectivation: The creation of a shared constructs that represent a group’s understanding of the world. At this point, knowledge is objectified – and is perceived as having an existence independent of individuals.

 Legitimation: The authorization of objectified knowledge as being “correct” or “standard.”

 Reification: The process by which objective knowledge assumes a status that makes it difficult to change or challenge. A familiar example of reified knowledge is any procedure or process that is “hardened” into a system – “That’s just the way things are done around here,” is a common response when such processes are challenged.

  The links depicted in the figure show the relationships between these processes.

 Jackson and Klobas suggest that knowledge creation in ISD projects is a social process, which occurs through continual communication between the business and IT. Sure, there are other elements of knowledge creation – design, prototyping, development, learning new skills etc. – but these amount to nought unless they are discussed, argued, agreed on and communicated through social interactions. These interactions occur in the wider context of the organization, so it is reasonable to claim that the resulting knowledge takes on a form that mirrors the social environment of the organization.

 Clearly, this model of knowledge creation is very different from the usual interpretation of knowledge having an independent reality, regardless of whether it is known to the group or not.

 An operational model

 The above is good theory, which makes for interesting, but academic, discussions. What about practice? Can the model be operationalised?  Jackson and Klobas describe an approach to creating to testing the utility (rather than the validity) of the model.  I discuss this in the following sections.

 Knowledge sharing heuristics

 To begin with, they surveyed the literature on knowledge management to identify knowledge sharing heuristics (i.e. experience-based techniques to enable knowledge sharing).  As an example, some of the heuristics associated with the externalization process were:

• We have standard documentation and modelling tools which make business requirements easy to understand
• Stakeholders and IS staff communicate regularly through direct face-to-face contact
• We use prototypes

 The authors identified more than 130 heuristics. Each of these was matched with a process in the model. According to the authors, this matching process was simple: in most cases there was no doubt as to which process a heuristic should be attached to. This suggests that the model provides a natural way to organize the voluminous and complex body of research in knowledge creation and sharing. Why is this important? Well, because it suggests that the conceptual model (as illustrated in Fig. 1) can form the basis for a simple means to assess knowledge creation / sharing capabilities in their work environments, with the assurance that they have all relevant variables covered.

 Validating the mapping

 The validity of the matching was checked using twenty historical case studies of ISD projects. This worked as follows: explanations for what worked well and what didn’t were mapped against the model process areas (using the heuristics identified in the prior step). The aim was to answer the question:   “is there a relationship between project failure and problems in the respective knowledge processes or, conversely, between project success and the presence of positive indicators?” 

 One of the case studies the authors use is the well-known (and possibly over-analysed) failure of the automated dispatch system for the London Ambulance Service.  The paper has a succinct summary of the case study, which I reproduce below: 

The London Ambulance Service (LAS) is the largest ambulance service in the world and provides accident and emergency and patient transport services to a resident population of nearly seven million people. Their ISD project was intended to produce an automated system for the dispatch of ambulances to emergencies. The existing manual system was poor, cumbersome, inefficient and relatively unreliable. The goal of the new system was to provide an efficient command and control process to overcome these deficiencies. Furthermore, the system was seen by management as an opportunity to resolve perceived issues in poor industrial relations, outmoded work practices and low resource utilization. A tender was let for development of system components including computer aided dispatch, automatic vehicle location, radio interfacing and mobile data terminals to update the status of any call-out. The tender was let to a company inexperienced in large systems delivery. Whilst the project had profound implications for work practices, personnel were hardly involved in the design of the system. Upon implementation, there were many errors in the software and infrastructure, which led to critical operational shortcomings such as the failure of calls to reach ambulances. The system lasted only a week before it was necessary to revert to the manual system.

 Jackson and Klobas show how their conceptual model maps to knowledge-related factors that may have played a role in the failure project. For example, under the heading of personal knowledge, one can identify at least two potential factors: lack of involvement of end-users in design and selection of an inexperienced vendor. Further, the disconnect between management and employees suggests a couple of factors relating to reification: mutual negative perceptions and outmoded (but unchallenged) work practices.

 From their validation, the authors suggest that the model provides a comprehensive framework that explains why these projects failed. That may be overstating the case – what’s cause and what’s effect is hard to tell, especially after the fact. Nonetheless, the model does seem to be able to capture many, if not all, knowledge-related gaps that could have played a role in these failures. Further, by looking at the heuristics mapped to each process, one might be able to suggest ways in which these deficiencies could have been addressed. For example, if externalization is a problem area one might suggest the use of prototypes or encourage face to face communication between IS and business personnel.

 Survey-based tool

 Encouraged by the above, the authors created a survey tool which was intended to evaluate knowledge creation/sharing effectiveness in project environments. In the tool, academic terms used in the model were translated into everyday language (for example, the term externalization was translated to knowledge sharing – see Fig 1 for translated terms). The tool asked project managers to evaluate their project environments against each knowledge creation process (or capability) on a scale of 1 to 10.   Based on inputs, it could recommend specific improvement strategies for capabilities that were scored low. The tool was evaluated by four project managers, who used it in their work environment over a period of 4-6 weeks. At the end of the period, they were interviewed and their responses were analysed using content analysis to match their experiences and requirements against the designed intent of the tool.  Unfortunately, the paper does not provide any details about the tool, so it’s difficult to say much more than paraphrase the authors comments.

 Based on their evaluation, the authors conclude that the tool provides:

1. A common framework for project managers to discuss issues pertaining to knowledge creation and sharing.
2. A means to identify potential problems and what might be done to address them.

 Field testing 

One of the evaluators of the model tested the tool in the field. The tester was a project manager who wanted to identify knowledge creation/sharing deficiencies in his work environment, and ways in which these could be addressed.  He answered questions based on his own evaluation of knowledge sharing capabilities in his environment and then developed an improvement plan based on strategies suggested by the tool along with some of his own ideas.  The completed survey and plan were returned to the researchers.

 Use of the tool revealed the following knowledge creation/sharing deficiencies in the project manager’s environment:

1. Inadequate personal knowledge.
2. Ineffective externalization
3. Inadequate standardization (objectivation)

Strategies suggested by the tool include:

1. An internet portal to promote knowledge capture and sharing. This included discussion forums, areas to capture and discuss best practices etc.
2. Role playing workshops to reveal how processes worked in practice (i.e. surface tacit knowledge).

Based on the above, the authors suggest that:

1. Technology can be used to promote support knowledge sharing and standardization, not just storage.
2. Interventions that make tacit knowledge explicit can be helpful.
3. As a side benefit, they note that the survey has raised consciousness about knowledge creation/sharing within the team.

Reflections and Conclusions

In my opinion, the value of the paper lies not in the model or the survey tool, but the conceptual framework that underpins them – namely, the idea knowledge depends on, and is shaped by, the social environment in which it evolves. Perhaps an example might help clarify what this means. Consider an organisation that decides to implement project management “best practices” as described by <fill in any of the popular methodologies here>. The wrong way to do this would be to implement practices wholesale, without regard to organizational culture, norms and pre-existing practices. Such an approach is unlikely to lead to the imposed practices taking root in the organisation. On the other hand, an approach that picks the practices that are useful and tailors these to organizational needs, constraints and culture is likely to meet with more success. The second approach works because it attempts to bridge gap between the “ideal best practice” and social reality in the organisation. It encourages employees to adapt practices in ways that make sense in the context of the organization. This invariably involves modifying practices, sometimes substantially, creating new (socially constructed!) knowledge in the bargain. 

Another interesting point the authors make is that several knowledge sharing heuristics (130, I think the number was) could be classified unambiguously under one of the processes in the model. This suggests that the model is a reasonable view of the knowledge creation/sharing process. If one accepts this conclusion, then the model does indeed provide a common framework for discussing issues relating knowledge creation in project environments. Further, the associated heuristics can help identify processes that don’t work well.

  I’m unable to judge the usefulness of the survey-based tool developed by the authors because they do not provide much detail about it in the paper. However, that isn’t really an issue;  the field of project management has too many “tools and techniques” anyway.  The key message of the paper, in my opinion, is the that every project has a unique context, and that the techniques used by others have to be interpreted and applied in ways that are meaningful in the context of the particular project. The paper is an excellent counterpoint to the methodology-oriented practice of knowledge management in projects; it should be required reading for methodologists and  project managers who believe that things need to be done by The Book, regardless of social or organizational context.

Introduction

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.

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.

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.

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. 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 recognized these; their 1970  paper contains a nice summary of these, 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 state 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 hand, 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.

Introduction

One consequence of the increasing awareness of knowledge as an organisational asset is that many organisations have launched projects aimed at managing knowledge.  Unfortunately, a large number of these efforts focus entirely on technical solutions, neglecting the need for employee participation. The latter is important; as  stated in this paper, published a decade ago, “Knowledge transfer is about connection not collection, and that connection ultimately depends on choice made by individuals…”  This suggests that participant motivation is a key success factor for knowledge management initiatives. A recent paper entitled, Considering Participant Motivation in Knowledge Management Projects, by Allen Whittom and Marie-Christine Roy looks at theories of motivation from the context of knowledge management projects. This post is a summary and annotated review of the paper.

Many researchers claim that the failure rate of knowledge management projects is high, but there seems to be some confusion as to just how high the figure is (see this paper, for example). In the introduction to their paper, Whittom and Roy claim that the failure rate may be higher than 80% – but they offer no proof. Still, with many independent researchers quoting figures ranging from 50 to 80%, one can take it as established that it is a matter that merits investigation. Accordingly, many researchers have looked at causes of failure of knowledge management projects (see this paper or this one).  Some specifically identify lack of participant motivation as a cause of failure (see this paper or this one). Whittom and Roy claim that despite the work done thus far, knowledge management research does not provide any suggestions as to how motivation is to be managed in such projects. Their aim, therefore, is to:

1. Present concepts from theories of  motivation that are relevant to knowledge management projects.
2. Propose ways in which project managers can foster participant motivation in a way that is consistent with business objectives.

These points are covered in the next two sections. The final section presents some concluding remarks.

 Theoretical Overview                                    

 Motivation and Knowledge Transfer

The authors define motivation as the underlying reason(s) for a person’s actions. Motivation is usually classified as extrinsic or intrinsic depending on whether its source is external or internal to the individual. People who are extrinsically motivated are driven by rewards such as bonuses or promotions. Typically such individuals work for rewards. On the other hand intrinsically motivated individuals are self-driven, and need little supervision. Their enthusiasm, however, depends on whether or not their personal goals are congruent with the task at hand. This is important: their aims and objectives may not always be aligned with business goals. Further, intrinsically motivated individuals perform creative or complex tasks better than others, but this type of motivation varies greatly from one person to another and cannot be controlled by management. See my post on motivation in project management for a comprehensive discussion on extrinsic and intrinsic motivation.

The authors then discuss the link between motivation and the willingness to share knowledge. Knowledge falls into two categories: tacit and explicit. Tacit knowledge is hard to codify and communicate (e.g. a skill, such as riding a bicycle) whereas explicit knowledge can be formalised and transmitted (e.g. how to open a bank account). Tacit knowledge is in “people’s heads” and is consequently harder to capture. More often than not, though, it turns out to be more valuable than explicit knowledge. In their paper entitled, Motivation, Knowledge Transfer and Organisational Forms,  Osterloh and Frey state that, “…Intrinsic motivation is crucial when tacit knowledge in and between teams must be transferred…” Following this work, Gartner researchers Morello and Caldwell proposed a model in which intrinsic motivation drives the creation and sharing of tacit knowledge which in turn drives the dissemination and use of tacit knowledge in the organisation (I couldn’t find a publicly available copy of their work – but there is an illustration of the model in  Figure 1 Whittom and Roy’s paper).  

The message from motivation research is clear: intrinsic motivation is critical to the success of knowledge management projects.

Rewards and Recognition

Rewards and recognition are “levers of motivation”: they can be used to enhance and direct employee motivation towards achieving organisational goals. Reward systems are aimed at aligning individual efforts with organisational objectives. Recognition systems, on the other hand,  are designed to express public appreciation for high standards of achievement or competence. These may be set  according to criteria that diverge from preset objectives (as an example – a public thanks for a job well done can be made irrespective of whether the job is in line with company objectives)

Rewards can be extrinsic (not related to the task) or intrinsic (related to the task) and material or non-material.  Extrinsic rewards are typically material – i.e. they involve giving the recipient something tangible. Financial incentives are the most common form of extrinsic rewards because they are easily administered through the pay system.  Extrinsic rewards can also be non-financial (gift certificates or a meal at a nice restaurant, for example). For the same investment, non-financial rewards are found to have a more lasting effect than financial ones. This makes sense: people are more likely to remember a memorable meal than a few hundred dollar raise; the latter is sometimes forgotten as soon as it comes into effect. A downside of financial rewards is that they are easily forgotten and may actually decrease intrinsic motivation (see this paper by David Beswick). Another is that they may encourage sub-standard work, particularly in cases where benchmarks are based on volume rather than quality of output.

Extrinsic rewards can also be non-material – promotions and training opportunities, for example (see this paper by Wolfgang Semar for more on non-material, extrinsic rewards).

Intrinsic rewards generally pertain to the satisfaction derived from performing a task. The moral satisfaction arising from a job done well is also a form of intrinsic reward. It should be clear that these rewards work only for intrinsically motivated individuals. Intrinsic rewards are invariably non-material and they cannot be controlled by management.  However, awareness of factors influencing intrinsic motivation  can help managers create the right environment for intrinsically motivated individuals.  Kenneth Thomas, in his book entitled, Intrinsic Motivation at Work – Building Energy and Commitment, identifies four psychological factors that can influence intrinsic motivation. They are:

1. Feelings of accomplishment: These can be enhanced by devising interesting work tasks and aligning them with employee interests.
2. Feelings of autonomy: These can be enhanced by empowering employees with responsibility and authority to do their work.
3. Feelings of competence: These can be enhanced by offering employees opportunities to demonstrate and enhance their expertise.
4. Feelings of progress: These can be enhanced by fostering a collaborative atmosphere in which project successes are celebrated.

 These factors are (to an extent) under management control. If nothing else, it is worth being aware of them so that one can avoid doing things that might reduce intrinsic motivation.

Motivation crowding and psychological contracts

 The authors then examine the effects of rewards on intrinsic motivation in the context of knowledge management projects (Recall that intrinsic motivation was seen to be a key success factor in knowledge management projects).  They use motivation crowding theory to frame their discussion. Crowding theory suggests that intrinsic motivation can be enhanced (“crowded-in”) or undermined (or “crowded-out”) by external rewards.

To understand motivation crowding, one has to look at how extrinsic (or external) rewards work. Basically there are two ways in which an extrinsic reward can be perceived. To quote from the paper,

External interventions, such as rewards, may influence this perception either through information or control. If people see a reward as being related to their competence (information), intrinsic motivation for the task will be encouraged or maintained. On the other hand, if they see a reward as a way to control their performance or autonomy, intrinsic motivation would be decreased.

Extrinsic rewards can have a positive or negative effect on information and control. This is best understood through an example: consider a company that announces cash incentives for the top three contributors to a knowledge database. This reward has a positive control aspect (i.e. encourages participation) but a negative information aspect (i.e. no check on quality of contributions). Consequently, the reward encourages high volume of contributions with no regard to quality. This situation typically undermines or “crowds-out” intrinsic motivation. Note that motivation “crowding out” is sometimes referred to as motivation eviction in the literature.

Crowding-out is also seen in recurring tasks. For example, if a monetary incentive is offered for a task, there will be an expectation that the incentive be offered the next time around. On the other hand, non-monetary interventions such as increased employee involvement and autonomy in project decision making can “crowd-in” or enhance intrinsic motivation.

These effects are intuitively quite obvious, but it’s interesting to see them from a social science / economics point of view. If you’d like to find out more, I highly recommend the paper, Motivation crowding theory: A survey of empirical evidence, by Bruno Frey and Reto Jegen.

The take home lesson from the above is that intrinsic motivation can sometimes be negatively affected by external rewards. Manager, beware.

Whittom and Roy also discuss the notion of psychological contracts between the employer and employee. These contracts, distinct from formal employment contracts, refer to the unstated (but implied) informal, mutual obligations pertaining to respect, autonomy, work ethic, fairness etc. An employee’s intrinsic motivation can be greatly reduced if he or she perceives that the contract has been breached. For example, if an employee’s regarding improvements to a knowledge database are ignored, she might feel undervalued. In her eyes, management (and hence the organisation) has lost credibility, and the psychological contract has been violated. In psychological contract theory, personal relationships are seen to be  an important driver of intrinsic motivation: people are more likely to enjoy working in teams in which they have good relations with team members.

Discussion

Practices to foster intrinsic motivation

One conclusion from the aforementioned theories is that intrinsic motivation is essential for the transfer of tacit knowledge. Accordingly, the authors suggest the following practices to maintain and enhance intrinsic motivation of employees involved in knowledge management projects: 

1. Avoid the use of monetary rewards. Instead, use non-monetary rewards that recognize competence. Monetary rewards may also encourage the transfer of unimportant knowledge.
2. Involve employees in the formulation of project objectives.
3. Encourage team work and team bonding. A good team dynamic encourages the sharing of tacit knowledge. The technique of dialogue mapping facilitates the sharing and capture of knowledge in a team environment.
4. Emphasise how the employee might benefit from the project – this is the old WIIFM factor. This needs to be done in a way that shows how the benefit is integrated into the organisation’s culture – i.e. the benefit must be a realistic and believable one, else the employee will see right through it.
5. Good communication between management and employees. This one is a “usual suspect” that comes up in virtually all best practice recommendations. Unfortunately it is seldom done right.

Contextual recommendations based on knowledge and motivation types 

Theories of motivation indicate that, as far as motivation for knowledge sharing is concerned, one size does not fit all. The particular strategy used depends on the nature of the knowledge that is being captured (tacit or explicit), participants’ motivational drivers (intrinsic or extrinsic) and organizational resources. Based on this, the authors discuss the following contexts

1.  Tacit knowledge management / intrinsic motivation: This is an ideal situation. Here the manager’s role is to support participants in achieving project objectives rather than to influence their behaviour through rewards. Extrinsic rewards should be avoided because participants are intrinsically motivated.
2. Tacit knowledge management / extrinsic motivation: From the preceding discussion of motivation theories, it is clear that this is not a good situation. However, all is not lost. A manager can develop knowledge management strategies based on structured training, discussion groups etc. to help codify and transfer tacit knowledge. These strategies should highlight the project benefits (for the employee and the organisation). Further, extrinsic rewards can be offered, but their “crowding-out” effect over time should be kept in mind.
3. Explicit knowledge / intrinsic motivation:  Here the knowledge management aspect is easier because the knowledge is explicit. Typically, once the objectives are identified, it is clear how knowledge should be captured and organized. Obviously, structured training and tools such as Wikis and databases can help facilitate knowledge transfer. Further, these will be more effective than case (2) above, because the participants are intrinsically motivated.. Recommendations, as far as rewards are concerned are the same as in the first case.
4. Explicit knowledge / extrinsic motivation: For knowledge management the same considerations apply as in case (3). However, these strategies will be less effective because employees are extrinsically motivated. For rewards management, the considerations of case (2) apply.

As discussed above, the motivation strategy should be determined by whether the team members are intrinsically or extrinsically motivated. Unfortunately, though, the strategy often dictated by the culture of the organization – the manager may have little say in determining it. The authors do not discuss what a manager might do in such a situation.

Conclusion

 The paper presents no new data or analysis of existing data. As such it must be evaluated on the basis of new concepts and theoretical constructs that it presents. From this perspective  there’s little that’s new in this paper.   That said, project managers leading knowledge management projects might find the paper a worthwhile read because of  its coverage of motivation theories (crowding theory and psychological contracts, in particular). 

Let me end with an extrapolation of the above discussion to software projects. The holy grail of knowledge management initiatives is to capture tacit knowledge. By definition, this knowledge is difficult to codify.  One sees something similar in requirements gathering for application software. The analyst needs to capture all the explicit and tacit process knowledge that’s in users’ heads. The former is easy to capture; the latter isn’t. As a result requirements usually do not capture tacit process knowledge. This is one aspect of what Brooks referred to as the essential problem of software design – figuring out what the software really needs to do (see this post for more on Brooks’ argument). Well designed software embodies both kinds of knowledge, so software projects are knowledge management projects in a sense.  As far as motivation is concerned, therefore,  the theories and conclusions sketched above should apply to software projects.  An intrinsically motivated development team will  improve the chances of success greatly;  a trite statement perhaps, but one that may resonate with those who have had the privilege of working with such teams.

I’ll say it at the outset: once in a while there comes along a book that inspires and excites because it presents new perspectives on old, intractable problems. In my opinion,  Dialogue Mapping : Building a Shared Understanding of Wicked Problems by Jeff Conklin falls into this category. This post presents an extensive summary and review of the book.

Before proceeding, I think  it is only fair that I  state my professional views (biases?) upfront.  Some readers of this blog may have noted my leanings towards the “people side” of project management (see this post , for example). Now, that’s not to say that I don’t use methodologies and processes. On the contrary, I use project management processes in my daily work, and appreciate their value in keeping my projects (and job!) on track. My problem with processes is when they become the only consideration in managing projects. It has been my long-standing belief (supported by experience) that if one takes care of the people side of things, the right outcomes happen more easily; without undue  process obsession on part of the manager.  (I should clarify  that I’m not encouraging some kind of a   laissez-faire, process-free approach, merely one that balances both people and processes). I’ve often wondered if it is possible to meld these two elements into some kind of “people-centred process”,  which leverages the collective abilities of people in a way that facilitates and encourages their participation. Jeff Conklin’s answer is a resounding “Yes!”

Dialogue mapping is a process that is aimed at helping groups achieve a shared understanding of wicked problems – complex problems that are hard to understand, let alone solve. If you’re a project manager that might make your ears perk up; developing a shared understanding of complex issues is important in all stages of a project: at the start, all stakeholders must arrive at a shared understanding of the project goals (eg, what are we trying to achieve in this project?); in the middle,  project team members may need to come to a common understanding (and resolution) of tricky implementation issues; at the end, the team may need to agree on the lessons learned in the course of the project and what could be done better next time. But dialogue mapping is not restricted to project management – it can be used in any scenario involving diverse stakeholders who need to arrive at a common understanding of complex issues. This book provides a comprehensive introduction to the technique.

Although dialogue mapping can be applied to any kind of problem – not just wicked ones – Conklin focuses on the latter. Why? Because wickedness is one of the major causes of fragmentation: the tendency of each stakeholder to see a problem from his or her particular viewpoint ignoring  other, equally valid, perspectives.  The first chapter of this book discusses fragmentation and its relationship to wickedness and complexity.  Fragmentation is a symptom of complexity- one would not have diverse, irreconcilable viewpoints if the issues at hand were simple.  According to Conklin, fragmentation is a function of problem wickedness and social complexity,  i.e.  the diversity of stakeholders.  Technical complexity is also a factor, but a minor one compared to the other two. All too often, project managers fall into the trap of assuming that technical complexity is the root cause of many of their problems, ignoring  problem complexity (wickedness) and social complexity. The  fault isn’t entirely ours; the system is partly to blame:  the traditional, process driven world is partially  blind to the non-technical aspects of complexity.  Dialogue mapping helps surface issues that arise from these oft ignored dimensions of project complexity.

Early in the book,   Conklin walks the reader through the solution process for a hypothetical design problem. His discussion is aimed at highlighting some limitations of the traditional approach to problem solving. The traditional approach is structured; it works methodically through gathering requirements, analysing them, formulating a solution and finally implementing it. In real-life, however,  people tend to dive headlong into solving the problem. Their approach is far from methodical – it typically involves  jumping back and forth between hypothesis formulation, solution development, testing ideas, following hunches etc. Creative work, like design, cannot be boxed in by any methodology, waterfall or otherwise. Hence the collective angst on how to manage innovative product development projects. Another aspect of  complexity arises from  design polarity;  what’s needed (features requested) vs. what’s feasible(features possible)   –  sometimes called the marketing and development views.  Design polarity is often the cause of huge differences of opinion within a team;  that is,  it manifests itself as social complexity.

Having set the stage in the first chapter, the rest of the book focuses on describing the technique of dialogue mapping. Conklin’s contention is that fragmentation manifests itself most clearly in meetings – be they project meetings, design meetings or company board meetings. The solution to fragmentation must, therefore, focus on meetings.  The solution is  for the participants to develop a shared understanding of the issues at hand, and  a shared commitment to  a decision and action plan that addresses them. The second chapter provides an informal discussion of how these are arrived at via  dialogue that takes place in meetings.  Dialogue mapping provides a process – yes, it is a process – to arrive at these.

The second chapter also  introduces some of the elements that make up the process of dialogue mapping. The first of these is a visual notation called IBIS (Issue Based Information System). The IBIS notation was invented by Horst Rittel, the man who coined the term wicked problem. IBIS consists of three elements depicted in Figure 1 below – Issues (or questions), Ideas (that generally respond to questions) and Arguments (for and against ideas – pros and cons) – which can be connected according to a specified grammar (see this post for a quick introduction to IBIS or see Paul Culmsee’s series of posts on best practices for a longer, far more entertaining one). Questions are at the heart of dialogues (or meetings) that take place in organisations – hence IBIS, with its focus on questions, is ideally suited to mapping out meeting dialogues.

The basic idea in dialogue mapping is that a skilled facilitator maps out the core points of the dialogue in real-time, on a shared display which  is  visible to all participants. The basic idea is that participants see their own and collective contributions to the debate, while the facilitator fashions these into a coherent whole. Conklin’s believes that this can be done, no matter how complex the issues are  or how diverse and apparently irreconcilable the opinions. Although I have limited experience with the technique, I believe he is right: IBIS in the hands of a skilled facilitator can help a group focus on the real issues, blowing away the conversational chaff. Although the group as a whole may not reach complete agreement, they will at least develop a real understanding of other perspectives. The third chapter, which concludes the first part of the book,  is devoted to an example that illustrates this point.

The second part of the book delves into the nuts and bolts of dialogue mapping. It begins with an introduction to IBIS – which Conklin calls a “tool for all reasons.” The book provides a nice informal discussion, covering elements, syntax and conventions of the language. The coverage is good, but I have a minor quibble : one has to read and reread the chapter a few times to figure out the grammar of the language. It would have been helpful to have an overview of the grammar collected in one place (say in a diagram, like the one shown in Figure 2). Incidentally, Figures 1 and 2 also show how an IBIS map is structured:  starting from a root question (placed on the left of the diagram) and building up to the right as the discussion proceeds.

A good way to gain experience with IBIS is to use it to create issue maps of arguments presented in articles.  See this post for an example of an issue map based on Fred Brooks’ classic article, No Silver Bullet.

Dialogue mapping is issue mapping plus facilitation. The next chapter – the fifth one in the book – discusses facilitation skills required for dialogue mapping. The facilitator (or technographer, as the person is sometimes called) needs to be able to listen to the conversation, guess at the intended meaning, write (or update) the map and validate what’s written; then proceed through the cycle of listening, guessing, writing and validating  again as the next point comes up and so on. Conklin calls this the dialogue mapping listening cycle (see Figure 3 below).  As one might imagine, this skill, which is the key to successful dialogue mapping, takes lots of practice to develop. In my experience, a good way to start is by creating IBIS maps of issues discussed in meetings involving a small number of participants.  As one gains confidence through practice, one shares the display thereby making the transition from issue mapper to dialogue mapper.

One aspect of the listening cycle is counter-intuitive – validation may require the facilitator to interrupt the speaker.  Conklin emphasises that it is OK to do so as long as it is done in the service of listening. Another important point is that when capturing a point made by someone, the technographer will need to summarise or interpret the point. The interpretation must be checked with the speaker.  Hence validation – and the  interruption it may entail - is not just OK, it is absolutely essential. Conklin also emphasises that the facilitator should focus on a single person in each cycle – it is possible to listen to only one person at a time.

A side benefit of interrruption is that it slows downs the dialogue.  This is a good thing because everyone in the group gets more time to consider what’s on the screen  and how it relates (or doesn’t) to their own thoughts. All too often, meetings are rushed, things are done in  a hurry, and creative creative ideas and thoughts are missed in the bargain. A deliberate slowing down of  the dialogue counters this.

The final part of the book – chapters six through nine – are devoted to advanced dialogue mapping skills.

The sixth chapter presents a discussion of the types of questions that arise in most meetings. Conklin identifies seven types of questions:

Deontic: These are questions that ask what should be done in order to deal with the issue at hand. For example: What should we do to improve our customer service? The majority of root questions (i.e. starting questions) in an IBIS map are deontic.

Instrumental: These are questions that ask how something should be done. For example: How can we improve customer service? These questions generally follow on from deontic questions. Typically root questions are either deontic or instrumental.

Criterial: These questions ask about the criteria that any acceptable ideas must satisfy. Typically ideas that respond to criterial questions will serve as a filter for ideas that might come up. Conklin sees criterial and instrumental questions as being complementary. The former specify high-level constraints (or criteria) for ideas whereas the latter are nuts-and-bolts ideas on how something is to be achieved. For example, a criterial question might ask: what are the requirements for improving customer service or how will we know that we have improved customer service.

Conklin makes the point that criterial questions typically connect directly to the root  question.  This makes sense: the main issue being discussed is usually subject ot criteria or constraints. Further, ideas that respond to criterial questions (in other words, the criteria) have a correspondence with arguments for and against the root questions. This makes sense:  the pros and cons that come up in a meeting would generally correspond to  the criteria that have been stated. This isn’t an absolute requirement – there’s nothing to say that all arguments  must correspong to at least one criterion – but it often serves as a check on whether a discussion is taking all constraints into account.

Conceptual: These are questions that clarify the meaning of any point that’s raised. For example, what do we mean by customer service? Conklin makes the point that many meetings go round in circles because of differences in understanding of particular terms. Conceptual questions surface such differences.

Factual: These are questions of fact. For example: what’s the average turnaround time to respond to customer requests? Often meetings will debate such questions without having any clear idea of what the facts are. Once a factual question is identified as such, it can be actioned for someone to do research on it thereby saving a lot of pointless debate

Background: These are questions of context surrounding the issue at hand. An example is: why are we doing this initiative to improve customer service? Ideas responding to such questions are expected to provide the context as to why something has become an issue.

Stakeholder: These are the “who” questions. An example: who should be involved in the project? Such questions can be delicate in situations where there are conflicting interests (cross-functional project, say), but need to be asked in order to come up with a strategy to handle differences opinion. One can’t address everyone’s concerns until one knows who all constitute “everyone”.

Following the classification of questions, Conklin discusses the concept of a dialogue meta-map – an overall pattern of how certain kinds of questions naturally follow from certain others. The reader may already be able to discern some of these patterns from the above discussion of question types. Also relevant here are artful questions – open questions that keep the dialogue going in productive directions.

The seventh chapter is entitled Three Moves of Discourse. It describes three conversational moves that propel a discussion forward, but can also upset the balance of power in the discussion and evoke strong emotions. These moves are:

1. Making an argument for an idea or proposal (a Pro)
2. Making an argument against an idea (a Con)
3. Challenging the context of the entire discussion.

Let’s look at the first two moves to start with. In an organisation, these moves have a certain stigma attached to them: anyone making arguments for or against an idea might be seen as being opinionated or egotistical. The reason is because these moves generally involve contradicting someone else in the room. Conklin contends that dialogue mapping takes removes these negative connotations because the move is seen as just another node in the map. Once on the map, it is no longer associated with any person – it is objectified as an element of the larger discussion. It can be discussed or questioned just as any other node can.

Conklin refers to the last move – challenging the context of a discussion – as “grenade throwing.” This is an apt  way of describing such questions because they have the potential to derail the discussion entirely. They do this by challenging the relevance of the root question itself.  But dialogue mapping takes these grenades in its stride;  they are simply captured as any another conversational move – i.e. a  node on the map, usually a question.  Better yet, in many cases further discussion shows how these questions might connect up with the rest of the map. Even if they don’t, these “grenade questions” remain on the map, in acknowledgement of the dissenter and his opinion.  Dialogue mapping handles such googlies (curveballs to baseball aficionados) with ease, and indicates how they might connect up with the rest of the discussion – but connection is neither required nor always desirable. It is OK to disagree, as long as it is done respectfully. This is a key element of shared understanding – the participants might not agree, but they understand each other.

Related to the above is the notion of a “left hand move”. Occasionally a discussion can generate a new root question which, by definition, has to be tacked on to the extreme left of the map.  Such a left hand move is extremely powerful because it generally relates two or more questions or ideas that were previously unrelated (some of them may even have been seen as a grenade).

By now it should be clear that dialogue mapping is a technique that promotes collaboration – as such it works best in situations where openness, honesty and transparency are valued. In the penultimate chapter, the author discusses some situations in which it may not be appropriate to use the technique. Among these are meetings in which decisions are made by management fiat. Other situations in which it may be helpful to “turn the display off” are those which are emotionally charged or involve interpersonal conflict. Conklin suggests that the facilitator use his or her judgement in deciding where it is appropriate and where it isn’t.

In the final chapter, Conklin discusses how decisions are reached using dialogue mapping. A decision is simply a broad consensus to mark one of the ideas on the map as a decision. That’s it. How does one choose which idea is to be anointed as the group’s decision. Well quite obviously: the best one. Which one is that? Conklin states, the best decision is the one that has the broadest and deepest commitment to making it work. He also provides a checklist for figuring out whether a map is mature enough for a decision to be made. But the ultimate decision on when a decision (!) is to be made is up to group. So how does one know when the time is right for a decision? Again, the book provides some suggestions here, but I’ll say no more except to hint at them by paraphrasing from the book: “What makes a decision hard is lack of shared understanding. Once a group has thoroughly mapped a problem (issues) and its potential solutions (ideas) along with their pros and cons, the decision itself is natural and obvious.”

Before closing, I should admit that my experience with dialogue mapping is minimal – I’ve done it a few times in small groups. I’m not a brilliant public speaker or facilitator, but I can confirm that it  helps keep a discussion focused and moving forward.  Although Conklin’s  focus is on dialogue mapping,  one does not need to be a facilitator to benefit from this book; it also provides a good introduction to issue mapping using IBIS. In my opinion, this alone  is worth the price of admission.  Further,  IBIS can  also be used to augment project (or organisational) memory.  So this book potentially  has something for you,  even if you’re not a facilitator and don’t intend to use IBIS in group settings.

This brings me to the end of my long-winded summary and review of the book.  My discussion, as long as it is, does not do justice to the brilliance of the book. By summarising the main points of each chapter (with some opinions and annotations for good measure!), I have attempted to convey a sense of what a reader can expect from the book.  I hope I’ve succeeded in doing so. Better yet, I hope I have  convinced you that the book is worth a read, because I truly believe it is.