Sequential Patterns in Information Systems Development: An ...

Sequential Patterns in Information Systems Development: An Application of a Social Process Model DANIEL ROBEY Georgia State University and MICHAEL

NEWMAN

University of Manchester and Vrije Universiteit, Amsterdam

trace the process of developingand implementinga materialsmanagementsystem in one company over a 15-year period. Using a process research model developed by Newman and

We

Robey, we identify 44 events in the process and define them as either encounters or episodes. Encounters are concentrated events, such as meetings and announcements, that separate episodes, which are events of longer duration. By examining the sequence of events over the 15 years of the case, we identify a pattern of repeated failure, followed by success. Our discussion centers on the value of detecting and displaying such patterns and the need for theoretical interpretation of recurring sequences of events. Five alternative theoretical perspectives, originally proposed by Kling, are used to interpret the sequential patterns identified by the model. We conclude that the form of the process model allows researchers who operate from different perspectives to enrich their understanding of the process of system development. Categories and Subject Descriptors: K.6. 1 [Management Systems]: Project and People Management

of Computing

and Information

General Terms: Human Factors, Management Additional

Key Words and Phrases: Social processes,

system implementation

1, INTRODUCTION Problems associated with the development and implementation of large, computer-based information systems (IS) have been a central interest of

The empirical research reported in this study was supported by grants from the Research Board of the Institute of Chartered Accountants of England and Wales and the Department of External AfTairs, Ottawa, Canada. Authors’ addresses: D. Robey, Department of Computer Information Systems, College of Business Administration, Georgia State University, P.0, Box 4015, Atlanta, GA 30302-4015; em ail: [email protected]; M. Newman, Department of Accounting and Finance, University of Manchester, Manchester M13 9PL, UK email: mike. [email protected]. Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tQ lista, requires prior specific permission and/or a fee. @ 1996 ACM 1046-8188/96/0100-0030 $03.50 ACM Transactions on Information Systems, Vol. 14, No. 1, January

1996,

Pages

30-63.

Information Systems Development

.

31

researchers for many years. Information system development (ISD) carries inherent risks, including the potential failure of the IS itself, expensive cost overruns, and time delays. Recent accounts of project failures, such as those at BART [Laudon and Laudon 1991] and Bank of America [Frantz 1988], illustrate the tremendous cost and low payoff of some major IS projects. These accounts motivate inquiry into the nature of LSD with the hope that increased understanding will help make ISD more effective and less frustrating for those involved in the process. Such inquiry is further motivated by recent claims that modern organizations have greater information-processing needs because of the pace at which the “post-industrial” environment changes [Huber 1984; Scott Morton 1991]. Environmental change places greater pressure on system developers to design systems that can be implemented more quickly and ef15ciently. In the postindustrial environment, systems will also require more-frequent modification as information requirements change more rapidly. With attendant pressures to reduce the costs of IS staff, the need for effective system development increases the importance of ISD as an area of study. Like other organizational innovations, an IS is the product of social action. In a recent paper, Hirschheim et al. [1991, p. 589] articulated the “social action perspective” on ISD as follows: From a social action perspective, ISD consists of coordinated sequences of human actions. Several groups interact during system development: analysts, primary users, management, technical specialists, etc. Their interactions are not random, but are governed by human intentions. Because the typical, large IS project involves many actors in complex technical choices over a long period of time, the prospect of smooth and efficient completion is often remote. Some actors occupy roles within the organization, whereas others are located outside the organization’s boundaries (e.g., vendors and consultants). Some actors perform very limited tasks, and others assume responsibility for managing the entire process. The entry and exit of actors make lengthy projects especially prone to the risks of failure. This article reports a case study of one firm engaged in the development and implementation of a major IS over a period of 15 years. The company’s experience revealed serious difficulties in coping with the social and technical demands of ISD, and severely adverse economic and individual consequences ensued. Ultimately the company reversed a pattern of repeated failure and implemented the system successfully. We examined the events in the case using a process model of user-analyst relations developed in a previous paper [Newman and Robey 1992]. This model facilitates the detection and display of the sequence of social interaction and draws attention to the social context within which analysts and users interact. Because our observations spanned 15 years, we could identify repeating sequences of actions and associate them with the failure and success of the project at various times. The purpose of our research is to demonstrate the value of using the process model to identify the recurring sequences of events that comprise the social process of ISD. The resulting “pictures of the process” can support a ACM Transactions on Information Systems, Vol. 14, No. 1. January 1996.

32

.

D. Robey and M. Newman

variety of theoretical interpretations. In our discussion of the case, we argue that five of Kling’s [1980] six theoretical perspectives on the social analysis of computing can be enriched by the analysis of processes provided by the model. Rather than favoring one of these interpretations over the others, our discussion emphasizes the value of process analysis in multiple interpretations.

2. INFORMATION

SYSTEM

DEVELOPMENT

AS A SOCIAL PROCESS

It has long been acknowledged that the successful implementation of information systems rests upon both social and technical influences [Curtis et al. 1988]. From an awareness of the social context for implementing techniques of operations research and management science [Churchman and Schainblatt 1965; Schultz and Ginzberg 1984] came an appreciation for the importance of the relationships between the developers and users of information systems [Lucas 1974; Swanson 1974]. Some contemporary methodologies for ISD, such as ETHICS [Mumford and MacDonald 1989] explicitly combine social and technical objectives and depend upon the participation of users in the development process. Considerable research has been conducted on user participation in ISD and the social context of IS implementation (see Swanson [1988] for a review). Although the interest in social influences during ISD remains high, few researchers have approached ISD directly as a process. More typically, researchers have adopted a “factors” approach [Franz and Robey 1987] relating predictor variables, such as user participation and top-management support, to outcome variables, such as implementation success. Studying a process directly requires that sequences of events be identified that lead to outcomes of interest. A process research model defines different types of events that occur over time, using these as the model’s basic theoretical constructs. One objective of process models is to explain why outcomes at the end of a sequence of events occur. Typically, process models specify antecedent conditions that exist prior to a sequence of events, describe the events in the process itself, and relate those events to outcomes. The events in a process model are operationalized by specifying rules for identifying and classifying actual incidents into different kinds of events [Van de Ven and Poole 1990]. Process models permit similarities among sequences of events to be measured, and topologies may be generated based on similar groupings [Abbott and Hrycak 1990; Sabherwal and Robey 1993]. Process models differ fundamentally from factor (or variance) models, which attempt to explain the variation in a dependent variable by studying its associations with one or more independent variables [Mohr 1982]. Process models may complement variance models by providing the recipe that links independent with dependent variables [Markus and Robey 1988]. However, Mohr [1982] cautions that the form of a process model is incompatible with that of a variance model, and the two should not be combined within a single research model. Mohr [ 1987] has championed the use of process models in ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996.


.

33

organizational research and has offered a fresh perspective on the adoption of microelectronics. The process model used in this research, drawn from Newman and Robey [ 1992], focuses specifically on events that involve interactions between IS analysts and IS users. Antecedent conditions represent the relationship between analysts and users prior to the start of a project. Newman and Robey identified four varieties of antecedent conditions: joint development, analystled development, user-led development, and equivocation (no stable relationship). Each is the culmination of the historical events that preceded the current project. The model predicts the continuation of established patterns unless critical encounters steer the course in a different direction. The ontological assumption underlying the model is that social processes are indeterminate, so specific predictions about the persistence and change in the pattern of social interaction are not offered. Where departures from established patterns do occur, however, the model suggests that critical encounters between users and analysts serve as the occasions that trigger such change. The model adopts the form of the punctuated equilibrium model of change [Gersick 1991; Van de Ven 1992]. It employs two types of events: episodes, which are relatively long periods of equilibrium; and encounters, which are shorter in duration and serve as punctuation between longer episodes. Encounters are opportunities to address prior performance, to express dissatisfaction, and to plan for meeting future needs. Encounters may be precipitated by external events, such as pressure from a parent company, the moves of a competitor, or the actions of a vendor. Some encounters may be designed into the process itself, such as the formal “signoffs” and “ walk-throughs” found in traditional ISD. Not all encounters between users and analysts are judged to be equally important, so the model focuees only on those that are critical to the trajectory of the project. Researchers using the model are required to make judgments about which events are critical and which are not. Although the rules for making such judgments should be specified as part of one’s research method, the use of rules does not remove the researcher’s need to interpret the meaning of events. Encounters are opportunities for actors to challenge established practices. If no such challenge occurs, the model predicts that the established relationship will continue and be reinforced and reproduced. For example, analyst-led projects may often be characterized by traditional design methods. Without encounters challenging such an approach we would predict their continuation. However, such a challenge could arise from users who resist the development process. Eventually, the users may come to dominate the process themselves, or there may be an equivocal stalemate in their relationship [IMarkus 1983; Newman and Robey 1992]. The periods between encounters are designated as one of the three types of episodes: acceptance of the claim made, rejection of the claim, or equivocation [Newman and Robey 1992]. Acceptance of the claim acknowledges the legitimacy of the other party’s proposal. By contrast, rejection of the claim by either party is likely to result in an episode characterized by a change in the ACM Transaction

on Information Systems, Vol. 14, No 1, January 1996.

34

.


relationship between the parties. In the third type of episode, equivocation, actors neither accept nor reject the claim but adopt a “wait-and-see” stance. Figure 1 uses hypothetical events to illustrate the mapping convention used in the model. Encounters are represented as points; episodes are represented by lines drawn between encounters. The vertical axis of Figure 1 consists of three areas or zones corresponding to the three types of episodes described. The character of an episode (acceptance, rejection, or equivocation) is designated by the zone into which the line moves. That is, the first episode shown, between encounters 1 and 2, is “rejection” because the line moves out of the acceptance zone and into the rejection zone. The apparent movement of this episode through the “equivocation” zone in Figure 1 has no significance and is an artifact of the graphic representation. The horizontal axis in Figure 1 represents temporal sequence, with events to the left occurring before events on the right. The horizontal scale does not represent calendar time. Encounters are positioned equidistantly along the horizontal dimension to indicate their sequence, not the date that they occurred. As Abbott and Hrycak [1990] note, occurrence of events in calendar time is potentially misleading and generally less relevant than the sequence of occurrence relative to other events. Figure 1, therefore, should not be read like a graph with two coordinates. It simply shows the sequence of the two types of events (encounters and episodes) and describes the nature of the episodes. 3. METHOD We employed the case study method in conjunction with the model described previously in order to examine the process of ISD. Case studies are widely used in IS research, comprising about 1370 of all research methods used, according to Orlikowski and Baroudi [199 1].1 Although case studies may be used for testing theory [Lee 1989; Yin 1984], case methods are most useful for gaining detailed knowledge about phenomena for which theoretical propositions are unavailable [Eisenhardt 1989]. The traditional advantages of case methods include rich description and an appreciation for the social context within which events occur. Case studies also pose limits for researchers. Usually cases cannot be compared easily, and the lack of experimental controls threatens internal validity and the strength of causal arguments drawn from the data. It is also difficult to generalize findings from one case to a population of organizations, as one could with a larger sample. These limitations can be partially overcome by applying case methods over longer periods of time. Longer studies allow some degree of quasi-experimental control [Campbell and Stanley 1963]. As observations are taken over time, naturally occurring “treatments” may be identified and associated with subsequent events. In a short case study, it is more dificult to detect such

1Orlikowskiand Baroudi11991]notedthat researchon IS designand use comprisedabout77% of all IS researchsampled.They did not cross-classifymethodwith researchtopic,so we can only speculatethat case studiesare well representedin researchon IS design and use. ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996.

Time Acceptance

Antecedent conditions:

cn2

en 1 ~P I

No significant pattern of development

Equivocation

@

Analyst - led development

~P~

LJser-led development

Rejection

Joint development

●

en5

I

Legend: —

e@

encounter (en) episode (ep )

u

(D < Q

o Fig.

1.

Mapp]ng

e\,ents

inasocial

process

(hyp{)thctical

example)

[Ncwn)i~n:~nd

R{,hy 1992].

: 3

(J

m

36

.


significant events. Longer studies in a single organization are better for distinguishing significant events from ordinary ones. The case research method is appropriate for studying the ISD process because it enables the identification of sequences of events and the classification and interpretation of those events. This research employed case research methodology to create a narrative account of events that took place between the years 1975 and 1990 in one division of a major corporation attempting to implement a major materials management system. The corporation is given the pseudonym Centco in this article, and the division implementing the system is called the Supply Division. One of the authors conducted three intensive waves of nondirective interviews with members of Centco who were involved in the development of the system. Interviews were conducted onsite in 1978, 1986, and 1990, The method is limited in that informants’ reports are at least partially retrospective. However, at each site visit, informants were asked to discuss both current and past events, thereby producing a concurrent and reconstructed account of the key events over the entire 15-year period. This method of data collection involves the reconstruction of event histories [Glick et al. 1990]. From all three visits, over 300 transcribed pages were generated from interviews with 12 respondents. Interviews were supplemented by direct observations and written documents such as annual reports, memoranda, and organizational and project charges provided by the informants. For example, the chairman’s statements from the annual reports were examined for the years 1978 to 1989 to confirm interview reports about trends in the competitive environment faced by Centco. Data gathering was decoupled from the analysis. One of the authors gathered the data, produced the transcripts, and wrote out a narrative description of the case. In 1990, a 37-page summary was given to one of the principal informants, who confirmed the researcher’s account except for some minor historical details. His suggestions were incorporated into the case where appropriate, without prejudicing comments from other informants. Both authors then identified the two types of events defined in the process model: encounters and episodes. The authors produced the list of events together and did not attempt to establish interrater reliability by producing event lists independently and checking agreement. Encounters were defined as events of short duration, such as a meeting or the announcement of a decision, Episodes were defined as events of longer duration, during which the relationships between users and analysts remained stable. All events pertained to the context of user-analyst relations because we were mainly interested in this social relationship and how it affected ISD. Once encounters and episodes were defined, we mapped them onto the general form of process model presented in Figure 1. The method required us to exercise a number of subjective judgments, as guided by the specific definitions for the two types of events. Because episodes are defined as the periods of relative equilibrium between encounters, their occurrence was determined once the encounters were specified. It was somewhat more difficult to characterize episodes as acceptance, rejection, and equivocation. VJe felt that the case’s data were rich enough to support such ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996


.

37

distinctions, although all such judgments are ultimately subjective. By including verbatim excerpts from interviews in our Results section, we share some of the evidence for our choices with the reader. We also judged many events to be inconsequential, and these were not included. 4. RESULTS The results are presented in the following manner. First, we give a general description of the case site and the problems it faced. Then we describe the history of systems development activities and the specific conditions antecedent to the events in the case. The events are then presented in the format of the process model previously described. Events are divided into four periods for ease of analysis. 4.1 Centco and Its Supply Function Centco is a subsidiary of a US-based conglomerate, herein called GenComm. In 1990, Centco employed 14,000 people in several geographically dispersed locations in North America. Centco’s total revenue for 1989/90 was $1.6 billion, on which it earned $118 million in profits. Centco’s Supply Division was responsible for centralized purchasing, inventory control, warehousing, and distribution from two large central warehouses. Supply’s repair facility serviced all kinds of equipment and manufactured some parts. Supply also operated a department responsible for acquiring and maintaining vehicles for the company’s local needs. Supply’s building maintenance department was responsible for the maintenance and operation of all heating, ventilation, and air-conditioning equipment. Supply was headed in 1990 by a vice president, Roger,* who reported directly to Centco’s president of operations, who in turn reported to Centco’s chairman and chief executive, Graham. Graham was responsible for the Centco group of companies, made up of the traditional operating company, two manufacturing branches, an international installation company, and an international marketing branch. Centco operated within an industry that underwent deregulation throughout the 1980s. People at Centco were aware of the threat from greater competition, but they were not clear how the company would respond. The pressures to contain costs confirmed the need for more sophisticated IS management, especially in the materials management area. As of 1990, the Supply Division purchased between $300 and $400 million of inventory per year and held approximately $70 million of equipment and materials in stock. The pervasive management orientation at Centco was either engineering or finance. Executives with this orientation viewed the Supply Department as a staff group through which engineering people were rotated in order to round out their backgrounds and to prepare them for higher management positions. Historically, materials and inventory management at Centco suffered from gross inefficiencies and waste. Before 1975, no attempt to build information

~All names used are fictitious ACM Transactions on Information Systems, Vol. 14, No 1, January 1996.

38

.


systems to control inventory costs had been successful. The project leader for MIS (James) analyzed the procedures and practices in the late 1970s and described the extreme anomalies: You always find in a large company that the amount of material on hand is inversely proportional to the need, until you’ve got a decent system going. We have things like [names equipment] which we need frantically all the time. We have about a 10-minute supply based on the last four years of usage. We calculate to five decimal places on the computer. Of things we don’t need, we have up to, the top-ranker at the moment, is 14,500 years. inventory meant excess carrying charges, estimated to be at least $6.5 million per annum. One cause of excess inventory was insufficient and inaccurate data in the manual system. For example, acquiring materials for a particular work order required sending out a purchase order for all its requirements at one time. This meant that some of the material was brought in too early. Because it was physically available, that material was often used for other work orders or emergency maintenance requirements. This practice caused the materials not to be available when required for the original order. Back orders were often placed unnecessarily because no one knew about inventory that was actually in stock. Part of the problem was lack of space in Supply’s facility. So material was stored elsewhere as new space became available, leading to a situation where the same material was stored in multiple locations. The poor information permitted some bizarre financial practices to flourish, which James revealed:

Excess

Under the rules of the company, the President is allowed to sign checks of $25,000 at the most without going to the board or without giving cosign or something. There are fellows there in inventory that are writing off in excess of a million dollars in a day of material. It eventually has to go through the books; it’s the asset of the company. But you can’t just happily write on and off a million dollars a day because you feel like it.

4.2 Systems

Development at Centco

Information systems at Centco had traditionally been developed for Supply by Management Information Services (MIS). Responding to ad hoc requests, MIS had built several isolated systems spread over three hardware platforms: IBM, DEC, and Datapoint. In 1974, Ira moved to Supply from MIS as part of a natural job progression. Ira had been instrumental in developing some of the systems in use, and he arrived at Supply to help implement a new catalogue system and a new purchase order system. At the end of his first year in Supply, it was clear to Ira that Supply had a “mish-mash” of eight or nine systems that had been implemented with no overall plan in mind. Several of these systems were quite large and represented high costs of development and operation. At Centco there were deep misgivings concerning the ability of the company, and the Supply Department in particular, to adopt a state-of-the-art Materials Management System (MMS). Aa James reported: There are a hell of a lot of people who have been here from school and never been anywhere

else, so whatever

they’ve seen is mainly

ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996

from this company

Information Systems Development virtually;]

but they’re

but terribly outdated doing.

all the same.

Oh yeah,

in management

they’re

techniques

all experienced

.

39

engineers

and this type of thing we’re

4.3 Antecedent Conditions

In late 1975, after conferring with MIS, Supply’s management brought in Sysco Consulting and its principal, DuBose, to look at the Supply operation. DuBose conducted a study and produced recommendations for both future systems development and new organizational structures. These were included in a report, coauthored with Ira, the one full-time representative from Centco’s Supply Department. The systems plan included 13 phases and was partially underway because DuBose had already been working with the MIS people to make Supply’s data more visible to the users. DuBose had been hired to provide the programming resources to put some of their database contents online. DuBose proposed to complete the remaining phases because Supply did not have enough staff in the data processing group. DuBose also proposed to conduct an analysis of the user department’s requirements. Sysco’s organizational recommendations coincided with the arrival of a new vice president, Bowman, in the Supply Division. Bowman was the first financial senior manager to have headed Supply, and DuBose’s report was the evidence he needed to rethink how Supply should be run. Bowman focused on reorganization and pushed for longer-range plans for systems development. However, Jess in the MIS Department objected to the use of Sysco to support Supply’s systems development. Although DuBose was supplying resources that Jess could not provide, Jess felt that Sysco’s involvement would unfairly divert Supply’s resources away from MIS over the next two years, Jess offered the alternative of searching the market for software packages, and Bowman agreed that an alternative to DuBose’s plan should be considered. Jess then hired James, who had worked in the aerospace industry as a systems designer within a production control function. His qualifications produced the expectation that James was an expert in Supply’s inventory problems. James’ first assignment was to conduct the search for software packages. James’ search began by assembling the names of producers and marketers of materials management systems packages. He did some desk checking of the capabilities of each system, soliciting Ira’s help again as Supply’s representative. Ira listed all the features that he could think of, and he and James set out to inspect software packages that had made their shortlist. They went first to the parent company’s (GenComm) largest operating company. That trip proved disappointing as the GenComm System turned out to have all the weaknesses of Centco’s. The search also included trips to McDonnell-Douglas and to Florida Power and Light, with no success. Finally, James and h-a went to Tampa Electrical Company and examined a system provided by TRES Computer Systems. TRES had installed an interim system for Tampa Electric and was designing a far more complex, integrated materials management system, which they described to Ira and James. TRES ACM Transactions

on Information

Systems,

Vol. 14, No. 1, .January

199S

40

.


had volumes of documentation on this new system, and Ira felt that it offered great potential even though these people were describing a system that did not yet exist as a whole. Ira commented: So we sort of bought in on this thing, bought in on a system that did not exist. It was, in effect, bits and pieces of existing coded logic operating in a variety of companies. More than anything, it was the concept of one key man from the TRES company that we bought in on.

These antecedent conditions serve as prelude to the events in the process model. The first encounter is the presentation of a formal proposal to begin systems development in 1976. 4.4 Period I (1975-1979):

MMS3

Encounter 1: Proposal to Begin. When James and Ira returned to Centco with information about the TRES systems, they clearly identified to the vice president of Supply (Bowman) and to Centco’s president (Bob) that a risk was involved because they were not buying a working system. If they were to go with TRES, they would be buying into a philosophy of a system that TRES was selling. Ira’s and James’ recommendation was that, if they were willing to take these risks, they should get on with the design of what they called MMS3—Materials Management System 3—which would be Centco’s materials management system. MMS2 was the hydroelectric utility system that TRES was developing for Tampa Electric. Bob decided that the risk was worth taking. There were large savings to be made in the materials area if Supply could acquire a system that had the functionality being described by TRES. The original calculations in the mid-seventies indicated a two-year payback on an investment of $4 million and a net present value of $11.7 million over a five-year period.3 The crucial factor was whether the system could be successfully introduced and used. The risks involved were never addressed explicitly in the TRES contract, although they were apparent to Ira: But there was a definite risk that we had to manage—that our project manager, whoever he turned out to be, would have to manage and that was that. We must ensure that the Tampa Electric Company MMS2 [was] developed in parallel with our design of MMS3. James, the MIS project as follows:

project

leader,

described

the process

of initiating

the

We went up to the steering committee, which consists of the president and vice president. It was the highest possible level and so I was up there for, what, three and a half hours doing [a] presentation. “Right! How soon can you get it in?’ “Well sir, I think it will be about two and a half years to get this thing

3 Net present value is a common discounting method used for evaluating the financial viability of projects. The estimated benefits and costs are discounted to a common point in time, usually the present, and netted off against each other. A positive net present value usually indicates a viable project. ACM Transactions on Information Systems, Vol. 14, No. 1, Janusry 1996

Information Systems Development organized

because

we’ve

got

all this preliminary

work.”

“Can’t

.

41

you do it

quicker?’ I said, “No, afraid not.” And away we were, the VP rather delighted. Episode 1: Acceptance. The result of the first encounter was an acceptance of the project at the highest level. Those involved in the proposal seemed highly enthusiastic about the benefits that such a system could bring to supply. Encounter 2: Jess Appointed as Project Manager. The acceptance of MMS3 by the steering committee and the enthusiasm that followed were quickly tempered when Jess was appointed to manage the project. As Ira explained: There was a feeling that here is somebody from the MIS Department who is going to come and tell us what kind of a system we can have and can’t have, through his role as the project leader,

Episode 2: Equivocation. This move took the edge off the initial enthusiasm and raised some concern among the users about the viability of the project under MIS’s leadership. Supply wanted to take the project leadership role itself because they were, after all, paying for the new system. Encounter 3: Organization of Users. James became the project leader for MIS, and Ira became the project leader for Supply and other user departments’ efforts. They set up an organization wherein Ira coordinated some 35 users, including internal audit, engineering, construction, industrial relations, and all aspects of accounting. These users were at one time spending 75% of their time on the project. James obtained a trailer and pulled everyone working on the project together, including three or four analysts from TRES. This huge involvement was consistent with James’ explanation of his leadership role: I think user involvement is extremely important. For instance, the last two days I’ve been doing presentations during lunch. We lay on the lunch, sandwiches and coffee, and then I stand up there and tell what a fantastic system this is and how it’s going to save the company.

Episode 3: EquiL1ocation. The effort to organize TRES personnel and the users into a project team met with mixed success. It became clear very early that the only person within TRES that really understood how this whole concept fit together was TRES’S Brush, whom Ira and James had met at Tampa Electric working on MMS2. Therefore, they demanded Brush’s services in helping to design MMS3. TRES then pulled Brush off the Tampa account and sent him up to Centco where he spent several weeks with James’ group, imparting to them an understanding of how the whole system would work together. He helped them modify the system to meet Centco’s needs rather than take the software as given and modify Supply’s operating procedures. The management users at Centco offered resistance to the project. For example, engineering was initially very uncooperative, as expressed by James: We came to some areas like engineering, where a certain gentleman resides, and they are extremely difficult. They think they have to have everything done their own way. That’s just them. Then we wouldn’t get anywhere. They’re very A(’M Transactions

on Information

Systems,

V(II. 14, No

1, January

1996.

42

.


importan~; ] they’re one of the users[;] they’re giving all the forecasting information. How do we get all the materials on their wretched little site? [Said with feeling.] They are not prepared to tell us when they’re going to do something. This went ta and fro and to and fro. Political battles all over the place, and in the end we said, “Right, don’t bother.” So we just chopped off the front end of the project, literally, and we said, “Fine, when we fire this thing up, you do realize gentlemen that the only way you’re going to order material is through this system? This system is going to do all the purchasing for the company, even to having the contract, and handles all purchasing, all the accounts payable so if you don’t go through the system you won’t get the thing bought because we ain’t going to pay for it.” So they said, “Oh! That’s a point.” So we just walked off or left it and waited for something to happen. They came back and said, “Maybe we should.” They were so diflicult to deal with, their manager or whatever he is.

Other areas were more cooperative. The stores area, for example, had just undergone a change in their top management, and the new managers were supportive of the project. As James described them: . . . three new younger, dynamic guys, really keen to go. Tremendous! Because they really want to see the system go. They’re not going to sit around and listen to all this rubbish. One or two [other] people have been removed sideways, “promoted’’-more of all the good stuff that goes on, so I’m delighted by that.

Encounter 4: Sign-Off on Systems Requirements. In spite of the resistance described, the system specifications were completed successfully in 1977. Over 500 people in Centco had been interviewed, and the systems definition amounted to seven volumes and over 1500 pages, “every sentence” of which had been approved. Episode 4: Acceptance. The project was on target at this point parties awaited the arrival of the MMS3 software from TRES.

as all

Encounter 5: Software Arrives from TRES. With the design work completed, TRES coded some of the modules and began delivering them to Centco in 1978. When the “specs” started coming through, Centco had some serious doubts about the quality of what they were getting. Jess confronted TRES about the problems and was told that development of MMS2, upon which MMS3 was to have been based, had fallen well behind schedule at Tampa Electric. Ironically, when the key designer of MMS2, Brush, was pulled away by Centco to work on the MMS3 project team, progress on MMS2 faltered. Now the entire concept that Brush had planned to be designed and incorporated into MMS2 was completely ruined. MMS2 was completely off track and out of control. Episode 5: Rejection. Jess was quite upset by the delivery of an unacceptable product, and he threatened TRES with nonpayment. Several people at TRES, including two senior vice presidents were fired because of this situation. At Centco, Jess explained his reservations about the software: I basically told them that “You’re giving me some deliverables, but I don’t know how to judge these. I don’t know whether this is good, bad or indifferent.” And the reason for it was that the model against which I would have compared that, which was the implemented Tampa Electric Company system, never happened. ACM Transactions on Information Systems,

Vol. 14, No. 1, January

1996


.

43

Encounter 6: Jess Refuses Payments to TRES. Jess ultimately decided not to accept the software coming from TRES and refused to authorize payment, He explained: I basically halted payment on the thing about two months after we got into the next stage of development, which was the detailed computer design. And finally their president and their new VP, who had responsibility for this area, coming several months. to us and telling us that they can’t do it—after

Episode 6: Rejection. Jess’ action to stop payments to TRES precipitated counterthreats by TRES, and meetings were held on “neutral grounds” by representatives of both companies. Although Jess was not supported by James and Ira in this action, he did receive support from top management. The vice president and the president, who had originally approved the MMS3 project, had left Centco, The new president, Graham, had served as vice president of operations when the project was first proposed, and he had expressed concern about the advisability of going ahead with this project in view of the risks involved. But he had been overruled by the former president, Bob. Now that Graham

was in charge,

he seized

the problems

with TRES

the opportunity he needed to cancel the whole thing. From Ira’s perspective, the project team looked in vain for support management

when

the trouble

with TRES

as

from top

began:

We really needed somebody to stand behind us and say “Never mind; these are just temporary difthdties. Let’s just go on.” What we found was that our president had left, gone back to [company] where he’d come from originally, and we had inherited a person who was a very conservative, very cautious individual, who had himself expressed some concern.

Encounter 7: Project Cancellation. Centco started legal action that eventually culminated in terminating the contract. Lawsuits were threatened by both parties, and meetings took place on neutral ground. The termination of the project was both symbolic and ironic, as Ira described it: Finally, the exchange of a dollar—we give you a dollar; you give us a dollar, and we’ll call it quits. My favorite story is that we probably gave them a U.S. dollar and [that] they gave us a Canadian dollar, and we lost out even on that.

The definition of requirements had cost Centco $800,000 in fees paid to TRES and an estimated $1.5 million in internal expenses, for a total of $2.3 million. Episode 7: Rejection. The project was dead, and in its aftermath several significant developments transpired. The “wounded” had to be dealt with. GenComm, the parent company, had learned what Centco had been doing to develop a materials management system in 1974. GenComm had made its own evaluation of TRES and had also contracted for MMS3, proceeding along the development stages with TRES about six to twelve months behind Centco. When Centco cancelled its project, GenComm “sat back for a while and tried to figure out what had happened. ” After a couple of visits to Centco and lots of telephone calls, GenComm concluded that the MMS3 project had failed because of Centco’s mismanagement of the project, not because of TRES’S inability to deliver. GenComm continued on for some 18 months more ACM Transactions

on Information

Systems,

V(,) 14. No

1, .Jnnuary

1996

D. Robeyand

44.

M. Newman

with the TRES people before canceling with reason was not lack of delivery of MMS3. different GenComm operating companies to doing things within MMS3. GenComm’s perception of the affair raised the management of the MMS3 project, Both cancellation of the project. Ira said:

TRES as well. But GenComm’s Rather, it could not get seven agree on one standard way of the issue within Centco about Ira and James questioned Jess’

There was one ingredient that I felt was responsible for the final [Centco] termination, and I felt that the project could have gone otherwise; and that was that our project manager from data processing [Jess], who did not really understand the business needs that we were trying to address with this computer system, didn’t understand the potential for benefits and savings, worried more about the technical aspects, and worried more about what this job and this project could mean for his career . . . . He had, very early in the game, threatened to cancel the whole project. Several of us, [James] and myself among the leaders, rose up and said “You can’t do this to us. We’ve put two or three years of our life and our thoughts and our ideas into this thing, which is really going to work. We believe. Why don’t you believe?”

Ira and James argued that they should cut back on the scope of the project and continue with a downsized crew of people. They felt that continuing work on the project would protect the investment that they had put into it. Their pleas were not heeded. By contrast, Jess perceived James as a “loose cannon” in Centco who was at times “critical with a vengeance” of Centco’s culture. Jess also perceived Ira and James to be too involved with TRES to let go: [James and Ira] were so emotionally involved in wanting this product and believing that these people could do it that . . . when I decided to halt payment and I sent the letter that caused the crises, I was backed up by the VP that I reported to, but I wasn’t backed up by those two. And I think what happened speaks for itself, as to who was right.

Encounter cancellation, agers

8: Formal Hearing a formal

to determine

hearing

whether

Over Cancellation. was

scheduled

the project

In the wake of MNIS3’S

before

had been

a board

lost because

of senior of Jess’

manmis-

management or whether it had been cancelled legitimately. James, the project leader, pressed the issue of Jess’ leadership, arguing that the failure was a result of the project manager’s disregard of the project’s risks. Not having any clear evidence as to who was to blame, management cast their vote in favor of Jess. Jess had been with Centco for about 10 years at the time and, as a more-senior employee than James, Jess was judged to have been right.

Episode 8: Rejection. James was removed from his window o~~ce, put into a small cubicle, and given nothing to do until he realized that it was in his best interests to negotiate a termination agreement. He left Centco sometime thereafter and found employment writing children’s books. Jess and Ira were both disgruntled and unhappy with the whole fruitless exercise. ACM Transactions

on Information

Systems,

Vol. 14, No. 1, Janusry

1996


.

45

Encounter 9: Reinvestigation of the McDonnell-Douglas System. In the process of wrapping up the project, Jess called in McDonnell-Douglas, the first company that Jess and Ira had visited on their original tour. Jess believed that McDonnell-Douglas had a potential product, even though James and Ira had rejected it. He arranged for the developers of this system to be brought in to see if Centco could put in the McDonnell-Douglas system. Episode 9: Rejection. For the next Douglas personnel assisted in a study ments definition at Centco. At the end that there was not enough functionality the idea of using their package. That market. Jess returned to MIS and Ira 4.5

Period II (1980-1984):

In-House

ten to twelve weeks, the McDonnellto match their system to the requireof that period, Jess and Ira concluded to make the match work and rejected left no other known packages on the to Supply.

Development

Encounter 10: Proposal for In-House Development. Using DuBose’s original recommendations, Supply proposed to reinstate in-house development as the course for future systems development. Episode 10: Acceptance. There was little opposition to this approach at Centco. MIS were busy with converting online, real-time applications, originally written for their DEC 10 hardware, to the Amdahl machines formerly reserved for batch processing. Encounter 11: Ira Proposes to Rewrite Materials Management System. While supporting in-house system development, Ira saw the opportunity to reestablish his credibility with the Supply users by rewriting the materials management systems. His hope was to get permission eventually to build bigger and better systems from within the Supply division, Episode 11: Equivocation. Ira designed an advanced system that was both a technical rewrite of some of DuBose’s efforts on the DEC and an application of the knowledge that Ira had acquired from the MMS3 experience. The result of his work was a system called MDS—Material Distribution System. MDS incorporated state-of-the-art principles specifically tailored for Centco, although it was not the integrated system that Ira had always imagined and wanted. Management at Supply seemed pleased with Ira’s approach to producing a workable system for Supply. Although MIS had not initially opposed Supply’s proposal to perform in-house system development, they now were not happy to see Supply proceeding independently with a major project. Encounter 12: MIS Proposal for Business Model. MIS asserted themselves at this point by insisting that Supply’s system conform to Centco’s systems standards, known as the “business model.” Ira explained: So, before I was allowed to resume designing in-house systems for the Supply function, I had to work with the MIS people and go through the building of a business model. So, six months later we have got ourselves the first rough-cut on a business model using the Holland methodology that [Jess]—who was the Data Resource Manager by this time in MIS—had imported to Centco.. and ACM Transactions on Information Systems, Vol. 14, No 1, January 1996.

46

.

D. Robey and M, Newman

was using to build the corporate business model. Out of this exercise came, I believe there were, eleven phases? Well, this time we’ve only got eleven!” [said with disdain; the previous number was 13].

The preliminary estimate of duration was eight to ten years to deliver the 11 phases, at a cost of $10 million. Episode 12: Equivocation, Work on the first of the development phases was begun. Because Ira had built the business model for Supply, and it was restricted to the supply function, he expected to assume a leadership role in this operation. Instead, the MIS people took the project leadership. The first major task was to build the corporate catalogue that defined all the bills of materials, prices, lead times, descriptions, etc. for all the products manufactured, stocked, or serviced in the company. It was not long before the MIS people were sharing the leadership of this project with people from the Engineering Department, much to Ira’s chagrin: We were sort of like a voice in the wilderness, left alone to cry out there and say “What about us?” We were the initiators. We built the business model. We helped to justify this thing financially. And now we’ve lost control of it. Management at Supply wanted a system but were afraid of the 11 phases, the 8-10 year completion time, and the $10-11 million price tag that the MIS group had projected for in-house development. Encounter 13: News of the ASI Product. At this time Supply’s new materials management director, Woodrow, returned from a meeting at GenComm. He reported that: [GenComm] have now found another software package marketed by [ASI]. And we and Supply feel that we should have a look at that system at the request of [GenComm] [Centco].”

and see whether

or not the software

package

is appropriate

for

Episode 13: Equivocation. Rather like a “white knight” returning home with good news, Woodrow held out new hope that Supply would not have to go down the route directed by MIS. The case for MISS solution was looking increasingly weak, although Supply had not yet rejected MISS proposal to build the system in-house. Encounter 14: Ira Evaluates the ASI Product, In 1984, Ira was pulled from systems development work at Centco and sent to judge the appropriateness of the ASI package at GenComm for Supply. Ira put a number of people together and, after three or four months, concluded that ASI’S package was usable. It had, by their estimation, about 60–70Yc of the functionality they were looking for, based on the business model. Episode 14: Rejection. MIS categorically rejected the idea of importing ASI product to Supply. Ira explained the situation:

the

Now what had happened is that the MIS, in the building of the business model, when explaining why we should spend that kind of time and money, and then the development of the eleven-phase in-house development, they’d put all of their eggs in that one basket of in-house development. So, when I came back ACM Transactions

on Information

Systems,


1996,


.

47

and said “This package has really got something and we should have a look at it in detail,” I ran headlong into MIS saying give it a 20 percent chance of success,”

“Oh no, it’s not worthwhile.

We

MIS went to great lengths to gather evidence from anyone who could disparage the ASI software package. Supply became very enthusiastic about leading their own project based on the ASI package. They now totally rejected in-house development. The Period

final

episode

I. Not

management

only

of Period was

problems,

little

II reflected progress

Period Ill (1984-1

same

problems

to solve

but there was also a clear rejection

$10 million proposal. MIS was very reassert control over the process. 4.6

the

made

987):

unhappy

that

that

Supply’s of MIS’s

the users

were

ended

materials 1 l-phase, trying

to

ASI Package Development

Encounter 15: Ira Appointed Project Manager. Following three months of “head-bashing” and reanalysis, the user team at Supply assembled the statistics necessary to justify that the ASI package was worth a detailed look. They were able to satisfy the vice president of Supply, some of the operational people, and the line people with their arguments, as summarized by Ira: No matter how many people we put on it, we just do not have the skills and ability and knowledge required to design such a system. As it turned out, the two principals of [ASI] were both respected experts in the field of forecasting, mathematics, operations research, statistics, all of those areas, and had designed the forecasting model on which their whole company’s success was built in the initial years. And who am I to say that I know enough about forecasting models that I could have designed the equivalent of that? So we ended up telling the executive that, not only is this system cheaper and faster to install, but we doubt whether we could provide the equivalent functionality ever through in-house development.

Episode 1,5: Equivocation. With the project newly justified, Ira conducted a detailed review, feature by feature, module by module, program by program. with ASI. He read their documentation and visited other customer sites for demonstrations. Centco joined the ASI user group, about 400 compato ASI products. nies who met every six months to lobby for enhancements From these activities, Ira learned enough to claim that the functional fit of the system was even greater than originally thought. A figure of 84-85r+ fit to Centco’s needs was quoted. The MIS group, now led by Dom, belittled the effort. Dom was the subject of some complaints and discussions with his management. As described by Ira: I said, 6’1can’t go on. He’s either with us or against us. What are we going to do’? And they hauled him on the carpet and said, “Get with it! The user is driving this project.”

The new system had to be justified to Encounter 16: Project Appro~al. senior management. Ira presented the business case with full financial justification for the ASI product. In the process, he encountered the board chairman, Graham, who had been the vice president of operations during ACM Transactions on Information Systems. Vol 14. No 1. ,January 1996

48

.


Period I when MMS3 was proposed. Graham wanted to know how the ASI differed from the materials management system that TRES offered. Ira elaborated: It is an existing operating system[,] and I can show it to you. In fact that was part of the strategy for evaluating the system, to bring it in-house and demonstrate it, and call in some of the senior management people and show them, no matter how briefly . . . have them ask the questions and have the people demonstrating the system key in their questions and show them the answers. So, provided that this was not contrived, that you could touch it, you could feel it, you could smell it. It’s an existing working system. Plus the fact that [GenComm] has brought this package and [that] several of the [other companies] either installed it or are actively installing it at those companies.

have

On the basis of the evidence presented to them, top management approved Supply’s proposal to acquire and implement the ASI System, called MMIS II. The contract for MMIS H was signed in April, 1986, with implementation due in two years. Supply also signed a five-year enhancement and maintenance contract with ASI. Episode 16: Equivocation. Users expected that the two-year target was achievable because a similar system, implemented in an Alaskan oil company at the same time, took less than two years to complete within budget. MIS had been “put in their place” by the action. MIS resented the external award of the enhancement and maintenance contract because it was keen to take this lucrative contract for themselves. Significantly, MIS was able to insist that Supply adopt the IMS version of the software. The working system that Ira had presented to top management was the software’s CICS version, which was indeed operational.4 The IMS version was not yet available as a completed system. There were approximately 200 CICS installations compared to five IMS installations, and Centco was the only ASI client proposing to take the full IMS package. ASI started delivering the first parts of the system in late 1986. These were primarily the planning systems, and they went fairly successfully. Encounter 17: Confrontation between Ira and Dem. At this point, the relationship between MIS and Supply took a turn for the worse. Ira described his confrontation with Dom: I couldn’t put the system in without MIS, because they were going to install it at this end and [because] they were going to operate it at this end. And yet I couldn’t work with the rules and the people that [Dom] was setting down and assigning to the project. And he and I clashed continuously, either directly or through the messages that he was sending with his people. And finally, he and I agreed that we’d got to sit down and have a discussion. And he came out here, and he made some statements; and immediately my back went up, and I made some statements. And we parted company agreeing

4 CICS and IMS are different database management systems. IMS can handle larger databases than CICS, which is ostensibly why CentCo’s MIS group insisted on obtaining the IMS version

rather than the more-established CICS version of ASI’S software. ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996.


to disagree. I remember

that meeting.

It was probably

.

49

the low point in the

whole project,

Episode 17: Rejection. The personal dislike between Ira and Dom magnified the technical problems in the project. Several problems had become apparent as more modules were delivered in the first quarter of 1987. Some modules failed to operate on the computer. When Centco bought the IMS version, it received a copy of the IMS system that was being installed at another company, SouthWest. serious problems encountered

As Centco

began

to work

with

this system,

it

and tried to make modifications. Simultaneously, SouthWest reported similar problems with the IMS version. The package included fixes that had been made to the IMS version by ASI, who apparently had done a technical rewrite on the CICS version. Some of the enhancements were not fully tested, and some of the modifications were not fully installed. That system was now causing hundreds of problems at both SouthWest and Centco, and the Centco project started to miss dates. Supply invited the ASI people to Centco and complained about their problems. MIS, meanwhile, tried to impose operating standards on the system retroactively. MIS argued, for example, that any given transaction not have more than one second of CPU residence, whereas Supply argued that the package required a second and a half. MIS said they would have to rewrite it. Supply was trying to satisfy these requirements while trying to get the system running and trying to get the users to test and understand the system. Encounter 18: Financial Crisis at Supply. The project received an unexpected blow in 1987 from an unrelated series of events. Russell, the vice president of Supply, and some of his managers committed some major budgeting blunders that resulted in a $5 million deficit. There was also evidence of poor control of the planning function and some major industrial relations problems. Russell had also committed a strategic error by launching a series of commercial companies, and Russell had become president of most of these companies. In addition, Russell had some personal problems. Episode 18: Rejection. As a consequence of the financial crisis, the MMIS II project effectively came to a halt; senior managers in Supply were offered early retirement packages, and a new management team was installed. 4.7

Period IV: Resurrection

of MMIS II (1987-1990)

Encounter 19: New Project Manager Appointed. The new vice president of Supply, Roger, made it clear that he was not going to work with the senior managers who had served under Russell, including the MMIS II project manager. He had also learned of the trouble with MMIS 11 and wanted to establish control over the project straight away. Roger appointed a new project manager, Thompson, whose prior experience at Centco had been in marketing. Episode 19: Rejection. mitments to the project

Thompson immediately cancelled all previous comand requested that the whole thing be rejustified

ACM Transactions on Information Systems, Vol. 14. NO 1, January 1996

50


.

with a new business case. Ira, although de facto replaced by Thompson, initially retained his title (the same as Thompson) and conditions of employment. But Ira was, in effect, an administrative assistant to Thompson. Ira’s angst is apparent in the following statement: I tried to impart to him—on, I thought, a friendly basis—where we’d come from with the project and why we needed the system. And I’m trying to share with him the user perspective of the need for the system. And he didn’t want that. He resented any attempt by me to try and explain what we’d done and why we’d done it and all the rest of it. He was, from day one, going to do this thing all by himself. And I would answer whatever questions were put to me, and that was all that was required of me. So I was shuffled off into the next ofice and sat there with my mind spinning. “What have I done? Where did I fail in this thing?’ In the eyes of others His

career

had

been

involved “red-circled”

in the project, because

Ira was part

of the

project

of the problem.

crisis.

Thompson

characterized h-a as a “details person,” one with a tremendous understanding of the paperflow in Supply, but one also who had “screwed this thing up” to a certain

extent,

although

not with intent.

Encounter 20: Thompson Rejustifies Project. Over the next few months the business case for the system was rewritten by Thompson with the help of Ira. The original business case in 1985 had shown an incremental cost of $18 million and a net present value of $4 million. The comparable figures for the new case were $34 million in incremental costs over 10 years and a net present value of only $2 million. The total cost was estimated to be $76 million, an astoundingly high figure for such a low net present value, indicating a high financial risk. Episode 20: Equivocation. Rejustifying the project was no easy matter. A change in the financial reporting for Supply meant that a $34 million project would be the largest expense in what had become a relatively small part of Centco. Top management questioned the need for the system, and MIS continued to argue against the package. Despite the uncertainty and opposition to the project, the feeling grew that it would be better to go forward than to cancel the project. This meant that the contract dispute with ASI would have to be settled, and the issue of MIS’s intransigence would also have to be dealt with. There also remained an uneasy tension between Thompson and Ira. Thompson would ask Ira carefully phrased questions which were to be answered, “yes or no, and don’t add anything beyond,” according to Ira. Encounter 21: Visits to ASI Headquarters. Because the project was difficult to justify financially, it was important to avoid further technical problems. As part of the evaluation of the project, Thompson visited ASI headquarters in mid-1988 to see if those problems that MMIS II had experienced before the project was suspended could be resolved. Thompson was accompanied by his manager and the MIS manager, Dem. According to Thompson: So my boss and myself and the MIS guy went down . . . So we start off the meeting, and [Dom] starts off by saying “Here’s your problem .,. ,“ So he’s ACM Transactions on Information Systems, Vol. 14, No, 1, January 1996.

Information Systems Development really aggressive . . . away.

.

51

So [ASI] waited their turn, and they just blew this guy

So one of the complaints the MIS guy made was that it’s taking anywhere up to two months to [fix] an error. And they said “Well, we’re prepared to send you ten tapes a month, if you want, but you’ll only accept one, . And of course, right away we’re on the defensive.

Episode 21: Equivocation. Soon after these visits, Dom was moved off the project, and MIS supplied a new project leader. This paved the way for MIS to enter the new phase of development as a major partner. Ira saw the incident as a means to establish greater communication with Thompson. Thompson now understood how difticult Dom had been and how destructive MIS had been for Supply’s effort. Although the justification of the project had not been fully accepted yet, Thompson’s approach was enjoying a growing credibility at Centco. Encounter 22: Centco Buys Out ASI’s Maintenance Contract. Centco settled with ASI by paying a negotiated percentage for the modules delivered and paying the remaining portion of the software license fee upon acceptance. Under pressure, ASI agreed on terms of severance of the contract, getting most of their contracted money out of the deal but losing the lucrative, five-year maintenance contract. At this point, MIS bought into the project, agreeing to test and install the system and to customize it according to the specifications in the original contract with ASI. Episode 22: Acceptance. All the ingredients were now in place to enable Thompson to proceed with MMIS II. The financial picture although not exciting was acceptable, and there was more of a feeling that the less-tangible benefits of automation would make it essential to go ahead. A large amount of sunk costs had been incurred and needed to be justified with some result. The MIS issue had also been resolved, and they were now fully on board under new leadership. Thompson also adopted a conservative strategy of defining five phases of implementation. He considered it too risky to bring the whole system up as an integrated package. At this time, Ira accepted a line position in customer equipment, although he retained a liaison role with the project. As of September, 1990, implementation of MMIS II was proceeding at a satisfactory pace, producing optimism that the system would be fully implemented by early 1991. Forecasting and planning modules had been fully installed and operational for two years. Purchasing was carrying live data in a pilot application. Accounts Payable was carrying the majority of their accounts and was about to convert all their accounts to the system. The on-hand-balance application was due to be implemented and then “rolled out” to the other warehouses: a major undertaking involving around 1200 people. Indeed, there was a large sign in the supply building indicating the precise date (October 8, 1990) for this event, with the number of days being counted off to the deadline. This put the systems people under some pressure. Although the strategy of phased implementation was causing many headaches, such as running old and new systems simultaneously, it did ACM Transactmns on Information Systems, Vol. 14, N,, 1. January 1996

52

.


offer tangible commented:

evidence

to managers

that

something

was

happening.

Ira

A lot of people are off our backs now, and they’re saying “I know you’re not

there, but essentially you’ve delivered capability. I can see people using it. I see reports, and I hear about the system. And you’re right; it seems to be well received and better than what we had before.” So that strategy of delivering bits and pieces has saved us some of the embarrassing moments of having to explain why we’re a year or two behind where we thought we were going to be. This project has been to the brink and looked over many times since then. It’s now, I would say, past the point of no return, to use an old navigational term. It’s shorter to go forward and cheaper to go forward to the end than it is to go back. And you probably don’t have enough fuel to go back anyhow. We’re past that critical point. Table I provides a summary listing of all the preceding events, shows the key actors involved, and indicates their relationships to one another. Figure 2 maps the progression of events involved through all four periods of ISD at Centco. The first three periods can be seen ending in rejection; the final period ends in acceptance and favorable relationships between MIS, Supply, and Centco management. Period IV also evidences the first tangible progress toward getting the materials management system implemented. 5. DISCUSSION ISD is a process with significant economic and social consequences. Although Period IV brought some relief from the earlier frustrations and conflicts, the tale of Centco is not a happy tale. Economic consequences were especially dire. Not only was the implementation of Supply’s materials management system long overdue, but the resources expended in the effort were enormous. This meant that Supply was unable to achieve the types of cost containment measures that were necessary. The consequences for individual careers were also substantial. Several participants departed, and others arrived, with the pulse of the project. Ira, James, Jess, and Thompson all experienced personal and professional consequences from their participation in the various periods of the project. Over the years covered in the case, the basic relationship between the personnel in the MIS department and those in Supply also changed. The antecedent conditions that existed in 1975, that is, the traditional analyst-led approach to systems development at Centco, had changed to joint development by 1990. Neither MIS nor Supply gained complete control over projects, as each group contributed to efforts that were moderated by an outside project leader from Marketing. The process model predicts no change in antecedent conditions unless critical encounters occur. In the case, we have seen numerous critical encounters that shifted the relationships among the central actors. Were the case study to continue beyond Period IV, joint development would be considered as the antecedent conditions for the next sequence of events. It is vital to understand the dynamics of social processes that are capable of producing outcomes such as those experienced at Centco. The social process ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996.

Information Systems Development Table I.

.

53

Summary of Events and Key Actors in Each Period

Key Actors”

Period

Antecedent Conditions: Mixed opinions about the roles of MIS, Supply, and external consultants(SYSCO) in ISD at Centco. Centco management using the occasion

Centco-Supply/MIS

of Sysco’s report to reorganize Supply toward longerrange systems development. Period 1, En 1 Ep 1 En2

MMS 3 ProposaJ to begin Acceptance Jess appointed as project director

Ep2

Equivocation

En3 Ep3 En4 Ep4 En5 Ep5 En6 Ep6 En7 Ep7 En8 Ep8 En9 Ep9

Organization of users Equivocation Sign-off on systems requirements Acceptance Software arrives from TRES Rejection Jess refuses payment to TRES Rejection Project cancellation Rejection Formal hearing over cancellation Rejection Reinvestigating McDonnell-Douglas Rejection

P~

In-H

EnlO

Proposal for in-house development

Ep10 Enll

Acceptance Ira proposes to rewrite Materials Management System Equivocation MIS proposal for business model Equivocation News of the ASI product Equivocation Ira evaluates the AS1 product Rejection

Epll En12 Ep12 En13 Ep13 En14 Ep14

Centco-Suppl y/MIS Supply-MIS

Supply-MIS Supply-MIS TRES-MIS Supply /TRES-MIS Supply /TRES-MIS Centco-MIS system

Supply/MD-MIS

Develor)men supply-Mls supply-M1s SLIpply-MIS Supply-MIS Supply -hlls

Period 111. ASI Package Development supply-MIs Ira appointed project manager En15 Equivocation Ep15 Centco-Suppl y Project approval En16 Ep16 Equivocation Supply -hl[s En17 Confrontation between Ira and Dom Rejection Ep17 Centco-Supply En18 Financial crisis at Supply Ep18 Rejection “Key actors separated by a slash (/) operate as a temporary coalition with common interests. Key actors separated by a hyphen (-) operate with opposing interests.

ACM Transactions on Information Systems, Vol 14, No. 1, January 1996

54

.

D. Robey and M. Newman Table 1.

Continued

En19 Ep19 En20

Resurrectionof MMIS 11 New project manager appointed Rejection Thompson rejustifies project

Ep20

Equivocation

En21

Visits to ASI headquarters Equivocation Centco buys out ASI’s maintenance contract

Period IV.

Ep21 En22

Key Actors” Centco-Supply Centco-Supply Suppiy/AS1-MIS

Supply /MIS-ASI Acceptance ‘Key actors separated by a slash (/) operate as a temporary coalition with common interests. Key actors separated by a hyphen (-) operate with oppmng interests. Ep22

model applied to the Centco case provides the form for analyzing social action, and the main advantage of this approach is its ability to identify repeating patterns. When looking for patterns in a wealth of qualitative data, even a simple model can provide important clues. The process model sorts events into two categories (encounters and events) and assigns one of three kinds of values (acceptance, rejection, and equivocation) to episodes. It presents information about the sequence of events, although sequence information is not subjected to rigorous quantitative analysis. Essentially, the process model filters out much of the qualitative information contained in a case study narrative while capturing the essential information about the sequence and character of events. More complex models can certainly be developed, but the power of even a simple process model has been demonstrated in this research. The sequential patterns identified in social processes are potentially subject to a wide variety of theoretical interpretations. Some researchers, for example, would interpret the interactions between Supply and MIS as politically motivated. Others might view the case as evidence that complex projects require specific management techniques, such as those applied by Thompson. Still other interpretations might focus on the changes in the environment, the corporate culture of Centco, the quality of the software, and so on. Rather than choosing among these perspectives, our discussion demonstrates the utility of the process model in supporting the insights gained from different perspectives. Each of several theoretical approaches to the case study can be enhanced by the identification of patterns in the relationships among key actors in the social process. Kling [ 1980] has carefully articulated a broad range of theoretical perspectives applied to the social analysis of computing. Three of the into a broader perspectives —rational, structural, and human relations—fit category that Kling labels “systems rationalism.” According to Kling [1980, p. 63]: Systems rationalists typically emphasize the positive roles that computerized technologies play in social life. Often, they examine new capabilities of computing technologies (e.g., computer conferencing) or new areas in which existing computer technologies may be applied. They assume that there is a marked consensus on major social goals relevant to computing use, and they often ACM Tmnsactions on Information Systems,


1996

cnll

cn5

md

Accewc PI

EquivOcatim II 7 3 I D

Rejectioo entl

ml

en8

en9

en15

en10

en18

~

CU19 eI120

3 $ ,,3 “.

s Phase 1

/

[ 1975-1979)

Fig.2.

Phase 11

(1980-1984)

Sequence ofeventsat

Centco.

r

Phase 111

(1984-1987)

Phase Iv

3

(1987-19-

; < Q o j 3

. m (n

56

.


develop a relatively synoptic account of social behavior. Systems rationalists place efficiency, whether economic or organizational, as the predominant value, Moreover, they typically focus on a narrowly bounded world of computer use in which the computer user is a central actor. By contrast, three other perspectives—interactionist, organizational politics, and class politics—fall into what Kling terms “segmented institutionalism.” These approaches differ from systems rationalism in several fundamental ways. According to Kling [ 1980, p. 65]: Rather than assume a consensus on important goals and values, segmented institutionalists assume that intergroup conflict is as likely as cooperation unless the contrary is empirically demonstrated. They identify as dominant values the sovereignty of individuals and groups over critical aspects of their lives, the integrity of individuals, and social equity; economic or organizational efficiency is subservient to these values. They typically identify settings of computer use as broad in scope, and they are likely to emphasize parties other than the computer user (e.g., clients, regulators, suppliers, competitors, or controllers of critical resources). Neither the systems rationalists nor the segmented institutionalists have proven the superiority of their respective assumptions. Rather, both perspectives continue to guide research on the application of information technology in organizations. Our objective here is to show that the interpretation from five different perspectives may be enriched by data about social processes: Unfortunately, space limitations prevent a full analysis of the Centco case from each perspective, However, the brief analyses provide sufilcient evidence that multiple interpretations are both plausible and enhanced by the identification of recurring sequences of social action. 5.1 Rational Perspectives Kling [1980] characterizes the rational approach as assuming Rational. that technology is a tool for achieving the shared goal of greater efficiency. Organizations themselves are viewed as rational means for attaining shared goals, so an IS should be designed to increase organizational efficiency. Where inefficiencies occur, the blame is placed on the quality of the technical solution, not the social system adopting it. Social systems are assumed to be free of annoyances such as politics or resistance to change. The fields of management science and computer science are dominated by a focus on technical improvements. A rational analysis of the Centco case would diagnose the problem as the inferior quality of the various software solutions. Improved technical solutions and improved practices for software development would be recommended in a rational analysis. For example, the need for more thorough testing is quite obvious, especially on versions where software developers have had little practical experience (e.g., the IMS version of ASI’s product).

5 The sixth perspective, class politics, is difficult to apply to a case study involving interactions only among professional workers in an organization. Therefore, we have not included an interpretation from this perspective. ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996.


.

57

Rationalists would also emphasize the need for more systematic evaluation of alternative products, perhaps supported by formal methods for project selection. For the rationalist, the case offers ample evidence of the premature implementation of software that was poor in quality. The process model enhances the rational perspective by laying the history of technical problems out in a sequential pattern. The repeated carelessness of Centco and its consultants and vendors in Periods I, II, and III is more easily observed, as are the consequences of premature implementation. When technical improvements are introduced in Period IV, results improve. These improvements include Thompson’s strategy to implement the system in modules, each of which can be tested and used before the next is installed. The sequential analysis also invites inspection of the greater reliability in packaged software and the evolution of systems practice between 1975 and 1990. Centco may have suffered through the profession’s learning years when long backlogs and faulty systems were commonplace. From a rational perspective, Centco’s more recent success could be explained by general improvements in the technical quality of software and professional practices. Structural. The structural approach expands the analysis of the rational perspective by including the social context of the computing application. The social context of the organization includes its structure and environment, and rational objectives are achieved when there is a fit among the environment, the organization’s structure, and computing applications, Thus, environmental changes, such as an increase in competitive pressure or a change in safety regulations, can effect a change in an organization’s structure. In the structural perspective, information systems are viewed as rational components of organizational structure and can help an organization to adapt to the demands of its environment. By tracing the events at Centco, the process model helps to identify significant external conditions that affect the development of the information system, Centco’s industry was undergoing deregulation, and new competitors had entered the market, placing new financial pressures on Centco. Centco’s response was to spin off specialty companies to deal with specific competitive pressures, not to revise its core organizational structure to one more suitable for the changing industry conditions. The spinoffs did not affect Centco’s main businesses and such core functions as inventory control. As a result, the materials management system was developed within an organizational structure that seemed isolated from the realities of the environment. Historical commitments and outmoded bureaucratic procedures placed little pressure on the participants to succeed in their task of building a system, despite the urgent need to control costs and material flow more efficiently. Thus, a structural interpretation of the case would identify the revision of organizational structures in response to environmental change. The failure to achieve early success in system development could be attributed in part to the centralization of the MIS function. In a highly regulated environment, the centralization of functions such as MIS might be an effective way to organize. In a more competitive environment, the need for swift response renders a ACM Transactions

on Information

Systems,

Vol. 14. No

1, January

1996

58

.


centralized structure less effective. Clearly, the users in Supply understood the need to develop the materials management system, and they pushed aggressively to create the system themselves. Of course, this made them more vulnerable to the weaknesses in packaged software available from vendors. Human Relations. The human relations perspective also adopts a rational perspective on social analysis, but it incorporates social and technical criteria into the analysis. Human relations operates under the idealistic assumption that social and technical goals can be simultaneously achieved, or jointly optimized, in the implementation of information technology. The primary means for achieving joint optimization is the participation of users in the design of information systems. Through the involvement of both users and analysts in systems development, the consequences of the application on individuals and groups can be considered as part of the design problem. Human relations, thus, widens the shared goal to include social objectives such as job satisfaction and work group autonomy as well as economic objectives such as efficiency. Interpreted from a human relations perspective, the Centco case reveals apparent benefits of users and analysts working together, and these benefits are brought into sharper relief by the process model. In the first three periods described in the case, users and analysts did not cooperate very well. The members of the project team from Supply seemed eager to pull away from the influence of MIS, while MIS sought to preserve its right to control development. It was only in Period IV that Thompson emerged as a project leader and got the users and analysts to cooperate by sharing the maintenance contract with MIS. Thompson’s agenda may have excluded some objectives from negotiation, but the dependence of the parties on each other was acknowledged and used as the basis for making joint progress. The case ends with a new atmosphere of joint development established. 5.2 Segmented

Institutionalist Perspectives

lnteractionist. The first three perspectives share the assumptions of rationality, but differ from each other in how broadly shared objectives are defined. In the following two perspectives, the assumption of rationality is suspended. In the interactionist perspective, focus is placed on the symbolic meaning of technology to subgroups with different interests and values. The organization is viewed as a “culture” in which objective reality is interpreted and understood in a social context. Subcultures exist both within and outside an organization, and these subcultures must interact to produce cultural artifacts such as an information system. Systems development is understood as a social process in which social meanings are both created and preserved. The interactionist approach focuses on the revision and preservation of meanings over time and draws attention to the symbolic side of computing applications. In Centco’s organizational culture, firmly established prior to 1975, little importance was placed on efficiency. Rates and tariffs were historically based on demonstrable costs, so there was little incentive to streamline operations ACM Transactions on Information Systems, Vol. 14, No, 1, January 1996.


.

59

or practices for reporting inventory. Enormous waste in excess inventory was tolerated. As the industry’s environment became more competitive, the parent company placed greater pressure on Centco to control costs and reduce waste. The information system assumed both a functional and symbolic role in this effort. Clearly, a well-designed system would enable costs to be reduced, but the system also signaled a change in Centco’s cultural assumptions. Actors from different subcultures sought to preserve older, less ef%cient practices at the same time as the need for change was being expressed by others. An interactionist perspective emphasizes the dynamics of cultural change and examines the processes that are the source of social change. The interactionist perspective benefits from an analysis of events over time because the process of cultural change at Centco can be observed more easily. The mere fact that it took some 15 years for a version of the proposed system to become operative is evidence that tolerance for waste was firmly embedded as a cultural assumption. The systems development efforts were marked by collisions between MIS and Supply, each of which had a different view of the process. Cultures develop rituals that are repeated, and systems development can be regarded as a ritualistic cultural practice. The process model allows us to track the conflicting tensions between cultural persistence and cultural change. Organizational Politics. Compared to the interactionist perspective, organizational politics focuses more narrowly on the interests of subgroups and the conflicts among subgoals. Political analysis requires the identification of stakeholders and their interests, along with an understanding of the social context that presents opportunities for overt conflict. Stakeholders with conflicting subgoals are assumed to mistrust each other and to seek opportunities to enhance their power to achieve their subgoals at the expense of others’ subgoals. Unlike the human relations perspective, organizational politics is skeptical about the prospect of resolving conflicts satisfactorily. In place of constructive resolution of conflicting interests, we are more likely to find unstable compromises. It is easy to frame the events at Centco in political terms. As Table I indicates, two definable stakeholder groups exist: MIS and Supply. Their interests differ, and they have ample opportunity to exert themselves in the pursuit of their respective subgoals. Supply forms occasional coalitions with external parties in an effort to bypass the MIS department. Rational arguments employed by both parties thinly mask the political motives of the actors. For example, the need to obtain the IMS version of ASI’s software is ostensibly a rational argument, but it also reduced the reliability of the system. The political impact of forcing the IMS choice, therefore, was to make Supply fail in its efforts to become independent of MIS. Eventually, a compromise was struck that allowed both MIS and Supply to get part of what each wanted—a politically astute move on Thompson’s part. The process model allows the political conflicts to be mapped out and understood as social events. The primary focus of the model is on interactions between parties, and the assumption of incompatible goals is easy to support. ACM Transactions

on Information

Systems,

Vol

14, No

1, January

1996

60

.


Encounters may be interpreted as occasions for overt conflict, whereas episodes may be seen as periods where temporary “solutions” to the conflict are enacted. Efforts by parties to increase their power by forming coalitions, exerting energy into political activity, and by controlling the flow of information are also easily interpretable with the process model.

6. CONCLUSION Our objective is to demonstrate the potential value of a specific process model for research on ISD. The process model aids in the empirical detection of repeating patterns of social activity, and its value is largely independent of a researcher’s theoretical preferences. An understanding of the sequential patterns in ISD can serve as a platform for multiple interpretations. It is not our purpose to provide a complete analysis of the events in the case from each of the theoretical perspectives identified in this article. Nor do we claim that the perspectives addressed in this article exhaust all possibilities. Other theories, such as organizational learning, can also be adapted to the form of the process model. The primary contribution of this article is the demonstrated usefulness of the social process model developed earlier [Newman and Robey 1992]. Rather than modify that model based on the data presented here, we have used the model to aid in the analysis of a rather complex social history. The model’s utility is evident from the patterns discernible in the story. Just as punctuation makes a string of words more meaningful by isolating groups of words into phrases, so the model helps the researcher to make sense of complex social processes. The aim of scientific inquiry is advanced by any method that reduces raw data in a meaningful fashion. The insights gained from applying the social process model to the Centco case may be further enhanced by the use of different theoretical perspectives, and this represents an extension over the original exposition of the model. We have also tried not to favor one theoretical perspective over another. All contribute to an understanding of Centco’s development efforts, and all benefit potentially from an analysis of the social process. Case studies can and have been used to “test” the strength of competing theoretical explanations [Lee 1989; Markus 1983], despite the limitations imposed by the research design (i.e., lack of large samples, control groups, and other experimental conditions). We have excluded one of Kling’s [1980] perspectives (class politics) only because we lack data to illustrate how it might be applied to CentCo. Regardless of the theoretical perspective adopted, an important question to address in future research on the process of ISD is how to reverse repeating patterns of failure. We expect most social processes to persist in the absence of concerted attempts to change them. For example, the beginnings of Periods II and III are not marked by significant efforts to change ISD practices at Centco. Although the periods begin with different events, the larger patterns resemble each other. Supply proposes one course of action; MIS rejects it and proposes another which Supply rejects; promising new information arrives ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996.


.

61

and ultimately leads to disappointment and further rejection. Periods II and III both begin by “restarting” the same process, which reproduces the same pattern and leads to similar results. Period IV begins differently. Instead of restarting the same pattern, fundamental changes are introduced that might be termed “rebuilding.” First, independent leadership (Thompson) is provided to the project, breaking the former practice of assigning the responsibility of developing the system to either MIS or Supply. Thompson indicates clearly that he is not going to depend on Ira for advice, although he subsequently appreciates Ira’s situation better after the trip to ASI with Dom, the MIS leader. Thompson’s actions effect greater agreement between Supply and MIS, and such actions move the practice of ISD from a condition of analyst-led development to a condition of joint development, The result of rebuilding the social process appears to be more constructive than its periodic restarting. The issue raised here suggests a need for theories about social processes to address the question of persistence and change in patterns of social action. Although the outcomes of social processes may be largely indeterminate, it is a practical necessity to gain greater understanding of processes so that counterproductive patterns can be changed. We know that change is often precipitated by an external crisis (e.g., Encounter 18) that challenges the viability of existing practices. But similar events occurred much earlier in Centco’s history and precipitated little change. Why was one crisis an occasion for change while earlier crises were effectively ignored? Theories of social process need to focus on such questions, regardless of their fundamental assumptions about rationality. It is clear that change does not occur simply because actors become aware of the need for change. Our research clearly indicates that actors were aware of the patterns and their negative consequences. Actors talked freely about Centco’s wasteful climate, and they both bragged and lamented about their personal involvement in the social process. Awareness, however, proved to be insufficient to avoid repetition of the pattern. While academic researchers develop more useful descriptions and theoretical explanations of the dynamics of social processes, actors involved in developing information systems can draw some tentative practical implications from this research. From our description of the process model, actors should have the ability to identify, record, and classify the events that occur during an ISD project. Repeating patterns of social action can thus be detected and analyzed. If repeating patterns produce consequences that are unproductive for the organization and damaging to individuals, they can be changed. An active and conscious effort to avoid such problems as those experienced at Centco can begin with an ongoing analysis of social processes. This analysis might indicate where a critical encounter could be designed and implemented. The process model used in this research guides the collection and display of information about the social actions that comprise ISD. When guided by powerful explanatory theory, the analysis could aid in the reversal of troubled systems development efforts or the avoidance of those troubles altogether. ACM Transactions on Information Systems, Vol. 14, No 1, January 1996

62

.


ACKNOWLEDGMENTS

The authors thank Line Dub&, Lei Lei, Guy Par&, Carol Saunders, Wishart for their comments on earlier drafts of this article.

and Nicole

REFERENCES A. AND HRYCAK, A. 1990. Measuring resemblance in sequential data: matching analysis of musicians’ careers, Am. J. SOCiol. 96, 144-185. CAMPSELL, D. T. ANDSTANLEY,J. C. 1963. .Experimental and Quasi-Experimental Research, Rand-McNally, Chicago, Ill. CHURCHMAN, C, W. ANDSCHAINBLATT, A. H, 1965. The researcher and the manager of implementation. Manage. Sci. 11, B69-87. CURTIS, B,, KRASNER, H., AND ISCOE, N. 1988. A fieldstudy of the software design

ASBOIT,

An optimal Designs for A dialectic process for

large systems. Commun. ACM 31, 1268-1287. EISENHARDT,K. M. 1989. Building theories from case study research, Acad. Manage. Reu, 14, 532-550. FRANTZ,D, 1988. B of As plans for computer don’t add up, Los Angeles Times, Feb. 8. FRANZ, C. R. ANDROBEY, D, 1987. Strategies for research on information systems in organizations: A critical analysis of research purpose and time frame. In Critical Issues in Information SystemsResearch,R. Boland and R. Hirschheim, Eds, Wiley, New York, 205-225. GERSICK,C, G. 1991. Revolutionary change theories: A multilevel exploration of the punctuated equilibrium paradigm. Acad. Manage. Rev. 16, 10–36. GLICK, W. H., HUBER, G. P., MILLER, C. C., Don, D, H., ANDSUTCLIFFE,K. M. 1990. Studying changes in organizational design and effectiveness: Retrospective event hi stones and periodic assessments. Org. Sci. 1, 293–312. HtRSCHHEIM,R., KLEIN, H. K., AND NEWMAN, M. 1991. Information systems development as social action: Theoretical perspectives and practice. Omega 19, 587–608. HUBER, G. P. 1984, The nature and design of post-industrial organizations. Manage. Sci. 30, 928-951. KMNG, R. 1980. Social analyses of computing Theoretical perspectives in recent empirical research. ACM Comput. Suru. 12, 1, 61-110. LAUDON,K. C. AND LAUDON,J. P. 1991. Management Information Systems: A Contempomry Perspective. Macmillan, New York. LEE, A. S. 1989. A scientific methodology for MIS case studies, MLS Q. 13, 33-50. LUCAS, H. C,, JR, 1974, Toward Creatiue System Design. Columbia University Press, New York. MABKLW,M. L. 1983. Power, politics and MIS implementation. Commun. ACM 26, 430-444. MARKUS, M. L. AND ROBEY, D. 1988. Information technology and organizational change: Causal structure in theory and research. Manage.Sci. 34, 583-598. MOHR, L. B. 1982. Explaining Organizational Behavior. Jossey-Bass, San Francisco, Calif. MOHR, L. B, 1987. Innovation theory: An assessment from the vantage paint of the new electronic technology in organizations. In lVew Technology as Organizational Innovation: The Development and Diffusion of Microelectronics, J. M. Pennings and A. Buitendam, Eds. Ballinger, Cambridge, Mass., 13-31. MUMFORD,E. AND MACDONALD,W. B. 1989. XSEL’S Progress: The Continuing Journey of an Expert System. Wiley, Chichester, UK. NEWMAN,M. AND ROBEY, D. 1992. A social process model of user-analyst relationships. MIS Q. 16, 249-266. ORLIKOWSKI,W. J. ANDBAROUDt,J. J. 1991. Studying information technology in organizations: Research approaches and assumptions. Inf. Syst. Res. 2, 1-28. SABHERWAL.,R. AND ROBEY, D. 1993. An empirical taxonomy of implementation processes based on sequences of events in information system development. Org. Sci. 4, 548-576. SCHULTZ,R. L, AND GtNZBERG, M. J. Eds. 1984. Management Science Implementation. JAI Press, Greenwich, Corm. ACM Transactions on Information Systems, Vol. 14, No. 1, January 1996.


.

63

S(() PI M( )RT()~. M. S., Ed, 1991. The Corpomtion of the 1990s: Infimmatlon Technology and orgn))~zational Trans/imnatian. Basic Books, New York. s\\,msos.E. R 1974. Management information systems: Appreciation and involvement, Mana#L,. .%. 21. 178-188. s\\,\ ssos, F;.1; 1988 In/imnat/on S,vstcn~ Ir)ipl(>ttientatiort, Irwin, Homewood. [Il. \’.\\ i)~ Vt:X. A H. lWW Suggestions for studying strategy process. .Strat. Manage, .J. 1,?, 169 18s V,\s I)t: V~s. A H. ~~1) P(x)l.K, hl. S. 1990. Methods for studying innovation development in the Tvlinnesota Innovation Research Program. Org. SCl. 2, 313 335. YIN, R. K. 19S4. (’as,> Rtsear(h Lksi#n and .kfethod,s, Sage, Hollywood, Calif. Received February

1993; revised November

1993 and April 1994; accepted September

1994

ACM TransactIons on Information Systems, Vol. 14, No. 1, .January 1996

Sequential Patterns in Information Systems Development: An ...

Sequential Patterns in Information Systems Development: An ...

Suggest Documents

Sequential Patterns in Information Systems ...

Executive information systems development in an ...

Managing change in an information systems development ...

An Economical Perspective on Information Systems Development ...

Information Systems Development as an Activity

Authorship patterns in Information Systems - Semantic Scholar

Computing, Information Systems & Development

Information Systems Development

INFORMATION SYSTEMS DEVELOPMENT:

Mining Conjunctive Sequential Patterns

An Agile Information Systems Development Method in Use

Sequential Information Elicitation in Multi-Agent Systems - arXiv

Application Development in Database-Driven Information Systems

Taxonomy Development In Information Systems: Developing A ...

Information Systems Development in Nigerian Software Companies ...

Information Systems Development in Nigerian Software Companies

Information Systems Development Methodologies in ... - ECIS 2001

information systems development in emergent organizations - CiteSeerX

System Development in Information Systems Research

Information Systems Development in a Developing Country

System Development in Information Systems Research

Gradual Trends in Fuzzy Sequential Patterns - CiteSeerX

Zips: Mining Compressing Sequential Patterns in Streams

FEYERABEND AND INFORMATION SYSTEMS DEVELOPMENT ...