Problem Solving Dialogue: Cognitive Mapping And IBIS · Problem Solving Dialogue: Cognitive Mapping And IBIS ... PROBLEM SOLVING DIALOGUE: COGNITIVE MAPPING AND IBIS ... to compare

M Westcombe & M Pidd Problem Solving Dialogue (MS 01/02)

Problem Solving Dialogue:Cognitive Mapping And IBIS

Working Paper MS 01/02The Management School

Lancaster University

This is a revised version of working paper MS 01/02. Please do not reference this paperwithout obtaining permission from the authors. We direct readers to Mackenzie A, Pidd

Michael, Rooksby J, Sommerville I, Warren I and Westcombe M Wisdom, decisionsupport and paradigms of decision making which is currently in print with the

European Journal of Operational Research (EJOR).

M Westcombe*, M Pidd, Adrian Mackenzie, Ian Warren and Ian Sommerville

AbstractCognitive mapping, as used within Strategic Options Development and Analysis (SODA), and Issue-based Information Systems (IBIS), as used in Dialog Mapping are two approaches that aim to supportpeople tackling wicked problems. Though they come from different disciplines, operational researchand computer science, the two approaches have many similarities and some differences. Each has asupporting methodology, embodies a definite technique, has a suggested process and employssupporting technology. Both approaches could be employed in OR practice, taken separately or incombination, and issues relevant to the choice of approach are discussed.

Mark Westcombeattivation

25 MeadowsideLancaster

GB LA1 3AQ0845 456 2494

[email protected]

Mike PiddDepartment of Management

ScienceLancaster University

LancasterGB LA1 4YX

[email protected]

Adrian Mackenzie, Ian Warrenand Ian Sommerville

Computing DepartmentLancaster University

LancasterGB LA1 4YR

* Correspondence

-1- Lancaster University Management School


PROBLEM SOLVING DIALOGUE: COGNITIVE MAPPING AND IBIS................................................ 3

INTRODUCTION....................................................................................................................................................... 3

Wicked problems.......................................................................................................................................... 3

COGNITIVE MAPPING IN OR..................................................................................................................................... 3

DESIGN RATIONALE.................................................................................................................................................4

IBIS: An Exemplar Of Design Rationale......................................................................................................5

COGNITIVE MAPPING AND IBIS COMPARED................................................................................................................. 5

METHODOLOGY......................................................................................................................................................6

Strategic Options Development and Analysis.............................................................................................. 6Dialog Mapping............................................................................................................................................7

TECHNIQUES..........................................................................................................................................................7

Cognitive maps............................................................................................................................................. 7IBIS............................................................................................................................................................... 8

PROCESS............................................................................................................................................................... 9

Using Cognitive mapping with groups.........................................................................................................9Using IBIS in meetings............................................................................................................................... 10

TECHNOLOGY...................................................................................................................................................... 12

Decision Explorer.......................................................................................................................................12Group Explorer.......................................................................................................................................... 12QuestMap................................................................................................................................................... 13

CONCLUSIONS...................................................................................................................................................... 13

ACKNOWLEDGEMENTS........................................................................................................................................... 14

REFERENCES........................................................................................................................................................14



PROBLEM SOLVING DIALOGUE: COGNITIVE MAPPING AND IBIS

INTRODUCTION

Many operational research (OR) practitioners areaware of cognitive mapping1, 2 as a soft-ORtechnique useful in 'messy'3 problems, althoughfew might have used it in practice. Fewer still willhave heard of Issue-based Information Systems4 orIBIS, developed within the Design Rationale fieldof software engineering, to tackle 'wicked'5problems. IBIS is similar to cognitive mapping,using maps to capture and structure conversationtaking place around a problem, with the aim ofimproving decision making. Little dialogue hastaken place between the cognitive mapping andIBIS research communities, which has deprivedpractitioners in both fields of exposure to theexpertise of the other. This paper highlights themain features of IBIS and cognitive mapping so asto compare and contrast their use with groupsengaged with strategic problems.

Cognitive mapping and IBIS are bothmodelling techniques based on 2-D directedgraphs of nodes containing text which are linkedtogether as a map. A model is built to represent theproblem space by a series of interconnected maps.Figure 1 and Figure 2 are examples of such maps.The techniques are embedded withinmethodologies: SODA* (Strategic OptionsDevelopment and Analysis) is the framework for"designing problem solving interventions"6 usingcognitive mapping; and Dialog Mapping7 providesa framework for IBIS. Both approaches provideguidance for managing the process of groupproblem solving in workshops, such as developingshared understanding8 and ensuring politicallyfeasible9 solutions. Although not essential, theireffectiveness is enhanced by the use of technology– generally this involves networked PCs operatingspecialised software and projection of the groupmodel onto a shared public screen. The nextsection briefly discusses wicked problems as thebasis for the comparison. Wicked problemsIBIS was developed to address what Rittel andWebber5, 10 termed “wicked” problems. Thesecontrast with tame problems, in which most things

* The SODA methodology has been further developedand is referred to as JOURNEY Making. This paperuses the term SODA throughout when discussingproblem structuring and JOURNEY Making whenspecifically discussing its application to the design oforganisational strategy.

are understood and to which automated problemsolving methods can be applied11. Wickedproblems have stakeholders with differentparadigms, that have their own vocabulary andmeans of expression; they have hidden agendas,different values and competing interests; and areoften physically distributed12, 13. Moreover, there islittle hard data available for analysis; the nature ofthe problem evolves over time; and resources,including time, are limited. They are uniqueproblems with no correct solution, in which thehardest and most demanding element is problemdefinition. They fragment the objectives andprocesses of project work and act as a barrier tocollaboration14. Dialog Mapping, like SODA,assumes that solving such wicked problems is"fundamentally a social process"12, 15. Both seekto encourage dialogue to support collectiveenquiry.

COGNITIVE MAPPING IN ORThe term cognitive mapping first appeared in thepaper ‘Cognitive Maps in Mice and Men’16 but theideas did not emerge from psychology into ORuntil the late 1970s. Within psychology, the termcognitive map is most commonly used to indicatethe internal, mental maps that we maintain inunderstanding and representing our physicalsurroundings. The development of cognitive mapsin OR began with the adoption of repertory grids17,

18 originally developed from Kelly’s work on theTheory of Personal Constructs19. In OR, acognitive map is a two-dimensional directed graphof the type shown in Figure 1 that "represents theway in which a person defines an issue"6. WithinOR, the development and use of such maps owesmuch to the work of Eden1, 6, 9, 15, 20, 21, 22, 23, 24, 25, 26, 27,

28, 29, 30.The example shown below in Figure 1 illustrateswhat a cognitive map looks like. It is adapted froma 1-to-1 interview conducted by one of the authorswith a senior manager from a company supplyingspare parts to the naval industry. To maintainclient confidentiality the company is referenced toas 'OURmgmt'. The map is discussed at morelength in the section devoted to Techniques:Cognitive maps.



Figure 1 Example of a simple cognitive map

Similar maps can be built for groups, either bymerging individual cognitive maps, or directlyusing a facilitator in a brainstorm-type workshop.These workshops can be computer assisted or usepost-it style ovals to build maps manually, 31, 32.Maps built directly with groups are normallyreferred to as cause maps, as they no longer reflectthe cognition of an individual. Cause maps formthe basis of SODA workshops from the initialbrainstorm activities; structuring of the problem;through to agreement regarding an action plan.This present discussion focuses on the building ofcomputer supported cause maps within SODA.

DESIGN RATIONALE

Design Rationale is a field of research within thesoftware engineering, human-computer interaction(HCI) and computer supported collaborative work(CSCW) research communities. It seeks to aiddecision-making during a design process byformally capturing the knowledge thataccumulates. The representation of this knowledgeas a map provides an audit trail of the decisionsmade and the rationale behind them. The design

deliberations can then be reused either by the sameteam at a later date; by others engaged on the sameproject such as the maintenance team33; or by adifferent project team engaged on a similarproject. A number of different design rationaleapproaches4, 34, 35, 36 and supporting software tools37,

38 have been developed. Others have incorporatedadditional tools such as risk analysis39 or forsupporting concurrent engineering teams40. Eachapproach uses a formal notation to code and linkdifferent elements of the argumentation so as toguide the map building. That is, they are moreformal than the rules for building cognitive maps.

Most design rationale notations have beeninspired by the pioneering work of Rittel41 whodevised IBIS, the first design rationale notation.The development of IBIS as Dialog Mapping hasbeen principally the work of Conklin4, 7, 8, 12, 13, 14, 33,

42, 43, 44, 45, 46, 47, 48, 49. Others have been influenced byargumentation theory, in particular the workstemming from Toulmin50. Moran and Carroll51, 52

and Buckingham Shum53, 54, 55, 56 provide acomprehensive introduction to the aims, uses andapplications of the principal notations and presents



the realities of using them. Of all the designrationale notations, IBIS is most like cognitivemapping. It has concentrated most on the process,as well as content57, of using a mapping techniquewith groups. It is probably the most popularnotation, with an ongoing research community58

and the most case studies reported by practitioners,see for example Selvin59.IBIS: An Exemplar Of Design RationaleIBIS was introduced by Rittel to "support co-ordination and planning of political decisionprocesses."41 The initial work sought to helpproblem solving groups identify, structure andresolve issues within design or planning problems.The nodes of an IBIS map are labelled asQuestions, Ideas or Arguments (Pros and Cons). Amap begins by asking a Question, generating Ideasthat might resolve the Question and adding thePros and Cons against each Idea4. A simpleexample of an IBIS map is shown in Figure 2which, for illustration purposes, has been adaptedfrom the cognitive map of Figure 1.

More complex maps develop as the issues areexplored, further questions are raised and as thedialogue develops. Unlike SODA, the DialogMapping methodology does not involve an initialbrainstorm of ideas before focusing on a few areasof concern. As described later, it begins bybuilding a map around an issue that has normallybeen decided prior to the meeting. Discussion neednot be restricted to this issue, though, and parallelmaps can be built and, later, pulled together. UsingIBIS produces a more traditional meeting than thatresulting from cognitive mapping and SODA. TheIBIS map reflects the exchanges taking place, so asto guide the dialogue and, as discussed later,improve the nature of the meeting4. The notationprovides the basis for the meeting’s process andhelps to improve the likelihood of an effectiveoutcome. Unlike SODA, IBIS does not necessarilyrequire a process facilitator49.

Figure 2 Example of an IBIS map



COGNITIVE MAPPING AND IBIS COMPARED

This section compares cognitive mapping and IBISby discussing four components of each approachin turn. These are:

1. Methodology: the intellectual frameworkwithin which SODA and Dialog Mappingare justified and that provides guidelinesfor using the associated techniques in anintervention.

2. Technique: the modelling rules andmethods that form the basis ofcognitive/cause and IBIS maps.

3. Process: the management of the workshopand decision making procedure.

4. Technology: the computer-based tools thathave been developed to support themethodology, process and techniques

Each of these components depends on the othersand all are evident during a properly managedworkshop. The section on Process illustrates theapplication of both approach best and highlightsthe contrasts between the two. Table 1 provides asummary of the terminology used throughout thenext sections of the paper.

METHODOLOGY

Both techniques are used within a set of guidelinesthat assist the practitioner to design anintervention. The SODA methodology has beenwell documented and includes a step-by-stepaccount of how to use cognitive mapping2 andalso how to plan a "quick and dirty" strategyworkshop23. Dialog Mapping7 has emerged morerecently as a framework for using the IBIStechnique4 to help groups structure problems inface to face meetings. It is similar to SODA in thatit is a model focused60 approach and is concernedwith unstructured problems, sharing understandingand meaning8, and developing sharedcommitment8 amongst group members. Apractical illustration of how Dialog Mapping canbe used with a facilitator as a meeting tool can befound in The Dialog Mapping Experience45. Bothapproaches are designed for use with problem

solving groups and to support collaborative work.They are less applicable for groups engaged in 0-1sum games such as public policy, where dialogueis adversarial, and ambiguity may be the keycurrency in negotiations.Strategic Options Development and AnalysisSODA is often referred to as a soft-OR or aProblem Structuring Method. A fundamentalassumption of SODA is that power andorganisational politics lie at the heart of problemsolving and decision making23. It accepts that“aspirations are disputed, conflict exists andmanagers compete for scarce resources”23 and soaction plans or ways forward need to benegotiated6. It does not necessarily seek theoptimal way forward, but rather one that the groupis willing to agree and commit to. Cognitivecommitment to the action plan is achieved throughdeveloping shared understanding betweenparticipants, and emotional commitment throughparticipation in the workshop process9.

SODA assumes that each stakeholder has asubjective view of the problem based on theindividuals’ knowledge and experience6. It useslanguage and conversation to share these differentperceptions. In practice this means that, as ideasare represented in the map, the different groupmembers' debate their different views. Thefacilitator exploits this by encouraging the team todiscuss the model and to bring about sharedagreement by allowing participants to gentlychange their minds. A SODA workshop hencerequires modelling the problem using cognitivemapping, using mapping software and theexistence of a facilitator to managing the groupprocess.

JOURNEY Making23 is an extension ofthe original SODA methodology20 applied tomanagement teams engaged in strategy making. Ituses cause maps to explore goal systems and corecompetencies and combined with other analysessuch as identifying threats and stakeholderanalyses.

Technique Cognitive Mapping IBISMethodology SODA Dialog MappingMapping software Decision Explorer QuestMapGroup support system Group Explorer QuestMapGroup map Cause map IBIS mapResearch Field Soft OR / Problem

Structuring MethodsDesign Rationale

Application Messy problems Wicked problemsTable 1 Cognitive mapping and IBIS terminology



Dialog MappingDialog Mapping sees wicked problem solving as asocial process that cannot solely rely on therational-scientific paradigm of gather, analyse,formulate and implement44. It considers thatmeetings are the best tool we currently have forwicked problem solving, even though the standardformat often fails to be effective. The section onProcess describes how it aims to enable meetingsto allow information processing while supportingcommunication and collaboration. Key to this isthe use of the IBIS notation and a map to developshared understanding and commitment, and thegeneration of collective intelligence14.

Dialog Mapping emphasises theimportance of a collaborative display14, usuallyby the projection of an IBIS map. A collaborativedisplay demonstrates to participants that theirpoint has been heard, it helps the group structuretheir thinking and reduces their reliance onmemory. The availability of this shared spacechanges the dynamic of the group, as the displayitself becomes a participating member in theconversation. It is intended to support jointproblem solving and to encourage collaborativeconversation of the kind “Yes, and …” rather than“Yes, but … .” By validating the material with thegroup, a facilitator encourages them to takeownership of the map. This leads to sharingmeanings, and understanding and develops bothcognitive and emotional commitment. Dialogmapping does not, however, require consensus onthe problem, rather it aims for stakeholders to“understand each other’s positions well enough tohave intelligent dialog about the differentinterpretations of the problem, and to exercisecollective intelligence about how to solve it.”13

The developing Compendiummethodology61, 62, 63 applies IBIS to knowledgemanagement and aims to mediate collective sense-making, to support group memory and interfaceswith other tools used for project management46. Itallows maps to be updated between meetings, byexporting them into other documents and by usingweb-based tools. It also uses templates similar tothe PQR and CATWOE analyses of Soft SystemsMethodology64, 65 to explore issues.

TECHNIQUES

As introduced earlier, both approaches rely onsimple two-dimensional graphs of nodescontaining text. These nodes are then linked withan arrow to show their relationships, creating ahierarchical structure of concepts. Bothapproaches aim to provide an alternative to lineartext and to offer a more systematic and systemic

means of interrogating a decision space throughstructured dialogue. The main differences betweenthe two representation systems is that building acognitive map is rather informal, as node types aread-hoc and their linking to some extent isinterpretative, while the IBIS approach aims toexplore the decision space by employing moreformal representations.Cognitive mapsWhether concerned with an individual’s cognitivemap based on interviews or a group’s cause map,the method of representation in the map is thesame. Cognitive mapping is a simple, non-linearrepresentation of argumentation as shown earlierin Figure 1. The nodes of the map are conceptsthat have some meaning for the individual (and/orgroup) involved and are, as far as is possible,expressed in the words that they themselves use.The cognitive mapping guidelines2 provide furtherrules for phrasing concepts, such as restrictingeach concept to one idea; using 8-10 words foreach; and using the imperative form of the verb toconvey an action-orientated formulation of theproblem.

The links between nodes are intended torepresent the causal relationship between theconcepts. These links are causal, in that ‘conceptA’ may lead to or have implications for ‘conceptB’6. This linking structures the concepts into ahierarchy which shows the positive or negativecause and effect between individual conceptsacross the model. This helps individuals see thebigger picture, in a way that other representationsor conversation cannot. Understanding thecause:effect relationship between two nodesdepends on the specific context, which includesthe priorities or worldviews of individuals – since,what is a cause for one may be an effect foranother. In strategy development this is done byidentifying concepts that are agreed with the groupas goals and placing them at the top of thehierarchy. This frames the discussion and providesa context in which concepts can be linked tocascade down from these goals.

The map in Figure 1 shows two conceptsthat the interviewee felt were goals: "increaseOURmgmt margins" and "increase OURmgmtshare of customer material support from 25% to45%." At the time, one of the business unit'sagreed strategies for achieving these goals was to"redefine the support chain." The bottom right ofthe map shows four options for this mentioned bythe interviewee. As the problem was discussed,other strategies were formulated and optionsgenerated. This led to the interviewee identifying



issues that would need to be overcome such as"changing customer culture from cost plus tocommercial costing." The node types used inFigure 1 are distinguished in the map by usingdifferent fonts and colour coding for each of goal,strategy, option and issue. Colour coding theconcepts helps with visualising or navigating themap and provides a heuristic for chunkingconcepts together to aid memory or thinkingprocesses. Although these node types are typical ofsome of those used in a strategy context23, theyare essentially ad-hoc. Unlike IBIS and othermapping tools, cognitive mapping has no formal orprescribed node type. When preparing for anintervention, the facilitator chooses, perhaps withthe client, what node types might be appropriatefor the workshop objectives. These can be adaptedor added to during the workshop to helpparticipants make sense of the map and to steer thedialogue.

A map is intended as a representation ofthe views and arguments of one individual orgroup. It is informal and easy to use, andparticipants are aided in seeing the problem’ssystemicity or big picture. This "quick and dirty"approach to modelling can, however, limit themaintenance or further use of the resulting maps,as they quickly become outdated. The mapsthemselves are merely transitional objects, themeans to an end. The process of building themodel is the focus, not the building of acomprehensive and near perfect model that acts asan artefact.IBISThe representations used in all design rationalenotations are much more formal than thoseemployed in cognitive mapping. IBIS constrainsnodes to three types: A Question node that states an issue in

question form; An Idea node that proposes an option or

possible resolution to the question; and An Argument node (pro or con) that states an

opinion or judgement that either supports orobjects to one or more Ideas4.

These three node types support the "identification,structuring and settling of issues raised by problemsolving groups."41 The notation also constrainsthe linking between the node types which, asexplored in the later section devoted to Process,helps maintain a structured dialogue. Thepermitted links that can be made between nodesare shown in Figure 3. These links are not causal,rather nodes are connected by links with differentsemantic types. For example, Ideas respond to

Questions and Arguments support or object tothese Ideas. Nodes are linked graphically on thedisplay to reflect the nature of the argument, withsubordinate nodes strictly to the right. A Decisionnode is used to represent an action that the grouphas agreed will resolve a particular Question.Other nodes can be included in the map on an ad-hoc basis, particularly references or hyperlinks toother maps and documents. Originally, links hadlabels showing their semantic type, such as'supports' or 'objects to', but these are generally notdisplayed, although the links are often colourcoded.

Figure 3 IBIS notation's standard nodes and legallinks

Posing Questions is central to IBIS andDialog Mapping4. Examples include: what needsto be done, how and why it should be done; askingabout the meaning behind concepts; asking forfacts; or seeking clarification or criteria by whichto judge issues. Most importantly, however, whenthere is disagreement or misunderstanding, theyare used to frame the issue as a question. Asdiscussed in the section devoted to process, thistransforms the discord into collaborative inquiry4.It diffuses the personal issues that arise fromadversarial discussion and allows issues to beinvestigated in partnership, rather thanconfrontation.

The IBIS notation ensures that the maprepresents the dialogue taking place in the group,rather than representing the decision space. Unlikecognitive mapping, an Idea may be included as adistinct node more than once, if it is an option thatresponds to more than one question. This avoidsmultiple links on the map and preserves thedifferent story-lines, since an argument made for



the adoption of an idea might only be relevant toone story and question. To manage repeatinstances of an Idea a hidden link can be used toremind the group of the different instances, or thesoftware's search function used. Preserving theaccuracy of story-lines is easier in IBIS than whenusing cognitive mapping with groups, because themeaning behind the dialogue is represented, ratherthan the problem itself.

As an example, Figure 2 shows how theQuestion 'how do we increase our market share?'has been answered by two Ideas. One Idea, 'offer aservice provision', has generated arguments for andagainst its adoption. The other 'reduce client costs'has been queried by a Question, which in turn hasbeen responded to by two Ideas that have beenfurther explored. The map reflects the dialogue,rather than an abstract logic, and so its structuredepends on the idiosyncrasies of the particularmeeting. In other circumstances the Question"How to reduce client's costs?" might not havebeen raised and the two Ideas "redefine the supportchain" and "move to commercial costingagreement" might have been linked directly to"reduce client costs." An example of this type oflinking is shown with the Idea "change our designand costing culture." The IBIS Manual4 provides acomplete guide to the mapping technique.

PROCESS

As already discussed, both mapping techniques areembedded in methodologies that guide their usewithin interventions and inform the processfollowed. A group workshop needs to providerelevant tasks, facilitate group communication, andmanage group dynamics. It needs to ensure that thegroup members converge to a sharedunderstanding and commit themselves to a wayforward. The techniques represent the dialogue,but it is the processes that provide a structure andprotocol for communication. It is the process thatmust demonstrate to the participants that thedecision making procedure is sensible - that it isprocedurally rational66. The successful executionof the workshop's process places the most demandon the consultant's skills.Using Cognitive mapping with groupsA SODA workshop usually begins with arelatively free ranging brainstorm prompted by aquestion such as, "What are the issues facing theorganisation over the next x years?" This is oftendone with a blind gather67, 68 in which individualsanonymously and simultaneously contribute ideaswithout seeing each others contributions.Participants input concepts via their laptops to themodel on the facilitator's machine, but without any

display to the projection screen. This generates awide range of ideas or concepts and the gather isterminated by the facilitator, typically when up to50 contributions have been made. The concepts areroughly clustered by the facilitator and shownback to the group. Further concepts are added asparticipants review one another's contributions andpiggy-back67, 68 of one another's ideas. This isdone either via a participant's laptop or through thefacilitator. This two stage brainstorming helpsavoid group-think69 and broadens the decisionspace, as well as encouraging the building of ideason the back of others.

The emerging clusters are agreed with thegroup and are further developed by the group.Links may be added between concepts, keyconcepts might be identified using a round robin,concepts might be colour coded according to theirtype, or clusters might be isolated and developedthrough in-depth discussion. Again the facilitatormay add the concepts and links suggested by thegroup, or instruct the participants to do sothemselves through their laptops. Typically, oncethe brainstorm material has been structured, thegroup identifies a set of key concepts and thenranks them by voting23. The ranking might beused to prioritise the issues on which to spendworkshop time, or used as a tool to note and sharedivergent opinions. Voting is also used to establishwhether a groups' opinions are aligned or toidentify outliers, people who may be aware ofinformation of which the rest of the group isignorant. In discussing the voting patterns, thegroup can share meaning and understanding andestablish agreement. A second vote on the sameissues generally involves a shift towards groupconsensus.

Throughout a SODA workshop, the choiceof activity at any particular point depends on whatthe facilitator considers most appropriate to thetask. SODA places great reliance on the facilitatorto select and shape each step of the workshop,since there is no rigorous, step-by-step procedure.In their presentation of Strategic Choice, Friend &Hickling70 point out that a group will shift its focusas it works and that it is wrong to assume thatthese shifts follow a particular sequence. InSODA, these shifts emerge as the model isdeveloped and discussed. During the course of atypical SODA workshop a group might beinvolved in several different brainstormingactivities; structuring the brainstorm materialthrough clustering and linking; coding conceptsaccording to their type; identifying key concepts tobe further developed; voting on the priority of the



key concepts; elaborating these concepts throughdiscussion; establishing goals and options;generating actions; and finally agreeing a wayforward. The facilitator is not limited to using thecognitive mapping to achieve all of this. She maychose to incorporate any appropriate activity,which may or may not exploit the software.Managing this contingent23 approach to theworkshop process is important and relies on keycraft skills.

When planning for a workshop thefacilitator must establish a clear set of workshopobjectives and should anticipate the potentialworkshop stages that might be useful. This processdesign should be done in negotiation with theclient, during which the facilitator and client bothlearn their way into the problem situation and theissues that need to be tackled. This process designplaces an overhead on using the methodology andinhibits its use in a normal meeting format whichmight benefit from some improvised problemstructuring.Using IBIS in meetings

As mentioned earlier, a Dialog Mappingsession does not begin with a wide-rangingbrainstorming activity, instead a Question is posedthat prompts for Ideas (options) that directlyaddress the problem. Typically a question askswhat should be done, or how it should be done.This generates a handful of Ideas, along withArguments for or against. These are added to themap and linked to the Ideas as pros and cons. Fromthis point the dialogue may go in any one of manydirections, with the map being built to reflect theconversational turns. Participants may raise issuesthat challenge an Argument. These are phrased asQuestions and Ideas added that might resolvethem. More Ideas and Arguments may be addedagainst the original Question. Parallel Questionsmay be introduced, generating a second map that islater linked into the original. Questions might alsoconsider the project objectives or criteria, or evenquestion the validity of the problem itself. Themap building may proceed linearly, but often Ideasare mapped before the relevant question has beensuggested, and Arguments often precede the Ideas.As each thread of the conversation draws to aclose, the map acts as a short term memory aid toremind the group of what has been discussed andwhat remains to be elaborated. Conklin45 providesa well documented example to show how typicalDialog Mapping might progress.

As discussed in the section onTechniques: IBIS the framing of issues as

Questions is central to transforming the dialogueinto one of collaborative problem solving. Thefacilitator is critical to instigating thistransformation. For example, if in Figure 4 'reduceclient costs' is suggested as an option, but anotherparticipant retorts that client costs cannot bereduced, the facilitator can capture this as 'Howcan we reduce client costs?' This recognises theissue raised, but removes the potential for a yes-noconfrontation and instead poses it as an issue forcollaborative enquiry4 and prompts for Ideas tosolve it.

To illustrate how questions can be usedunder various circumstances, imagine that the mapin Figure 4 was built differently and that theoriginal root question was 'How do we reduceclient costs?' At some point in the conversation, aparticipant might ask "Why are we doing this?"This conversational move is integrated into themap by seeking the meaning behind the map’s rootQuestion. In Figure 4 this would be mapped by theIdea 'reduce client costs' and the Question that liesat the root of this being 'How do we increase ourmarket share?' Alternatively the participant mayhave commented "We should be talking aboutwhat service we're offering, not how to reduceclient costs!” This is represented in the map as aparallel Question to 'How do we reduce clientcosts?' Again the Ideas behind each of theseQuestions is mapped and a root Question sought tolink both threads. In normal conversation either ofthese comments can act as grenades4, but DialogMapping exploits them to expand the map andincrease the discussion's frame. Both scenarioscould disrupt the dialogue as the group argues theproblem's focus. Instead the two strands arecaptured by a global question which removes anypotential for dispute. This global question diffusesheat by demonstrating that, although opinionsdiffer, all group members are working towards acommon goal.

Dialog Mapping makes no use of voting,rather it relies on the group to eliminate options asfocus develops and shared understanding emerges.It relies on a full exploration of the map during thedivergent stage of the workshop so that whenconvergence takes place, a decision is easilyestablished. This might take the form ofindividuals personally endorsing particular optionsand discussion continuing until agreement on oneparticular option occurs, or options might bebenchmarked against a set of agreed criteria.



Figure 4 Representation of a dialogue that could have occurred in three different ways

A facilitator is not essential for DialogMapping, as IBIS was originally conceived for useby groups versed in its notation and its rules ofengagement. This requires commitment from thewhole group to gaining fluency in the notation,something a facilitator can alleviate. Operating thisway means that a participant must act astechnographer, or scribe, for the group, which maylose the regular summarising of the dialogue that afacilitator would provide. Working without afacilitator also assumes that the group will be selfregulating and effective in directing its focus to thekey issues.

The Dialog Mapping process is implicitwithin the IBIS notation and, unlike SODA, cannotbe so readily distinguished from its technique.SODA uses cognitive mapping as a formallanguage to represent the argument and a 'cultural'language71 to provide the "protocol for the processof arguing and interacting"72. The IBIS notation isitself fundamental in changing the conversationalmodel, although the facilitator need not reveal thenotation to the group. IBIS aims to break the habitsfound in problem solving meetings such as

“argument by repetition”, axe grinding, blocking,rhetoric and reflex response4. Although the varietyof activity is far more limited than in a SODAworkshop, which makes long workshops lesssustainable, it has some advantages. It requires lessprocess planning or expertise in facilitating groups- indeed a Dialog Mapping session can beginspontaneously in any meeting without the need forpreparation. The question of “What should wedo?” is sufficient enough a prompt to begin aproblem structuring dialogue. The format is like astandard meeting, which may be less threateningthan other problem structuring methods and is lessof a risk for an individual to introduce to a group.

However its initial stages are less wide-ranging than SODA and risk elaborating a sideissue in great depth before the true problem isidentified. It relies more on the group selfcorrecting itself to identify the real issues. As withany standard meeting, there is a risk that the groupmay be efficacious in thoroughly exploring anissue, but ineffective in that they focus on thewrong issue. Thus, although the underlyingtechnique and methodology of IBIS is very similar



to cognitive mapping, the process of using it withgroups differs greatly.

TECHNOLOGY

The modelling techniques have many similaritiesand unsurprisingly employ similar computersupport. Both techniques can be practised withoutrecourse to computer technology23, 32, 72, 49, butwith 1 day workshops generating up to 600concepts, mapping software greatly assists themanagement of this complexity. Both approachescan be used with a single PC projecting the modelonto a public screen or using networked laptopcomputers and data projector7, 49, 73. Cognitivemapping has two associated software packages,Decision Explorer74 for a single PC user andGroup Explorer75 for networked PCs. IBIS isprincipally associated with the QuestMap37software currently being further enhanced underthe working title of Mifflin76. Eden9, 24, 25, andAckermann72, 77 have written about the impact ofGDSSs and the criteria by which to judge theireffectiveness.Decision ExplorerThe Decision Explorer software (originallyGraphics COPE) is a cognitive mapping andanalysis tools for the single user. It can be used bythe individual to build, manipulate or analysemaps, or by a facilitator with projection facilitiesin a SODA workshop. A single model is composedof a number of interconnected maps on differentview tabs. Each view can sensibly display up to 40concepts as part of a map, or 60 concepts as part ofa brainstorm that has yet to be linked. Conceptsand links are entered directly onto the map and canbe freely placed without grid restrictions. Anyindividual concept can be displayed in more thanone view, either like most software packages as acopy, or as a "transclusive" link. A transclusivecopy of a concept allows it to appear in a secondor further view such that any text or link editing ofone instance of the concept will be dynamicallyand universally applied to other instances of it. AsConklin46 discusses in relation to QuestMap, thisform of “transclusive” linking is counterintuitiveand a difficult part of learning either software.Beyond the visualising element, the tool alsooffers an array of functions for text wrap; the useof colour and font styles; creating ad-hoc node andlink types; numbering concepts for easy reference;the ability to filter out concepts; automated ormanual graphing tools; etc. A comprehensiveexplanation of the functionality available is givenin Decision Explorer user78 and reference79 guidesand workbooks80.

Although cognitive mapping places lessemphasis on the formal structure of the decisionspace model, a well conducted map buildingsession should lead to a model with a structure thatcan be analysed in a variety of ways29, 30. Thisincludes feedback loop analysis, which can beperformed on the whole model or just a subset.Ad-hoc analysis23 can be used during a workshopto inform the process or aid visualisation; duringreport writing or later.Group ExplorerGroup Explorer extends Decision Explorer toconnect other users across a local area network(LAN) and provides data input functions toDecision Explorer. Unlike QuestMap, only thefacilitator has full access to the Decision Explorermodel and functionality - this being the screendisplay projected onto the public screen. It allowsthe facilitator to provide the participants' laptopswith anonymous concept input, linking or votingfunctionality. The management of the participants'laptops is best done through an additionalmachine, referred to as the ‘chauffeur’. Thechauffeur also provides the facilitator with groupmanagement data such as who is entering what andwhen, how individuals are voting, etc. This helpswith managing activities by indicating who hascompleted a task, who might be having problems,and identifying who input what. Both facilitator'smachines are typically operated by a secondperson supporting the facilitator.

Anonymous data input and voting can beused throughout, or only for some of the workshopactivities – such as brainstorming and voting.Anonymity can help in surfacing challenges toreceived doctrine and allow for risk taking23.More importantly, though, it reduces the energyrequired for an individual to shift opinion. If theparticipant has not been identified as holding aposition, there is less need for them to defend theirposition23 or account for a change of mind. Thedesign rationale world has tended not to offeranonymity, believing that an idea or viewpoint isvalidated partly by knowing who has made thesuggestion. Armstrong81 has suggested that shortterm, real-time discussions benefit fromanonymity, while long term usefulness of anyinformation requires attribution.

Radio network cards have greatlyimproved the reliability of the portable networksused for SODA workshops, which previouslysuffered regular network crashes caused by wearon the network cables. Although costly in terms ofboth hard and software, the Group Explorerfeatures significantly enhance the workshop



experience over the single user mode. Itparticularly eases the burden of data capture,allowing participants to input concepts themselves,rather than through the facilitator. Voting is alsomore versatile and effective than transcribingconcepts to flip charts and voting with sticky dotsQuestMapQuestMap was originally developed as gIBIS47, 48,

49 to provide asynchronous, distributed (i.e.different time, different place) groupware supportto groups using IBIS over a LAN. Increasingly,particularly with a focus on strategic problems,QuestMap has been used in face-to-face meetings.The key difference that distinguishes QuestMapfrom Decision Explorer is that it uses a hypertextsystem, rather than an array of view tabs displayedat the bottom of the screen. When discussion of aconcept expands, a new map is built off it as ahyperlink. Movement from one map to the next iseasily managed and reflects the full model'shierarchical structure. This allows maps to be builtthat are not restricted to the screen size, with theuser scrolling up or along the map. Managing themaps is more intuitive than in Decision Explorerand involves a shorter learning curve for the newuser. Decision Explorer, however, exploits the lessformal cognitive mapping rules to provide thesophisticated user with more power to manipulateand analyse the model. Naming views and placingtheir tabs in chronological order along theDecision Explorer screen gives participants a moretangible means of relating to the workshop model.

Since QuestMap's origins lie in the supportof distributed collaborative teams, workshopparticipants all have direct access to the full modeland functionality. The facilitator's machine has noadditional capability, beyond being the copy that isdisplayed to the group via the projector. As such,workshops normally only involve a singlemachine, perhaps operated by a second facilitatoracting as a technographer. This also removes theopportunity for electronic gathering of brainstormmaterial or voting, neither of which are suggestedby the Dialog Mapping methodology.

Mifflin76 is being developed to extendIBIS as a knowledge management tool that acts asa complete project repository or organisationalmemory76. The research is wide ranging andincludes interfacing IBIS maps with standardsoftware packages, exporting maps to webinterfaces and processes relating to distributed andasynchronous map building46, 62. Asynchronousweb-based gathers could be useful to precedecognitive mapping workshops. They could reduceworkshop time and costs, but potentially improve

the quality of contributions as participants aregiven a longer timeframe to reflect. It could be anefficient means for gathering the initial brainstormmaterial for facilitators working without access togroupware and using a single laptop computer.

CONCLUSIONS

SODA and Dialog Mapping, together with thecognitive mapping and IBIS techniques, havemuch in common. The social element of problemsolving is fundamental to both methodologies.They both involve building maps with problemsolving groups to tackle messy or wickedproblems. These maps are projected onto a publicscreen to act as a group memory aide and tosupport collaborative dialogue. They are used fordeveloping shared understanding and commitmentto a set of actions. They both involve the use of afacilitator and similar computer technology. Themap building techniques may differ, but there is atime in any workshop where the group developsfluency in any structuring notation and respondsintuitively to any map. Other distinctions,however, can affect the choice of approach toadopt more importantly.

Dialog Mapping is closer to the standardmeeting format and sessions can be brief andindeed spontaneous, perhaps using only a largewhiteboard. There is less process planninginvolved, principally because the process is soembedded within the technique. This places lessonus on the facilitator to develop expertise in itsuse, and indeed less overhead on planningworkshops. Learning the technique may also beeasier, employing short practice sessions withsmall groups on a whiteboard. The notation alsolends itself to representing fine-grained analysis ofa particular component or option within a problem,when the group needs less intervention from thefacilitator and more time to consider and discussthe issues amongst themselves. A facilitator usingSODA can find map building at these timesdifficult due to his dependence on the group toguide the content and structure. The drawbacks arethat there is less variety of activities within aDialog Mapping session, which reduces the lengthof time a group can stay motivated on a topic.Further, there is no wide ranging brainstormactivity to ensure breadth of coverage or to avoidgroup-think.

SODA requires workshops to be speciallyconvened, which are distinct from conventionaldaily meetings. Its adoption challenges theorganisational culture more as it appears moresubstantially different and risky. The workshopformat does, though, bring the advantages of



anonymity and voting, and the model can beanalysed by the software. The workshop processrelies less on the group self-regulating thediscussion and guarantees a quicker focus on thekey issues. Currently, there is a wider body ofliterature than for Dialog Mapping to provide theexpert user with more comprehensive processadvice. The UK practitioner will also find morefamiliarity with its use amongst the ORcommunity. The software and hardware support ishowever far costlier for a networked SODAworkshop, than for the single PC used in a DialogMapping meeting.

The author's are currently researching andtesting a hybrid process and tool support thatexploits the benefits found in both approaches. Itmarries the soft OR attention to problemdefinition, procedural rationality and process withthe design rationale focus on maintainability. Ituses cognitive mapping to open up and explore thedecision space to encourage divergent thinking ,negotiate objectives and identify key issues. It thenuses the IBIS notation to develop fine grainedanalysis around the identified key issues. The IBISmaps can be built as appropriate over time duringbrief meetings, with a technographer rather thannecessarily a facilitator. They are also more easilymaintained or updated as branches can be 'retired'simply by inspecting their root question, ratherthan looking at each individual concept and itsstoryline as is the case in cause maps.

Both cognitive mapping and IBIS offerpowerful tools to solving problems in today'sorganisations. They share many research interestsand would benefit from a greater awareness of oneanother's perspectives.

ACKNOWLEDGEMENTS

This papers stems from EPSRC-supported researchinto Decision Support for Systems Engineering,the Wisdom Project: EPSRC ref GR/M60361.Duncan Shaw provided valuable comments onearly drafts of the paper.

REFERENCES


1 Eden C (1988). Cognitive Mapping: a review. Eur J Oper Res 36: 1-132 Ackermann F, Cropper S and Eden C (1992) Getting Started with cognitive Mapping in 7th Young OR ConferenceTutorial Papers. Birmingham: O.R. society. Also available at http://www.banxia.com/depaper.html3 Ackoff RL (1979). The future of operational research is past. J Opl Res Soc 30: 93-1044 Conklin J (1996) The IBIS Manual: A Short Course in IBIS Methodology. Available athttp://www.gdss.com/wp/IBIS.htm5 Rittel HWJ and Webber MM (1973). Dilemmas in General Theory of Planning. Policy Sci 4: 155-696 Eden C and Ackermann F (2001). SODA – The Principles. In: Rosenhead J and Mingers J (eds). Rational Analysis fora Problematic World Revisited 2001. Wiley: Chichester 7 Conklin J (forthcoming). Dialog Mapping. Quoted on: http://cognexus.org/index.htm8 Conklin J (1996) Designing Organizational Memory: Preserving Intellectual Assets in a Knowledge Economy.Working paper, GDSS. Available at http://cognexus.org/dom.pdf9 Eden C (1992). A Framework for Thinking about GDSSs. Group Decision and Negotiation 1: 199-21810 Rittel HJ and Webber MM (1984). "Planning problems are wicked problems". In: Cross N (Ed.), Developments inDesign Methodology. Wiley, pp. 135-14411 Pidd M (1996). Tools for Thinking: Modelling in Management Science. John Wiley & Sons: Chichester12 Conklin J and Weil W (1996). Wicked Problems: Naming the Pain in Organisations. Working paper. Available at:http://www.gdss.com/index.html13 Conklin J (2001). Wicked Problems and Fragmentation. Working paper. Available at:http://cognexus.org/wpf/wickedproblems.pdf14 Conklin J (2001) Making Sense of Fragmentary Information. Working paper. Available athttp://www.cognexus.org/makingsense.pdf15 Eden C (1992) Strategy Development as a Social Process. Journal of Management studies 29 6: 799-81116 Tolman EC (1948). Cognitive maps in rats and men. Psychological Review 55: 189-20817 Fransella F and Bannister D (1977) A Manual for Repertory Grid Technique. London: Academic Press18 Bannister D and Fransella F (1986) Inquiring Man: The Psychology of Personal Constructs. Croom Helm, London 3rd

edition19 Kelly GA (1955) The Psychology of Personal Constructs. Volumes 1 and 2. Norton, New York20 Eden C (1989). Using Cognitive Mapping for Strategic Options Development and Analysis. In: Rosenhead J (ed).Rational Analysis for a Problematic World. Wiley: Chichester21 Eden C (1985) Perish the Thought!. J Opl Res Soc 36 9: 809-81922 Eden C (1992) On the Nature of Cognitive Maps. Journal of Management Studies. 29 (3): 261-26523 Eden CL and Ackermann F (1998). Making Strategy: The Journey of Strategic Management. London, SagePublications24 Eden C (1995) On Evaluating the Performance of 'wide-band' GDSS's. European Journal of Operational Research 81:302-31125 Eden C and Ackermann F (1996) "Hourses for Courses": A Stakeholder Approach to the Evaluation of GDSSs. GroupDecision and Negotiation 5: 501-51926 Eden C and Ackermann F (2001) Group Decision and Negotiation in Strategy Making. Group Decis Negot 10 (2):119-14027 Eden C (2000) Mapping Distinctive Competencies: a systemic approach. J Opl Res Soc 51 3: 291-30028 Eden C and Ackermann F (1992) Strategy Development and Implementation – the role of a Group Decision SupportSystem. In: Kinney S et al (eds) Computer Augmented Teamwork: A Guided Tour pp 325-343. Van Nostrand andReinhold, New York29 Eden C, Ackermann F and Cropper S (1992) The Analysis of Cause Maps. Journal of Management studies 29:3 pp309 - 32430 Eden C and Ackermann F (1998) Analysing and Comparing Idiograhic Causal Maps. In: Eden C and Spender JC (ed)Managerial and Organizational Cognition: theory, methods and research. Sage, pp 192 - 20931 Ackermann F and Eden C (2001) SODA – Journey Making and Mapping in Practice. In: Rosenhead J and Mingers J(eds). Rational Analysis for a Problematic World Revisited 2001. Wiley: Chichester.32 Bryson et al (1995) Using the Oval Mapping Process to Identify Strategic Issues and Formulate Effective Strategies.In: Bryson J (ed) Strategic Planning for Public and Nonprofit Organisations. San Francisco, Jossey-Bass pp 257 - 27533 Conklin J (1989) Design Rationale and Maintainability. Proceedings 22nd Hawaii International Conference on SystemsScience Vol 2 pp 533 – 539. Los Alamitos IEEE Computer Soc Press34 Lee J and Lai KC (1991) What's in Design Rationale? Human-Computer Interaction Vol 6, 3&4 pp 251 - 28035 MacLean A et al (1991) Questions, Options and Criteria: Elements of Design Space Analysis. Human-ComputerInteraction Vol 6, 3 & 4 pp 201 - 25036 Potts C (1994) Supporting Software Design: Integrating Design Methods and Design Rationale. In: Design rationale:Concepts, Techniques, and Use. Moran TP and Carroll JM (Eds) Lawrence Erlbaum Associates: Hillsdale, NJ pp 295-32237 The QuestMapTM software is available from the Soft Bicycle Company Inc, Washington DChttp://www.softbicycle.com38 Lee J (1990) SIBYL: A Tool for Managing Group Decision Rationale. CSCW 90 Proceedings, Association forComputing Machinery, October pp 79-92

39 Monk SR, Pendaries JM, Durin B and Sommerville I (1995) Supporting Design Rationale for System Evolution. InProc 5th European Conference on Software Engineering pp 307 - 323, Springer40 Klein M Capturing (1993) Design rationale in Concurrent Engineering teams, IEEE Computer January41 Rittel HJ and Kunz W (1970). Issues as elements of information systems. Working paper 131, Institute of Urban andRegional Development, University of California at Berkeley. Available at http://www-iurd.ced.berkeley.edu/pub/WP-131.pdf42 Conklin J et al (1998) Towards an Ecological Theory of Sustainable Knowledge Networks. Working paper availableat http://www.gdss.com/wp/ecology.html43 Conklin J (1993) Capturing Organizational Memory. In D Coleman (Ed) Proceedings of Groupware'92 pp 133 – 137,San Francisco, Morgan Kaufmann. Available at http://www.gdss.com/wp/COM.htm44 Conklin J (1996) The Age of Design. Working paper. Available at http://cognexus.org/ageofdesign.pdf45 Conklin J (2001) The Dialog Mapping Experience – A Story. Working paper. Available athttp://cognexus.org/dmepaper.htm46 Conklin et al (2001) Facilitated Hypertext for Collective sensemaking: 15 Years on from gIBIS. Hypertext'o1conference. Aarhus Denmark August 14 – 18 2001. Available at http://cognexus.org/conklin-HT01.pdf47 Conklin J & Begeman ML (1988) gIBIS: A Hypertext Tool for Exploratory Policy Discussion. ACM Transactions onOffice Information Systems, Vol 6, No 4 October, pp 303-33148 Conklin J and Begeman (1989) gIBIS : A Tool for all Reasons. Journal of the American Society for Informationscience, 40 pp 200 - 21349 Conklin J & Burgess Yakemovic KC (1991) Human-Computer Interaction Vol 6, pp 357-39150 Toulmin S (1958). The Uses of Argument: Cambridge University Press: Cambridge.51 Moran TP and Carroll JM (1991) Introduction to This Special Issue on Design Rationale. Human-ComputerInteraction Vol 6, 3 & 4: 197 - 20052 Moran TP and Carroll JM (eds) (1996) Design Rationale Concepts, Techniques, and Use. Lawrence ErlbaumAssociates, Mahwah, New Jersey53 Buckingham Shum S (1996) Design Argumentation as Design Rationale. The Encyclopaedia of Computer Scienceand Technology, Marcel Dekker Inc NY Vol 35 Supp 20 pp 95-12854 Buckingham Shum S Hammond N (1994) Argumentation-Based Design Rationale: What Use at What Cost?International Journal of Human-Computer Studies, 40 (4) pp 603 - 652. Also available athttp://kmi.open.ac.uk/sbs/DR.html55 Buckingham Shum S (1996) Analysing the Usability of a Design Rationale Notation. In: Design rationale: Concepts,Techniques, and Use. Moran TP and Carroll JM (Eds) Lawrence Erlbaum Associates: Hillsdale, NJ pp 185-21556 Buckingham Shum S et al (1997) Graphical Argumentation and Design Cognition. Human-Computer Interaction, 12(3) pp267-300. Also available at http://kmi.open.ac.uk/sbs/DR.html57 Eden C (1990) The Unfolding Nature of Group Decision Support – two dimensions of skill. In: Eden C and RadforddJ (Eds) Tackling Strategic Problems: the role of group decision support. Sage, London58 Compendium Institute at http://www.compendiuminstitute.org/library/papers.htm59 Selvin, A. and Sierhuis, M. Case Studies of Project Compendium in Different Organizations. In Workshop onComputer-Supported Collaborative Argumentation, Conference on Computer-Supported Collaborative Learning,Stanford, CA (12-15 Dec., 1999), 1999. Available at http://d3e.open.ac.uk/cscl99/Selvin-CaseStudies/Selvin-CaseStudies-paper.html60 Morton A, Ackermann F and Belton V (2001) Technology-driven and Model-driven approaches to Group DecisionSupport: focus, research philosophy and key concepts. Research paper No 2001/1 Management science, StrathclydeBusiness School. Available at http://www.mansci.strath.ac.uk/papers.htm61 Selvin AM and Buckingham Shum SJ (2000) Rapid Knowledge Construction: A Case Study in CorporateContingency Planning Using Collaborative Hypermedia. In: Proc KMaC 2000: Knowledge Management Beyond theHype. Operations Research Society, Birmingham, UK 16-19 July 2000 pp 48-58. Also available athttp://kmi.open.ac.uk/publications/papers/kmi-tr-92.pdf62 Selvin A et al (2001) Compendium: Making Meetings into Knowledge Events. Knowledge Technologies 2001 March4-7 2001 Austin Texas . Available at http://www.kmi.open.ac.uk/tr/papers/kmi-tr-103.pdf63 Buckingham Shum S (2000) Structuring Discourse for Collective Interpretation. Distributed Collective Practices2000: Conference on Collective Cognition and Memory Practices. Paris 19-20 Sept 2000. Also available atwww.limis.fr/WkG/PCD200064 Checkland P and Scholes J (1990) Soft Systems Methodology in Action. Chichester: John Wiley & Sons65 Checkland P (2000) Soft Systems Methodology: A Thirty Year Retrospective. Systems Research and BehaviouralScience Special Issue 17 pp S11 – S5866 Simon HA (1976). From substantive to procedural rationality. In: Simon HA (1982), Models of bounded rationalityVolume II: Behavioural, Economic and Business Organisation. MIT Press: Cambridge, MA, pp 424-44367 Shaw D (2001). Exploring what happens in a JOURNEY Making gathering – Using group communication software tosupport brainstorm-type activities. PhD thesis, University of Strathclyde68 Shaw D, Ackermann F and Eden E (2001). Sharing Ideas in Groups - A Research Report On Electronic GroupBrainstorming For Real-World Workshops. Working Paper: RP01113 Aston Business School, UK. Available athttp://research.abs.aston.ac.uk/wpaper/0113.pdf69 Janis IL (1982). Groupthink. Houghton Mifflen Company, Boston.

70 Friend JK and Hickling A (1997) Planning Under Pressure: the Strategic Choice Approach. Butterworth-Heineman,Oxford.71 Robinson M (1991) Double-level languages and co-operative working. AI and Society, 5:34-6072 Ackermann F and Eden C (1994) Issues in Computer and non-computer supported GDSSs. Decision Support Systems12 381 - 39073 Ackermann F and Eden C (2001) Contrasting Single User and Networked Group Decision Support Systems forStrategy Making. Group Decision and Negotiation 10: 47 - 6674 The Decision Explorer software is available from Banxia Software Ltd. http://www.banxia.com75 The Group Explorer software is available from Phrontis Ltd. http://www.phrontis.com/76 The Mifflin software is available from Compendium Institute. http://www.compendiuminstitute.org/tools/mifflin.htm77 Ackermann F (1996) Participant's Perceptions on the Role of Facilitators Using Group Decision Support Systems.Group Decision and Negotiation 5: 93-11278 Banxia Software Ltd (1997) Decision Explorer's User Guide. . Banxia Software Ltd, Glasgow, UK Available athttp://www.banxiausa.com/dexplore/pdf/DEGuide.pdf79 Banxia Software Ltd (1997) Decision Explorer Reference Manual. Banxia Software Ltd, Glasgow, UK80 Brightman J (1999) An Introduction to Decision Explorer. Banxia Software Ltd, Glasgow, UK. Available athttp://www.banxia.com/dexplore/pdf/DEIntro1.pdf81 Eric Armstrong correspondence on unrev-II email discussion list RE: Visual Stimuli & IBIS Methodology (15November 2001) available at http://www.onelist.com/community/unrev-II

Documents

Problem Solving Dialogue: Cognitive Mapping And IBIS · Problem Solving Dialogue: Cognitive Mapping And IBIS ... PROBLEM SOLVING DIALOGUE: COGNITIVE MAPPING AND IBIS ... to compare