Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Communication’ Category

The user who wasn’t there: on the role of the imagined user in design discourse

with one comment

Introduction

Users should be the centre of focus on projects as they are the ultimate beneficiaries (or sufferers) of the end-product. Given this, there should be frequent dialogue between the designers/creators of a product and those who will use it. Most project managers would accept the foregoing as an uncontroversial, even obvious, statement of the way things should be done. However, there is a potentially a gap between this and reality. In a fascinating case-study-based paper entitled, The imagined user in projects: Articulating competing discourses of space and knowledge work, Chris Ivory and Neil Alderman look at how, in project work, knowledge about users is often constructed without direct user input – i.e. is inferred, or even attributed without justification. This post is an annotated summary of their paper.

The paper is based on a case-study of a project that was aimed at redesigning office space for employees in a higher education environment. The contentious choice here – as one might imagine – is the one between an open-plan and cellular (individual office-based) design. In the paper Ivory and Alderman discuss how the notion of the imagined user is used (by designers, or even by management) to justify particular design choices.  To quote:

The paper builds a case for the role of the imagined user as a rhetorical device in the expression and enactment of discourses within projects. Our position stems from observations that, despite the rise and rise of user-centered and participative design, the user is most notable for his or her physical absence from the design process and that interaction with users is not one of simple knowledge-transfer, but one in which knowledge about users is constructed both with and without input from users. The creation and referencing of ‘imagined users’ is part of a persuasive process – imagined users are simplified caricatures that conveniently fit (or do not fit) the sorts of design solutions (in this case particular configurations of space) under discussion. This suggests the need to go beyond knowledge-transfer accounts of the role of the user in the design and project process and to acknowledge the social construction of imagined users in project interactions.

Users and the problem of knowledge transfer

Project management theory and practice emphasise the importance of users in projects. Users typically have a dual role: firstly, they provide input into design (through requirements) and improve the quality of design decisions; second, they test the product and validate that the project objectives have been met. It is the former process that Ivory and Alderman focus on:

Interest in user input as a corrective to poor design has led to a research focus on how best to expedite the interaction between users and designers; what might be termed a ‘knowledge transfer’ focus. This emphasises finding better ways of getting to know users’ contexts and encouraging users to maximise their understanding of what is technically and financially possible. Mechanisms identified for doing this include: user groups, usability trials, user surveys, direct user observation and, latterly, various web-based forums.

The authors contend that there are two problems with this “knowledge transfer based” approach:

  1. Those involved in seeking user input may view certain suggestions as being unnecessary or even undesirable. This could happen for a variety of reasons ranging from expediency to politics.
  2. The difficulty of capturing what the user really means is often underestimated.  In particular,  the difficulty of translating experience to words and the possibility of misinterpretation implies that it is difficult, if not impossible, to capture user requirements in a complete and objective manner. This is particularly true of implicit knowledge, and hence the vast literature on the problem of knowledge capture.

As a consequence, it is often easier for designers to make decisions based on their own knowledge and their perceptions of user needs. Ergo, the imagined user…

Imagined users

To understand the concept of the imagined user, let’s begin by looking at what the authors’ have to say:

The imagined user is a discursive construct, depending for its existence on the dialogue of those involved in the design process. Imagined users are conjured up in the form of vignettes and anecdotes based on personal and second-hand experience, assumptions and more or less reliable research data. The key role of the imagined user in design dialogue is to give substance and rhetorical force to competing discourses relevant to the design issues in question. Creating and drawing on imagined users effectively translates broader discourses into persuasive context-specific accounts of users and use. The design process is not just an exercise in trying to ‘get it right’; it is a forum for the expression of potentially conflicting cultural, economic, political, ideological and professional preferences.

The word ‘discursive’ refers to the idea that the imagined user emerges as a consequence of the dialogue between designers and users and designers and others. Through the course of the design discussions, a certain view of what was said  (or intended to be said) by users  is built-up by designers and managers,  regardless of whether or not it was actually said or intended. This view is the imagined user.

In introducing the idea of the imagined user, the authors highlight the role of discourse (dialogue, discussion and conversation) in shaping the direction that a project takes. In this connection it is important to note that discourse is often used as a means to exercise power – which could be hard power (as by management decree) or soft power  (as by convincing or persuading others through logic and/or rhetoric).

The role of politics

Project management research generally tends to disregard the activities and work  that occurs before “a project becomes a project.”  In contrast, Ivory and Alderman focus on :

“…interactions that occurred in the early planning and design phases of the project studied; the period when there was a commitment within the organisation to begin a capital project, but no firm or detailed decisions as to the precise form the project should take.”

Their point is that decisions made in these early stages can have a crucial effect on determining the subsequent course of the project. Many of these decisions are driven by politics rather than “real user” requirements. So one could even say that:

…the outcomes of projects reflect political processes and power struggles between stakeholders as much as the physical design decisions and actions of project manager.

This, I think, is a very insightful observation that may chime with the experience of project managers who have worked in politically charged environments.

The case study

The case study is based on interviews with senior management in a university department that was engaged in renovating office space for its staff. The contentious aspect of the design was the choice between an open-plan and cellular model. The initial idea was to go with an open-plan – justified on the basis of open communication being important in an academic environment – but this was later modified in the course of discussions with users. In the interviews, the authors elicited information on why the open-plan model was chosen first and then subsequently modified.

The authors analysed the interviews by grouping the points made for and against a particular design choice, and then linking these to the broader social and organisational context.

The history of the project is a bit involved so, to ensure that I get it right, I’ll quote directly from the paper:

The history of the project was long and convoluted, but centred around the perceived need to bring a split site department onto a single site, whilst improving the facilities for the teaching of its students. At an early stage, a key objective imposed by senior management of the University was for a substantial amount of open plan space to form the core of the design. Negative reaction and lobbying by user groups within the department led to an agreement for a limited number of cellular offices to be included, but nowhere near enough to guarantee each academic their own office.

The initial project proposal failed on planning grounds and the project was reconstituted through a proposal to lease commercial office space, with some re-configuration to suit educational use. This was attractive to senior management in that it enabled the project to be funded primarily out of fee revenue rather than appearing on the balance sheet as a capital expenditure.

The project sponsor drove the choice of a commercial lease and insisted on increasing the use of open plan space. He was supported by other members of the senior management team and the Estates department, which viewed the high cost of existing space as a major problem for the University. These actors had positive views of previous projects to create open plan working spaces, both for administrative functions and for research units. The case study project was the first to propose the same solution for a conventional teaching department.

The solution being pursued by the project sponsor was not universally supported amongst senior management and neither was their insistence on an open plan design. When they left the institution, just prior to the signing of contracts, the new project sponsor successfully sought additional funding to allow for an increase in the provision of cellular offices. The to-ing and fro-ing of the project process and the shifts in power within the project form the backdrop to our investigation of the discourses about academics as space users and knowledge workers.

With the description of the case study done, I now move on to the authors’ analysis of the competing positions based on their interviews.

Analysis of arguments

The arguments for open-plan

The arguments for an open-plan design can be summarised as follows:

  1. The rational economic choice: This argument was based on minimising cost and optimising space usage.  The interesting thing about this argument is that it is framed solely in terms of an organisational view –  user input, being considered irrelevant, is simply not solicited . As the authors put it:  “This discourse frames the issue of space solely in organisational terms. In effect the organisation assumes a priority over, and becomes a proxy for, all users. Consequently, any need for further discussion about the user is negated – the user effectively disappears (is unimagined)..”
  2. The inevitability of progress argument: This argument hinges on the premise that change is inevitable.  Managers who advocated this position drew upon other examples where open-plan offices were implemented, and were (presumably) successful.  Such arguments deem any concerns regarding the change as irrelevant, even pointless (after all, progress is good; change is inevitable).  In this case too, users are dealt with indirectly, by appealing to users in other environment who have, presumably, accepted the inevitability of progress.
  3. Constructing a fit between users and space: This argument focuses on presenting actual examples of situations where having an open plan was a benefit. For example, one user articulated his experience thus: “You could talk to people and my PA was sitting next to me more or less. And for the first time I could see there was an incredibly efficient way of getting things done. You can see people, you can walk over, you can get access to people, you get a lot more  communication…” Typically, though, most of these descriptions referred to administrative rather than academic work. The authors suggest that such “blurring of categories of work”  is sometimes used by designers to ignore input by real users – creating imagined users in the bargain.  Another project sponsor mentioned how an open plan would break academic silos and encourage people to talk to each other. Again, we see a recourse to an imagined user  who conforms to the stereotypical, uncommunicative academic.

Of course, real users who might disagree, present problems to those who wish to impose their own design choices. The authors discuss ways in which designers and managers seek to neutralise the opinions of such users. Some of the arguments presented included

  1. Resistant users lack self-knowledge: these arguments were based on the premise that users actually didn’t actually understand that open-plan offered a better working environment, and that once they did they would be fine with it.
  2. Resistant users are wrong: this needs no explanation!
  3. Resistant users are falsely claiming that they have unique requirements: This is best explained through an example. Academics might justify their claim to cellular offices because they need to concentrate on their work. Management could counter this claim by arguing that everyone, including office staff, need to concentrate, so there’s nothing special about academics.
  4. Resistant users are self-interested: These arguments were based on the logic that universities are there to serve students, not teacher; ergo, unreasonable demands (such as those for cellular offices) are immoral.
  5. Cellular offices are not used anyway! This argument was based on the observation that offices are unoccupied for 70% of the workday (presumably whilst they were teaching). So their claims to individual offices were unjustified

Basically, if one is going to take recourse to an imagined user, one has to be able to dismiss the opinions of real users!

The arguments against open-plan

The arguments against an open plan design included:

  1. Dismissing the claims of open-plan advocates: These hinged on arguments that advocates of open plan had weak arguments (such as “My mother used to work in an open-plan environment and she loved it”) or had personal agendas.
  2. Creating alternative views of how academic work is done:   One such view might be that academic work is different from administrative work;  it needs the peace and quiet afforded by a cellular office. Strangely, this  counter-argument was not offered by any of the stakeholders.  Instead, tenured academics (higher up in the hierarchy) offered the argument that contract researchers and administrators could go into open-plan because their work was “non-core”   (a euphemism for “not important”). Again we see an imagined user – one engaged in “unimportant” activities.
  3. “People are the organisation”: This is the converse of the rational view presented in the previous section. This argument centred on the premise that the academic staff are the organisation, and that a move to open-plan would destroy employee morale, thereby destroying the organisation in the bargain.  Here too there’s an implicit appeal to an imagined user – the exemplary, indispensable (tenured) academic who would be demoralised by the loss of his office and who may thus be forced to quit. Note that in this argument, other users – contract academics and support staff are imagined as being dispensable.

The authors note that the third argument won out in the end, as they state:

The idea that morale would be damaged in an organisation dependent upon academic support made the appropriateness of open plan or cellular offices irrelevant – the organisation would cease to function effectively if its staff withdrew their support. In this way we see how resistance to the perceived threat of open plan office accommodation on the part of academic staff was manifested through the threat ‘to take their bat home’. The possibility of staff choosing to work at home, rather than occupy the new open plan space, represented too much of a risk for the project in the eyes of some senior managers…

Wrapping up

So what can we take away from this paper?

The case study highlights the use of imagined users to justify specific design views and/or decisions in a specific project.  Both sides of the argument appealed to such users – stereotypes that seem plausible but might not actually exist. This strategy isn’t new,  soccer moms and Howard’s battlers being two examples from political discourse.

The authors find it surprising that none of the arguments offered (by either party) invoked the example of an academic engaged in research – an imagined user who might actually need the peace and quiet offered by a cellular office! They surmise that this may be because in the present day work is considered as (primarily) interactive and social. Ultimately the case against open plan was made by not talking about academic work, but by “selling out” other staff – i.e. simple politics.

Imagined users are often generalisations or composites based on real users, but can also be convenient fictions. However, as the authors note, “Discourses that imagine the user may well fly in the face of empirical evidence or be based largely on hearsay or anecdote, rather than the results of rigorous research, but are no less effective for all that.”   Those who run projects  need to be aware of the power and possibility of the user who wasn’t there, because arguments that invoke imaginary users can be effective rhetorical devices to get  projects moving in  specific  (but not always desirable!)   directions.

Written by K

November 15, 2009 at 10:13 pm

Building project knowledge – a social constructivist view

leave a comment »

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.

Figure 1: Knowledge creation/sharing model

Figure 1: Knowledge creation/sharing model

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.

The Approach: a dialogue mapping story

with 19 comments

Jack could see that the discussion was going nowhere:  the group been talking about the pros and cons of competing approaches for over half an hour, but they kept going around in circles.  As he  mulled over this, Jack  got an  idea – he’d been playing around with a visual notation called IBIS (Issue-Based Information System) for a while, and was looking for an opportunity to use it to map out a discussion in real time (Editor’s notereaders unfamiliar with IBIS may want to have a look at this post and this one before proceeding).  “Why not give it a try,” he thought, “I can’t do any worse than this lot.”  Decision made,  he waited for a break in the conversation and dived in when he got one…

“I have a suggestion,” he said. “There’s this conversation mapping tool that I’ve been exploring for a while. I believe it might help us reach a common understanding of the approaches we’ve been discussing. It may even help facilitate a decision. Do you mind if I try it?”

“Pfft  – I’m all for it if it helps us get to a decision.” said Max. He’d clearly had enough too.

Jack looked around the table. Mary looked puzzled,  but nodded her assent. Rick seemed unenthusiastic, but didn’t voice any objections. Andrew – the boss –  had a here-he-goes-again look on his face (Jack had a track record of  “ideas”)  but, to Jack’s surprise, said, “OK. Why not? Go for it.”

“Give me a minute to get set up,” said Jack. He hooked his computer to the data projector. Within a couple of minutes, he had a blank IBIS map displayed on-screen.  This done, he glanced up at the others: they were looking at screen with expressions ranging from curiosity (Mary) to skepticism (Max).

“Just a few words about what I’m going to do, he said. “I’ll be using a notation called IBIS – or issue based information system – to capture our discussion. IBIS has three elements: issues, ideas and arguments.  I’ll explain these as we go along. OK – Let’s get started with figuring out what we want out of the discussion. What’s our aim?” he asked.

His starting spiel done, Jack glanced at his colleagues: Max seemed a tad more skeptical than before; Rick ever more bored; Andrew and Mary stared at the screen. No one said anything.

Just as he was about to prompt them by asking another question, Mary said, “I’d say it’s to explore options for implementing the new system and find the most suitable one. Phrased as a question: How do we implement system X?”

Jack glanced at the others. They all seemed to agree – or at least, didn’t disagree – with Mary, “Excellent,” he said, “I think that’s a very good summary of what we’re trying to do.” He drew a question node on the map and continued: “Most discussions of this kind are aimed at resolving issues or questions. Our root question is: What are our options for implementing system X, or as Mary put it, How do we implement System X.”

Figure 1

Figure 1

“So, what’s next,” asked Max. He still looked skeptical, but Jack could see that he was intrigued. Not bad, he thought to himself….

“Well, the next step is to explore ideas that address or resolve the issue.  So, ideas should be responses to the question:  how should we implement system X? Any suggestions?”

“We’d have to engage consultants,” said Max. “We don’t have in-house skills to implement it ourselves.”

Jack created an idea node on the map and began typing. “OK – so we hire consultants,” he said. He looked up at the others and continued, “In IBIS, ideas are depicted by light bulbs. Since ideas  respond  to questions, I draw an arrow from the idea to the root question, like so:

Figure 2

Figure 2

“I think doing it ourselves is an option,” said Mary, “We’d need training and it might take us longer because we’d be learning on the job, but it is a viable option. ”

“Good,” said Jack, “You’ve given us another option and some ways in which we might go about implementing the option. Ideally, each node should represent a single – or atomic – point. So I’ll capture what you’ve said like so.” He typed as fast he could, drawing nodes and filling in detail.

As he wrote he said,  “Mary said we could do it ourselves – that’s clearly a new idea – an implementation option. She also partly described how we might go about it: through training to learn the technology and by learning on the job. I’ve added in “How” as a question and the two points  that describe how we’d do it as ideas responding to the question.” He paused and looked around to check that every one was with him, then continued. “But there’s more: she also mentioned a shortcoming of doing it ourselves – it will take longer. I capture this as an argument against the idea; a con, depicted as red minus in the map.”

He paused briefly to look at his handiwork on-screen, then asked, “Any questions?”

Figure 3

Figure 3

Rick asked, “Are there any rules governing how nodes are connected?”

“Good question!  In a nutshell: ideas respond to questions and arguments respond to ideas. Issues, on the other hand, can be generated from any type of node.  I can give you some links to references on the Web if you’re interested.”

“That might be useful for everyone,” said Andrew. “Send it out to all of us.”

“Sure. Let’s move on. So, does anyone have any other options?”

“Umm..not sure how it would work, but what about co-development?” Suggested Rick.

“Do you mean collaborative development with external resources?” asked Jack as he began typing.

“Yes,” confirmed Rick.

Figure 4

Figure 4

“What about costs? We have a limited budget for this,” said Mary.

“Good point,” said Jack as he started typing.  “This is a constraint that must be satisfied by all potential approaches.”    He stopped typing and  looked up at the others, “This is important: criteria apply to all potential approaches, so the criterial question should hang off the root node,” he said.  “Does this make sense to everyone?”

Figure 5

Figure 5

“I’m not sure I understand,” said Andrew. “Why are the criteria separate from the approaches?”

“They aren’t separate. They’re a level higher than any specific approach because they apply to all solutions. Put another way, they relate to the root issue – How do we implement system X – rather than a specific solution.”

“Ah, that makes sense,” said Andrew. “This notation seems pretty powerful.”

“It is, and I’ll be happy to show you some more features later, but let’s continue the discussion for now. Are there any other criteria?”

“Well, we must have all the priority 1 features described in the scoping document implemented by the end of the year,”   said Andrew. One can always count on the manager to emphasise constraints.

“OK, that’s two criteria actually: must implement priority 1 features and must implement by year end,” said Jack, as he added in the new nodes. “No surprises here,” he continued, “we have the three classic project constraints – budget, scope and time.”

Figure 6

Figure 6

The others were now engaged with the map, looking at it, making notes etc. Jack wanted to avoid driving the discussion, so instead of suggesting how to move things forward, he asked, “What should we consider next?”

“I can’t think of any other approaches,” said Mary. Does anyone have suggestions, or should we look at the pros and cons of the listed approaches?”

“I’ve said it before; I’ll say it again: I think doing it ourselves is a dum..,.sorry,  not a good idea. It is fraught with too much risk…” started Max.

“No it isn’t,” countered Mary, “on the contrary, hiring externals is more risky because costs can blowout by  much more than if we did it ourselves.”

“Good points,” said Jack, as he noted Mary’s point.  “Max, do you have any specific risks in mind?”

Figure 7

Figure 7

“Time – it can take much longer,” said Max.

“We’ve already captured that as a con of the do-it-ourselves approach,” said Jack.

“Hmm…that’s true, but I would reword it to state that we have a hard deadline. Perhaps we could say – may not finish in allotted time – or something similar.”

“That’s a very good point,” said Jack, as he changed the node to read: higher risk of not meeting deadline. The map was coming along nicely now, and had the full attention of folks in the room.

Figure 8

Figure 8

“Alright,” he continued, “so are there any other cons? If not, what about pros – arguments in support of approaches?”

“That’s easy, “ said  Mary,  “doing it ourselves will improve our knowledge of the technology; we’ll be able to support and maintain the system ourselves.”

“Doing it through consultants will enable us to complete the project quicker,” countered Max.

Jack added in the pros and paused, giving the group some time to reflect on the map.

Figure 9

Figure 9

Rick and Mary, who were sitting next to each other, had a whispered side-conversation going; Andrew and Max were writing something down. Jack waited.

“Mary and I have an idea,” said Rick. “We could take an approach that combines the best of both worlds – external consultants and internal resources. Actually, we’ve already got it down as a separate approach –  co-development, but we haven’t discussed it yet..” He had the group’s attention now. “Co-development allows us to use consultants’ expertise where we really need it and develop our own skills too. Yes, we’d need to put some thought into how it would work, but I think we could do it.”

“I can’t see how co-development will reduce the time risk – it will take longer than doing it through consultants.” said Max.

“True,” said Mary, “but it is better than doing it ourselves and, more important, it enables us to develop in-house skills that are needed to support and maintain the application. In the long run, this can add up to a huge saving. Just last week I read that maintenance can be anywhere between 60 to 80 percent of total system costs.”

“So you’re saying that it reduces implementation time and  results in a smaller exposure to cost blowout?” asked Jack.

“Yes,” said Mary

Jack added in the pros and waited.

Figure 10

Figure 10

“I still don’t see how it reduces time,” said Max.

“It does, when compared to the option of doing it ourselves,” retorted Mary.

“Wait a second guys,” said Jack. “What if I reword the pros to read – Reduced implementation time compared to in-house option and Reduced cost compared to external option.”

He looked at Mary and Max. – both seemed to OK with this, so he typed in the changes.

Figure 11

Figure 11

Jack asked, “So, are there any other issues, ideas or arguments that anyone would like to add?”

“From what’s on the map, it seems that co-development is the best option,” said Andrew.  He looked around to see what the others thought: Rick and Mary were nodding; Max still looked doubtful.

Max asked, “how are we going to figure out who does what?  It isn’t easy to partition work cleanly when teams have different levels of expertise.”

Jack typed this in as a con.

Figure 12

Figure 12

“Good point,” said Andrew. “There may be ways to address this concern. Do you think it would help if we brought some consultants in on a day-long engagement to workshop a co-development approach with the team? ”

Max nodded, “Yeah, that might work,” he said. “It’s worth a try anyway. I have my reservations,  but co-development seems the best of the three approaches.”

“Great,“ said Andrew, “I’ll get some consultants in next week to help us workshop an approach.”

Jack typed in this exchange, as the others started to gather their things. “Anything else to add?”  he asked.

Everyone looked up at the map. “No,  that’s it, I think,” said Mary.

“Looks good,”  said Mike . “Be sure to send us a copy of the map.”

Figure 13

Figure 13

“Sure, I’ll print copies out right away,” said Jack. “Since we’ve developed it together, there shouldn’t be any points of disagreement.”

“That’s true,”  said Andrew, “another good reason to use this tool.”  Gathering his papers, he asked, “Is there anything else? He looked around the table. “ Alright then, I’ll see you guys later,  I’m off to get some lunch before my next meeting.”

Jack looked around the group.  Helped along by IBIS and  his facilitation, they’d overcome their differences and reached a collective decision. He had thought it wouldn’t work, but it had.

“ Jack, thanks  for your help with the discussion. IBIS seems to be a great way to capture discussions.  Don’t forget to send us those references,” said Mary, gathering her notes.

“I’ll do that right away,” said Jack, “and I’ll also send you some information about Compendium – the open-source software tool I used to create the map.”

“Great,” said Mary. “I’ve got to run. See you later.”

“See you later,” replied Jack.

————

Further Reading:

1. Jeff Conklin’s book is a must-read for any one interested in dialogue mapping. I’ve reviewed it here.

2.  For more on Compendium, see the Compendium Institute site.

3. See Paul Culmsee’s series of articles, The One Best Practice to Rule Them All, for an excellent and very entertaining introduction to issue mapping.

4. See this post and this one for examples of  how IBIS can be used to visualise written arguments.

5.  See this article for a dialogue mapping story by Jeff Conklin.