Introduction

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 
136 137 138 139 140 141 142 143 144 145 146 

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

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.