Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Narayanan V.K., Armstrong D.J. - Causal Mapping for Research in Information Technology (2005)(en)

.pdf
Скачиваний:
76
Добавлен:
28.10.2013
Размер:
5.82 Mб
Скачать

260 Larsen and Niederman

Appendix C (Continued)

Documentation consistency

Specifying outcomes

Documentation detail

Staff communication between project phases

Documentation method

Staff knowledge and skill

Documentation process description

Staff preferences

Documentation quality

Staff skills

Documentation utility

Staff turnover

Early involvement

Staffing

Early testing

Staffing turnover

Enterprise-level requirements process details

Standardization

ER (data) model

Standardized platform approach

ER diagrams

Standardized use

Faith and trust

Standards

Focus on overview

Success measures

Formal information requirements

Task accounting

Functional area

Task complexity

Guideline design/process

Team size

Hardware capacity

Technology diversity

Hardware/software capacity

Testing/quality assurance

Hierarchy chart

Time, money

Hiring

Tool investment

Ideal documentation approach

Tool platform selection

Implementation issues with ER versus OO

Tool use

Implementation of modeling

Tools

Individual expertise and contribution

Tools description

Individual performance

Training

Information requirements documents

Training methods

IT staff skill levels

UML

Java provides some CASE tool functionality

UML use

Java, OO approach

UML/CASE tools

Leadership

Uncertain situations

Learning / Improvement

Universal development approach

Level at which business process documentation

Use

occurs

 

Linkage of requirements to technical models

Use case

Management mandate

Use of OO

Manual approach

Use of packages

Master scheduling

Use of UML

Matrix organization

Use/non-use of UML

Measurement

User characteristics

Meeting all requirements

User contract

Mentors

User expectations

Metrics

User involvement

Modeling

User liaison

Modeling formality

User satisfaction

Modeling thoroughness

User signoff

Modular training

User survey

Multinational staffing

User type

Narrowed features/simplification

Value of CASE tools, difficult to measure

Need for developer – user communication

Vendor experience

Non-OO design

Vendor selection

Object /class diagrams

Vendor staff turnover

Object diagrams

Visual representation

Object-ERD

Visualization of screens and outputs

On-line CASE tools

Word document

OO

Work expectations

OO Approach

----------------------

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Adoption of UML 261

Appendix D: Concept List for

Dependent Variables (Effect)

Ability to model system

Project cost

Ability to provide documentation

Project difficulty

Ability to provide modeling

Project management organization

Adoption of UML practices

Project management quality

Amount of risk

Project management success

Application success

Project organization

Change management

Project outcomes

Client satisfaction

Project process success (ease/flow)

Client satisfaction

Project quality

Communication requirements

Project success

Communication with users

Prototyping

Component oriented production environment

Quality assurance

Cost

Quality of documentation

Design quality

Quality of information requirements document/

Detailed user requirements

Quality of packaged processes

Developer satisfaction

Quality of tool use

Developer skills

Quality of use of OO

Developer team communication

Quick view

Developer-user communication

Requirements documents

Development guidelines

Reuse

Development model

Role of analysts

Development outcome

Role specialization

Deviation from standards

Satisfaction measure -- questionnaire

Documentation

Scalability

Documentation outcomes

Scope definition

Documentation quality

Scope problems

Documentation success

Sense of closure

Documentation utility

Skill development

Documenting business issues/decisions

Skills

Ease of data retrieval for user

Staff mentoring

Ease of learning OO

Staff skills

Economic value

Staff skills and knowledge

Effective tool use

Staff training

Effort on documentation

Staffing alternatives

Enhance knowledge base for project work

Standardization

ER use

Standardized platform approach

Extra overhead

Standardized use

Formality of documentation

State chart diagram

Formality of modeling

State transition diagrams

Generating user feedback

Subset of CASE tools

Information requirements success

Success measure – fulfill all contracted

 

requirements

In-house use of CASE tool

Sufficient modeling

Insurance against personnel loss

System consistency

Integrating data and process views

System use

Integration of development environments

Technology diversity

Internal versus external staffing

Technology diversity

IT role

Tendency to use OO/UML

Learning curve

Testing effectiveness

Maintenance

Thorough modeling

Model use

Tool use

Modeling formality

Training

Narrowed features/Simplification

Turnover

Need for analysis and documentation

UML use

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

262 Larsen and Niederman

Appendix D (Continued)

Need for requirements documentation

UML use (sequence diagrams and use case

 

diagrams)

Need for specific tool

Use case

Obligation satisfied

Use levels of ER

On-line CASE tools

Use of DFD and ER

OO

Use of modeling

OO project management

Use of OO approach

OO skill development

Use of sequence diagrams

OO skills

Use of use case

OO success

Used for development

OO tool use

Used for testing

OO use

Usefulness of models

Package customization

User participation

Package stability

User requirements writing

Pattern of modeling content

User satisfaction

Performance

User understanding

Pressure for IT personnel to perform

Version control

Problem understanding

Visualization of documentation

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Using Causal Mapping to Support Information Systems Development 263

Chapter XI

Using Causal Mapping to Support Information Systems Development:

Some Considerations

Fran Ackermann

Strathclyde Business School, UK

Colin Eden

Strathclyde Business School, UK

Abstract

Identifying what different stakeholders in a business need from Information Systems development has always been seen as problematic. There are numerous cases of failure as projects run over time, over budget, and, most significantly, do not meet the needs of the user population. Whilst having a structured design process can go some way towards reducing the potential of failure, these methodologies do not attend sufficiently to clarifying and agreeing objectives or to considering the social and cultural elements inherent in the ownership and adoption of any new system. Instigating an effective, and structured, dialogue between users, developers and, when appropriate, sponsors, is therefore a critical consideration. Linking user needs, as they see them, to the language of IS developers and vice versa is crucial. Both parties need ownership. This chapter focuses upon the use of causal mapping, supported where appropriate by special software, that facilitates the development of a shared understanding (of both business needs and IT opportunities) and through this common platform enables a negotiated and agreed outcome. The nature of the outcome invites translation to structured design processes.

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

264 Ackermann & Eden

Introduction

Although Information Systems (IS) are able to provide considerable benefits to organizations, there have been an extensive number of failures. For example, in 1999 the Financial Times noted that 50% of systems projects fail to meet their expected rate of return. A later, more spectacular, example is the system developed by ICL for UK Post Office counters a system which went massively over budget and was never completed in line with the original specification (Financial Times, 22 July 1999). Explanations for these problems abound and range from poor communication with users and customers, not learning from past experiences, over-ambitious rates on returns, unexpected demand levels, amongst others (Boddy, Boonstra & Kennedy, 2002).

The use of structured approaches such as Structured Systems Analysis and Design Method (SSADM) (Downs, Clare & Coe, 1988), Information Engineering (Martin, 1986) and other such methodologies were touted as aiding the development of the systems through providing careful, logical procedures to follow. However, experience showed that they still fell short in terms of supporting the process of IS development, as they lacked understanding of the boundaries and properties of the systems starting well down the development process. More recent approaches such as prototyping, and Rapid Application Development (Martin, 1991), which were developed to answer some of the difficulties, are still unable to provide what is required. For example, no aid is provided by these techniques for managing differing, and possibly conflicting, objectives of users, or addressing the organization’s social and cultural norms of behaviour. Defining requirements is often regarded as a simple process, or one that can be determined by the Information Systems (IS) staff. As argued by Jayaratna (1994) and Stowell (1995), what is needed is a deeper understanding of the nature of organizations and how the system interacts with the organization

Orlikowski, Walsham, Jones and DeGross (1995) found that even when systems are developed with consideration of the organization’s working practices there are problems as appropriation of systems can often be diverted from original intention as user needs change and are refined over time and use. However, they suggest that this is likely to be particularly the case if and when business practices and their socially construed norms are not well understood. Acknowledging the need to attend to the social and ethical considerations, however, is not new, as noted in Enid Mumford’s work (1983) and, as Zuboff comments, IS “ultimately reconfigures the nature of work and the social relationships that organize productive activity,” (1988) further reinforcing the need.

Therefore, methods and techniques for facilitating dialogue between users, developers and, when appropriate, sponsors is important. Soft Systems Methodology (SSM) a problem structuring methodology has seen some success in this area (Checkland & Scholes, 1990). As its name suggests, SSM pays particular attention to the “soft” or social issues. The approach recognises that in most situations there is a lack of clarity regarding the objectives of the system in question and that these issues often comprise many aspects and subtleties which make working with the apparently messy IS design situation problematic. Providing some means of surfacing and structuring existing concerns is achieved through the formalism of what is called a “rich picture”a cartoonlike picture that depicts the aspirations and situations of stakeholders of the system

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Using Causal Mapping to Support Information Systems Development 265

being considered. The process explicitly allows for the social elements to be revealed along with consideration of possible different interpretations of the system (different conceptual models) and so enables an effective dialogue to take place. The process is expected to result in the agreement of an owned outcome.

Another problem structuring method, which is gaining popularity, is the use of causal mapping. There are an increasing number of papers detailing management research and problem solving practices that have effectively applied mapping. These applications appear in a range of research arenas including IS (see Nelson, Nadkarni, Narayanan & Ghods, 2000; Boland, Tenkasi & Te’eni, 1994; Zmud , Anthony & Stair, 1993). Mapping’s ability to surface and structure individual theories of the world with their associated detail not only allows the individuals themselves to understand their thinking better but also provides a rich basis upon which to enable the different stakeholders in the group to negotiate a shared understanding and make agreements.

In this chapter we begin by reviewing the background and features of our particular form of mapping before exploring its use in a real-world example, considering what that experience suggests about the requirements of successful IS design, and then finally making some concluding remarks.

Causal Mapping

As is also evident elsewhere in this book, not only are there a number of different ways that causal mapping can support Information Systems, but there are different forms of Causal Mapping. The particular version considered in this chapter is based upon the work of a cognitive psychologist George Kelly (1955) whose propositions about how individuals make sense of their world resulted in a powerful body of theory known as personal construct theory (PCT). From this body of theory Kelly developed an instrument: Repertory Grids (Fransella & Bannister, 1977; Bonarius, Holland & Rosenburg, 1981) which has been used in IS research (Hunter & Beck, 2000; Tan & Hunter, 2002). In addition, and, more pertinently for this chapter, cognitive mapping was developed to reflect more depth and greater appreciation of individuality than that which was offered by repertory grids (Brown, 1992; Eden, 1988). However, as many organizational tasks require the involvement of a number of participants, a range of different forms of group mapping have been developed (Ackermann & Eden, 2001; Eden & Ackermann, 1998) to extend the use of causal mapping that is founded in personal construct theory. These different forms include:

The “Oval Mapping Technique” a manual, rather than computer-assisted, process. Individuals are provided with oval shaped cards (about 11x19cms, or large rectangular post-its) and identical pens (to help increase anonymity). They are asked to write down any concerns, aspirations, issues or assumptions that come to mind. Each contribution is written on a separate oval card. These ovals are posted up on a flipchart paper-covered wall, enabling others to read and “piggyback” off them. During this process of generating a scatter picture of the important aspects of the situation under consideration, a facilitator works at clustering the material into themes so as to manage the large amount of material.

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

266 Ackermann & Eden

It is not untypical to have 200+ contributions surfaced from a group of eight by the end of a two-hour session. Once the rate of contributions has slowed down or stopped, the group, with the help of the facilitator, works through each cluster exploring how the content of the different statements causally influence one another, both within and across clusters. This process inevitably surfaces further views as different chains of causality are presented and captured. The result is a structured causal map. The map represents not only the different themes/clusters but also their degree of interaction with one another. The process invariably enables the participants to move from an often very divergent view of the situation to a more convergent one.

The second form of group mapping involves the use of a mapping software package Decision Explorer1 to capture and structure the material. Instead of having participants write down their contributions, the facilitator captures the contributions as they are stated in facilitated discussion, thus in real time. The facilitator regularly checks with participants that views have been captured correctly, and explores their relationships with other already captured statements. This enables participants to concentrate on the discussion using the developing map as an aide mémoire. As a result of working electronically the group can interactively “play” with the captured material exploring, for example, the consequences of different options, examining possible alternatives, and agreeing objectives/goals (end points of the causal chains). In doing so they are always aware of the causal ramifications of their developing agreements. In addition, rapid searches can be carried out for statements focusing on a particular topic, as well as a range of analyses used to enable exploration of the structure of the map. Analysis results, such as the identification of “central” statements that influence and are influenced by many others, of “potent options” that can affect many goals, and of significant outcomes or goals, subsequently can be colour coded and categorised. Finally by having a number of views available (similar to spreadsheet packages where there can be a number of sheets) of different aspects, managing the complexity of the large body of material surfaced becomes easier.

The third and final form has participants provided with laptops connected together through a local area network, and connected through Decision Explorer to a public screen — the combined system is run through the software Group Explorer2. This allows participants to directly enter their contributions (both statements and relationships) into the map developing on the public screen as soon as they think of them. This allows for total anonymity and reduces the pressure on the facilitator to capture the material. In addition, this mode of working provides other useful features such as the ability for each participant to rate the importance of statements on a scale or to prioritise them. For example, through using the “preferencing system” participants are able to demonstrate anonymously which of the options they will support and which they will not, providing a reality check on the proposed way forward. Alternatively, participants can use the rating tool, which allows them to explore which of the various options might provide best support for an objective and whether there is any consensus about this.

Each of these has been applied to a range of different decision making areas (see Ackermann & Eden, 2004) including problem structuring (Eden & Ackermann, 2001), strategy development (Eden & Ackermann, 1998) and the modelling of disruptions and delays occurring on large engineering projects (Ackermann et al., 1997).

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Using Causal Mapping to Support Information Systems Development 267

In each of these processes the technique of causal mapping provides the means of developing a graphical representation of an individual’s or group’s perception of issues by building up chains of argumentation. Therefore, statements/nodes (facts, assertions, options, issues, goals, etc.) are captured along with their relationships where the arrow (relationship) implies causality. In Figure 1, the individual is discussing the use (or not) of a financial information system. Node 13 and 7 are both assertions resulting in the perceived consequences of 9 and 6. This is a small causal map frequently individual maps comprise 80+ statements and group maps in excess of 400 statements.

Furthermore, the analysis of the structure of the causal map can reveal patterns. For example, busy points typically suggest key issues, superordinate statements (those at the top of the chains of arguments) imply values or goals, and feedback loops imply potential dynamic behaviour. In Figure 1, node 17 has a considerable amount of material supporting it some of which is shown in detail, e.g., nodes 15, 18, 20 and some of which is currently hidden (nodes 27, 25, 23), suggesting that it is likely to be a key issue. Node 8 is displayed as a goal this was something that the individual felt was good in its own right. Finally on the left of the figure is a feedback loop (comprising nodes 17, 19 & 20)

in this case operating as a vicious cycle (a self-sustaining negative situation). In this way the user is able to examine both the whole (in terms of emergent properties of its structure) and the detail to help develop a fuller understanding of the interaction of different considerations, and so make a more informed decision.

The map enables a better understanding to be developed as statements are explored alongside their context. Adhering to the formal coding guidelines (see Appendix A) is necessary for the analysis of emergent properties of the map to be reliable, but it also provides a powerful aid to group thinking. For example, the guideline asking that each

Figure 1. An example map

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

268 Ackermann & Eden

statement be worded in an action-orientated form encourages those developing the maps to be clearer about what might be done and why that would be expressed by an assertion. Attending to the direction of causality between two statements prompts consideration of what is the means and what is the desired end or outcome of two action-oriented statements, often revealing underlying values.

Although mapping can help individuals better understand their world, when considering Information Systems design it is mapping’s ability to support group negotiation that is of most interest here. Capturing the views of those participating, along with the full context of their views as chains of argument means individuals are better able to determine what they are concerned about and what they want regarding the system within the context of the opinions of others. Through this extended picture, a greater understanding of meaning is elicited (through the context) and thus an appreciation of the rationale for particular views. Moreover capturing all of the contributions provides participants with a sense that the process is “just” (Kim & Mauborgne, 1991). From this often quite extensive map3, a shared understanding begins to emerge. One objective is for those involved to begin to understand, in use, what is meant by very general descriptions of the proposed system (Checkland & Holwell, 1998).

Using Mapping to Develop an

Information System

As intimated above, developing a clear and shared understanding of the purpose of the system by all who have some stake in its development and use is important for ensuring that the system is used and used within appropriate bounds. Information is always given meaning by its context, and often IS’s are designed with a presumption of context. A good understanding can only be derived from a clear knowledge of purpose and the limits to its application.

Understanding who the stakeholders might be, who will give the information meaning and in what way might they be involved (or effect the usage of the system) is critical. Stakeholder analysis and management techniques such as those described in Boddy, Boonstra and Kennedy (2002) or Ackermann and Eden (2003) provide a good starting point.

Ackermann & Eden employ particular forms of mapping to determine not only who the stakeholders are, but also the details regarding their disposition, relationships with others, and the nature of the power and interest they may use to influence the success or otherwise of the information system. By building a grid whose axes are power and interest, participants are able to position stakeholders according to their relative power to influence success (as determined by the purpose of the IS) and interest in usage. The grid usefully shows those who have both the interest and power to ensure success or failure, and so attention to their views regarding the development of the IS will be crucial. A better understanding of these stakeholders can be elicited by exploring in more depth the bases of power and the nature of interest. Those who have power and no interest in the outcome can easily determine failure (intentionally and unintentionally) and so must be carefully managed. Mapping the influence network among these powerful stakehold-

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.

Using Causal Mapping to Support Information Systems Development 269

ers provides important clues as to which of them can be used as opinion formers increasing the chances of success. Analysis of these maps follows the same conventions as those used to analyse causal maps.

By facilitating not only the means of contributing effectively to these deliberations, but also structuring the contributions to enable effective management of the unfolding complexity (rather than reducing it), sufficient and productive time can be spent in the exploration stage. The purpose of the exploration is to consider in depth the emergent properties and develop agreed action packages. This ability through capturing the richness and diversity of views along with managing their structure represents the stages of Intelligence and Design, in what Simon (1959) describes in his four stages of decision making.

By describing a case study that employed mapping as a means of developing an IS, aspects of the process and some of the benefits of mapping will be illustrated and explored. As with most case studies in IS development, the material is sensitive, and so the material presented below is less expansive than preferred.

Developing an Information System for Student Tracking4

The organization discussed below is part of a large University. Rather unusually, it is a self-funded unit receiving no public monies. Therefore, it operates in many ways as a business with one of the main objectives being to not make a loss, and make enough surplus to reinvest in its educational products. At least, sufficient revenue is required so that the organization can pay staff, keep the estate in order, and provide its commitment to a high quality total service to students. The major contribution to finances is unsurprisingly student fees, although executive development programmes, amongst other activities, contribute. Currently the unit delivers its key products in many different locations (product offerings not only at home but in four countries in South East Asia, four in the Middle East, and two European countries).

One of the consequences of having such a widely dispersed programme (at any one time the school has around 2,000 students on its books) is that it is paramount that an effective and efficient information system is available to track enquiries, manage admissions, and monitor the progress of students. However as is often the case, an incremental growth in locations and student numbers along with a growing recognition of the power of information technology had resulted in an ad hoc approach to the development of information systems. Consequently, there were six different systems being used, involving a range of different programmes databases, spreadsheets, and word-processing packages. Getting data from one to another was problematic, frequent errors occurred and thus accurate and timely information was difficult to attain. A new system was required.

In order to ensure that the new system was as effective as possible, it was necessary to take into account views from staff with responsibilities for marketing, operations, academic delivery, and unit management along with those from the computer support

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.