UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Managing MIS project failures : a crisis management perspective Iacovou, Charalambos L. 1999

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_1999-389022.pdf [ 16.09MB ]
JSON: 831-1.0089237.json
JSON-LD: 831-1.0089237-ld.json
RDF/XML (Pretty): 831-1.0089237-rdf.xml
RDF/JSON: 831-1.0089237-rdf.json
Turtle: 831-1.0089237-turtle.txt
N-Triples: 831-1.0089237-rdf-ntriples.txt
Original Record: 831-1.0089237-source.json
Full Text

Full Text

MANAGING MIS PROJECT FAILURES: A CRISIS MANAGEMENT PERSPECTIVE by CHARALAMBOS L. IACOVOU B.Sc, The University of Vermont, 1992 A THESIS SUBMITTED IN PARTIAL FULLFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY in THE FACULTY OF GRADUATE STUDIES Faculty of Commerce and Business Administration We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA January 1999 © Charalambos L. Iacovou, 1999 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of The University of British Columbia Vancouver, Canada Date 1116111 DE-6 (2/88) ABSTRACT This study describes a conceptual framework that portrays information system project failures as organizational crises. The main assumption of this study is that such failures will invariably happen and thus there is a need to make them less costly and more beneficial to organizations. To identify the behaviors and factors that influence an organization's ability to effectively manage a project failure, this dissertation reviews the crisis management literature. Based on this review, a three-stage model is formulated. To understand the mechanisms underlying this model, a number of hypotheses (which are informed by a number of related organizational behavior areas) are generated. These hypotheses focus on three key crisis management factors: the organization's ability to promptly detect an impeding failure, its capacity to manage the failure's impacts, and its propensity to learn from it. To empirically assess the validity of the conceptual model, three case studies of Canadian public organizations were conducted. The empirical findings provide strong support to the model's conjectures and indicate that project failures generate several crisis-related behaviors and responses. More specifically, the findings suggest that an organization's proactive preparation for a failure can have a significant moderating effect on its impact. However, the findings clearly show that an organization's ability to promptly detect (and prepare for) a failure is impeded by behaviors that are motivated by escalation of commitment. Such behaviors lead to a prolonged pre-crisis denial period and have a suppressing effect on whistle-blowing, which is pursued as a denial-curtailing strategy by non-management participants. The empirical findings describe both operational and legitimacy tactics used by organizations to cope with the aftermath of a project failure and indicate that credibility restoration is a significant ii concern during large crises. Finally, the empirical evidence indicates that organizational learning and adaptation are more likely to follow major project failures than less significant ones. This contradicts threat-rigidity arguments and provides support to the failure-induced learning theory. 111 T A B L E OF CONTENTS ABSTRACT II T A B L E OF CONTENTS IV LIST OF TABLES VII LIST OF FIGURES VIII ACKNOWLEDGEMENT IX CHAPTER 1 - INTRODUCTION 1 1.1 OBJECTIVE OF THE DISSERTATION 2 1.2 PERVASIVENESS OF ISD CRISES 6 1.3 UNDERSTANDING ISD CRISES 11 1.3.1 The Elements of an Organizational Crisis 11 1.3.2 The Implications of ISD Crises 13 The Negative Effects of ISD Crises 13 The rewards of ISD Crises 14 1.3.3 The Challenge: Effective ISD Crisis Management 16 1.3.4. Research Questions 18 1.4 DISSERTATION OUTLINE 21 CHAPTER 2 - THEORETICAL FRAMEWORK 23 2.1 THE CRISIS PROCESS.. . 24 2.2 THE CRISIS IMPACT 29 2.3 ISD PRE-CRISIS STAGE 32 2.3.1 The Escalation of Commitment Hypothesis 37 2.3.2 The Whistle-blowing Hypothesis 42 2.4 ISD CRISIS STAGE 45 2.4.1 Managing the Operational Crisis 51 2.4.2 Managing the Legitimation Crisis 52 2.5 ISD POST-CRISIS STAGE 54 2.5.1 Failure-Induced Change Arguments 58 2.5.2 Threat-rigidity Arguments . . 59 2.6 SUMMARY OF HYPOTHESES'.'.'.'.'.'.'....'...' '..'..'....' 63 CHAPTER 3 - RESEARCH METHODS 65 3.1 RESEARCH METHODOLOGY 66 3.1.1 The Case Methodology 66 3.2 RESEARCH DESIGN 71 3.2.1 Case Selection 72 The Northern Utilities Case 77 The Green Valley Hospital Case....'...| ' "^ "..!""!"!!"!""""""I"!"I!l78 The Royal Canadian University Case 81 3.2.2. Data Collection 84 Interviews 84 Documents 87 3.2.3. Data Analysis 89 3.3 SUMMARY OF VALIDATION MEASURES 94 iv CHAPTER 4 - EMPIRICAL FINDINGS 98 4.1 WITHIN-CASE FINDINGS 99 4.1.1 Northern Utilities Case Findings 99 IMIS Crisis Impact 101 IMIS Project Importance 103 Controllability of IMIS' failure ; 105 IMIS Pre-crisis Stage 106 Escalation of Commitment in the IMIS project 110 Whistle-blowing in the IMIS project 114 IMIS Crisis Stage 118 Operational Crisis Management 120 Legitimacy Crisis Management 124 IMIS Post-crisis Stage 128 Summary of NU Case Findings 131 4.1.2 Green Valley Hospital Case Findings 134 IPACS Crisis Impact 135 IPACS Project Importance 137 Controllability of IPACS' failure 139 IPACS Pre-crisis Stage 141 Escalation of Commitment in the IPACS project 146 Whistle-blowing in the IPACS project 151 IPACS Crisis Stage 155 Operational Crisis Management 155 Legitimacy Crisis Management 161 IPACS Post-crisis Stage 164 Summary of GVH Case Findings : 168 4.1.3 Royal Canadian University Case Findings 171 NICS Crisis Impact 172 NICS Project Importance 175 Controllability of NICS' failure 177 NICS Pre-crisis Stage 180 Escalation of Commitment in the NICS project 186 Whistle-blowing in the NICS project 188 NICS Crisis Stage 191 Operational Crisis Management 192 Legitimacy Crisis Management 194 NICS Post-crisis Stage 195 Summary of RCU Case Findings 199 4.2 BETWEEN-CASE FINDINGS 202 4.2.1 Crisis Impact ". 203 4.2.2 Pre-crisis Stage 207 4.2.3 Crisis Stage 2 1 1 4.2.4 Post-Crisis Stage 2 1 3 4.2.5 Summary of Findings 2 i 5 CHAPTER 5 - CONCLUSIONS 219 5.1 IMPLICATIONS FOR RESEARCH 220 5.2 IMPLICATIONS FOR PRACTICE 224 5.3 LIMITATIONS 233 5.4 FUTURE RESEARCH 236 BIBLIOGRAPHY 240 v APPENDIX 1: NORTHERN UTILITIES CASE HISTORY 257 APPENDIX 2: GREEN V A L L E Y HOSPITAL CASE HISTORY 275 APPENDDC 3: ROYAL CANADIAN UNIVERSITY CASE HISTORY 294 APPENDIX 4: INTERVIEW GUIDE 309 APPENDIX 5: INDEX OF COLLECTED DOCUMENTS 322 vi LIST OF TABLES Table 2-1: Crisis Stage Models 24 Table 2-2: Typical Crisis Management Outcomes 27 Table 3-1: Case Characteristics 76 Table 3-2: Participant Demographics 86 Table 3-3: Classification of Interview Questions 87 Table 3-4: List of Descriptive Codes 91 Table 3-5: Case Quality Enhancing Tactics 95 Table 4-1: Role-Ordered Matrix: Attributions of Responsibility for IMIS Failure 106 Table 4-2: Role-Ordered Matrix: Pre-crisis Warning Signs I l l Table 4-3: Actions to Manage the Impact of the IMIS Failure 122 Table 4-4: Case Dynamics Matrix of the IMIS Project 132 Table 4-5: Summary of Hypothesis Assessment in the NU Case 133 Table 4-6: Role Ordered Matrix: Pre-crisis Warning Signs 148 Table 4-7: Role Ordered Matrix: Opinions About Organizational Learning 165 Table 4-8: Case Dynamics Matrix of the IMIS Project 169 Table 4-9: Summary of Hypothesis Assessment in the G V H Case 170 Table 4-10: Case Dynamics Matrix of the NICS Project 200 Table 4-11: Summary of Hypothesis Assessment in the RCU Case 201 Table 4-12: Case-ordered Predictor-Outcome Meta-matrix 204 Table 4-13: Summary of Hypotheses Assessment 216 Table 4-14: Listing of Supported Hypotheses 217 vii LIST OF FIGURES Figure 2-1: Attributes of a Successful Crisis Management Process 26 Figure 2-2: ISD Crisis Management Model 30 Figure 4-1: Event-State Network of the NU Case 100 Figure 4-2: Event-State Network of the GVH Case 135 Figure 4-3: Event-State Network of the RCU Case 172 Figure 4-4: Interaction between Project Importance and Pre-crisis Preparation 206 Figure 4-5: Interaction between Controllability and Impact 215 Figure 4-6: Revised ISD Crisis Model 218 vm ACKNOWLEDGMENT I would like to thank the individuals who participated in this study. I appreciate their time and their willingness to share their thoughts and opinions. I am especially grateful for the trust they placed in me in sharing sensitive, and sometimes controversial, information about their experiences in their organizations. Without their trust, the implementation of this empirical study would have not been possible. I would like to acknowledge the financial support provided by KPMG Canada for one of the case studies. I would like to express my deep appreciation for the time, effort and energy that my committee members invested in my research. Their expertise and ability to guide, listen and provide insightful feedback contributed enormously to the quality of my research and more importantly, to my professional development. Both Dr. Izak Benbasat and Dr. Nancy Langton provided invaluable advice and were always willing to go the extra mile in providing me with the needed assistance. I am especially grateful to my advisor, Dr. Albert S. Dexter, who was always insightful, supportive, and understanding. He made hard work seem a challenge and a delight. I firmly believe that no one else could do a better job in motivating and mentoring me. I feel extremely fortunate for having these three individuals as my teachers and mentors. Their professionalism, thoughtfulness and understanding truly inspire me and guide my daily conduct with my students. I am also thankful for the emotional support that my family and friends, and especially my wife Paula, provided to me during my doctoral studies. Unquestionably, without their support I would not have been able to complete this study. Because of this, I would like to dedicate this dissertation to all of you who made it possible for me to pursue my dreams during my school years: my family, friends and mentors. IX Chapter 1 INTRODUCTION Success is relative. It is what we can make of the mess we made of things. T.S. Eliot Chapter 1 1.1 O B J E C T I V E O F T H E D I S S E R T A T I O N The aim of this dissertation is to empirically investigate failures of information systems (IS) projects by framing them as a special case of organizational crisis. The main premise of this dissertation is that because information systems development (ISD) failures wil l invariably happen, researchers and practitioners should strive to make them less costly and more beneficial to organizations. As my conceptual and empirical work wil l show, I contend that the crisis management (CM) perspective provides a useful framework for understanding and guiding the management of ISD failures. To conceptualize ISD failures, I utilized Lyytinen and Hirschheim's (1987) IS failure definition. Based on an extensive literature review, they defined IS failure as the "inability of an IS to meet a specific stakeholder group's expectations" (p. 263). A stakeholder group is a collection of individuals sharing a pool of values concerning how the IS should serve the group's interests. Past research classified IS stakeholders into three distinct groups: users, business managers, and IS professionals. ISD failure is a subjective concept and is determined by the gap between the group's expectations and the perceived ability of the system to fulfill those expectations. In general, the stakeholders label a project as a failure when (1) no "workable system" is produced (i.e., either the project is abandoned or it produces a useless system) or (2) a system is produced but its development "involves vast amounts of overspending both in cost and time." (Lyytinen and Hirschheim, 1987, p. 265). This notion of ISD failure has been used by several researchers to classify their own work on project abandonment (cf. Ewusi-Mensah and Przasnyski, 1991) and runaway projects (cf. Keil, 1995). 2 Chapter 1 In this dissertation, I investigate ISD failures from a crisis management perspective. I view the ISD failure situation as an example of internal organizational crisis. To portray this viewpoint, I adopted the term "ISD crisis" to describe the process of ISD failures.1 This more accurately reflects the nature of the phenomenon under study. I believe that ISD failure situations represent both an opportunity and a risk and are not always failures per se. IS projects that have run into major problems provide the opportunity for the management to engage in remedial actions in order to mimmize their negative effects and turn them around so that they produce successful systems. This may require additional --and at times, very substantial- resources (in terms of time, cost, number of attempts, etc.). Nevertheless, it may be possible to eventually develop a useful information system with positive net returns (in spite of the additional cost of the corrective actions). Therefore, the classification of all project overruns and abandoned development attempts as failures is misleading and neglects the "opportunities" that are borne is such situations. Unquestionably, there are a number of projects, however, which eventually turn into "true" failures with significant negative ramifications for the people and the organizations involved. In this dissertation, I assert that well-managed ISD crises can turn-around a failing project; mismanaged ISD crises are likely to lead to failure. The use of the C M perspective to examine failed IS projects has important research and practical implications. To examine whether IS project failures can be viewed as 1 "Crisis" comes f rom the Greek word Krisis meaning a moment of decision. I n Greek tragedies, crises were tu rn ing points where h u m a n choice could make a fundamenta l difference to the fu ture (Shrivastava, 1993). 3 Chapter 1 organizational crises, I formulated a comprehensive framework. This framework, which is created from a number of related theoretical streams in organizational behavior, highlights key processes, antecedents and effects of ISD failures. It provides a strong conceptual foundation to the largely atheoretical research on IS failures and can be used to guide future research in this area. The application of the C M model in the area of ISD failures has important implications for C M theorists as well. Firstly, this research contributes to the existing C M body of knowledge by focusing on internal crises. The vast majority of the C M literature has focused on significant external events, such as environmental disasters (cf. Seley and Wolpert, 1988; Fischer, 1991; Bonnieux and Rainelli, 1993) and technological accidents (cf. Starbuck and Milliken, 1988) which create public relations predicaments for the involved organizations. Very little attention has been paid to internal crisis events such as ISD failures. As Flowers (1996) points out, this may be due to the tendency of organizations to avoid publicity when such events take place: When a bridge collapses, a ship sinks, or an airliner falls out of the sky, it is a very public disaster. By comparison, IS disasters are generally private affairs from which individuals and organizations seek to distance themselves in the hope that the details of the failure wil l soon be forgotten. Therefore while such disasters happen with surprising regularity, very little may be known about the events that contributed to a particular IS failure. (Flowers, 1996, 2) By investigating ISD failures as an example of intra-organizational crisis, this research ascertains the usefulness and apphcability of C M conjectures in crisis situations that are mostly contained within the organization. Lastly, this research contributes to the C M literature by integrating disconnected theories and empirically examining contrasting viewpoints to provide a fuller understanding of organizational crisis processes. Specifically, 4 Chapter 1 my framework integrates escalation of commitment with whistle-blowing arguments to study the early stages of failing IS projects. Also, it contrasts threat-rigidity with failure-induced leaning arguments to examine organizational adaptation following an ISD failure. I believe that my empirical investigation is valuable for practical reasons as well. The frequency by which IS projects run into problems and become "failures" is alarming (Standish Group International, 1995; Jones, 1996). Despite the magnitude of this problem, the management of ISD crises has been largely neglected by IS researchers. By utilizing CM concepts and research findings, this dissertation fills this gap by providing guidance to managers when dealing with such projects. More importantly, I believe that the adoption of the CM perspective to examine this phenomenon accurately portrays the dual nature of this phenomenon: the presence of a problem and the potential for turnaround. This highlights the significance of an organization's ability to turn around a troubled project and prevent the materialization of a failure. The following section illustrates the significance of this research by focusing on the widespread nature of IS project failures in organizations. The final section of this chapter frames IS project failures as a form of organizational crisis and discusses the relevant research questions that guided my empirical research study. 5 Chapter 1 1.2 P E R V A S I V E N E S S O F I S D C R I S E S The fact that major, unanticipated problems during the life of IS projects lead to delays, overspending, and the development of ineffective systems is well documented in the IS failure literature (cf. Ackoff, 1967; Morgan and Soden, 1973; Brooks, 1974; Lucas, 1975; Bostrom and Heinen, 1977; Gladden, 1982; Turner, 1982; Keider, 1984; Lyytinen and Hirschheim, 1987; Ewusi-Mensah and Przasnyski, 1991; Flowers, 1996; Jones, 1996; Ewusi-Mensah, 1997). Having realized the risks associated with IS development, several researchers have recommended the use of formal approaches and tools to improve the process and outputs of IS development. Such approaches include formal project management tools (cf. Lucas, 1978; Ginzberg, 1981; Naummann and Jenkins, 1982; Lynch, 1987), sophisticated software engineering methods (cf. Sanella, 1988), automation of the development process using CASE tools (cf. Jander 1987; Vessey, 1995), etc. While the use of such methods and tools contributes significantly to the success of IS development attempts, it would be a gross exaggeration to suggest that their use has diminished the risk of failure. On the contrary, recent reports indicate that IS development problems are far from over (cf. Betts, 1992; McPartlin, 1992; Cringley, 1994; Ellis, 1994; Flowers, 1996; Jones, 1996). A small sample of widely publicized failed ISD attempts illustrates the magnitude of the problem: 6 California's Department of Motor Vehicles (DMV) decided to merge its driver and vehicle registration systems in 1987. At the time, it was estimated that this seemingly straightforward project would be completed by 1993. Instead, the completion date receded to 1998 and the projected cost exploded to 6.5 times the original estimate. In December 1993, seven years and more than $49 million dollars after its initiation, the project was abandoned. As a result, the D M V had to use a system written in 1965 in assembler to process the registrations. To understand the causes of this fiasco, a public inquiry was conducted leading to the resignation of the director of D M V (Ellis, 1995; Green, 1995; Hamilton, 1995). In the early 1990's the British Performing Rights Society (PRS) began the implementation of an integrated Performing Right On-line Membership System to manage the administrative processes of the organization. The new system was to replace a number of proprietary, legacy applications using an open-systems architecture. After a number of delays, the project was abandoned in 1992. During its two and a half years of the project, PRS spent $17 million on the development of the system (Flowers, 1996). The developers of the Denver Airport allocated about $193 million to create a state-of-the-art baggage-handling system. This computerized system was designed to move up to 1700 bags per minute using 4000 telecars running over 20 miles of track and six miles of conveyor belt. Unfortunately, this massive project suffered costly Chapter 1 delays with enormous financial costs due to software problems. It took the developers of the system more than sixteen months and a $45 million extra effort to fix the bugs in the software to make it operational. The unavailability of the system delayed the opening of the facility costing the airport's planners more than $700 million in operating costs, a demotion of their bond rating to junk, and a lengthy investigation by the Securities and Exchange Commission (Stokes, 1995; Hume, 1996; Stokes, 1996). In the late 1980's, the London Ambulance Service, which is the largest ambulance service in the world, initiated its first computerization project that would allow dispatchers to transmit information to the vehicles. After spending $11.25 million for its development, the service abandoned the project because it was not able to handle its daily load. Within a year, another project was initiated to introduce a more sophisticated, computer aided dispatch system. The system went live on October 26, 1992 and was shut down the next day because of massive "exception reports" and "lost emergency calls". After attempting to operate the system in a semi-manual mode for a few weeks, the system was totally abandoned (Flowers, 1996). In 1988, a consortium comprised of Hilton Hotels, Marriott, and Budget Rent-A-Car Corporations subcontracted to AMRIS (a subsidiary of American Airlines), the development of a leading edge travel industry reservation system (CONFIRMS). Originally, the system was expected to cost $55.7 million. During the life of the 8 Chapter 1 projects, various delays and cost re-estimates were announced. Three-and-half years after the project had begun and a total of $142 million had been spent, the project was canceled. This led to multimillion-dollar legal battles between the partners (which led to an out-of-court settlement in 1994) and the firing of many top executives by AMRIS. (Oz, 1994; Flowers, 1996). • Two IBM systems integration projects of the US Air Force's early warning systems in California and Colorado were delayed for five years. More importantly, the original estimated cost of these two projects was $600 million; the actual cost was $1.95 billion ("Air Force Misses Target," 1989). • In a study of software projects, the U.S. government's General Accounting Office (GAO) discovered that, out of the nine software projects in the study (costing a total of $6.8 million), projects worth $3.2 million (47 percent) were delivered but not used, $2.0 million-worth (29 percent) were paid for but not delivered, and $1.3 million-worth (19 percent) were abandoned or reworked (Forester and Morrison, 1990). Some readers may conclude that these cases are isolated incidents and do not accurately reflect the current state of the IS development efforts. The following statistics are more convincing: Based on a survey of 6,700 projects, Jones (1996) estimates that over 23 percent of all projects are likely to be cancelled (for large projects, the likelihood of cancellation 9 Chapter 1 can be as high as 65 percent). Of the large systems that are completed, about two-thirds experience schedule delays and cost overruns (which may be as high as 100 percent of the original estimates). • According to a survey of 365 firms (representing 8,380 projects) by The Standish Group International, 31.1 percent of all ISD projects are canceled before completion; 52.7 percent of them cost more than 180 percent of their original estimate; the average project schedule overrun is 222 percent; and only 16.2 percent of ISD projects are completed on-time and on-budget (for large companies, this estimate is a low nine percent) (Standish Group International, 1995). • According to a survey of 150 corporate IS managers by the Center for Project Management, half of all projects become runaways (LaPlante, 1995). • According to Gibbs (1994), for every six new large-scale systems that are put into operation, two others are canceled. • According to a survey of 300 large companies by KPMG Peat Marwick, 65 percent of organizations have gone "grossly" over budget on at least one project (Cringley, 1994). There is no doubt that ISD failures do and will continue to occur in organizations. Even though a significant research effort has been invested into understanding their causes, no 10 Chapter 1 study has yet investigated the post-failure management of ISD projects. Given the propensity of IS projects towards failures, I feel it is no longer appropriate to consider if a project will run into trouble but rather what to do when it happens. To do so, researchers must view IS project failures as an organizational phenomenon and examine its antecedents and consequences. I posit that by framing project failures as a type of organizational crisis, researchers can more fully understand both their negative effects and benefits and begin developing effective strategies for managing them. 1.3 UNDERSTANDING ISD CRISES 1.3.1 The Elements of an Organizational Crisis The term "crisis" has been used in research to describe a diverse set of organizational events (Pearson and Clair, 1998). Based on an extensive review of the CM research, I have cataloged the essential features of a crisis situation. Organizational crises are: (1) low probability events (Weick 1988; Pearson and Mitroff, 1993) that (2) allow a restricted amount of time in which a response action must be taken (Hermann, 1963, Wilks and Dyson, 1983), (3) are beyond the complete control of the involved organizations, partly due to ambiguity of cause and effect (Dutton, 1986; Jackson and Dutton, 1988; Kast, 1990; Morin, 1993; Pearson and Mitroff, 1993; Pearson and Clair, 1998) and (4) have threatening consequences for the organizations facing them (Hermann, 1963; Wilks and Dyson, 1983; Weick, 1988; Shrivastava, 1993). 11 Chapter 1 There is no doubt that ISD failure situations possess the above four characteristics of a crisis (surprise, urgency, deficiency and threat). An IS project that fails is usually an unanticipated event for many of the involved parties (some of them of course are surprised sooner than others). When such a failure occurs, there is a need to promptly take actions to rectify the situation and satisfy the original need for the system (e.g., initiation of a replacement project or acquisition of a third-party solution). A project failure situation can be a difficult predicament for the project team or the organization as a whole as the resources needed to "turn around" the project may not be available. This may be because the organization as a whole lacks the needed "crisis management" resources or simply because senior management may restrict the abihty of the project team to control and rectify the situation (e.g., by limiting funds to acquire a new system or additional staff, reducing its support to the project, or transferring control of the project to an outside party). Lastly, a project failure will have threatening effects on the current or future operations of the organization and will likely impact the reputation and crechbility of the project team and the organization. Such impacts wil l require the organization to respond to the crisis to protect its operations and its image. Wasting organizational resources on failed projects can obviously attract the scrutiny and criticism of many stakeholders (shareholders, customers, auditors, etc.) with negative effects on the perceived legitimacy of the IS professionals and the organization as a whole. 2 2 As I do not believe tha t a l l project fai lures can satisfy the threat requi rement of organizat ional crises, I l i m i t my examinat ion to fai lures of strategic IS projects (i.e., projects of h igh importance). This ensures tha t the ISD fa i lure is more l i ke ly to impact the whole organizat ion and indeed be perceived (and managed) as a crisis. 12 1.3.2 The Implications of ISD Crises Chapter 1 ISD crisis situations have important implications for the individuals and organizations involved. There is no doubt that the majority of them are negative. However, ISD crisis situations provide opportunities to managers to reduce these negative effects and reap certain benefits. The major consequences of ISD crises, both negative and positive, are examined below. The Negative Effects of ISD Crises Reduced Returns. IS projects are initiated to either solve a business problem and/or take advantage of a business opportunity. These objectives are not met until the system is put in successful use. In the case of runaway projects, the system's net benefits usually diminish (due to increased development costs) and their materialization is delayed (due to schedule slips). None of the expected benefits materialize if the project is abandoned or produces an ineffective system. In such cases, replacement or alternative projects need to be initiated to accomplish the failed project's goals (Dearden, McFarlan, and Zani, 1971; Flowers, 1996). Opportunity costs. All financial, human and technological resources that are depleted in a project have an opportunity cost. ISD crisis situations usually require additional resources in order to turn around the project, which increase this opportunity cost. And if the project eventually becomes a failure (i.e. the project is completely abandoned), the 13 Chapter 1 resources consumed by it are losses to the organization. The examples that were described in the previous section of this chapter illustrate the magnitude of financial losses that can incur due to project failures. User dissatisfaction and alienation. When a project fails or is delayed, users must continue using the old (and sometimes manual) system causing frustration and disappointment. Such incidents lead to unfavorable perceptions and attitudes towards the MIS staff (Lucas, 1975) and create misgivings about the ability of MIS staff to develop successful systems (Doll and Ahmed, 1983; Fiegener and Coakley, 1995). These negative perceptions increase resistance towards future development work (Newman and Robey, 1992) and introduction of new technologies (Rai and Howard, 1994), reduce trust, cooperation and support from users and management (Senn 1978; Brown, 1991), and lead to dissatisfaction, disuse, and rejection of systems (Robey, 1979; DeSanctis, 1983; Baronas and Louis, 1988). The resulting alienation of users is significant given the critical importance of user cooperation in development work (cf. Cerullo, 1980; McFarlan, 1981; Markus, 1983; Ives and Olson, 1984; Tait and Vessey, 1988; Lin and Ashcraft, 1990; Lin and Hsieh, 1990; Barki and Hartwick, 1994; McKeen, Guimaraes, and Wetherbe, 1994). The rewards of ISD Crises Most of us assume failure is inherently bad. Some organizational theorists, however, argue that failure has important intrinsic rewards: organizational learning and adaptability. Sitkin (1992) argues that success creates many Habilities that "strategic failure" can address. 14 Chapter 1 He argues that success can lead to complacency, restricted search, low levels of attention, and homogeneity leading to reduced organizational learning. Failure can address these organizational shortcomings by offering a number of advantages. A failure can increase attention to potential problems, ease recognition and interpretation of such problems, stimulate search processes, motivate the organizational members to adapt, and increase risk-seeking and variety in organizational responses (Sitkin, 1992). While success leads to reliability (which is important for short-term success), Sitkin argues that failure leads to resilience (which is critical for long-term success). Similarly, Miller (1994) argues that organizations with lengthy intervals of success exhibit many attributes that inhibit adaptation. Based on an empirical study, he found that "successful" organizations exhibit (1) inertia in structure and decision making processes, (2) immoderation and adoption of extreme process orientations, (3) inattention due to reduced intelligence gathering and information processing, and (4) insularity by fading to adapt to environmental changes. Starbuck and Milliken (1988) pointedly illustrate the value of a crisis-based organizational learning: One is reminded of Gregory Bateson's metaphor about a frog in hot water: A frog dropped into a pot of cold water will remain there calmly while the water is gradually heated to a boil, but a frog dropped into hot water will leap out instantaneously. (p. 337) In the case of IS development, it can be argued that crises provide the opportunity to clearly identify weaknesses in the IS development process so that corrective actions can be taken to prevent similar incidents from taking place in the future. Moreover, one can argue that because of the newness and uncertainty that is inherent in technological innovations there are certain lessons that cannot be learned without trial and error. For example, the full 15 Chapter 1 extent of the capabilities of certain technologies can not be truly assessed without the experience of trying to build a system using the technology (Sitkin, 1992). A number of other researchers have discussed the importance of failure-based organizational learning in their writings (cf. Bignell and Fortune, 1984; Petroski, 1985; Fortune and Peters, 1995). More recently, two MIS researchers examined this issue within the context of I S project failures. Flowers (1996) argues that most organizations establish "a code of silence" after ISD failures, severely impeding the organizational learning process: While this closed approach to IS failure may arguably be good for the corporate image, it effectively stunts the development of a widespread management awareness of the pitfalls of IS development. Indeed, it could be argued that one outcome of this approach is that it effectively ensures that business organizations becomes locked in a cycle of failure, with each condemned to repeat the mistakes of others. Indeed, in the words of George Santayana: "Progress, far from consisting in change, depends upon retentiveness. Those who cannot remember the past are condemned to repeat it." (Flowers, 1996, p. 2) Ewusi-Mensah (1997) argues that post-failure formal audits are necessary for effective organizational learning. Such audits should examine "all aspects of the development effort with a mandate to uncover the underlying root causes and reasons for the failure" (Ewusi-Mensah, 1997, 80). He argues that such efforts will not only assist in improving the development practices and procedures of the organization but, most importantly, will be beneficial to improving the practices of the whole IS development industry. 1.3.3 The Challenge: Effective ISD Crisis Management When faced by crises, managers engage in crisis management in an effort to avert them or to 16 Chapter 1 effectively manage those that do occur. In general, crisis management efforts are deemed to be effective "when operations are sustained or resumed (i.e., the organization is able to maintain or regain the momentum of core activities necessary for transforming input to output at levels that satisfy the needs of key customers), organizational and external stakeholder losses are minimized, and learning occurs so that lessons are transferred to future incidents" (Pearson and Clair, 1998, 60). In the case of ISD failures, I argue that effective management of an ISD crisis requires managerial actions that minimize the losses (by taking advantage of turn-around opportunities or by containing the negative impacts of the ISD failure) and capitalize on the learning value of the ISD crisis. The primary of goal of this research is to empirically assess the factors that affect the ability of organizations to cope with their ISD crises. In general, it seeks to address the following research problem: Research Problem: How do organizations manage their ISD crises and their impacts? The effectiveness of a crisis management effort depends on its ability to meet three objectives. As Pearson and Mittroff (1993, 48) state, effective crisis management requires organizations to "be equipped to anticipate, respond to, and learn from their crisis experiences." In other words, successful crisis management requires (1) the early recognition and avoidance of/preparation for the crisis before it materializes, (2) appropriate response and containment of the damage during the crisis, and (3) organizational learning and adaptation after it (Meyers and Holusha, 1986; Pearson and Mitroff, 1993; Reilly, 1993; Pearson and Clair, 1998). The factors and processes influencing the ability of organizations to respond to these three demands are the main foci of this dissertation. 17 Chapter 1 1.3.4. Research Questions Extensive empirical research indicates that early warnings signs indicating that a crisis may be imminent are frequently present before a failure (Pearson and Clair, 1998). As Mitroff et al, (1988, p. 104) point out, "the first and perhaps single most important lesson [in crisis management] is that prior to its actual occurrence, nearly every potential crisis is thought to leave a repeated trail of early warning signals." In the case of ISD failures, these signals may include dissatisfied users expressing their concerns (Ginzberg, 1981), time and cost overruns (Keil et al, 1994), and lack of system acceptance (Keil, 1995). In many cases, such signs usually remain undetected by project managers who are not willing to accept the negative information about the performance of their project. This leads to non-prevention and mis-preparation for the crisis increasing the likelihood of a failure with significant negative effects (Mitroff et al., 1987). Smith (1990) describes this tendency as a "crisis of management" as the actions -or inaction- of management usually promulgates the development of an escalating crisis. The process of ignoring warning signs has been studied in-depth by escalation researchers (cf. Staw and Ross, 1987). Consistent with previous observations by crisis researchers, I believe that warning signs are largely ignored during ISD pre-crisis periods (cf. Jones, 1996). Indeed, Keil (1995) found that solid negative information about the performance of a major IS project was repeatedly ignored by managers. In a survey of abandoned projects, Ewusi-Mensah and Przasnyski (1991) found out that 35 percent of such projects are not canceled until the last stage of their 18 Chapter 1 development life cycle. To examine the crisis-detection and crisis-preparation capabilities of organizations when faced by ISD crises, this dissertation addressed the following research question: Research Question 1: Why are organizations unable to promptly detect and respond to the early warning signs of failing strategic IS projects? When the crisis reaches a point of no return (the acute crisis phase), the failure signs are too strong and cannot be ignored any further. At this point, the organization is usually forced to acknowledge the existence of a crisis and takes action to contain the damage and to return its operations to normalcy (Mitroff et al., 1987). In the case of ISD crises this may refer to the point when an announcement is made that the project is in major trouble and plans are initiated to rectify the situation (e.g., the company hires an external consultant to assist with the development of the project). This is the most critical point in the crisis process. The correct decision can "turn around" a failing project; the wrong one can result in an ISD failure and create a major problem for the whole organization. If, for example, the project manager continues to be in denial, this process may be delayed resulting in large financial losses to the organization and a major blow to the credibility of the project team. Although the overall goal during this stage is to "turn around" the situation and reduce the damage, very little is known about how organizations accomplish this. As Quarantelli (1988) pointed out, crisis management literature provides the overall strategy for managing a crisis but not specific tactics. Each crisis situation requires specific tactics to manage its impacts. 19 Chapter 1 In the case of ISD failures, very little is known about how organizations establish priorities during the climax of ISD crises and how successful their tactics are in managing the crisis situation. Thus, this dissertation explored the following research question: Research Question 2: How do organizations manage the aftermath of failed strategic IS projects? After the acute crisis is over, the organization can potentially learn from it and adapt in order to prevent simdar situations and be better prepared in dealing with them in the future. This organizational learning usually requires reform of organizational procedures. Smith (1990) labels this the "legitimization crisis" stage, as there is a need to restore legitimacy and external confidence in both the managerial structure and operations of the organization. For example, in the case of an ISD failure, managers may decide to reform implementation policies, development tools, or vendor selection criteria depending on the cause of the ISD failure. There is no guarantee, however, that a learning process will take place. If managers are still in shock and disbelief and are not willing to accept the "root" causes of the crisis they may learn nothing or the wrong lessons (Mitroff et al., 1987). They may, for example, attribute the failure to external factors and retain their old values and processes placing the organization in risk again. Lack of an appropriate response to the failure (especially by the IS department) may further anger senior management (and other stakeholders) resulting in drastic changes (such as the termination of IS executives, restructuring of the IS department, etc.). Indeed, externally imposed change is frequently one of the consequences of a major crisis due to the lack of proactive organizational learning (Meyers and Holusha, 1986). To date, no study has examined whether organizations indeed adapt in response to ISD failures. 20 Chapter 1 To explore this issue, this dissertation addressed the following research question: Research Question 3: Do organizations capitalize on the learning value of their IS project failures? I believe that these three research questions are important in attaining a full understanding of ISD crisis situations. The answers to' these questions will enable researchers to better understand the organizational phenomenon of ISD crises and allow managers to formulate appropriate strategies for managing troubled IS projects and the aftermath of their failures. 1.4 DISSERTATION OUTLINE To address these three research questions, I formulated a theoretical framework describing the key processes and factors associated with the advent and management of ISD crises. Chapter two discusses the framework and describes a number of related organizational theories supporting the framework's assumptions and propositions. These theories were integrated into a comprehensive model to generate specific hypotheses and define the scope of the empirical investigation that took place. To empirically assess these propositions, three in-depth case studies were conducted. Chapter three describes the methods that were utilized to carry out the empirical investigation. This chapter discusses the appropriateness of the case method for this investigation, provides information about the specific organizations that comprise the cases, and describes the data collection and 2 1 Chapter 1 analysis techniques that were utilized in this research. Chapter four provides a summary of the empirical findings by discussing the results of the within-case and cross-case analyses. It also relates study findings to the existing CM and MIS literature. Chapter five discusses the implications of this research for MIS and CM researchers and practitioners, describes the limitations of this study and provides suggestions for further investigation. 22 Chapter 2 THEORETICAL FRAMEWORK Storms pass, but their driftwood remains Ancient Proverb 23 Chapter 2 2.1 THE CRISIS PROCESS Even though the CM literature is quite diverse and crosses many disciplines, the vast majority of it is based on a well-defined arid widely accepted process framework depicting the stages of a crisis. According to this framework, a crisis can be conceptualized in three distinct phases: pre-crisis, crisis, and post-crisis. Although the various CM researchers use different concepts to describe each stage (see Table 2-1), they are in agreement about the nature of the events and behaviors that transpire during each stage.3 This three-stage framework provided the conceptual foundation for this dissertation. This chapter discusses the main premises and assumptions of the framework and explores them using well-accepted organizational theories. Based on this theoretical examination, I developed a number of hypotheses that describe the research model. These were assessed during the empirical part of this dissertation. Table 2-1: Crisis Stage Models Meyers & Holusha (1986) Fink (1986) Smith (1990) Booth (1993) Pre-crisis Prodromal Crisis of Management Shock/Denial Crisis (Acute and Chronic) Crisis Operational Crisis Acknowledgment Pos t -c r i s i s Crisis Resolution Crisis of Legit imizat ion (Mal)adaptation The crisis stage framework posits that during the early part of a developing crisis (the pre-crisis stage), warning signs about the impending failure are usually visible. In most 3 For th is study, I adopted Fink 's (1986) labels to describe these stages due to the i r s impl ic i ty. 24 Chapter 2 situations, such signs are ignored. As a result, the organization is not likely to take effective steps to avoid the crisis or appropriately prepare for it. In other cases, such warning signs are promptly detected alerting the organization to prepare for the failure and, if possible, take steps to avoid it all together. Assuming the crisis eventually materializes (because the organization did not detect it or was unable to avoid it), when it reaches its climax, its impact tends to attract the attention of affected managers and other stakeholders and attempts to manage it are initiated. During this crisis stage, organizations that were in denial are forced to acknowledge the failure's existence (even though in extreme cases some organizations may continue to ignore it further heightening its negative impacts). In most cases, managers engage in intense crisis management efforts to contain its damage and protect the organization's operations. In other cases, such attempts may be superficial or non-existent leading to a poor management of the crisis. After the crisis has subsided (assuming it was not consequential enough to cause the failure of the whole organization), it is possible that the organization will alter its behavior to reflect the lessons learned from the crisis and to adapt to its new post-crisis environment. Unfortunately, crisis-based organizational learning is not universally pursued in failure cases (Fink, 1986; Meyers and Holusha, 1986; Smith 1990; Booth, 1993; Pearson and Clair, 1998). As mentioned in Chapter One, a crisis can be successfully managed if the organization prepares for, appropriately responds to, and learns from it (see Figure 2-1). However, the CM Literature shows that in reality most organizations are not able to successfully manage 25 Chapter 2 all three aspects of their crises. Of course, some crises are easier to manager than others; at the same time, some organizations are better at managing their crises than others. Despite these differences, however, Pearson and Clair (1998) argue that the typical organizational response to a crisis contains both elements of success and failure, leading to "midground outcomes" (see Table 2-2 for a classification of common outcomes of crisis management efforts). Figure 2-1: Attributes of a Successful Crisis Management Process Pre-crisis Crisis Post-crisis Preparation — > Crisis Mamgement — • Adaptation Unfortunately, researchers subscribing to the CM process framework do not provide theory-based explanations for the diversity of the organizational responses to crises. The lack of explanatory arguments (identifying the factors that affect an organization's response to a crisis) in the CM process framework is troubling. However, it appears that such a lack of predictability is a liability found in virtually all pure process models (Shaw and Jarvenpaa, 1997). Even though process models, such as the CM one, are valuable in representing stages and events and the temporal and sequential relationships among them (Mohr, 1982; Markus and Robey, 1988; Orlikowski and Baroudi, 1991), they tend to ignore key factors that influence these events. In other words, pure process models describe 26 Chapter 2 events that occur during a process, but fail to identify key factors that explain why these events take place: The path from one event to the next in a process model is probabilistic, or subject to random external forces that may cause the path to deviate. The path is inherently unpredictable. (Shaw and Jarvenpaa, 1997, p.7). Table 2-2: Typical Crisis Management Outcomes CRISIS CONCERN FAILURE MIDGROUND SUCCESS Signal d e t e c t i o n A l l signals of impeding crisis go ignored Organizat ion is caught completely unaware Signals of potent ia l crisis send organizat ion into stage of alert Signals are detected early so tha t the appropriate responses are brought to bear I n c i d e n t c o n t a i n m e n t Crisis escapes beyond boundaries of organizat ion Ex te rna l stakeholders are negatively impacted Damage to those beyond organization boundaries is s l ight Major impact is total ly confined w i t h i n organizat ion There is no stakeholder in ju ry or death Business r e s u m p t i o n A l l organizat ion operations are shut down Down t ime is lost i n br ing ing organizat ion back to operat ion Areas of operation most affected by crisis are closed temporar i ly Funct ional down t ime is m i n i m a l w i t h l i t t le effect on product/service Business is main ta ined as usual dur ing and after crisis There is no loss of product or service del ivery Effects on learning No learn ing occurs Organizat ion makes same mistakes when s imi lar incident occurs Learn ing occurs but i ts disseminat ion is spotty Organizat ion changes policies/procedures as a resul t of crisis Lessons are appl ied to fu ture incidents E f fec t s on r e p u t a t i o n Organizat ion suffers long-last ing repercussions Indus t ry reputat ion suffers as a resul t of crisis Public perceives organizat ion as a v i l l a in as a resul t of ineffective crisis management Negative effects of crisis are short l ived Public perceives errors i n details of crisis management effort but continues to consume product/service as usual Organizat ional image is improved by organization's effectiveness i n managing crisis Organizat ion is perceived as heroic, concerned, caring and a v ic t im Resource availability Organizat ion scrambles bu t lacks essential resources to address crisis Organizat ion scrambles and scrapes by own and others' ad hoc assistance Organizat ion or external stakeholders' resources are readi ly available for response Decision making Slow i n coming because of in te rna l conflicts Fantasy dr iven Slow i n coming because of extraorganizat ional constraints Ample evidence of t imely, accurate decisions Grounded i n facts Source: Pearson and Clair (1998). 27 Chapter 2 To address this shortcoming of process models, researchers have recommended the development of hybrid models by integrating factor and process constructs (Shaw and Jarvenpaa, 1997). Consistent with this recommendation, and to address the predictability liability of the CM framework, I identify and discuss key factors that influence the events that take place during each stage of a crisis. As a MIS investigator indicated in a survey of process researchers, such factors are critical in understanding the driving forces of the process events: [W]hen people look at stage models they tend to focus on the stages. But the real key is the transition between stages, and the mechanism underlying this. (Shaw and Jarvenpaa, 1997, p. 27) Even though Mohr (1982) criticized the integration of factors and processes in hybrid models, he implicitly highlighted the close relationship between factors and processes by recommending that the researchers focus on "precursor" and "outcome" variables (factors) associated with each process. Furthermore, more recent scientific thinking in MIS forcefully rejects Mohr's arguments: Each hybrid form is able to answer a research question or to arrive at a conclusion that would not be possible from a pure process or variance model. So rather that failing, as Mohr implied, these models succeed at furthering our knowledge of important IS issues. (Shaw and Jarvenpaa, 1997, p. 13) Although I concurred with Shaw and Jarvenpaa's (1997) assertions about the usefulness of 28 Chapter 2 hybrid models, I wanted to avoid the "model blurring" effects that exist in such models. To achieve this, I state the formal theoretical propositions in factor-based terms only. The remainder of this chapter discusses the theoretical framework in detail (see Figure 2-2). First, I define the main construct of interest, the crisis impact, and discuss two factors that significantly affect it. Next, I discuss each crisis stage in detail. For each stage, I review the CM literature identifying the events and behaviors that are expected to take place in it. Then, I identify key factors that are expected to influence (and be influenced by) these events and behaviors. These factors were identified based on a review of the empirical and theoretical research in relevant organizational areas. Lastly, I summarize my arguments by formulating specific hypotheses that were assessed empirically using three case studies. 2.2 T H E CRISIS IMPACT The main research issue of this dissertation deals with a key concept in the CM literature: the crisis impact. Crisis impact is a multidimensional construct and refers to the consequences that the crisis has on the organization experiencing the ISD project failure. It refers to the total negative effects that the crisis has on the resources (financial, human, legitimacy, strategic positioning, etc) and operations of the affected organization. Failures of major systems that cost an organization millions of dollars in losses, severely affect its 29 Chapter 2 Figure 2-2: ISD Crisis Management Model 30 Chapter 2 operations and become public are classified as high impact crises. On the other hand, failures that are contained within an organization, have insignificant or no consequences on its operations and do not cause large financial losses will be considered to be low impact crises. For example, a failure of a well-publicized large, strategic marketing IS project that severely impedes the ability of an organization to introduce a new line of products would be classified as a high impact crisis; the cancellation of a small upgrade project that would have simply improved the interface of an internal email system for a small department would have little or no negative effects and would thus be classified as a low impact crisis. In general, two factors are expected to significantly influence the ISD crisis impact in an organization: (1) the project's importance to the organization and (2) the apparent ability of the organization to prevent its failure (controllability) (Schlenker, 1980). Project importance refers to the significance that the organization places on the system under development. This includes the strategic potential and urgency of the system. In the MIS literature, in addition to subjective assessments (cf. Keil, 1995), researchers have used a number of surrogate measures to assess this construct, including project size and complexity indicators (cf. Ewusi-Mensah and Przasnyski, 1991). In general, there should be a correlation between the importance of the project and the resources devoted to it. Thus, once the project fails, one expects that the financial losses will be higher for more important, larger projects (Jones, 1996). Furthermore, the failure of strategic projects is more Likely to impact the organization's operations and threaten the credibility of its senior managers (Flowers, 1996). Thus, I hypothesize that in the case of IS project failures: 31 Chapter 2 Hypothesis 1: Project importance will lead to greater ISD crisis impact. It is important to note that for this dissertation, I largely focus my arguments and empirical investigations on failures of strategic systems (i.e. projects of high importance). As I pointed out in Chapter One, for an event in an organization to be classified as a crisis, it must be significant enough to rise above the routine organizational "noise" and threaten an important aspect of the organization (financial resources, operations, strategic positions, legitimacy, etc.). As I doubt that the failure of minor, non-strategic IS projects can satisfy this requirement, I excluded them from my investigation. Controllability refers to the extent that the organization is perceived as responsible for its project's failure (Weiner, 1986). It is the perceived responsibility that is assigned to the organization (or its sub-units) for the cause of the failure. In general, one expects that project failures that are caused by conditions beyond the control of the organization (such as changes in the computing environment, vendor incompetence, etc.) will have a smaller impact on the creditability of the organization and the project team (cf. Schlenker, 1980; Pearson and Clair, 1998). In contrast, when the failure of the project is attributed to internal causes (such as incompetence of internal staff, lack of planning, etc.), the impact of the crisis on the legitimacy of the organization is likely to be consequential (Staw, Sanderlands and Dutton, 1981; Mone, McKinley and Barker, 1998). Thus, I expect that: 32 Chapter 2 __ Hypothesis 2: Failure controllability will lead to greater ISD crisis impact. In addition to the above two factors, the impact of an ISD crisis is largely determined by the actions that the organization undertakes in preparing for, managing and learning from the crisis. A well-managed ISD crisis can effectively negate many of the negative consequences of the above two factors; a mismanaged crisis can only worsen their negative effects. Finally, it is important to recognize that the magnitude of a crisis impact does not remain constant throughout the crisis process. Partly due to the managerial actions and partly to the effects of time, it changes during the course of the crisis. In general, it is hypothesized that the relationship between a crisis impact and time follows an inverted U -shape: The pain produced by a crisis follows a predictable path over time. In the pre-crisis phase, it increases slowly. When the actual crisis strikes, the pain shoots upward like an angry fever until it climaxes. As the crisis passes, it slowly declines, but it ends at a level higher that it was before the episode began. (Meyers and Holusha, 1986, p. 15) The following three sections examine the behaviors and events that influence the ISD crisis impact during the various stages of this process. 2.3 ISD PRE-CRISIS STAGE Crisis management theorists overwhelmingly agree that before each crisis there is a period during which "you know something is wrong, but just what, you are not clear" (Meyers and Holusha, 1986, p. 13). Indeed, research shows that such signals are present in the early 33 Chapter 2 stages of failing ISD projects (Ginzberg, 1981; Gladden, 1982; Jones, 1996). In most cases, organizations are unable to promptly detect such warning signs and act accordingly (Meyers and Holusha, 1986; Smith, 1990; Booth, 1993). In other cases, the pre-crisis warning signs seem to be detected early leading to an effective crisis preparation (or sometimes, avoidance) effort (Fink, 1986; Pearson and Clair, 1998). Crisis preparation refers to the actions that the organization undertakes to prepare for and/or avoid an impending crisis. Unfortunately, research shows that in most cases, organizations do not engage in effective crisis preparation because they ignore the early warning sings (Fink, 1986; Pearson and Clair, 1998). In many cases, even though non-performance information exists, no action is usually taken because such information is treated as part of the normal "background noise" in projects. For example, negative information about the functionality and performance of the system is frequently attributed to users' resistance to change instead of the low quality of the system. This is partly due to the fact that it is often impossible to discriminate between the first warning signs of an impeding project failure and the everyday, minor troubles that all projects face. As more negative information continues to emerge, however, project managers should be more likely to perceive and label the situation as a crisis (Billings, Milburn and Schaalman, 1980). Unfortunately, research shows that even when ample negative information exists about a project, many managers tend to enter into a "prolonged period of denial" (Meyers and 34 Chapter 2 Holusha, 1986, p. 14). During this denial phase, organizational units are likely to constrict and distort information exchange, avoid and hinder joint problem solving with their "adversaries" and are likely to seek risk and resist concession making (Gladwin and Kumar, 1987). This leads to a manifestation of a "delayed reaction syndrome" which is defined vas the "reluctance of organizations to invest in crisis management planning until conclusive evidence is available that there is a problem" (Booth, 1993, p.l). By this time, however, it is usually too late to prevent the crisis from materializing.4 These arguments are supported by extensive empirical work that found that significant evidence of an imminent failure is largely ignored by managers before they publicly admit that a crisis exists (Fink, 1986; Smith, 1990; Pearson and Mitroff, 1993; Smith and Sipika, 1993). In the case of MIS failures, preliminary empirical evidence seems to suggest that such warning signs are indeed present but remain ignored. An experiment by Keil, Mixon, Saarinen and Tuunainen (1994) indicates that such denial is more Likely to take place in large IS projects. This is consistent with the findings of a number of case studies (Keil, 1996; Flowers 1996; Jones, 1996). These cases indicate that large IS projects seem to suffer from the "delayed reaction syndrome," resulting in major failures causing the organizations millions of dollars in financial losses and in many cases, a public embarrassment. Similarly, surveys indicate that a large proportion of ISD failures are not recognized until the very last stage of the development process (Ewusi-Mensah and 4 Th is process of i n i t i a l denial, fol lowed by shock, anger and acceptance is prevalent i n many si tuat ions of potent ia l loss, inc lud ing death (cf. Kubler-Ross, 1969). 35 Chapter 2 Przasnyski, 1991) at which point the Ukelihood of successful recovery is almost nil (Jones, 1996). Given the theoretical and empirical evidence that exists, I believe that the delayed reaction syndrome will be present in the pre-crisis stage of failing ISD efforts. The hypothesized reluctance to admit - in a timely manner - the existence of an impeding failure is consequential for two reasons. Firstly, it is important to detect failures early to cut the losses short. As Weick (1988) points out, "errors are less likely to enlarge if they are understood more fully, more quickly" (p.308). Frequently, managers ignore the signs of failing IS projects and continue to pour resources in them hoping that the problem will go away. This leads to expensive, runaway projects that fail to produce successful systems (cf. Keil, 1995) or to projects that are canceled in the later stages of their life cycle, costing organizations millions of dollars (cf. Boehm,1981; Ewusi-Mensah and Przasnyski, 1991; Jones, 1996). Secondly, it is critical to identify such crises early so that the organization can prepare for the ISD crisis and to plan a turn-around strategy. Research shows that the labeling of a situation as a crisis results in action of large magnitude that involves high-level executives (Dutton and Jackson, 1987). Moreover, it shows that being prepared to deal with a crisis is associated with the short-term effectiveness of the organization's response to it (Banerjee and Gillespie, 1994). A similar pattern was identified by Jones (1996) regarding ISD failures: The probability of a successful recovery for a project in trouble correlates very strongly with the point at which the problems are first recognized. As with various medical conditions, early diagnosis can often lead to successful therapy programs. Conversely, the later the point at which the condition is recognized, the lower the prognosis for a successful recovery. (p. 34) 36 Chapter 2 In summary, CM research indicates that alert and well-prepared organizations are more likely to successfully contain the impact of their crises, whereas organizations ignoring the warning signs of their impeding crises are more likely to contribute to their escalation. Given the positive effect of early crisis detection and preparation, I hypothesize that: Hypothesis 3: Pre-crisis preparation will lead to lower ISD crisis impact. Unfortunately, as the above review of the CM literature indicates, in most cases organizations do not adequately prepare for their crises due to prolong periods of denial. Given the detrimental effects of such behavior, it is important to understand why organizations tend to engage in it. Two complementary bodies of literature, escalation of commitment and whistle-blowing, are reviewed to identify specific factors affecting an organization's capacity to promptly detect and respond to failure warning signs. 2.3.1 The Escalation of Commitment Hypothesis The concept of escalating commitment is used to describe the human tendency to adhere to a course of action despite the existence of negative information about its viability (Staw and Ross, 1987; Brockner, 1992). Weick (1988) describes the pitfalls of such commitment: The dark side of commitment is that it produces blind spots. Once a person becomes committed to an action, and then builds an explanation that justifies that action, the explanation tends to persist and become transformed into an assumption that is 37 Chapter 2 taken for granted. Once this transformation has occurred it is unlikely that the assumption will be readily viewed as a potential contributor to a crisis. (p.310) Extensive theoretical and empirical evidence indicates that when managers' attitudes and behaviors are affected by escalating commitment, they are less Likely to acknowledge early warning signs (Staw and Ross, 1987) and engage in corrective actions to either avoid or prepare their organization for the failure (Meyers & Holusha, 1986; Fink, 1986; Smith, 1990; Booth, 1993; Pearson and Clair, 1998). A number of case studies in MIS (Keil, 1995; Flowers, 1996; Jones, 1996) indicate that escalating commitment behaviors are indeed present in IS projects and significantly contribute to the lack of preparation that is observed in IS project failures. Based on the theoretical arguments of the escalation theorists and the preliminary empirical findings in MIS cases, I anticipate that: Hypothesis 4: Managers' commitment to the project will lead to lower pre-crisis preparation. To investigate the tendency of managers to commit to failing courses of action, escalation theorists have focused on social-psychological processes in organizations. Both self-justification theory (Staw, 1976) and prospect theory (Whyte, 1986) have been used to understand this phenomenon with extensive empirical support (Ross and Staw, 1987; 1993). According to the escalation theorists, there are four groups of variables that contribute to escalating commitment: psychological, social, project, and organizational factors (Staw and Ross, 1987). 38 Chapter 2 Psychological determinants are intra-individual "forces that induce error in the calculation of gains and losses... [and] forces that can more directly bind individuals to a course of action" (Staw and Ross, 1987, p. 48). These forces cause managers to convince themselves that "things are not as bad as they appear" leading them to believe that continuation of the project is the appropriate choice (Brockner, 1992). Such forces include reinforcement traps, high-self esteem, self-justification, self-inference, and biases in human information cognition and processing (Staw and Ross, 1987; 1993). Interestingly, Brockner, Houser, Birnbaum, Lloyd, Deitcher, Nathanson and Rubin (1986) found that individuals who viewed tasks as reflective of their abilities are more likely to escalate their commitment despite negative feedback. Thus, I expect that project managers and IS professionals will be especially likely to engage in escalating commitment behaviors as IS projects tend to be perceived as reflective of their capabilities. Social determinants are perceived pressures from others to continue the prior course of action. According to Staw and Ross (1987), "social determinants of commitment may hold an individual to a course of action, regardless of whether the person has lost faith in the possible success of a project or the utility of its purposes" (p. 55). These pressures include competitive rivalry with other organizational groups, the need for face-saving and external justification, external binding and norms of consistency (Staw and Ross, 1987; 1993). Even though these social processes are pervasive in all types of organizational projects, I believe IS projects are especially likely to face these social pressures leading to escalation 39 Chapter 2 situations, due to the adversarial relationship between the IS and the rest of the organization (cf. Rothfeder and Driscoll, 1990; Wilder, 1990; Frangini, 1991; Earl and Feeny, 1994; Fiegener and Coakley, 1995; Friedman, 1995; Mirelli, 1995). Project characteristics are the "features" of the project as perceived by management (Keil, 1995). Among the most important features influencing commitment is the importance of the project to the organization (Staw and Ross, 1993). Substantial investments in strategic IS, which are expected to play a critical role in the operations of the organization, will tend to create high pressure situations leading to escalation of commitment by managers (Staw and Ross, 1993). Indeed, past research shows that if managers believe that the project will offer substantial benefits to the organization and that additional investments are likely to be efficacious by turning around the situation, they are likely to escalate their commitment to it (Rubin and Brockner, 1975; Staw and Fox, 1977; Bateman, 1983; Ross and Staw, 1987). To examine these effects within the ISD context, Keil et al. (1994) conducted five experiments. Keil et al. (1994) found evidence of escalation behavior in scenarios of runaway IS projects. Their findings identified an upward sloping sunk cost effect in scenarios of runaway IS projects providing support to Garland's (1990) assertions regarding the effects of sunk cost. Finally, escalation theorists argue that a number of organizational factors affect escalation behavior. These factors include support from senior management and the institutionalization of the project (Ross and Staw, 1987; 1993). I argue that because of 40 Chapter 2 their significant institutional value, strategic IS projects will receive substantial support from upper management and thus reducing the likelihood of their cancellation (cf. Keil, 1995). As Ross and Staw (1987), point out: Even though a project may no longer be feasible of economic grounds, withdrawal may still be difficult politically... External justification may push individuals into advocating actions that lack objective merit... [A] project may also have a wide set of political alliances and supporters. Not only those directly involved with a project, may work to maintain it, but other units interdependent or politically aligned with the threatened project can also be expected to provide support. (p. 60) To examine these effects, Keil (1995) conducted a longitudinal case study of the development of a major expert system. Keil (1995) traced the 13 year history of a strategic IS project using interview data, meeting minutes, and observations. The results of this case study indicate the presence of emotional attachment to the project leading to "empire building" and escalation of commitment attitudes by project and corporate managers.5 Given the strong empirical evidence supporting the notion that managers are more likely to engage in commitment escalation behaviors when dealing with important projects that enjoy the senior managers' support, I expect that such behaviors will be exhibited during the pre-crisis stages of strategic IS projects failures. In other words, I hypothesize that: Hypothesis 5: Project importance will lead to greater commitment to the project. 5 The fact tha t senior management's support to a project contributes to escalation of commitment si tuat ions has impor tan t impl icat ions for the vast major i ty of the M I S l i terature which "preaches" strong management support as a prerequisi te for successful projects. As these f indings indicate, such b l ind support can prove det r imenta l i n fa i l ing projects. 41 Chapter 2 Even though the escalation of commitment view offers a convincing account for the denial behavior that is observed during pre-crisis periods, I believe that its explanations are incomplete. The escalation perspective focuses exclusively on the behavior of managers who are viewed as passive recipients of negative information. It assumes that despite the social pressures to support a project, negative information will indeed emerge in organizational settings (usually by lower-level project participants) and will subsequently be ignored by managers. This view neglects the behavior of non-management participants (such as users and project team members) and assumes that the voicing of concerns by such participants will have no effect on whether the organization finally admits the existence of a problem. To take into account the attitudes and behaviors of non-management participants, I examine their pre-crisis behaviors from a whistle-blowing perspective. I contend that successful whistle-blowing attempts by participants will have a negative effect on the pre-crisis denial and will contribute to its cessation. To the best of my knowledge, this is the first systematic attempt to empirically investigate the relationship between the escalation and whistle-blowing perspectives. 2.3.2 The Whistle-blowing Hypothesis Whistle-blowing is the disclosure, by organizational members, of wrongful and questionable practices under the control of their employers to persons or organizations that may be able to affect action (Near and Miceli, 1985). Traditionally, whistle-blowing studies 42 Chapter 2 focused on individual whistle-blowers. Some theorists view such individuals as dissidents while others see them as reformers (Near and Miceli, 1987). Dozier and Miceli (1985) argue that whistle-blowing is a form of "pro-social" behavior involving both selfish and altruistic motives on the part of the whistle-blower. More recently, whistle-blowing theorists have called for a shift of focus from studying whistle-blowers as oddballs or heroes towards examining the effects of whistle-blowing on organizational outcomes (Miceli and Near, 1992; Graham, 1993). Consistent with this approach, I examine how whistle-blowing is associated with the de-escalation of failing ISD projects. In this dissertation, I view the attempts of organizational members to identify the project as a failure by boldly vocalizing their concerns about significant problems (in spite of the managers' escalating commitment behavior) as whistle-blowing efforts. Even though such attempts may threaten the organization's authority structure and functioning, they can contribute to the early identification of a failing project and the prompt initiation of remedial actions (Dozier and Miceli, 1985). It is important to recognize, however, that not all whistle-blowing attempts are equally successful in terminating pre-crisis denial (Terpstra and Baker, 1988; 1992). Simply put, it is not sufficient for the project participants to vocalize their concerns with the project's problems; the managers' favorable response to a whistle-blowing attempt is required to ensure its success. Indeed, Near and Miceli (1995) define effectiveness of whistle-blowing as "the extent to which the questionable or wrongful practice (or omission) is terminated at least partly because of whistle-blowing and within a reasonable time frame" (Near and Miceli, 1995). Predicting 43 Chapter 2 whether whistle-blowing will be successful in pressuring an organization into acknowledging the existence of a problem and taking preventive actions can be problematic in situations involving failing strategic IS. This is due to the conflicting effects of whistle-blowing and escalation of commitment behaviors, which are likely to occur during such situations. One may argue that the managers' denial (due to over-commitment) will negate the positive effects of whistle-blowing. In effect, this argument assumes that over-committed managers will ignore actual whistle-blowing (by dismissing or attempting to silence it). Contrary to this argument, one may assume that whistle-blowing will be successful in contributing to the termination of the pre-crisis denial by providing additional evidence about the project's problems and therefore making de-escalation more likely. Indeed, I believe that managers are less likely to continue their denial when their beliefs and commitment are challenged by intense whistle-blowing. In other words, I view whistle-blowing as a potential mechanism by which the denial of managers can be curtailed enabling the organization to initiate needed pre-crisis preparations. Even though there is paucity of empirical research that systematically investigated the net effect of whistle-blowing in ceasing questionable actions (such as the continuation of failing projects) and the factors affecting it, conceptual arguments and anecdotal evidence support this hypothesized effect (Near and Miceli, 1995). To examine whether whistle-blowing is indeed effective in terminating the pre-crisis denial, I hypothesize that: Hypothesis 6: Whistle-blowing by project participants will lead to greater pre-crisis preparation. 44 Chapter 2 Whether individual employees indeed engage in whistle-blowing during the pre-crisis stage of ISD crises depends on (1) their motivations and (2) their perceptions about the anticipated effect of their whistle-blowing. In the case of ISD crises, I believe that the potential failure of major, strategic IS projects motivates individuals to engage in whistle-blowing if the continuation (and eventual failure) of such projects would lead to a significant adverse effect on the organization. Indeed, extensive empirical research shows that individuals are more likely to engage in whistle-blowing when the seriousness of the questionable action is high (Miceli and Near, 1985; Victor et al., 1993; Dworkin and Baucus 1995). In other words, individuals are more likely to take action and voice their opinions when the failing project is critical to the organization and its failure would seriously harm the organization's operations and/or image. Given that among the main motivators of whistle-blowers is an altruistic tendency to protect the interests of the organization (Near and Miceli, 1987), I expect that the seriousness of an unmanaged failure of a strategic project will have a positive influence on whistle-blowing. Situations involving failing strategic IS are likely to exert an additional positive influence on whistle-blowing as the evidence of the project's problems is more likely to be public and visible to potential whistle-blowers. For smaller projects such evidence can be contained, sometimes intentionally, within the development and user groups that are responsible for their management. Indeed, empirical research shows that whistle-blowing is more likely to take place when the quality and visibility of evidence is high (Miceli and Near, 1985; Dworkin and Baucus, 1995). Based on these effects, I expect that: 45 Chapter 2 Hypothesis 7: Project importance will lead to greater pre-crisis whistle-blowing . Despite the above positive effects of project importance on whistle-blowing, I suspect that importance will have an additional, hindering effect on whistle-blowing due to its impact on the expected effectiveness of whistle-blowing attempts. This effect is an indirect one and is mediated by the managers' commitment to the project. As the discussion in section 2.3.1 shows, strategic projects are likely to lead to strong support and escalating commitment behavior by senior managers. Such conditions reduce the likelihood that senior managers will favorably receive whistle-blowing attempts. Indeed, research indicates that favorable responses to whistle-blowing are not likely when the questionable action (such as the continuation of a project) is important to the organization (Near and Miceli, 1985; 1995) and the management supports the course of action in question (Parmerlee, Near and Jensen, 1982; Near and Jensen, 1983; Near and Miceli, 1986; Miceli and Near, 1989). Under such circumstances, I expect that whistle-blowing is less likely to be pursued because potential whistle-blowers will recognize that over-committed managers are not likely to respond favorably to their views (Near and Miceli, 1985; 1986; 1987). Therefore, under conditions of high commitment to a project, such individuals will be less likely to express their views altogether. Thus, I anticipate that: Hypothesis 8: Managers' commitment will lead to lower pre-crisis whistle-blowing. 46 Chapter 2 2.4 I S D C R I S I S S T A G E After an organization has ignored the developing crisis for a period of time, it is inevitable that the failing project will reach a point when its impacts become so consequential to the organization that it necessitates the managers' recognition of the failure (Fink, 1986; Meyers and Holusha, 1986; Smith, 1990; Booth, 1993). In many cases, the damage caused by a project failure can be contained within the organization and --in spite of its financial cost and negative effects on morale and credibility- the organization can continue to operate without much trouble. The climax of some ISD project failures, however, can sometimes create a crisis that is visible to the organization's environment as well. For example, a failed project can delay or cease critical operations of the whole organization (such as in case of the Denver airport's baggage handling system) or create a major public relations predicament for the whole organization (such as in the case of the failed record keeping system developed by CBC in Canada). Typically, the organizational response to a crisis can take two forms: inaction or action (Starbuck, Greve and Hedberg, 1978). An organization may decide to remain inactive and not attempt to manage the crisis. This can occur for two reasons: either because the management feels that the problem is not important enough to demand its attention (i.e. the organization is still in denial about the crisis) or it feels that the impact of the crisis is so great that it becomes fatalistic and remains inactive (Goldberg, Dar-el, and Rubin, 1991). In 47 Chapter 2 most cases, however, organizations attempt to manage their crises. I believe that incidents of failures of strategic IS projects are significant enough to attract the attention of management but not overwhelming enough to lead the whole organization to panic and inaction. In sum, I believe that ISD failures create serious but manageable crises in organizations. Managing a crisis is not an easy task. Crises impose limitations on the ability of management to act and require special, non-routing management skills (Reilly, 1993b). In his seminal piece, Herman (1963) identified several effects of crises (such as intra-organizational conflict, decrease in communication, and questioning of authority) that limit the ability of institutions to promptly and effectively react to a crisis. In a review of the CM literature, QuaranteUi (1988) found that crises lead to communication, decision-making and co-ordination problems in organizations, making their management a difficult task. More recently, Reilly (1993) identified five key elements of successful crisis management responses. First, she argued that managers must be able to "sense" the problems by pinpointing their exact cause so that they can interpret the situation and prepare for the crisis (Kiesler and Sproull, 1982; Gephart, 1984; Dutton and Jackson, 1987; Banerjee and Gillespie, 1994). Secondly, the crisis management leaders must be able to promptly make decisions under non-routine, highly volatile conditions. This is extremely difficult as restriction of information processing and controls is usually the typical response of organizations to a crisis (Staw et al., 1981). Thirdly, the organization must be able to mobilize resources so that it can implement the contingency plans. After deciding what to do to deal with the crisis, one must have the ability to implement the decisions and plans. And 48 Chapter 2 as crises require different procedures and activities from routine management (Reilly, 1992) and place extreme demands on resources (e.g., managerial time and attention) (Meyer, 1982; Kanter, 1983), resource mobilization is an extremely critical ability. In the case of ISD crises, acquiring the needed financial, technological, and human resources and support to turn around a troubled project is expected to be difficult, especially during the early stages of the crisis because of the negative effects that such projects have on the credibility of the project leadership. Fourthly, the crisis management leaders must be able to effectively communicate their efforts to the affected organization and its environment. Practitioners have repeatedly identified the need for effective communication during crisis (Baton, 1990; Mitchell, 1993; Patterson, 1993). In ISD crisis situations, when the reputation of the project team is at stake, providing insufficient information to the rest of the organization can be detrimental. Finally, the crisis management leaders must be able to coordinate all the corrective actions during the crisis phase, something that becomes very difficult during times of a crisis (Quarantelli, 1988). Even though an organization's crisis management efforts may not always be successful, research shows that organizations devote substantial resources when managing their crises (Smith and Sipika, 1993). CM research studies show that organizations engage in intense crisis management efforts when the magnitude of the crisis is large and significantly impacts the organizations operations and image (Fink 1986; Meyers and Holusha, 1986; Mitroff et al., 1987; Smith, 1990; Booth, 1993; Pearson and Clair, 1998). Indeed, Dutton (1986) found that there is a positive relationship between the allocation of 49 Chapter 2 resources made by managers facing a challenging situation and the hkelihood that the situation is perceived to be a crisis. Based on these findings, I argue that: Hypothesis 9: ISD crisis impact will lead to greater crisis management. In addition to its intensity, the impact of the crisis also affects the nature of an organization's crisis response. When the failure is contained within the organization and the operations of an organization are not impacted as seen by external stakeholders (ie., the crisis impact is low), the organization is more likely to focus on activities that attempt to address the operational impact of the crisis. On the other hand, when the failure is so large and/or affects the organization's external image and relationships (eg, the impact is high), it is more likely that it will engage in crisis-management tactics aiming to protect its reputation and legitimacy (Meyers and Holusha, 1986; Smith 1990; Pearson and Clair, 1998). In general, I propose that organizations facing a high impact crisis are more likely to engage in both operational and legitimacy crisis management, whereas organizations facing a low impact crisis are more likely to focus mostly on operational crisis management efforts. Thus, I anticipate that: Hypothesis 10: High ISD crisis impact will lead to both operational and legitimacy crisis management (whereas low crisis impact will lead to operational crisis management only). A brief discussion of strategies and tactics used to manage the impacts of a crisis is presented 50 next. Chapter 2 2.4.1 Managing the Operational Crisis Operational crisis refers to the extent of the damage that is caused to the operations of the organization (Meyers and Holusha, 1986). In the case of ISD failures, it is possible that the failed projects may impact the current and/or future operations of a specific department or the organization as a whole. For example, the cancellation of a new accounting system developed to support activity-based costing (ABC) may delay (or totally eliminate) the accounting department's ability to initiate and manage such an initiative. Similarly, the cancellation of a strategic marketing system may curtail the introduction of a new product line. Research shows that when faced with such situations, organizations spend substantial resources to (1) contain the impact of the incident and (2) resume the company's operations (Pearson and Clair, 1998). Consistent with this observation, I define operational crisis management as the portfolio of tactics undertaken by an organization to contain the impact of the ISD crisis and protect its operations from it. Research shows that when a situation impacts the operations of an organization, its managers are likely to take control of the situation and mobilize extensive resources to manage its effects in an effort to minimize its operational impacts (Dutton, 1986; Smith and Sipika, 1993). The above strategies (containment and preservation) are generic in nature. The literature does not identify specific tactics that can be pursued during the crisis period to implement these strategies (Quarantelli, 1988). To identify such tactics, Iacovou and Dexter (1998) conducted a survey of 51 Chapter 2 expert IS consultants asking them to identify effective ISD failure management practices. 2.4.2 Managing the Legitimation Crisis Legitimation crisis refers to the harm caused to the reputation of key organizational groups (such as the IS department, senior management) or the whole organization due to the failure. Such legitimation habilities are especially prevalent in public crises (Thompson, 1967; Habermas, 1975; Dutton, 1986). I expect that during ISD failures, the legitimacy of certain groups or the organization may be at stake. Sometimes, the failure of a project will negatively impact the perceived competency and credibihty of the management team or the IS department in charge of the project. In other instances, the publication of a project's failure outside the organization will threaten the image of the whole organization and may raise questions about the senior management's ability to effectively run its operations and efficiently use its resources. Indeed, many well publicized ISD project failures (cf. Flower, 1996) represent instances where the legitimacy of the senior management was scrutinized because of the project failure. In response to threats to their credibihty, organizations usually undertake strategic actions to restore their legitimacy (Smith, 1990). Thus, I define legitimation crisis management as the set of tactics that are pursued during an ISD crisis to protect (or restore) the reputation of the involved organizations and individuals. When the effects of the failure on legitimacy are limited to internal stakeholders (users, project clients, etc.), these legitimacy restoring 52 Chapter 2 actions are likely to target internal audiences only. However, when external stakeholders are involved in the project and are affected by its fadure (such as customers, lending institutions, major IS vendors, etc.), the ensuing legitimacy hability can extend beyond the boundaries of the organization. In such cases, the legitimacy restoration efforts are likely to be intensified and target both internal and external audiences (Fink 1986; Suchman, 1995; Pearson and Clair, 1998). Protecting an organization's image and credibility is not easy during a crisis. In an extensive review of the legitimation literature, Suchman (1995) concluded that this is a unique organizational challenge: In the abstract, most of the legitimacy-building strategies... can serve to reestabhsh legitimacy following a crisis, provided that the organization continues to enjoy some modicum of credibihty and interconnectedness with the relevant audiences. Often, however, the delegitimized organization must first address the immediate disruption, before initiating more global legitimation activities. In particular, organizations must construct a sort of "firewall'' between audience assessments of specific past actions and audience assessments of general ongoing essences. (Suchman, 1995, p.597) According to Suchman (1995), to manage a legitimacy crisis, organizations must first avoid panic and then engage in restoration tactics. Avoiding panic is critical as it increases the likelihood of threat-rigidity effects (Staw, Sanderlands and Dutton, 1981) and escalates the perceived magnitude of failure legitimacy (Ashforth and Gibbs, 1990). Regarding specific legitimacy restoration tactics, Suchman (1995) identified two distinct strategies that are usually employed by organizations to manage a legitimacy crisis: (1) normalizing accounts (Scott and Lyman, 1968) and (2) strategic restructuring (Pfeffer, 1981). 53 Chapter 2 Normalizing accounts are explanations for the failure aiming to separate it from larger assessments of the organization as a whole (Scott and Lyman, 1968; Schlenker, 1980). Normalizing accounts can be broadly grouped into two categories: linkage and valence accounts (Scott and Lyman, 1968; Schlenker, 1980; Snyder, Higgins and Stucky, 1983; Snyder and Higgins, 1990). Linkage accounts are excuses attempting to deny or reduce the responsibility of the organization for the failure; valence accounts are justifications aiming to reduce the perceived damage caused by the failure (Scott and Lyman, 1968; Schlenker, 1980; Snyder and Higgins, 1983). Empirical research indicates that both types of accounts are used extensively in organization after predicaments (Giacalone and Rosenfeld, 1989; 1991; Marcus and Goodman, 1991; Bies and Sitkin, 1992; Rosenfeld, Giacalone and Riordan, 1995). In the case of strategic ISD failures, however, managers are more likely to use linkage accounts than valence accounts as a legitimation restoration tactic. This is because the mere fact that the failed project was a strategic one limits their ability to use linkage accounts (arguing that the impact of the failure is insignificant) (Schlenker, 1980). Strategic restructuring refers to "narrowly tailored changes" used to contain the damage (Suchman, 1995, p. 598). Large changes signal instability and unreliability and tacitly admit the existence of a prior, unattended problem. To avoid this, organizations selectively choose limited aspects of their operations that were flawed and visibly remedy them (Perrow, 1981; 1984). Two types of restructuring usually take place during a crisis: introduction of monitors and disassociation (Suchman, 1995). Monitors are representatives of institutions with high 54 Chapter 2 legitimacy and credibility who are asked to "post a bond" verifying the pragmatic legitimacy of the organization. For example, an organization facing an ISD failure may ask an auditing firm to conduct a post-audit to verify that the cause of failure lies outside the control of the organization. This will enable the firm to restore some of its credibility. Disassociation is a form of a structural change to symbolically distance the organization from "bad influences." The dismissal of project managers and the replacement of vendors who are seen as incompetent are examples of disassociation actions. 2.5 ISD POST-CRISIS STAGE After an organization manages the acute stage of its crisis, one hopes that it will adjust its future structure, culture and operations to take into account the causes and effects of the failure (Smith and Sipika, 1993). As Starbuck and Milliken (1988) pointed out "we benefit from disasters only if we learn from them" (p. 338). In certain cases, experimentation (i.e. taking risks that may lead to disasters) may be the only way to learn: We may need disasters in order to halt erroneous progress. We have difficulty in distinguishing correct inferences from incorrect ones when we are making multiple, incremental experiments with incompletely understood, complex systems in uncontrolled settings. (Starbuck and Milliken, 1988, p.337) Despite its critical importance, failure-based learning is not an easy task. This is partly because failures leave incomplete and minimal evidence that can be used for learning (Starbuck and Milliken, 1988). Also, many organizations are reluctant to engage in a post-55 Chapter 2 failure learning process "because of the false notion that an examination of past crises will only reopen old wounds" (Pearson and Mitroff, 1993, p. 54). This issue is quite prevalent in the aftermath of ISD failures: Frequently, abandonment decisions are so badly handled by companies, culminating in the firing and/or demotion of some key IS staffers... that even those left unscathed feel intimidated and so refrain from voicing their opinions. This is often the "code of silence" that exists within the computer industry with respect to discussing project failures. However, if we are to move beyond the current state of IS practice, we need to come to grips with the need to examine systems failures and shortcomings in order to gain insights that will significantly improve the technology and the art and practice of IS development projects in companies. (Ewusi-Mensah, 1997, p. 79) Learning from ISD failures (and most importantly applying these lessons to future ISD endeavors) is critical not just for the impacted organizations but for the whole IS industry (Ewusi-Mensah and Przasnyski, 1995; Jones, 1996; Flowers, 1996; Ewusi-Mensah, 1997). It is thus imperative to understand whether organizations indeed learn from their ISD crisis and find ways to make their learning more beneficial. To accomplish this goal, however, one must first understand how organizations learn in general. As Tsang (1997) points out, this is not an easy task: Researchers do not have any hesitation in creating their own definitions of organizational learning. Consequently, definitions are as many as there are writers on the subject... Most definitions entail aspects of both cognitive and behavioral changes. The cognitive aspect is generally concerned with knowledge, understanding, and insights. But there is a split among definitions on whether a change in actual or potential behavior is required. (Tsang, 1997, p.75) Indeed, literature reviews of the organizational learning field raise many questions about what organizational actions constitute evidence of organizational learning (Fiol and Lyles, 56 Chapter 2 1985; Levitt and March, 1988; Huber, 1991; Miller, 1996). In this investigation, I adopt a methodological view of learning (Miller, 1996). I define organizational learning as the acquisition of knowledge that improves organizational behavior (Miller, 1996). Consistent with organizational learning (Levitt and March, 1988) and crisis management researchers (Starbuck, Greve and Hedberg, 1978), I assume that acquisition of new knowledge is materialized through changes in organizational routines. In other words, organizational learning refers to the acquisition of new knowledge, which is codified in routines and not just in the memories of individual organizational members, and guides future organizational action. Whether organizations actually learn from their failure experiences has been the focus of a considerable debate by organizational theorists. Two major theories offer contradictory explanations about the effects of failure on organizational adaptation (Occasio, 1995). The theory of failure-induced change posits that failures increase the likelihood of risk-seeking behavior and searching for new routines (Kiesler and Sproull, 1982; Tushman and Romanelli, 1985) leading to organizational adaptation and learning (Sitkin, 1992). The threat-rigidity theory (Staw, Sanderlands, and Dutton, 1981), however, posits that failures in organizations lead to restrictions of information processing, constriction in control, and increased rigidity reducing the firms' ability to adapt. The majority of the empirical investigations of these two theories focuses on major, externally generated crises such as major economic adversity (Ocasio, 1995) and organizational decline (McKinley, 1993). To the best of my knowledge, this is the first attempt to assess the arguments of these two theories in the context of 57 Chapter 2 smaller, internal crises such as those caused by ISD failures. 2.5.1 Failure-Induced Change Arguments Sitkin (1992) argues that failure stimulates experimentation and is "an essential prerequisite for effective organizational learning and adaptation" (p. 231). Specifically, Sitkin (1992) argues that failure draws attention to potential problems and stimulates search for potential solutions "by providing a clear signal that something is amiss and must be changed" (p. 237). He argues that the experience of a failure leads to a learning readiness that is difficult to produce without a felt need for corrective action (Sitkin, 1992). Failure stimulates action for three reasons. First, it provides a clear, identifiable target and corrective action is more likely to be undertaken when such specific stimulus for change exist (Cyert and March, 1963; Locke and Latham, 1990). Second, it stimulates action aimed at adapting to the new circumstances which are recognized by the existence of a problem (Hedberg, 1981). Third, failure fuels a willingness to consider new alternatives and adopt institutional practices, even when the initial, identifiable "problem" subsequently shifts (Hedberg, Nystrom and Starbuck, 1976). Sitkin (1992) points out that not all failures are equally beneficial. "Intelligent" failures "(1) result from thoughtfully planned actions, (2) have uncertain outcomes, (3) are of modest scale, (4) are executed and responded to with alacrity and (5) take place in domains that are familiar enough to permit effective learning" (p. 243). He also argues that actions that are well planned can provide diagnostic information regardless of whether they succeed or fad. The learning value of failures can increase if the experience generates information that would be otherwise unavailable. Most importantly, Sitkin (1992) points out failures 58 Chapter 2 must be of sufficient magnitude to rise above the level of "background noise" and attract the attention of senior managers but not be grossly disastrous in a way that fundamentally challenges the organization as a whole. I believe that the majority of failures of strategic ISD projects fall within this range and thus one should expect to see some valuable learning taking place after such incidents. Considerable empirical evidence supports the above failure-induced change arguments. Miller (1994) found that firms facing a crisis are (1) less likely to exhibit inertia in structure and decision making process, (2) less likely to pursue immoderation, (3) less likely to reduce intelligence gathering and processing and (4) more likely to adapt to environmental changes than successful firms. Additional empirical studies found that firms facing a crisis are more likely to adapt by adopting new innovations (Miles and Cameron, 1982; McKinley, 1984; Bolton, 1993). 2.5.2 Threat-rigidity Arguments Based on an extensive review of the literature, Staw et al. (1981) identified several constricting effects of failure on the adaptability of individuals, groups, and organizations. When they face a threat, individuals experience high psychological stress and anxiety. Under such conditions, they tend to restrict their information processing and rely on internal hypotheses, prior expectations and well-learned, dominant responses. Groups react to external threats in an analogous manner. They tend to increase their cohesiveness, 59 Chapter 2 centralization, and uniformity. When facing internal threats, such groups tend to experience a loss in their cohesiveness, decrease their support for their leadership and face dissentions. At the organizational level, Staw et al. (1981) identified five consequences of threats that lead to rigidity: overload of communication channels, reliance on prior knowledge, reduction in communication complexity, centralization of authority, increased formalization, and a concern for increased efficiency. Based on these effects, Staw et al (1981) argued that organizations are likely to restrict their information processing, constrict their control and conserve resources in response to a failure. Such rigid behavior hinders organizational adaptation and learning. Similar arguments about the effects of failures were expressed by Sutton (1990). The threat-rigidity arguments have received considerable support as well. Cameron, Whetten and Kim (1987) reviewed the literature and identified twelve dysfunctional consequences of organizational decline: centralization, lack of long-term planning, reduction in innovation, scapegoating, resistance to change, turnover, low morale, loss of slack resources, fragmented pluralism, loss of credibihty, non-prioritized cuts and conflict. In an empirical study of 334 educational institutions, they found support for nine of these effects; their findings did not support the hypotheses about loss of slack resources, loss of credibihty and fragmented pluralism. Sutton (1990) also empirically identified a number of rigidity effects. These include: increased use of standard operating procedures, constriction of control in decision making by reducing participation and increasing centrahzation and cost cutting efforts to assure accountability. D'Aveni and MacMillan (1990) compared 57 successful firms to 57 60 Chapter 2 firms in crisis. They found that the successful firms are less likely to exhibit maladaptive and rigid behaviors than their unsuccessful counterparts. And DAunno and Sutton (1992) found that a reduction in organizational resources led to increased rigid use of existing procedures, less participative decision making and intra-organizational competition. As stated earlier, I believe that ISD failures will cause serious but not overwhelming crises in organizations. Given that strong rigidity effects are most likely to occur as a result of devastating organization-wide crises (Occasion, 1995), I doubt that the rigidity effects caused by most ISD failures will be strong enough to inhibit adaptation. In other words, I assert that the impacts of crises caused by most strategic ISD failures will be serious enough to receive the attention of management and necessitate change, but not so grave that they rigiclify the whole organization. In sum, I propose that: Hypothesis 11: ISD crisis impact will lead to greater post-crisis organizational learning. Recent theoretical arguments by Mone, McKinley and Barker (1998) indicate that the hypothesized relationship between crisis impact and learning is not linear. After an extensive review of the organizational learning literature and in attempt to reconsolidate the contradictory empirical findings in this area, they argue that a number of factors moderate the relationship between these two constructs. According to Mone et al. (1998), the perceived controllability of the crisis is one such moderating factor. They argue that: 61 Chapter 2 When decision-makers ascribe organizational decline to... uncontrollable causes, the resulting attributional framework constrains innovation because the necessity and even the possibility of proactive response are unclear. In contrast, when decline is attributed to... controllable causes, decision makers' schemas emphasize the necessity and the potential for effective actions, thus providing greater incentive to innovate. (Mone et al., 1998, p. 120) Mone et al. (1998) argue that managers are more likely to engage in organizational learning when they perceive that the cause of the failure was controllable for two reasons. First, because of higher-levels of self-efficacy, the aspirations, persistence and goal achievements of these managers will be higher (Bandura, 1986) leading to higher goal commitments and more ambitious performance objectives (Mone and Baker, 1992). Thus, under such conditions managers are more likely to commit the resources for organizational learning and adaptation (Mone et al, 1998). Secondly, when the failure causes are controllable, senior managers "are more likely to see an opportunity to assert themselves" (Mone et al., 1998, p. 125). This could be motivated by a felt responsibility and an opportunity to exhibit mastery over the crisis. In contrast, when the cause of the failure is attributed to uncontrollable factors, organizations are more likely to "fall prey to learned helplessness ... [and] threat rigidity effects are more probable" (Mone et al. 1998, p. 125). The arguments for the positive effect of controUability on organizational change are consistent with legitimacy arguments as well. When I S D failures are attributed to factors outside the control of the organization, the credibility of the organization will not be significantly damaged and, therefore, the pressure to signal organizational learning will not be as intense. In contrast, when the organization is seen as largely responsible for the ISD crisis, one expects that the pressure to adapt and eliminate the failure-causing elements will be higher and require evidence of such adaptation. Thus, 62 Chapter 2 consistent with Mone et al. (1998), I anticipate that: Hypothesis 12: Failure controllability will positively moderate the relationship between the ISD crisis impact and organizational learning. It is important to note that in their theoretical explanation for this moderating effect, Mone et al. (1998) emphasize that the "the individuals' perceptions of causes of events, rather than the actual causes, influence subsequent responses and behaviors" (p. 124). Thus, one would expect that in the case of ISD fadures, it is the managers' perceptions of controhability that influences the likelihood of organizational learning and not the actual causes of the failure. For example, ISD failures which are attributed to external causes (e.g., changes in the external computing environments) are less likely to be followed by organizational learning. 2.6 SUMMARY OF HYPOTHESES The propositions that were presented in this chapter identify the key assumptions of the theoretical framework and delineate the boundaries of the empirical investigation. In a few words, the framework hypothesizes that the pre-crisis denial that usually exists prior to ISD failures is affected by escalating commitment to the project. The model also proposes that this initial denial may end if effective whistle-blowing takes places. If the organization continues to deny the existence of problems and fails to take preventing actions to avoid or prepare for them, the failing projects will continue to follow their initial 63 Chapter 2 development course and deteriorate. As the failure progresses, the magnitude of the project problems will intensify until the failure reaches its climax. In the case of high impact crises, the failure of a strategic project will necessitate that the management recognizes the existence of a crisis and devotes substantial resources for its resolution. As part of their crisis management efforts, managers will devote resources to minimize the impact of the crisis on both the operations and the legitimacy of their organization. If the impact of the crisis is contained within the organization, I expect that these efforts will focus on operational issues only. After this acute crisis management period, I expect the impact of the crisis to diminish due to the effect of remedial actions, organizational adaptation and the passage of time. Finally, the model explores the issue of organizational adaptation as a response to an ISD failure. The model posits such learning is likely to take place when the impact of the crisis is high, especially when the apparent cause of the ISD crisis is attributed to controllable factors because of the need to engage in visible corrective actions. 64 Chapter 3 RESEARCH METHODS Facts speak louder than statistics Goeffrey Streatfield 65 Chapter 3 3.1 RESEARCH METHODOLOGY To investigate the phenomenon of ISD crises, three case studies were conducted from 1996 to 1998. The goal of the case studies was to empirically assess the apphcability of the theoretical framework within the context of ISD failures. To accomplish these goals, qualitative data were collected and analyzed about the relevant constructs using Yin's (1994) formal, positivist approach. This chapter describes the methods used to carry out the empirical investigation. This section discusses the selection of the case methodology for this study by summarizing its main advantages and shortcomings. The following section describes the overall research design and provides details about the three specific cases, the data collection methods, and the data analysis techniques. The last section reviews the specific steps that were undertaken during the data collection and analysis process to enhance the rigor of this investigation. 3.1.1 The Case Methodology According to methodological researchers, case studies are especially useful when the research aims to understand complex social situations (Schramm, 1971; Benbasat, Goldstein and Mead, 1987; Hamel, Dufour and Fortin, 1993; Yin, 1994; King and 66 Chapter 3 Applegate, 1997).6 As Yin (1994, p. 1) pointed out, case studies are "the preferred strategy when 'how' or 'why' questions are being posed, when the investigator has little control over events, and when the focus is on a contemporary phenomenon with some real fife context." Other researchers made similar observations. Schramm (1971) argued that case studies are especially helpful in illuminating a set of decisions: why they were taken, how they were implemented and with what result. In the case of MIS research, Benbasat et al. (1987) argued that case studies are useful when the research interest shifts to organizational rather than technical issues. Clearly, the selection of the methodology should be dictated by the nature of the investigation and the research questions. As Kvale (1988, p. 93) simply put it, "content precedes method." Indeed, my selection of the case method was chiefly motivated by the nature of my research subject and questions. As my primary interest was to assess the usefulness of the CM concepts in ISD failure situations, I felt that the case methodology was an appropriate choice as it would enable me to study "meaningful characteristics" of the relevant organizational events in each case (Yin, 1994, p. 3). Unquestionably, early studies of complex organizational phenomena, such as the management of ISD crises, necessitate their investigation within their natural context so that researchers can better identify and study all relevant factors and processes. Practical reasons also contributed to the selection of the case study as the methodology. The lack of previous research on ISD crises and the lack of valid survey-based measures of 6 For a detai led h is tor ical account of the evolut ion of the case study methodology see Hame l et al. (1993). 67 Chapter 3 the constructs of interest made it difficult to use survey or other quantitative studies. Furthermore, due to the sensitive nature of this research study (Leed and Renzetti, 1995), I was not convinced that I could gain access to the large number of companies experiencing major ISD crises required for completing a rigorous survey. Therefore, due to concerns with access and -especially-- my interest in developing a rich understanding of the ISD crisis process, I did not feel that other methods (such as surveys and experiments) could be as beneficial as the case study. Indeed, as Yin argues, the case methodology is quite appropriate when such issues are of concern: The case study inquiry (1) copes with the technically distinctive situation in which there will be many more variables of interest than data points, and as one result (2) relies on multiple sources of evidence, with data needing to converge in a triangulation fashion, and as another result (3) benefits from the prior development of theoretical propositions to guide data collection and analysis. (1994, p. 13) The case studies enabled me to collect rich, qualitative data about the context of ISD crises and the events that take place before, during, and after the crisis. The ability to collect qualitative data describing and explaining these complex organizational processes was very important for this study because: Qualitative data are sexy. They are a source of well-grounded, rich descriptions and explanations of processes in identifiable local contexts. With qualitative data one can preserve chronological flow, see precisely which events led to which consequences, and derive fruitful explanations. (Miles and Huberman, 1994, p. 1) In general, qualitative data collected during case studies have three major strengths. Firstly, the local groundedness of such data enhances the validity of the findings. Case data are collected in close proximity to the social situation under study and are provided by people who are intimately familiar with it. Secondly, qualitative data, due to their 68 Chapter 3 richness and holism, can provide "thick and vivid" descriptions that enable the researcher to capture and study complex situations. Lastly, qualitative data allow the researcher to study the meanings that the participants, and not just the researchers, give to the events associated with their Lives (Miles and Huberman, 1994, p. 10). Because of these qualities, qualitative data collection techniques are very useful in the study of perplexing organizational phenomena, such as ISD failures. Even though a number of researchers have criticized qualitative case studies, King and Applegate (1997) argued that these criticisms are partly due to the political and legitimacy threat posed by the introduction of qualitative methods in IS research against mainstream quantitative research. In general, the concerns raised by critics of the case study methodology center on generalizability and internal validity issues. In an extensive review of the case study methodology, Hamel et al. (1993) summarized these two concerns: The case study has basically been faulted for: (1) its lack of representativeness, and especially, the lack of representativeness of the case used as a point of observation for the social phenomenon or issue constituting the object of the study; and (2) its lack of rigor in the.collection, construction, and analysis of the empirical materials that give rise to this study. This lack of rigor is linked to the problem of bias. Such bias is introduced by the subjectivity of the researcher, as well as of the field informants on whom the researcher relies to get an understanding of the case under investigation. (1993, p. 23) In response, in his recent book on case studies, Yin (1994) argues that the perceived generalizability weakness of case studies is the result of the inappropriate tendency of researchers to focus on statistical (and not analytic) generalization. Yin (1994, p. 32) argues that researchers "should avoid thinking in such confusing terms as 'the sample of cases' or the 'small sample size of case,' as if a single case were like a single respondent in 69 Chapter 3 a survey or a single subject in an experiment." He points out that "case studies, like experiments, are generalizable to theoretical propositions and not to populations or universe." More specifically, Yin (1994) argues that to achieve analytic generalization, the research results of a case study must be mapped to a well established and rigorously validated theory. Of course, analytic generalization is not automatically granted when a case study is complete; the theory must be tested by replicating similar studies in other cases. By combining an empirically validated theory with a number of case replications, a research may be more confident that the case results would be generalizable to other situations that are similar to the ones in the completed cases. A similar argument about analytic generalizability was made by Miles and Huberman (1994), who argue that multiple-case sampling does not necessarily increase the generahzability of case findings unless generalizing from one case to the next takes place on the basis of a match to the underlying theory and not simply to a larger universe of cases. Regarding the criticism about the confidence in the data collected during cases, both Yin (1994), and Miles and Huberman (1994) indicate that threats to validity are present in all types of methodologies. The only way to protect and enhance the internal validity of the findings is to conduct a rigorous data collection and analysis. Following this advice, specific steps prescribed by Yin (1994), and Miles and Huberman (1994), were pursued to safeguard this study's findings against validity threats. These steps are discussed in the following sections and are summarized at the end of this chapter. 70 Chapter 3 3.2 RESEARCH DESIGN Research design is the "blueprint of an action plan" that describes what data are needed to answer the research questions, and how to collect and analyze them (Philliber et al., 1980). For this investigation, I utilized an explanatory, holistic, multiple-case research design (Yin, 1994). As the goal of this dissertation is to understand and explain the ISD crisis process, I felt that it was not sufficient to simply describe the process. Thus, I implemented an explanatory case design to identify the factors that influence (and are influenced by) the ISD crisis processes. I also decided to conduct a holistic examination of the entire development project and organization (and not just a specific sub-unit) in order to formulate an initial, complete understanding of ISD crises and their management. However, to be able to better assess the applicability of the CM framework, I limited my investigation to the constructs presented in my theoretical model. By doing so, I was able to identify common patterns in the way organizations manage their MIS project failures (as crisis managers) without having to worry about organization-specific structures, development strategies, and other secondary factors. During the planning of this study, I decided to pursue a multiple-case design. Even though gaining access to organizations facing ISD crises was expected to be quite problematic (due 71 Chapter 3 to the sensitive nature of the subject under study), I felt that it was important to conduct multiple-case studies to enhance the validity and generalizability of the findings. Indeed, case researchers have argued that multiple-case studies add confidence to the findings (Miles and Huberman, 1994) and generate more compelling and robust evidence (Herriott and Firestone, 1983). To achieve these results, I followed a replication, and not a random sampling logic, in selecting the three cases (Yin, 1994). 3.2.1 Case Selection The selection of three cases for this investigation was somewhat challenging for both methodological and practical reasons. When selecting potential cases, one must consider multiple cases as one would consider multiple experiments and not as multiple respondents in a survey (or multiple subjects within an experiment) (Hersen and Barlow, 1976; Morse, 1989; Kuzel, 1992). According to Yin (1994, p. 31), "each case must be carefully selected so that it either (a) predicts similar results (a literal replication) or (b) produces contrasting results but for predictable reasons (a theoretical replication)." As my goal was to achieve analytic (not statistical) generalization, I felt that a theoretical replication would be more useful. By studying and contrasting both cases of well-managed and mismanaged strategic ISD crises, I felt that the study could better validate the applicability of the conceptual framework. However, from a practical standpoint, I realized that gaining full, unrestricted access to organizations facing failures of major, strategic IS projects could be problematic due to the sensitivity of the research topic (Renzetti and Lee, 1993). No doubt, very few firms like to "air their dirty laundry." Given 72 Chapter 3 the expected reluctance of candidate organizations to provide me with full access to personnel and archival records, I felt it was preferable to select a few organizations that knew and trusted me. I approached and discussed the possibility of conducting studies of their strategic IS project failures with six Canadian organizations that were managing (or had recently managed) an ISD crisis. As my primary interest was in the instrumental value of the possible candidate cases, I was not intrinsically interested in a specific type of failed technology, type or size of organization, etc. Following Stake's (1994) advice, I selected three cases from which I felt I could learn the most. In other words, the companies were selected based on the need for purposive sampling and access. In terms of usefulness, the utility company, Northern Utilities (NU), was selected because it was having a difficult time managing a recent ISD crisis.7 My initial assessments showed that the other two companies, a large hospital, Green Valley Hospital (GVH), and a large university, Royal Canadian University (RCU) managed to cope with the acute phase of their ISD crises fairly well. The initial contacts with these companies identified additional variability in a number of key factors in the model. For example, the RCU case was selected because the failed project (unlike the projects in the other two cases) was not of great significance to the key operations of the organization (ie, its apparent crisis impact was low). Also, it initially appeared that GVH exhibited high 7 The names of the companies and involved indiv iduals have been altered to protect the i r anonymity. Also, other non-cr i t ical , ident i fy ing details (location of the organization, names of departments, exact amounts of f inancia l in format ion, etc.) have been disguised for the same reason. 73 Chapter 3 levels of post-crisis learning even though it was unsuccessful in managing the pre-crisis stage of its failure. Almost the exact opposite pattern was present in the other two cases. I believed that these differences among the cases (in terms of the importance of the projects, the magnitude of their crisis impact, and success in managing each stage of the crisis) would allow me to more fully assess the model's propositions through theoretical replication. I gained access to the utility company through my personal relationship with a partner of a major accounting firm that was hired by NU to help it manage the crisis. I had volunteered as a MIS consultant at the hospital and knew some of the information systems and other managerial staff. Finally, I knew some computer center staff at the university through personal relationships. As it turned out, these relationships between the "entry points" and myself --coupled with strict anonymity and confidentiality measures- yielded unrestricted access to both personnel and archival documentation in each of the case studies. A summary of the key features of each case is shown in Table 3-1. One limitation in my selection is the fact that all three cases represent ISD failures in public organizations. This raises the question of whether my findings are applicable to ISD crises in private firms (which may differ from public organization in terms of their planning, budgeting and management processes). Given that my emphasis in terms of external validity is on theoretical propositions (which are based on the crisis management theory that has been successfully applied to many public and private organizations) and not on specific behaviors that occurred in the three cases, I believe that my findings would 74 Chapter 3 be applicable to private firms as well. Furthermore, as the case studies reveal, each organization in this investigation was managed as an independent entity and faced severe competitive environments similar to those of private organizations. For example, the public utility in this study was facing tough economic conditions and the introduction of other competing utilities in its area and was subject to the same regulations that apply to private utilities. The university and the hospital were competing with a number of local competitors in terms of resources (governmental funding, students, professional talent, etc.). Given that no research study has investigated whether private sector organizations systematically differ from public organizations in terms of their crisis management behaviors, I am unable to empirically resolve this issue at this point. Only future rigorous empirical investigations can address this issue. 75 Chapter 3 Table 3-1: Case Characteristics Case NU GVH RCU Type of organization Provider of electricity and gas services to a major urban area Teaching hospital in a major city Large university in a major city Size of organization Revenue: $400 million Staff: 450 employees Revenue: $160 million Staff: 3,200 employees Revenue: $300 million Staff: 3,500 employees Purpose of project To introduce an organization-wide internal management system; replace legacy applications; and implement a new activity-based costing (ABC) system To implement a strategic plan aiming to re-engineer the hospital by introducing sophisticated, integrated clinical and financial systems To provide interested researchers with a sophisticated, numerically intensive computing facility Project Importance Critical for the implementation of the ABC (part of a larger strategic reorientation/re-engineering effort); received the approval of elected board members Critical component of a hospital-wide reengineering effort; largest hospital IS project in the province; received publicity and approval by provincial government Significant for researchers requiring intensive computing but not important to most of the university's activities or staff Development approach Purchase of a multiple- application package; customization of package by Oracle consultants and in-house, user-led teams Acquisition of multiple applications; customization and integration of the applications by Baxter consultants Installation of an IBM 3090/150S mainframe with a vector facility Causes of crisis User rejection, project mismanagement, and technical problems made the applications unusable Inability of vendor to deliver software; user rejection; technical problems Changing computer technology and environment, and technical difficulties led to low demand for service and inability to cost-recover Consequences of crisis Due to the unavailability of systems after conversion, NU was not able to control many of its financial activities and produce financial statements Due to the project's abandonment in 1992, GVH did not implement any clinical systems; some units purchased their own, non-integrated systems; failure to fully implement the SIS plan The university canceled the lease with IBM and acquired new computers to offer similar services Original completion date January 1996 January 1995 June 1989 Actual completion date November 1997 Original project was canceled in 1992; Many replacement projects were completed by December 1996; some are still incomplete August 1990; system was abandoned in 1992. Original estimate of project cost $1 million $6 million $4 million Estimated total cost of crisis Over $5.5 million Over $8 million Over $4 million (even though system was abandoned) 76 The Northern Utilities Case Chapter 3 NU initiated a major project in an effort to implement an organization-wide internal management information system (IMIS). The goal of this project was to develop a highly integrated internal accounting and reporting system that would enable NU to utilize the activity based costing (ABC) method in recording and controlling its costs. This project was initiated by the customer division of the organization and was part of a large strategic reorientation initiated by the senior management of the utility. After a formal procurement process, NU's management selected Oracle as the vendor. This was met by resistance from users who felt that Oracle's proposed solution was not satisfactory. According to the partnership contract, Oracle was to deliver ten applications and a number of custom-made interfaces that would allow the applications to communicate with each other. The project was to be completed by January 1, 1996 and cost about one million dollars. The development of each IMIS application was managed by a small group. Each group consisted of a few NU employees and one or two Oracle consultants. The operations and progress of these teams were supervised by two project managers (one from NU and one from Oracle). Due to a number of factors (such as lack of know-how and critical skills, lack of communication, and user resistance), the project faced severe problems that led to multiple delays and omission of critical testing activities. Despite this, the project conversion took place as planned using a direct cutover approach. This left NU with many 77 Chapter 3 non-functioning applications. At about the same time, NU's project manager left the organization and Oracle refused to continue working on the project because the allocated project funds were exhausted. The lack of fully tested and functional systems led to many problems within NU. Specifically, NU was unable to monitor and track its financial activities, process payments to its vendors, track payroll activities, control inventory levels or produce quarterly financial statements. To salvage the project, NU hired its auditor company (KPMG) to conduct a project audit. After the audit's completion, NU hired a number of KPMG consultants to help manage its recovery. Even though a multi-month, intense recovery effort was undertaken, not all applications were fully completed by the end of the recovery project in the spring of 1997. In 1997, another project team (composed of Price Waterhouse consultants) was brought in to upgrade the applications and develop missing, critical functionality. By 1998, almost all IMIS applications were fully functional. According to NU estimates, the total cost of the original project, its delays and the recovery efforts exceeded $5.5 million. For a more detailed historical account of this case, see Appendix One. The Green Valley Hospital Case In the late 1980's, due to adverse economic conditions and changes in the provincial health care system, GVH was facing strong pressures to cut costs and improve patient care. The administration of the hospital realized that the lack of information systems, especially in 78 Chapter 3 the clinical operations of the hospital, severely impeded its ability to strategically respond to the changing external environment. To rectify this situation, GVH hired Datacom, a small consultancy firm, to help it formulate a strategic information system (SIS) plan. As part of this plan, a hospital-wide integrated patient administration and care system (IPACS) was to be implemented by 1995. GVH issued a request for proposals and reviewed a number of proposals from interested vendors. The president of the hospital selected a $5.9 million proposal by Baxter Systems and IBM that recommended the installation of a set of US-made financial and clinical applications. This was met with strong opposition by almost all user departments who questioned the limited capabilities of the proposed systems and were not convinced that the US-made software could satisfy the unique features of the Canadian health care sector. In fact, the manager of the MIS department left the organization in response to this decision. Despite this resistance, after receiving the approval of the hospital's board and the provincial ministry of health, the project was initiated in 1990. Even though GVH had almost no functioning clinical systems at the time, the development of the clinical applications was postponed and the project begun with the implementation of a number of financial applications. The main reason for starting off with the financial applications was because they required fewer customizations than the clinical programs before they could be adapted for use in Canada. Even though the first couple of financial applications were installed with moderate success, when the project team attempted to implement additional applications the users strongly resisted their introduction due to their limited capabilities. The implementation of the first clinical applications faced 79 Chapter 3 similar difficulties due to user rejection and technological problems. Due to the inability of the vendor to customize its applications so that they could meet the needs of the users, the whole project was placed on hold in 1991. After lengthy negotiations between the involved parties, Baxter admitted that it could not deliver the promised applications and customizations. Baxter and GVH signed a termination agreement which dictated that Baxter was to refund almost all monies allocated for software development under the initial agreement. Under this agreement, IBM allowed GVH to modify its hardware orders, if needed, to fit the needs of future projects. Six months after the termination was agreement was signed, Baxter shut down its Canadian operations due to concerns with its potential profitability. Because of the political support and visibility given to this project, GVH felt pressure to initiate and complete a new project that would achieve the original goals of the SIS within the original time and cost estimates. Thus, it conducted an abbreviated procurement process to identify a new vendor. For mostly financial reasons, the management of the hospital selected Medsys (which was the supplier of the legacy systems that were to be replaced by IPACS). Because of the "no-overrun" restriction placed by the senior management on this project, users were asked to prioritize their needs and ehminate "unnecessary features" from their system requirement lists. This led to high user dissatisfaction. A number of the user departments began implementing their own, stand-alone applications. 80 Chapter 3 To legitimatize the completion of the IPACS project the president of the hospital hired Datacom again to conduct a project audit during 1994. The audit report (which was selectively distributed within the organization) concluded that all features of the SIS were "essentially" implemented for most applications and predicted that the remaining systems would be completed within the original time frame. Despite the optimistic predictions of the report, not all applications were completed on time. By 1997, a number of clinical systems were still not fully completed or not integrated. And even though the consultants indicated that the IPACS project "remained within the original cost estimates" despite the initial project abandonment, project participants estimate that the total cost of the original project, the recovery effort and the stand-alone investments in information systems made by individual departments exceed $2.5 million (without accounting for internal costs). A more complete history of the project can be found in Appendix Two. The Royal Canadian University Case RCU, a large Canadian university, considers itself to be one of the premier research institutions in North America. In the late 1980's, the administration of the university initiated two major initiatives related to the university's computing services. Firstly, it began phasing-in a charge back system that shifted all computer-related funds from the central computing services department to the user departments. At the same time, the administration initiated a procurement process for acquiring a sophisticated, numerically intensive computer that could be used by interested researchers. Even though the proposed system was not critical to the daily operations of the university, its president felt 81 Chapter 3 that "a first class university needed a first class computing facility" and strongly supported this initiative. To manage the selection of an appropriate solution, the president formed a selection committee that consisted of faculty members and computing services staff. The selection committee had a very difficult time in arriving at a decision for two reasons. First, due to the diverse needs of the researchers, there were a number of opinions about the exact configuration and capabilities of the proposed computer. Second, and perhaps most importantly, the committee could not reach a consensus about how the introduction of less expensive, powerful workstations and personal computers would impact the demands for mainframe-based computing and thus could not select an appropriate configuration. Because of these disagreements, the committee selected four possible solutions. After reviewing the committee's work, the administration of the university selected IBM as the winning vendor. Given that the university was among the recipients of the largest IBM donations in the country and IBM was interested in including RCU in another large computing project, many selection committee participants attributed this decision to non-technical reasons. According to IBM's proposal, the university was to receive an IBM 3090/150S mainframe with a vector facility through a four-year lease. The system was to operate IBM's AIX operating system. The selection of this system was strongly opposed by the computing center staff and researchers due to its poor price/performance ratio. 82 Chapter 3 After the system was installed on-campus, a small number of selected researchers were asked to participate in its beta testing. Due to technical problems with the AIX operating system, the availability of the computer was delayed a number of times. When the system was eventually put in operation (and the charge back fees were put into effect) its utilization dropped from about 100 percent to 7 percent! Apparently, many researchers decided that it would be more economical to purchase their own workstations instead of using the IBM computer. Having realized the potential of less expensive RISC-based computing, the computing center acquired a number of machines that made available to researchers who could not afford to purchase their own machines. As a result, many of the researchers, who were expected to be heavy users of the numerically intensive facility, were either using their own workstations or the less costly RISC-based services. Less than a year after its introduction, when the third lease payment (of $1,275 million was due), the IBM mainframe was hardly used and had a market value of less than $50 thousand. To rectify this situation, the university began investigating whether it could return the machine to IBM. A number of months were spent negotiating with IBM about the possibility of canceling the lease. At the same time, the computing staff carefully assisted the IBM users switch from the numerically intensive service to other services and began planning the acquisition of additional RISC computers that could eventually fully replace the services offered on the IBM mainframe. After lengthy negotiations, RCU exercised a "non-appropriation clause" in the contract that allowed it to cancel the lease if no funds were available for the lease payments. By exercising this option, the university did not pay the last two lease payments (totaling almost $2 million). The machine was returned to 83 Chapter 3 IBM within its first two years of operation. A more detailed account of this case is described in Appendix Three. 3.2.2. Data Collection To empirically investigate the ISD crises of the above three organizations, I used two complementary sources of data: face-to-face interviews and archival documentation. In general, data collected during interviews are targeted (because they focus directly on the research questions) and insightful (because they provide information about perceived causal inferences). However, interview data are subject to response bias and inaccuracies due to poor or selective recall. These threats were mitigated by utilizing archival documentation to verify and corroborate the interview findings. Archival data tend to be more stable, unobtrusive, have broad coverage, and are less likely to be subject to human memory and cognitive biases than interview data (Yin, 1991). Interviews To collect the data for this empirical investigation, fifty-one focused interviews (Merton et al. 1990) were conducted. All interviews were conducted by the author. The average length of the interviews was about two hours. The interviews were structured (Fontana and Frey, 1994). An interview protocol, with open-ended questions, was used to guide the data collection process. The protocol questions asked the respondents to describe matters of fact 84 Chapter 3 and provide their opinions and interpretations regarding these facts. As Yin (1994) points out, such interviews are: . . . an essential source of case study evidence as most case studies are about human affairs. These human affairs should be reported and interpreted through the eyes of specific interviewees, and well-informed respondents can provide important insights into a situation. (1994, p. 85) To receive a representative view of the events that took place as part of the I S D crisis in each case, the participants were carefully selected. After the initial entry of the researcher to each organization, two methods were used to identify potential informants. Firstly, I used "snowballing" by asking each interviewee to identify other involved individuals (Kvale, 1988) who could provide useful information to this study. Secondly, all collected documentation was reviewed to identify individuals that were involved with the project and the crisis management efforts. These two methods allowed me to identify and interview a diverse set of participants. A classification of the interview participants is shown in Table 3-2. Each case interview group included the chief administrator8 of the organization, a number of other executives (i.e. vice-president level managers), middle managers, and staff employees. In each case, about half of the participants were part of the project team while the other half were involved users and executives. Five individuals who were intimately involved with the projects but were no longer employed by the organizations during the time of the interviews were also interviewed by the author. Two of them proactively asked 8 The chief admin is t ra tor of R C U declined my inv i ta t ion to part icipate i n an interview. A senior adminis t rator of the univers i ty was in terv iewed instead. 85 Chapter 3 to be interviewed when they found out about this study from their ex-colleagues; the other three were contacted by the author based on the recommendations of other interviewees. Finally, nine non-organizational members, such as consultants and vendor's employees, who were highly involved with the projects, were also interviewed. Table 3-2: Participant Demographics Cases NU GVH RCU By Organizational Level Executives 5 3 2 Middle-managers 8 7 10 Staff 2 3 2 Non-organizational members 4 2 3 By Function IS employees 4 5 6 Non-IS employees 15 10 11 Total number of interviews 19 15 17 To conduct the interviews, I utilized a structured interview protocol. A copy of the protocol is included in Appendix Four. This protocol was developed by the author and was reviewed by two seasoned empirical researchers and two MIS consultants. Minor clarification suggestions were made by these reviewers and were incorporated in the final version of the instrument. The use of the interview protocol served two main purposes. First, it enhanced the reliability of the data collection be ensuring consistency across interviews.9 Secondly, it bound the data collection process by focusing on constructs that were pivotal to the study's theoretical framework as described in Chapter Two (see Table 3-3 for a classification of the interview questions). The respondents were ensured in writing that 9 Not a l l par t ic ipants were asked each of the 112 questions i n the protocol. Questions related to issues and aspects of the organizat ion tha t were un fami l ia r to a specific par t ic ipant were omi t ted f rom the interview. 86 Chapter 3 their answers to all of the questions were to be treated in confidence and any sensitive comments would be published anonymously without an attribution to their source. Table 3-3: Classification of Interview Questions Construct Corresponding protocol items Crisis impact 36, 37, 39, 40, 41, 42, 59, 68, 69, 104 Project importance 29, 31, 32, 33, 34, 35 Controllability of failure 38, 43 Pre-crisis preparation 45, 46, 48, 49, 50, 51, 54, 56, 57, 58, 105 Senior Management's Commitment 45, 46, 51, 52, 53, 55 Whistle-blowing 44, 45, 46, 47 Crisis management 56, 60, 61, 62, 63, 64, 65, 66, 67, 70, 71, 72, 73, 95, 105 Post-crisis learning 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 96, 97, 105 Demographic characteristics 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 29 To improve the quality of the data collected, I conducted "on the spot verification" (Kvale, 1988, p. 92). At the end of each major section of the interview, I asked each participant to review his main points. A similar approach was used at the end of the whole interview. I summarized the key points of the interview and the participant was asked to verify (and correct, if necessary) my understanding. Documents To corroborate the interview data, I collected hundreds of documents from each organization. These documents include internal memorandums, letters, electronic mail 87 Chapter 3 -messages, request for proposals, vendor proposals, agreements, audit reports, newsletters, project progress reports, meeting minutes and personal notes. The collected documents were furnished by several participants in each case study. The complete catalog of the documents that were collected during the case studies is included in Appendix Five. These documents were critical in understanding the ISD crisis process and constructing the historical accounts that are presented in the case summaries in Appendixes One, Two and Three. The collected documents were useful in three respects. Firstly, they allowed the researcher to tap into information that is normally not affected by the passage of time and biases that are present in personal retrospective accounts of historical events. Secondly, they identify the exact dates of the various events that took place during the cases. As the projects that were examined in this study were multi-year projects it was difficult for participants to accurately recall the exact timing of each activity and event. However, because the timing and sequencing of events are critical in developing accurate case descriptions and causal relationships, the collected documentation proved to be an invaluable resource during the data analysis stage. Lastly, and perhaps most importantly, the documentation served as a corroborative source of information for the descriptions and explanations provided by the participants (Yin, 1994). Overall, because I used multiple sources of data (interviews and documents) and multiple respondents (representing various organizational levels and functions), I am more confident about the quality of the data and the validity of the observations. The use of 88 Chapter 3 multiple data sources and respondents provided "multiple measures" of the main constructs of interest and, as my analysis will show, the documents and interview data represent converging lines of inquiry.10 This triangulation is especially useful in cases of controversial, sensitive issues (such as failures) which usually generate strong personal feelings and opinions that color recollection of events (Renzetti and Lee, 1993). Indicative of this was the fact that in two cases, two involved individuals had collected numerous emails, memos and other documentation as evidence of others' "wrongdoing" and their own whistle-blowing attempts. 1 1 The researcher benefited enormously in validating interview data from the document collections of these two participants, along with an extensive compilation of all project-related documents prepared by participants in the third case as part of their internal legal preparation efforts. 3.2.3. Data Analysis To collect and analyze the data for this empirical investigation, I followed a three-stage process (Miles and Huberman, 1994). To maintain the "chain of evidence" there was some overlap in the timing and activities of each stage. Despite this, these stages are described in a linear fashion. 1 0 There were no confl ict ing evidence between the interv iew data and in format ion i n the collected documents regarding major events i n the cases. I n a few instances of conflicts (which were associated w i t h minor details such as event dates, sequences, locations, part ic ipants, etc), the part ic ipants were asked to review the documents to refresh the i r memories and were al lowed to reconstruct the i r accounts. I f the discrepancy persisted, the in format ion i n the documents was used to reconstruct the case histories. 1 1 Fear ing tha t these indiv iduals could be questioned about their possession of these documents, one of them kept them at her home and the other locked them in one of her f i l ing cabinets. 89 Chapter 3 During the data collection stage, I conducted the interviews and collected the documents. All interview conversations were tape-recorded and the tapes were professionally transcribed. The complete text of each of the interview narrative was indexed and stored in a database. Each of the collected documents was also indexed in the database. I used this database to access transcribed conversations and documents that were needed during the data analysis stage. During the data reduction and display stage, I listened to all the tapes and read each transcript and document. This preliminary, impressionistic analysis of the data enabled me to begin formulating comprehensive understandings of each case (Kvale, 1988; Miles and Huberman, 1994). After this initial review, I re-read each transcript and coded its contents. To complete this categorization of the interview data I utilized purely descriptive codes that were based on the conceptual framework (see Table 3-4 for a list of the codes). The list of codes was created using the theoretical variables (and their states) of interest. All coding was done by hand12 so I used short, meaningful abbreviations for the codes. These codes were used as tags to assign meaning to chunks of the interview conversations. Each chunk usually consisted of multiple sentences and paragraphs. It is important to note that, for descriptive categorization purposes, what matters is not the words used as labels but rather their meaning. As Miles and Huberman (1994, p. 57) point out, such 1 2 Even though there are a number of computerized software programs tha t can analyze the l inguist ic patterns of tex tua l data and quant i fy them into numer ica l counts, I d id not feel tha t th is wou ld be a useful approach to take for th is invest igat ion. I concur w i t h Kap lan and Maxwe l l (1994) who argued tha t the abi l i ty to understand a phenomenon and i ts social context f rom the viewpoint of the study part ic ipants is largely lost when textual data is t ransformed into numer ica l tal l ies. Dur ing this early stage of ISD crisis related research, I feel that i t is more useful to focus on the holist ic understanding of ISD crisis si tuat ions rather than the language patterns i n the part ic ipants ' descriptions of the si tuat ions. 90 Chapter 3 coding "entails little interpretation and attributes a class of phenomena to a segment of the text." Table 3-4: List of Descriptive Codes D e s c r i p t i v e / d e m o g r a p h i c i n f o r m a t i o n D E S C Project DESC-P M I S department DESC-MIS Organizat ion DESC-ORG Vendor DESC-VEN Other DESC-0 C r i s i s i m p a c t I M P Operat ional I M P - 0 Legi t imacy I M P - L F inanc ia l I M P - F P r o j e c t i m p o r t a n c e I M P Strategic IMP-S Operations I M P - 0 Pol i t ica l IMP-P C o n t r o l l a b i l i t y o f f a i l u r e C N T R L Support ing evidence C N T R L + Contradictory evidence CNTRL-P r e - c r i s i s P R E Preparat ion — support ing evidence PRE-PRE+ Preparat ion — contradictory evidence PRE-PRE-Eva luat ion of pre-crisis actions PRE-EVAL S e n i o r m a n a g e m e n t ' s c o m m i t m e n t S M C Cont r ibu t ing factors SMC-FAC Escalat ion evidence SMC+ De-escalation evidence SMC-W h i s t l e - b l o w i n g W B Cont r ibu t ing factors WB-FAC Support ing evidence W B + Contradictory evidence WB-C r i s i s M a n a g e m e n t C M Operat ional C M - 0 Legi t imacy CM-L P o s t - c r i s i s l e a r n i n g L E A R N Organizat ional L E A R N - 0 Ind iv idua l L E A R N - I Adapta t ion evidence L E A R N - A D + No adaptat ion L E A R N - A D -Rig id i ty evidence L E A R N - R I G + Non-r ig id i ty evidence LEARN-RIG-After all data was reviewed, catalogued and coded, I created historical accounts of the cases to (1) ensure that I had a valid and complete understanding of the relevant facts and 91 Chapter 3 events and (2) begin the condensation part of the data analysis stage (Kvale, 1988; Miles and Huberman, 1994) and explore the relevant facts and processes. These historical summaries were created by author after carefully reviewing all of collected interview and document data. The goal of these accounts was to identify and reconstruct the sequence of all relevant events and behaviors that took place in each case. Each case summary was reviewed by participants from each organization to ensure its accuracy. The validated case summaries are presented in Appendixes One, Two and Three. During the conclusion drawing and verification stage, I analyzed the coded data looking for "regularities, patterns, explanations, possible configurations, causal flows, and propositions" (Miles and Huberman, 1994). To do this, I first used a time-ordered data display technique, event-state networks, to describe the key events that are discussed in the chronology of each case. These networks are simply graphical depictions of the major events that were included in each case summary (which were depicted as rectangular boxes) and the factors that influenced those events (which were depicted as circles). Event-state networks are very effective in depicting complex processes, such as organizational crises, by displaying "a string of coherently related events" (Miles and Huberman, 1994, p. 111). The event-state networks for each case are included in Chapter Four. To explain the events that took place in each case (as depicted in the case histories and event-state networks), I conducted within-case analyses. These analyses focused on explanation building by relying on the theoretical propositions presented in Chapter Two. The goal of these analyses was to build a comprehensive explanation about the data in 92 Chapter 3 each case and to develop ideas for further study (Yin, 1982). In the within-case analyses, I followed a program logic approach (Wholey, 1979) to understand the causal links between factors (states) and processes (events) and assess whether the empirical observations were consistent with the patterns of events as predicted by the theoretical framework. Also, I utilized role-ordered matrices (Miles and Huberman, 1994, pp. 122-126) to display the findings when the accounts of the respondents were not in agreement. These matrices simply summarize the conflicting accounts of participants and identify salient characteristics in the role of each participant13 that may explain the existence of disagreements among them. To summarize the interactions among the main constructs in the conceptual model, I utilized case dynamics matrices. These matrices display the causes of events and trace their consequential processes and outcomes (Miles and Huberman, 1994). Finally, I conducted a between-case analysis. In this analysis, I developed a case-ordered predictor-outcome meta-matrix to identify the commonalties and differences among the cases. In the cross-case comparison, I used a variable-oriented approach (which is consistent with the replication logic I used in the sampling) to identify the common patterns and explain the differences in the cases (Yin, 1984; Ragin, 1987; Miles and Huberman, 1994). The variable-oriented approach looks at each case and it teases out the variables of interest in each case and subjects them to comparative analysis. In these comparisons of cases, underlying similarities and systematic associations are sought out with regard to the main dependent variables (Ragin, 1987). The within-case and between-The role characteristics and description of the part ic ipants were selected by the author. 93 Chapter 3 case analyses along with the various analysis matrices are presented in the discussion in Chapter Four. 3.3 SUMMARY OF VALIDATION MEASURES To enhance the rigor of the empirical investigation and protect its findings from potential validity threats, I established a clear chain of evidence and followed many recommendations from case research experts in the data collection and analysis activities. Even though these actions were described in detail throughout this chapter, a brief summary of them is presented next for the interested reader. Maintaining a logical chain of evidence is critical in case studies. As Yin (1994) points out, such a chain enhances the validity of the study by allowing external observers (such as the reader of the case study findings) to follow the derivation of any evidence from initial research questions to ultimate case conclusions. I believe that the chain of evidence in this investigation is solid: I formulated the interview questions based on the theoretical constructs of interest; all collected evidence were recorded, transcribed, catalogued and coded; I constructed (and verified through the help of participants) the histories and event-state networks for each case using the collected evidence; and I used the original theoretical propositions to construct the matrices and guide the discussion that explain the events in these histories and networks. Most importantly, these activities took place in a highly iterative process, enhancing the coupling of the findings with the collected data. 94 Chapter 3 During the data collections and analysis process, I took specific steps to increase the internal, external, and construct validity and rehability of the findings (Denzin and Lincoln, 1994; Guba and Lincoln, 1994; Yin 1994). These steps are summarized in Table 3-5. Table 3-5: Case Quality Enhancing Tactics Issues Steps taken during data collection and analysis Construct Validity Used multiple respondents (current employees from various organizational levels and functions, ex-employees, external consultants, etc.) Used multiple data collection methods (interviews and historical documentation) to achieve triangulation Key informants reviewed case histories and analysis Internal Validity Established chain of evidence using qualitative analysis techniques: Conducted qualitative event-sequence analysis using event-state networks Conducted explanation building using within-case and cross-case analyses External Validity Used theoretical replication logic in selecting multiple case studies Reliability Used detailed interview protocol Developed detailed case databases Source: Yin, 1994, p. 33 Construct validity refers to the ability of a study to establish correct operational measures for the concepts being studied. By selecting a diverse sample of respondents in each case and by corroborating the interview data with the collected documentation, I believe that I managed to more fully and accurately understand the events under investigation. Also, by having participants review the findings and confirm the facts in them, I am more confident about the construct validity of this study. As Yin (1994, p. 145) points out, participants' 95 Chapter 3 reviews and comments enhance the accuracy of essential facts and evidence and thus increase the construct validity of the study. Internal validity refers to the ability of the study to unequivocally establish causal relationships, whereby certain conditions are shown to lead to other conditions, as distinguished from spurious relationships. I included both supporting and contradicting evidence to validate each linkage in the conceptual model. By carefully monitoring the close links between the original data and the findings, I believe that a reader can easily trace the findings back to the collected documentation and interview conversations. As a matter of fact, a number of original quotes and experts from the documents accompany each hypothesized relationship that is discussed in Chapter Four. External validity refers to the ability of the study to establish findings that can be generalized to similar contexts. In this investigation, this was not achieved through random sampling from a sampling frame of "average" ISD crises. Rather, external validity was enhanced by selecting cases with dissimilar, albeit theoretically explainable, outcomes. In other words, my intention was not to generalize a set of specific behaviors taking place as part of an ISD crisis. My interest lies in the formulation of generalizable theory-supported propositions that can be applied in diverse ISD crisis settings to explain (and predict) such behaviors. Finally, reliability refers to the ability of the study to demonstrate that its data collection and analysis can be repeated with the same results. To achieve this consistency I used 96 Chapter 3 highly structured protocols and catalogued every piece of data collected in the three case studies. I firmly believe that the transparency of the data collection and analysis techniques enables the reader to assess the reliability of this investigation. 97 Chapter 4 EMPIRICAL FINDINGS Where there is much desire to learn, there of necessity will be much arguing, much writing, many opinions; for opinion in good men is but knowledge in the making. John Milton 98 Chapter 4 4.1 WITHIN-CASE FINDINGS This section summarizes the key findings from each case and utilizes the collected data to empirically assess the research propositions that were presented in Chapter Two. For each of the three cases, an assessment of the crisis impact, a discussion of the various stages of the crisis and a brief summary of the findings are presented. 4.1.1 Northern Utilities Case Findings The IMIS project failure created a significant crisis for Northern Utilities that required intensive crisis management efforts. An explanation of the key factors and events that led to this failure, along with a description of NU's crisis management actions, can be found in Appendix One. A State-event network summarizing these factors and events is shown in Figure 4-1 (the critical elements of this network are discussed throughout this section). Event-state networks are time-ordered displays that visually summarize the chronology of events "permitting a good look at what led to what, and when" (Miles and Huberman, 1994, p. 110). The events in the network (which are represented as boxes) follow a temporal sequence starting from the top-left corner and following a meandering pattern from top to bottom, left to right, bottom to top, etc. The bubbles represent states which are conditions that are characterized by "more diffuseness, less concreteness, [and] existence over a longer time" (Miles and Huberman, 1994, p. 115). 99 o o IMIS Crisis Impact Chapter 4 The failure of the IMIS project, coupled with the lack of a contingency plan, exposed NU to a number of operational and legitimacy risks. KPMG auditors summarized these risks in a project audit review a few months after the failed conversion. The audit report identified the following risks faced by NU: • inability to meet a legal requirement to produce financial statements; • A/P problems could result in payments to incorrect firms and/or missed payments and/or lost discounts; • no management information to operate the company; • inability to effectively track sick/leave time [while] basic payroll is being met with some manual effort; • a lack of reliable inventory system could seriously impact service if parts are not available when required; • the current manual work-around process for payroll is open to error. NU's internal operations were severely impacted for about a year after the conversion date. Because of the systems' inability to capture financial data and generate needed reports, NU was incapable of monitoring many of its internal operations, including accounts payable, inventory, and payroll. As one executive simply put it, "our throat was cut." Another executive indicated that: The organization didn't know where it stood financially. We didn't know how much we're spending, how much we're not spending and whether or not we were exceeding our budgets. Many internal operations were impacted by the IMIS failure. For example, NU was unable to issue payments to its vendors. In certain cases, accounts payable remained overdue for up to six months even though vendors were billing NU on a "net 30" basis. NU was also unable to keep accurate payroll, vacation and sick leave records during this time. To deal 101 Chapter 4 with this, it resorted to recording such information on paper timecards and issuing "regular" paychecks to employees until the system was able to process the timecards containing vacation, sick leaves, and other relevant information. (Incidentally, it took over a year for IMIS to accomplish this and process the backlog of paper timecards.) Lastly, NU was unable to accurately record its inventories as the MRP and inventory modules were among the last ones to be completed. In addition to these operational impacts, the IMIS failure created a threat against the reputation of NU and its senior managers who championed this project. The cause of this legitimacy liability was threefold and involved major external stakeholders. Firstly, NU was not able to generate needed quarterly financial statements for an extended period after the system conversion. Due to the strict regulatory and audit policies in this industry, this placed significant pressure on the project team to quickly fix the systems and generate the financial statements so the auditors could review them. It took NU more than ten months to generate its first quarter statements and over a year to prepare the remaining quarterly and annual statements. Secondly, the failure of the IMIS threatened NU's relationships with its vendors. NU was unable to keep track of its purchases and payments for months after the failure increasing the risk of late payments. Thirdly, the threat to the credibility of the senior management was further imperiled by the need to provide accountability about the failure and its impacts to the public commission (and other governmental bodies) overseeing and allocating funds to NU's operations. The following comment summarizes the impact of the legitimacy crisis: I think our general manager was probably worried about being held accountable by 102 Chapter 4 the commission and I think this probably worked in our favor. By letting the project get to such a critical state the main worry of the elected commissioners became "let's just get it working because we've got no financials and we look really bad in front of the electric [utility commission]." The remainder of this section describes two key factors, project importance and controllabihty of the failure, and key events that influenced and were affected by this significant crisis impact of the IMIS failure. IMIS Project Importance The IMIS project was important for NU for a number of reasons. Firstly, it was pursued as a strategic investment that would enable NU to better manage its internal operations and strategically reposition itself in a radically changing regulatory and competitive environment. At the time, the regional municipal and provincial governments were considering integration of the local utilities and thus there was a strong pressure to reposition NU as a dominant utility player in the local industry. Also, the implementation of the project was partly initiated because it would have allow NU's management to better control, monitor and account for its costs and operations in the future. Such cost controlling capabilities were very important for NU in demonstrating their ability to effectively operate in the new competitive environment. Secondly, the IMIS project required significant amount of resources. The cost of the project was estimated to be over two million dollars, which represents over two percent of NU's total annual revenue. The actual cost of the project was more than twice its original estimating further increasing its perceived importance. Thirdly, the project was considered consequential because it 103 Chapter 4 impacted many critical areas of the organization. An executive commented on the organization-wide scope of the project: The IMIS project was mission critical because our financial systems formulated the basic structure of many of our internal operations including ordering, accounts payable and receivable, inventory, project management, costing and many others. It touched so many departments. Because of this, the project was given high profile and it was a big investment for us. The initial estimated costs, including internal time, was about $2.5 million. Because of the magnitude and importance of the project, NU's management sought the approval of the elected commission. Convincing the commissioners that IMIS was a wise investment was a long process and required strong commitment and constant reassurance by NU executives. This process magnified the political value and importance of the project and increased the management's stake in its eventual success. As an involved executive bluntly put it, "basically the general manager and I committed to the commission that we would deliver this thing on time and within budget so our asses were on the line to a certain extent." The high strategic and political significance of the IMIS project seems to be positively related to the failure's impact. Because IMIS was to be an integral part of the organization's operations and future strategy, the failure of the project severely impacted them. Furthermore, because of its political importance and the involvement of the commission, it created a visible failure further heightening the crisis and the need for an immediate, organizational response. These findings are consistent with hypothesis one and are discussed in more detail in the remainder of this section. 104 Chapter 4 Controllability of IMIS' failure Both NU executives and non-management employees felt that NU shared a significant part of the responsibility for the failure of the IMIS project for two reasons. First, the actual project management responsibility of the project was formally delegated to both NU and Oracle. Therefore, the inability of the project team to successfully deliver the systems was partly attributed to NU's incompetence to properly manage the project. Indeed, the KPMG audit report indicated that NU was responsible for the following failure-contributing factors: • the selection of an inexperienced project manager; • a lack of effective change control; lack of a contingency plan; • inadequate staffing and resource allocation; and • a lack of senior management involvement and "sense of ownership." Secondly, there was a clear consensus that NU could have been more proactive in managing the troubled project before it failed. As the remainder of this section will demonstrate, NU made no attempts to proactively prepare for the failure before the unsuccessful conversion of the system. This lack of preparation, according to NU employees, significantly contributes to NU's responsibility for the crisis. As the project's executive sponsor simply put it, " we could have started the recovery process earlier. We should have realized that something was wrong much earlier." The above observations are consistent with responsibility attributions made by both senior managers and non-managerial employees. In general, when asked to allocate "100 responsibility" points to groups or factors that contributed to the IMIS project crisis, the 105 Chapter 4 participants consistently allocated the majority of blame to their organization. This was mostly due to the fact that NU failed to take any actions to prevent the failure from materializing and did not proactively prepare for the crisis when it became aware of it (see Table 4-1). Table 4-1: Role-Ordered Matrix: Attributions of Responsibility for IMIS Failure Position Salient characteristics Comments Senior managers Executive involved i n the project I wouldn' t assign the major i ty of responsibi l i ty to Oracle. I wouldn' t go tha t far. I would probably say tha t i t was a 50/50. Had we done a better job w i t h mak ing an assessment we migh t not have had to deal w i t h Oracle. We might not have picked them as a vendor. Manager who d id not support the project About 30 percent should go to the executive team, 35 percent to the project team and 35 percent to Oracle. The project leader wasn't involved. The executive team didn't real ly wan t to be involved either. Non-management employees Appl icat ion leader This is a tough one. I blame the executive cause they signed the deal i n the f i rs t place but I t h i n k i f John had also stepped up and done his job better i t could have been different. I wou ld probably say John and Oracle would share equally and the executive a l i t t le higher. I t 's about 40/30/30. Involved end-user I tend to blame our side more t h a n Oracle because Oracle made a sales p i tch and yeah they fe l l down i n some respects too when we came to implementat ion bu t we didn't have to buy the i r product so I wouldn' t give them as strong a weight. I t h i n k our management fe l l down a lot. As these attributions of responsibility indicate, NU's apparent inability to prevent the failure from materializing by better managing the project and its relationship with Oracle, and the lack of proactive actions aiming to lower the impact of the crisis contribute to the accountability faced by NU's senior managers. These findings are consistent with hypothesis two. IMIS Pre-crisis Stage In the NU case, the project and senior managers took no steps to avert or prepare for the impeding failure. In fact, despite the lack of proper testing and population of the database 106 Chapter 4 with the needed data and the non-conclusion of several implementation steps, the conversion took place as originally planned. On January 1, 1996 the old systems were completely shut down and the new applications were put into production. Quickly, the end-users and involved managers realized that the new systems were not functional. The project managers informed them that it would take just a few days to take care of the glitches (it actually took more than a year and two recovery projects to achieve this)! At no point was an attempt made to formulate a contingency/backup plan in order to protect the operations from a possible failure of the new systems. Several attempts by application leaders to postpone the conversion and maintain the old systems in parallel for at least six months were rejected by the project manager. Consequently, the organization was caught unprepared to effectively deal with the failure leading to the high impact of the crisis. An executive reflected on this issue: I think we should have gotten a progress assessment on where the project was before the conversion. Had we have done that we simply would not have shut off the old system. We would have gone with the old system until the new one was working and our operations would not have been as severely affected by the system's failure. The following comment by another executive also indicates that the denial and the lack of preparation continued after the conversion of the system further intensifying and prolonging the negative consequences of the failure: Well, after the system went live in January, I was told that we wouldn't have financial statements until the middle of February. I didn't care about that. We've never had them that quickly before so who cares. As it comes to about the first of February, they began saying "oh gee, we've got these problems and all these things aren't working" and they couldn't keep track of all the financials, so you could just see that the thing wasn't going to work. As this continued to go on, we decided to do something about it and we called in KPMG. 107 Chapter 4 In sum, it appears that this prolonged denial significantly contributed to the lack of preparation for the IMIS failure leading to a high impact organizational crisis. This is consistent with hypothesis three. The fact that the IMIS project failure caught NU completely unprepared for it is puzzling because a series of unequivocal warning signs proceeded the failed conversion. Based on a review of the collected documents and the participants' accounts, these included the following red flags: • Significant concerns that were raised by both users and executives during the vendor selection process that led to the initial rejection of the Oracle proposal; • Statements by Oracle consultants who expressed concerns with the ability of Oracle to deliver a system that would satisfy NU's stated needs before the initiation of the project. As a project leader commented, "this was the biggest warning sign. The Oracle consultants who worked in the manufacturing side of the systems, right from the beginning took a look at our needs and said that the package won't fit. They said that to everybody; they made it very well known." • Multiple delays of critical deadlines. Characteristically, during a nine-month period, the completion dates for the various IMIS modules were postponed on at least eight occasions! Furthermore, as the progress reports show, about two months before the scheduled conversion date, none of the IMIS applications had progressed past stage three (as part of a seven-stage methodology)! • Rejection of the payroll module by the HR department. An executive reflected on the "warning " value of this rejection: The HR application was supposed to be installed first and be a quick win. It turned out that the Oracle application actually wasn't as good as what the HR department was currently using, which was a PC-based system. So they said forget this crap. 108 Chapter 4 There was an ongoing war for several months, which consumed a whole bunch of resources. They wanted to stay with what they had. We were concerned about the interface between the applications because both the purchasing module and the project costing module relied very heavily on data tables within the Oracle HR application. In the end, the HR department decided to use the Oracle application. We could have put a stop to that and laid down the law. What we should have done is told HR this is the system you're going to use and that's the end of it. Quit bitching and just do it. And you know that went on for several months before we finally put the hammer down on that. I think that could have been handled sooner and better. So we came to a real rush in the fall of 1995 and I probably should have clued in at that point that all was not well. • The abrupt discontinuation of the monthly progress reports four months before the conversion date without a justification. Interestingly, no manager or commissioner questioned this. • Verbal and written feedback from involved users who were expressing their concerns about major unresolved design issues just a few weeks before the targeted conversion date. For example, a memo from an application leader to the project manager states: It is now December 8th, three weeks to production and from a payroll viewpoint we have not discussed the interface between HR, PA, and payroll. You have mentioned that you have the record formats for payroll but they have not been finalized. No one has discussed the process of data flows. I'm getting very concerned about this outstanding issue. • The omission of critical development steps such as testing and development of production databases from scratch. An executive reflected on this issue: I guess one of the things that really should have keyed on me is what happened during a meeting in December a few days before the conversion. It was a meeting about how some aspect of the system was going to work. I thought the design phase was over several months previous so I probably should have clipped a little more.... I should have asked why the hell we were still talking about the design of this thing. It was supposed to be built by now and be in testing and we were talking about the design. So that should have probably been one hint but hindsight is 20/20. Given the multitude of warning signs, NU's lack of preparation for the crisis is perplexing. 109 Chapter 4 To examine the factors that facilitated the continuation of the project without any crisis intervention attempts, we examine the attitudes and behavior of involved managers and non-management employees. Escalation of Commitment in the IMIS project Whether the above warning signs were actually visible to busy managers and executives during the project can be questioned. However, with the exception of the project manager and an executive who were seen as responsible for the project's failure (see Table 4-2), all case participants indicated that the warning signs were serious enough and should have attracted the attention of the project managers and senior executives. Overall, the overwhelming majority of the case participants suggested that the warning signs were indeed visible but not acknowledged. As one participant pointed out: I think different people actually woke up to the fact that the project would fail in different stages. I think it depended on how closely you were involved with, certain aspects of the project. I mean, if you really watched the path that we took at each step and if you were to draw a linear diagram of what we did you could actually, literally just watch the chunks fall off as you go and that's sort of where it fell. Most managers ignored this though. We just kept pointing things out and we were getting told to keep going. The above comments and the apparent inaction by managers in preparing for the crisis indicate that the managers' escalating commitment to the project significantly contributed to its continuation. This is consistent with hypothesis four. 110 Chapter 4 Table 4-2: Role-Ordered Matrix: Pre-crisis Warning Signs Position Salient characteristics Comments Senior managers Project's executive sponsor I didn't delve into was happening in the project during its early stages. I guess if I would have, I would have realized things sooner... I think the signs were there very early. We didn't figure them out until way later. Manager not heavily involved with the project There were all the signs of not having the needed information about anything you requested and always being put off by saying that 'we're just about there, give us another week, just another week.' You knew deep down there was something wrong but no one could prove it was. There was denial. One of the managers responsible for the project The warning signs were very late. What was reported was that everything was going wonderful. When you read through the reports there are little issues that would pop up now and again but nothing of any consequence that would suggest you are going to face a failure. Non-management employees NU's project manager There was a lot of wolf crying. People got nervous because of the changes so some red flags were really not really red flags. I did not hear anything disturbing during the project. Application leader I think the people were blowing the whistle throughout the project, but I think the managers weren't listening. IS staff Most of us knew this was not going to work because of all the problems that came up during the project. There were a lot of critical issues that were raised but were ignored by the project managers. It appears that a major factor that contributed to the escalating commitment climate in NU was the project's political importance and visibility. Because it was such a "high priority" project, any delays or cost overruns in the project would be unacceptable. The following comment by a senior manager who was involved with the approval process reveals the political significance of the project and the resulting pressure: Completing the project on time and within budget was the most critical thing that I expressed to John [the project manager] right at the beginning of the project. This is going back to when the project first started. I said 'you know this thing has a very high profile. It was hard sell, it went back to the commission several times.' Basically the general manager and I committed to the commission that we would deliver this thing on time and within budget so our asses were on the line to a certain extent. I expressed that to John right from the beginning and all the way through. From my perspective, the time and budget were critical. And in the end neither one were met. I l l Chapter 4 This pressure to complete the project on time was felt by many individuals who were involved in it: There was a mandate to get it done by January 1st. It was etched in stone. We were told that it was not etched in stone but in our opinion it was certainly perceived as being etched in stone and the project manager had his own agenda to get this thing done. He wanted it on time, within budget, the whole shebang. So he went full guns to get this thing done at any cost and we weren't ready. I actually issued a memo in the middle of November when I recommend we don't go live January 1st that we go live June 1st. Target June 1st, run in parallel and don't go big bang. Unfortunately, they did not listen to me. It appears that the pressure to carry the project to a timely completion was so strong that managers were not willing to accept that the systems could fail, even days before the scheduled conversion date: We all thought that it was going to work. We had the utmost confidence it was going to work. So we cut cold. We did not have any proof that the data was actually verified and that the systems would work and integrate properly but we went ahead and put the systems into production. At the time, the fact that the systems could not be working was an unthinkable proposition. We were proved wrong. The tendency to ignore escalating negative information was so strong that even when one executive voiced strong concerns about the project's eventual success, the senior management team discounted them: I voiced my concerns at the beginning of this project. I also voiced them again about a year later saying I thought we should cut out losses and get out. We were a million into it and I suggested we get out then before we get any deeper. And the decision was "no, we're going ahead with it" cause the feeling was the project could be saved and that all would be well. As the previous quotes and events indicate, many senior managers believed that the project had to work no matter what the obstacles were in its path and continued to provide their strong support and commitment to it while trying to diffuse concerns. A memo from a 112 Chapter 4 senior manager, issued to project members just a few weeks before the conversion date, further illustrates the existence of an "over-committed" environment: The introduction of the IMIS is going to be "blamed" for many things. We must reflect carefully and think about the value or the opportunities the system will bring, rather than all the changes that are required to make it work. Our IMIS team has worked very hard to build a system that will meet our needs now and in the future. Don't shoot the messengers; they are on your side... Please lend your full support for the IMIS leaders, trainers, and the action planning team as we get set to go "live." There is no slack left in the schedule; we all need to meet our deadlines. In addition to the project's importance and visibility, the project manager's personal goals contributed to the escalation situation. As an executive explained, the project was important to the manager's career plans as well: I think the project manager had ulterior motives. He wanted to get a project under his belt and go to a consulting firm and do that type of work. So he wanted the project to be on his resume saying "project completed on time and on budget." Forget about facts. He was driving it and it was going to be implemented on time regardless and the budget costs were going to be there regardless of more monies being spent after the conversion. His whole driver was to accelerate the project. So every story around the project was geared to help that self-fulfilling prophecy. I think project managers can get hung up on those things in general. They tell you all the things you want to hear and that everything is going wonderful and you don't have to get involved with it. Consistent with this explanation, the project manager began searching for a new project management position in a consulting firm before the conversion date and actually left the organization for such a position a few days after the conversion of the systems (before the crisis became public). According to a large number of participants, the personal motives of the manager were so strong that he continually denied the existence of problems. An involved individual commented on this: I would meet with him on a regular basis expressing my concerns with major technical issues related to the project that were seriously impacting its progress. 113 Chapter 4 Despite this, when we went to the Thursday lunch meetings, he would say "this project is on time, on budget" ... oh geez... I think there was another one... yes, "with full functionality." It was the same story every week. "On time, on budget and fully functional." An executive observed a similar behavior: Basically, the project leader was the spokesperson for the whole group and he only spoke. He even prepped, I found out, project team members before meetings with the executive team so that they wouldn't go into areas that he knew were sensitive and weren't working. In summary, because of the high importance of the project (to the whole organization, the reputation of the senior managers, and the personal plans of the project manager), the managers were blindly committed to it hoping that it would be successfully completed. This is consistent with hypothesis five. Whistle-blowing in the IMIS project Due to the all the problems that took place during the project, a number of individuals . attempted to take action that would pressure the organization into acknowledging the existence of the crisis (and thus abandon the project or at least prepare itself for the impeding failure). Unfortunately, their attempts were not successful. As an executive put it, "there was a lot of information coming out of the trenches but it wasn't being listened to; the people down at the lower levels of the project were basically screaming for help but no one heard them." These non-management project members used a number of ways to express their concerns 114 Chapter 4 in order to influence the project's direction and pressure the managers to take actions seeking to avoid or prepare for the crisis. A number of them expressed their concerns informally to the project manager and involved executives. As mentioned earlier, these attempts were not successful and were diffused by the project manager. A project; participant discussed the usual result of such attempts: A lot of people tried to tell John that they were major problems with the project and it wasn't going to work. Nothing was getting up to the executives. Everyone was sounding it to John, but he was like Teflon. It was just rolling off him. I don't know if he had a hidden agenda cause of the way he left and the timing of his departure, but it certainly wasn't going up to the executive. In other cases, non-management project participants wrote memos in attempt to raise a "red flag" and change the project's direction. For example, an application leader prepared a memo proposing (and justifying in detail) a delay of the conversion. The project manager rejected this. In another memo, which was issued just three days before the conversion, a project participant informed the manager that none of the application leaders was ready to proceed with the conversion. Despite this, the project leader responded that the project activities would continue as planned! After witnessing the ineffectiveness of their efforts to stop the failing project within the leadership of the project, a number of participants attempted to bypass the project manager and raise the issue with NU executives who could potentially influence the direction of the project. One of the whistle-blowers commented on her motivation: The project was deteriorating but the managers were not doing anything about it. Because I was very involved with the project, I knew its problems and I knew they were major. I was afraid that the systems would be turned on without proper testing. So, I felt I needed to do something to stop this from taking place and help 115 Chapter 4 the managers better understand the situation. I just didn't want this to be a fadure because it involved a lot of money and a lot of hours of work. Unfortunately, none of the whistle-blowing attempts were successful in abandoning the project or preparing the organization for the impeding crisis. According to one project participant, his whistle-blowing attempt was ineffective because it was labeled as negativism: I tried to tell our project manager and Oracle that this was not going to work. They did not listen to me. So, I went up to my director. I did that on a few occasions. I told him how I felt and expressed my strong concerns with many aspects of the systems. He came back and said, "you know Cliff [the General Manager] doesn't want to hear anything negative about this. He just wants people to be committed and get this thing going." Well, this cost us dearly. A similar attempt was made by one of the application leaders. This leader confidentially communicated to one of the executives the troubles with the project and the tendency of the project management to discount major issues. An executive described this individual's whistle-blowing efforts: I know there was an individual in particular on the project that was just screaming for help and I guess she was being silenced very effectively by the project manager. I mean she knew were the project was. She knew that the system didn't work and wasn't going to be working for a long time so she was trying to raise these issues and she was basically silenced by the manager who told her to shut up and mind her own business. So, she went to one of the directors. He raised the issue during a meeting with the executives when John, the project manager, was present. John said "Don't worry." We believed him. The involved application leader commented on the result of this attempt: I was very heavily involved and I was very aware of the problems. But, I had no one to go to. The other people on the project had their everyday supervisor to talk to and say "You know I don't agree with this and we need to deal with it." The person could then take it higher above the project manager. I didn't have anybody. I only had him to go to if I didn't agree with something. So, every time I went to him, he 116 Chapter 4 would say "Go away, don't worry about it." One time, I went over his head and I went to a director and said "Look there are major problems here." He actually went back to John and said "You know she's come and told me this, this and this." So of course, John came right back to me. Well, that stopped that attempt and I decided to keep my mouth shut. The funny thing is that when the project failed I was invited to participate in a management meeting to talk about the problems. One of the directors actually had the audacity to ask me "Why didn't you come and tell us?" "Excuse me?" I said "I told Don, what the hell more did you want?" Then the man goes behind my back and tells John everything that I said. Do you really think I'm going to go in get my head chopped twice? Are you crazy? Like, get a life. And I said "You guys put him in his role, you were not asking the right questions and were not asking the right people." Interestingly, a number of participants indicated that managers used a "labeling" tactic that made it more difficult for them to openly express their concerns about the project reducing the likelihood of successful whistle-blowing attempts. According to the participants, their concerns were labeled as "irrational" and were attributed to individual characteristics to deflect attention from the project's problems. One participant commented: The management culture played a major role here. When you voiced concerns, people sort of looked at you and said "you're being negative." You were not being negative; you were just telling it the way it was but it was taken as if you were talking negative about the project and you were not committed and supportive when in reality this project wasn't going anywhere. You weren't negative, you were just being a realist. But, the culture was such that everyone kept saying "Come one everybody, pull your weight, get committed." So if you mentioned the project's problems, you were not committed! And you do everything to go forward. But, if you don't see any light at the end of the tunnel, there's no sense pretending there is light at the end when there isn't. A woman participant expressed another manifestation of this tactic focusing on women's "emotional tendencies." She explained: Sometimes when I raised a serious issue, John would come along and say "Well, it's okay, you are emotional. It's okay, you're a female." Because we're women, we are emotional. That's something they do around here. And they've done it one too 117 Chapter 4 many times to one girl here. I tell the truth and they probably can't stand it because I just say it. In summary, as the above evidence and accounts indicate, in an effort to change the direction of this project, certain individuals engaged in intense whistle-blowing efforts. The intensity of these efforts and the high importance of this project are consistent with the relationship proposed in hypothesis seven. Unfortunately, it appears that these efforts were ineffective, as they did not successfully curtail the denial that existed during the pre-crisis stage. This is inconsistent with hypothesis six. As the above examples indicate, the effect of whistle-blowing was diminished by the over-committed managers, their use of labeling strategies, and their continual pre-crisis denial. As the statements by whistle-blowers clearly indicate, even though the commitment-based behavior of managers did not prevent them from expressing their views altogether, it did have a suppressing effect on the propensity of these individuals to engage in subsequent whistle-blowing efforts. This provides support to hypothesis eight. Also, it indicates that even though both the enhancing effect of high project importance and suppressing effect of commitment escalation influence whistle-blowing, the enhancing effect appears to be greater. IMIS Crisis Stage Due to NU's lack of preparation to deal with the crisis of the IMIS project, its impact was quite consequential (see section necessitating a vigorous post-failure management effort. Indeed, the crisis-management support provided and resources allocated by the senior managers were substantial. An executive who was involved in the recovery effort 118 Chapter 4 commented: We had all the necessary help to support the recovery project. The executives were very eager to put the necessary money and effort into it. There was no problem gaining their support [during the recovery effort] because it was so late and so screwed up that everyone wanted to cover their butt including the commission who approved the dollars to do it. Interestingly, this high intensity of the recovery effort did not last for long. After the production of the first quarterly financial statements (which was the major concern of the management), the apparent support to the recovery project decreased substantially even though a number of applications were still not functional. This made the later stages of the recovery process more difficult to manage and further prolonged the crisis stage. The t above executive discussed the effect of this reduced crisis impact during the later part of the recovery efforts: I partly blame us [the executives] the most for the prolongation of the recovery process. Now that the statements are there, now that is not critical anymore, IMIS doesn't matter anymore. They're going back into their old habits again and that's what I'm seeing happening. I'm seeing a repeat of what we went through a year and a half ago. As these assessments indicate, the magnitude of the crisis is indeed related to the intensity of the crisis management efforts. This is consistent with hypothesis nine. It appears that management is much more attentive and willing to allocate the needed resources during the dramatic moments of the crisis. However, as the crisis subsides so does the support. During an interview in the final stages of the recovery process, a participant commented that "IMIS is an old story now. The managers are on to their bigger and better things and the executive as a whole doesn't seem to give the project very much time or attention." 119 Chapter 4 As mentioned earlier, NU pursued specific tactics to manage both the operational and legitimacy liabilities caused by the IMIS project failure. These actions, which are consistent with hypothesis eleven, are described in detail in the following sections. Operational Crisis Management Even though the IMIS project did not produce the anticipated functional applications, NU continued its efforts to complete the project for about two months after its conversion. During that time, NU hired the Oracle project manager to replace the NU project manager, who left soon after the cutover. The Oracle manager left NU after a few weeks when all allocated IMIS project funds were exhausted. In an another attempt to recover the systems, NU paid an additional $100 thousand to Oracle to complete the project. When these additional funds were consumed, many of the applications were still unusable. At the same time, there was a mounting pressure to address many key operations of the organization that were affected by the delays in the delivery of IMIS. To rectify this situation, NU engaged in intensive crisis management to (1) recover the project and (2) minimize the damage to the affected operations until the systems became functional. To turnaround the project and fix the problems in its applications, a swift project audit was conducted by KPMG MIS consultants. NU paid $25 thousand for this audit which concluded that the project was recoverable and recommended a specific recovery strategy that would put all systems in production within ten months after the failed conversion. A recovery project was immediately initiated resulting in the project team participants being 120 Chapter 4 "deeply relieved because a recovery effort was going to take place and something was actually going to happen!" A "prioritization" strategy was followed in the recovery project. Issues regarding "show stopper" modules were addressed first while issues regarding other applications (such inventory and MRP) were classified as secondary. Because of the seriousness of the situation, NU management was willing to allocate the needed support, staff time, and resources to the recovery project. The following actions illustrate the intensity of this effort: • A NU director (the IMIS executive sponsor) was assigned as a full-time manager of the recovery project and was relieved from his other responsibilities (which were temporarily assigned to another director). • A seasoned MIS consultant was hired as a full-time advisor to the recovery project. In addition, a number of other KPMG consultants were hired on a temporary basis to assist with the project. A number of individuals who were involved with the original project were seconded to the recovery project and were temporarily alleviated from their regular duties. • An additional $200 thousand were allocated by NU's management to the recovery project. • The project team met every morning to discuss daily progress, identify key issues and review the day's work schedule. • Weekly project progress reports were presented to senior management to ensure close monitoring of the project. This recovery project was concluded about ten months after the IMIS conversion when the 121 Chapter 4 first quarter financial statements were finally produced. Because certain IMIS applications were still not functional at the completion of the recovery effort, a third upgrade project was initiated. The goal of this project was to upgrade the IMIS software to a newer version that was released by Oracle and to address the remaining integration and functionality issues. The upgrade project was outsourced to Price Waterhouse and cost an additional $750 thousand. One of the directors indicated that this approach reflected many of the lessons that were learned from the original IMIS project: The consultants were solely responsible for delivering a quality assured functioning system. In addition, payments were made upon specific delivery milestones and there was a fixed upper cost limit on the services provided by Price Waterhouse. Whde this intensive project recovery and upgrade efforts were underway, NU undertook specific initiatives to mitigate the effects of the failed systems and address the operational liabilities caused by the delays. A summary of these key operational crisis management tactics is presented in Table 4-3. Table 4-3: Actions to Manage the Impact of the IMIS Failure Impact on Operations Remedial Action Inability to record and process the payroll and other HR-related activities Inability to record and manage accounts payable Inability to monitor inventory levels Inability to allocate costs to the appropriate activity cost centers Inability to produce financial statements A manual, exception-based system using paper timecards is initiated to temporarily manage payroll A temporary manual payment system in initiated; vendors are paid using hand-written checks A temporary materials inventory system was initiated Paper records are retained for processing when the systems become fully functional NU hires its auditors to recover the system and produce the statements 122 Chapter 4 The above remedial actions were necessary to address the impacts of the project's failure on the various operations of the organization. An executive summarized this impact as follows: The organization has no idea where it stands. The commissioners and the managers don't know where the utility stands financially, how much we're spending, how much we are not spending. Our financial data were processed in such a way that it is difficult, if not impossible, to trace the costs to each activity making auditing very difficult. Our accounts payable were not being paid. We had vendors outstanding for like four and five months when we usually pay net 30 days. We were cutting checks by the thousands by hand. The impact of that is horrendous and with no computer system keeping track of them at the time. It was a hand check being cut to get the vendors satisfied that they were getting paid for their product. Most of these remedial actions were planned and executed by the various individuals who were involved with the IMIS project. The general manager of the corporation commented on the ability of these staff members to respond to the crisis: There was clear direction of what we had to do. We needed to produce auditable financial statements and we had all the manual records to do it. I think it was virtually business as usual with the exception of our financial operations. People kept getting the system in piecemeal fashion. Our people came up with, what I thought were, quite creative contingency plans to get their tasks done. They said, 'Well, we'll do part of this way and part of that way.' So they were adaptive to what was available to get their job done. In summary, NU undertook several actions to shield its operations from the impact of the failed system. These actions included a project audit, replacement projects to complete the systems, and the use of paper-based, manual systems to support the existing operations. Interestingly, during the recovery effort, NU neglected to pay attention to its demoralized staff. Because of the critical need to manage the operational impacts of the crisis, little attention was paid to the needs and morale of the employees who were involved in the 123 Chapter 4 failed project. The director in charge of this effort commented on the lack of needed interaction between him and the rest of the organization: Probably one thing I haven't done well enough is to communicate with the rest of the organization. I probably left that one. I probably haven't done enough in that regard. An individual discussed the effect of this inattention to the project participants' morale: I need to feel like I'm treated with some sort of respect. That what I'm doing is value added. I don't feel like I'm adding any value anymore. I feel that I was used to get the system in, to get it running and they drew blood to get it. Now that it is almost done, you feel that you are consumable, they want to get rid of you, that you're not needed anymore. I think there's probably a lot of people that feel like that. Legitimacy Crisis Management A number of actions were also pursued to protect the reputation of the individuals and the organizations involved. These involved both mitigating accounts and strategic restructuring. Virtually all of the accounts that were presented to the researchers were "linkage" accounts as the impact of the failure was quite substantial (and thus was very difficult and perhaps inappropriate for project participants to reframe it as non-consequential using valence accounts). As the quotes in earlier parts of this section indicate, senior managers attempted to lessen their apparent responsibility by attributing the failure to Oracle's incompetence, the project manager's hidden agenda and the lack of warning signs. Non-management employees, on the other hand, attributed responsibility to management's inattention and lack of involvement (and not their own lack of experience and skill), in 124 Chapter 4 addition to Oracle's and project manager's incompetence. Such accounts were presented (and reinforced) throughout the project. The following comment of an executive exemplifies the use of linkage accounts: I told them that I felt that Oracle should have taken more responsibility for what they dropped the ball on. I felt they were totally negligent in any support that they didn't provide. They basically said that if you don't have more money we're not going to help you. We had no alternative but to go to another consultant and pay another quarter million dollars to try to get the thing going. While KPMG was conducting the audit of the project, the root causes of the failure were examined. This was not an easy task as various parties using different linkage accounts attributed the flawed decisions to different actors: And this is where part of the big break down came because of course Oracle now claims that was John's decision. He was fully responsible for it and of course our people are saying the Oracle manager was responsible for it, that it was her decision. NU managers presented responsibility-reducing linkage accounts to another key stakeholder: the elected commission. The following comment by a senior manager is representative of the accounts presented to the commission: Even though we share some responsibility, I made it very clear that it was Oracle's responsibility to bring this project to a successful completion. I told this to the commission on a number of occasions. I wanted them to know so that they didn't blame the internal staff for the failure, which they didn't. Finally, NU engaged in selective "strategic restructuring" to minimize the threat to the legitimacy of the organization and the management's image. It achieved this through the introduction of monitors and the implementation of disassociation tactics. 125 Chapter 4 To signal that the corrective actions that were being implemented during the recovery period, NU hired its accounting firm (an organization whose purpose it to affirm the legitimacy of other organizations) to conduct the project audit and assist in the recovery project. By hiring KPMG to conduct the audit, NU was signaling that an "objective" assessor was conducting the project review (while at the same time ensuring that the audit assessment was likely to be favorable due to its long-standing business relationship with KPMG). Also, by hiring KPMG as its project recovery consultants achieved two additional benefits. Firstly, it lessened the risk of exposure resulting from its inability to produce financial statements in a timely fashion. As one finance staff member indicated, "the pressure to produce the statements was somewhat reduced because our auditors were right there with us and they are aware of our situation so they've agreed to come in and do what they can with whatever we could prepare as we were moving along." Indeed, an executive confirmed that the financial statement issue heavily weighted in the selection of KPMG as the recovery project consultants: That is why we hired KPMG, they are our auditors [laughter]. There's the whole notion that there's a huge risk with having that open. Ironically, if you look at our real cost we probably had a better performance with no financial statements. I don't know if that tells you the value of financial statements [laughter]. Secondly, the hiring of KPMG to advise the recovery project indicated that an independent evaluator (the KPGM recovery project advisor, who was a seasoned KPMG project manager) was overseeing the crisis management efforts and bestowed KPMG's "seal of approval" to the recovery actions that were being implemented. This is important as it provides a second, independent opinion to the interested stakeholders (such as the commission) that substantial progress is being made and that the process follows 126 Chapter 4 legitimate practices. This validation could prove to be very important should the recovery project had failed, as it would have lessened the likelihood that NU would have been blamed for it (since, after all, it had followed validated, standard practices). Another attempt to "strategically restructure" by introducing "monitors" was pursued by hiring another KPMG consultant as an interim CIO for about four months while the recovery project was underway. While the goal of this change was to "initiate cultural change and create a strategic plan for the MIS department," it was important for symbolic reasons. This change signaled to the stakeholders that NU took the failure seriously and was undertaking steps (once again, under the supervision of "legitimated" MIS experts) to rectify factors that contributed to the project's failure. During this time, the MIS reporting structure was altered so that the interim CIO reported directly to the General Manager, indicating the increased importance of the MIS department. An executive commented on the symbolic value of KPMG's overall involvement with the recovery efforts: Let me put it to you this way, the hiring of two KPMG individuals to ensure that the rest of the IMIS is going to work and another KPGM consultant to review the IT department so they can support the system and rest of our MIS operations sends out a very strong message. It says that yes, the lesson has been learned and that it will not happen again with this executive team in this environment. Lastly, NU pursued a disassociation tactic to complement its legitimacy restoration strategy. In a public news release, NU announced the dissolution of its partnership with Oracle, whose incompetence appeared to be among the major causes for this failure. By 127 Chapter 4 distancing itself from Oracle, NU was indicating to the commission and other interested stakeholders that it was absolving itself from factors that could contribute to the worsening of the situation or cause future failures. A similar argument can be made about NU's disassociation tactics towards the IMIS project manager. Even though this manager proactively left the organization, NU managers and staff distanced themselves from him and his actions by expressing their strong disagreement with his decisions and behaviors. IMIS Post-crisis Stage As a result of this fadure, a number of changes took placed in NU. Firstly, a review of the MIS department, its operations, strategy and organizational structure was conducted. As a result of this review, the department was reorganized and the executive sponsor of the IMIS project became the first permanent CIO of the organization (indicating that his credibility was restored due to the successful management of the crisis). Also, the relationship between the department and the General Manager became direct (replacing the reporting relationship to the director of corporate services). This change reflects the renewed attention that the senior management paid to MIS in order to be more directly involved with the IT projects and operations and thus avoid simdar failures in the future. Secondly, the purchasing department was asked to develop a set of guidelines for evaluating and selecting products and setting up partnerships with vendors. According to the general manager, this was a key issue in the IMIS case and for project management in general: 128 Chapter 4 I think this project has changed the way I view how projects get done. The notion of how to select a business relationship is an important one. You have to look at the business relationship and not only at the product. You must decide what you want to achieve out of it. So, it isn't as simple as functionality and price. This is particularly important for software projects because you're going to be involved with it, with whoever is doing it. It's not like a truck that you can take someplace else to get it fixed if necessary. Interestingly, there is evidence to support that this "vendor-selection" related learning that ensued from the IMIS failure was applied in a subsequent project at NU. This is a prerequisite of successful organizational learning and supports the idea of effective crisis-based adaptation. The following comment illustrates this: If you look, we developed some software for our business planning processes after IMIS and it was done on a much different basis. It was a much smaller project of course, but it was done on a much different basis where we used some of the tools like quality function deployment and the analytical hierarchy process to take into account all of people's needs and what they wanted to do. We developed the specs of really what we wanted to do. We had it really nailed from the user point of view. And not only specs but also the functionality guides. We said that "we won't accept if it's this, this or this." You can't just say it must be "user friendly." You gotta kinda define what that means. Then we selected a company to do the work, a firm that is very customer focused. It was a much smaller company. They're interested in serving us. The person who was doing the development was kind of in very much contact with us and they recognized the importance of our deadlines and changes. So, I would say from an IT project perspective, that's probably the only IT project that we've undertaken after IMIS. This time we learned our lesson. There was far more time spent with users' specs boded down before we went out matching of who is going to deliver it. Thirdly, an organization-wide business planning methodology was instituted to prioritize project-related tasks. This change was the result of the project described in the previous quote and was identified as a partial consequence of the IMIS project by many participants. Unfortunately, some participants did not perceive this change as a successful one: 129 Chapter 4 It's funny cause we were in a meeting yesterday and it was said that no work is to be done now unless there's an action plan and that all of our work is supposed to be prioritized. But in the same breath, this new consultant who runs the business planning doesn't know the word planning. Everything is last minute. I don't think we're getting better. We've got a better business-planning tool. We really don't have a fundamental project management methodology. How things should be done through the corporation. If we're going to do something and it's a project here's the way we want it structured and here's the methodology we use. I don't see that anywhere. Interestingly, the above organizational adaptations took place without a formal audit of the root causes of the project failure. An executive explained the lack of such assessment: I don't think we'll spend a lot of time auditing the whole project history. I think there's a lot of the lessons that we've learned with it. Again I think to spend a whole lot of time rehashing the history is kind of pointless. I'd rather say, 'Well here's the system that we got.1 All the monies we spent for it are sunk costs so it really isn't important how much we spent to get here, we're here. And nobody is going to give us money back if we say we don't want this anymore. We can't take it back to Sears and say 'can we have a refund on it?' In addition to organizational learning, there was significant individual learning that took place as a result of the IMIS crisis. Indeed, individual reflection and learning was clearly reflected in the interviews that took place for this study. A number of participants came to the interviews with well-prepared mental lists of the failure causes (one involved participant even studied this issue in-depth and prepared a conference paper on it) and explained how these could be avoided in the future. The following comments reflect the perceived amount of individual learning that took place: When you look at the exposure of our whole team to a project like that I would think it was relatively naive. As we were going through it and somebody kept telling us "Oh yeah, this is all just normal stuff and it will all work well at the end," we eventually started to believe them. Now I think that we're all more skeptical and saying that "well it didn't work at the end so don't give me that." I think that the people working on IMIS got a better appreciation of software 130 Chapter 4 technology and better understand the risks associated with IT projects. I think it served as a wake-up call for many people. I think that individuals such as myself are much more knowledgeable now but I don't think the organization is much more knowledgeable. I don't know how you teach that to the organization. I certainly think that the individuals deeply involved have a good understanding but other than that I don't think the organization has learned anything. Perhaps we don't know how to make the organization learn. That's one of our failings.14 In summary, it appears that the organization altered its operations and procedures in response to the crisis. Furthermore, no evidence of organizational rigidity was identified by the participants in any of the interviews. These actions of organizational adaptation and the lack of rigidity effects are consistent with hypothesis eleven. Summary of NU Case Findings It appears that the failure of the IMIS project follows the patterns of a classic, textbook case of an organizational crisis. As the summary of the key events and factors in Table 4-4 indicate, NU was unable to avoid the crisis due to the high levels of pre-crisis denial that existed in the organization. This denial, coupled with escalating commitment, made it very difficult for project team members to receive validation when expressing concerns with the project's course. It also led to a lack of preparation. Because of this inaction, the unsuccessful conversion resulted in the impairment of many fundamental operations. To mitigate the impact of the failure on the organization's operations, NU managers engaged in 1 4 This comment was made dur ing the f i rs t round of interv iews before the post-crisis stage of the I M I S project (dur ing wh ich the previously described organizat ional changes took place). 131 Chapter 4 intensive crisis management efforts. These included a number of contingency plans for carrying out the affected processes and legitimacy protection tactics to protect and restore the reputation of the management team who were seen as partly responsible for the failure. Lastly, the organization adapted a number of its procedures to reflect the learning that took place during the I M I S crisis. To summarize the empirical assessment of the theoretical model, I display the research hypotheses and indicate whether or not they were supported by the case data in Table 4-5. Table 4-4: Case Dynamics Matrix of the IMIS Project Stage Antecedents Events Outcomes Pre-crisis Signif icant importance of the project to the organizat ion and management's reputa t ion creates an escalating commitment Warn ing signs are ignored by the involved decision makers and the conversion to the new, ineffective systems takes place N U is unprepared to manage the fai led conversion C r i s i s The fa i lure of the systems and the lack of preparat ion impacts many f inancia l operations of the organizat ion and threatens the credibi l i ty of managers N U allocates extensive resources to recover the project, inst i tu tes manua l systems to support affected operations; to manage the legit imacy threats, N U hires K P G M consultants and distances i tsel f f rom Oracle The impact on the operations is contained w i t h i n the organization; the commission is reassured tha t recovery is tak ing place Post-crisis The large magni tude of fa i lure necessitates the need for visible changes to reflect needed learn ing and adaptat ion N U restructures the IS department, establishes a new CIO posit ion, establishes vendor selection guidelines and introduces a formal project p lann ing methodology Learn ing is appl ied i n a new I T project and the manager's credibi l i ty of the managers is (part ly) restored 132 Chapter 4 Table 4-5: Summary of Hypothesis Assessment in the NU Case Number Hypothesis Support 1 Project importance w i l l lead to greater ISD crisis impact Positive; I M I S was an impor tan t project and its fai lure impact was substant ia l 2 Fai lure control labi l i ty w i l l lead to greater ISD crisis impact Positive; both contro l labi l i ty and impact are h igh 3 Pre-crisis preparat ion w i l l lead to lower ISD crisis impact Positive; the lack of preparat ion contr ibuted to the large magnitude of the fai lure's impact 4 Managers' commitment to the project w i l l lead to lower pre-crisis preparat ion Positive; the denial of negative in format ion, caused by escalating commitment, resul ted i n the cont inuat ion of the fa i l ing project and the lack of preparat ion 5 Project importance w i l l lead to greater commi tment to the project Positive; the importance of the project to both the organizat ion and the managers' reputa t ion contr ibuted to the escalation of the i r commitment to i t 6 Whist le-b lowing w i l l lead to greater pre-crisis preparat ion None; the whist le-b lowing at tempts were unsuccessful i n ending the pre-crisis denia l and i n i t i a t i ng crisis preparat ion efforts 7 Project importance w i l l lead to greater whist le-b lowing Positive; The project's h igh importance mot ivated indiv iduals to engage i n whist le-b lowing 8 Managers' commitment w i l l lead to lower whist le-b lowing Positive; even though the escalating commitment behavior of managers d id not prevent whist le-blowing f rom tak ing place, i t had a suppressing effect on subsequent whist le-blowing 9 ISD crisis impact w i l l lead to greater crisis management Positive; Substant ia l resources, t ime and at tent ion were allocated when crisis impact was high; these were subsequently reduced when the impact decreased 10 H i g h ISD crisis impact w i l l lead to both operat ional and legit imacy crisis management Positive; several contingency plans were in i t ia ted to support affected operations and two recovery projects were pursued to f ix the systems; at the same, t ime NU managed the legit imacy crisis by offering l inkage accounts and pursu ing moni tor ing and disassociation tactics 11 ISD crisis impact w i l l lead to greater post-crisis organizational learning Positive; signif icant organizat ional adaptat ion took place as a resul t of the serious impact of the fai lure 12 Fai lure control labi l i ty w i l l positively moderate the relationship between the ISD crisis impact and post-crisis organizational learning Not assessed; Because of the moderat ing effect i n th is relat ionship, i t cannot be assessed i n w i t h i n case analysis; i t requires more t h a n one data point and w i l l be examined i n the between-case analysis 133 Chapter 4 4.1.2 Green Valley Hospital Case Findings Even though IPACS was a large, strategic IS project, the crisis caused by its cancellation was contained and did not adversely impact the operations of the hospital. The key factors and events that led to its cancellation, along with a discussion of GVH's response to it, are discussed in this section. A graphical representation of these key events and factors is shown in figure 4-2. IPACS Crisis Impact The goal of IPACS was to computerize many of the operations of the hospital in order to improve communication, better track and manage costs, and facilitate the administration of quality treatments to patients. Most of the processes that were to be automated by this project existed before its introduction in a manual form. Thus, when the project was abandoned by the hospital (before the existing processes were converted to the new systems), there was little impact on the existing operations of the hospital other than the resulting delay in their computerization. Even though the cancellation of IPACS delayed the implementation of the hospital's reengineering strategic efforts, its overall effects on the organization were not consequential and did not attract external attention. During this crisis, the clinical staff continued to administer and record the treatments manually; the communications between the labs and the various medical departments continued to be paper-based; the finance and accounting departments continued to use their legacy 134 Chapter 4 software applications. In general, there was no disruption to the operations of the hospital. A manager commented on the impact of IPACS' cancellation: The most important consequence of this failure is that availability of clinical information to help people do their work with patients isn't really there. This is true for almost every clinical area in the hospital except for the lab and even in the lab it's not there for outpatients, it's only there for inpatients. So I guess what the hospital suffered from this whole thing was the delayed achievement of its goals. This is especially true for the patients, the physicians, the nurses and the other care providers who should have had better access to information and easier systems to use, but currently don't. Even though the IPACS project failure did not affect the operations of the hospital, it created a threat against senior management's credibility due to its high opportunity cost. Because the IPACS project was initiated to implement a five-year strategic IS plan, its failure exposed GVH to a number of governmental organizations, including the provincial ministry of health, which were responsible for monitoring the progress of the SIS plan. An involved manager commented on the legitimacy impact of the failure: The CEO had gone to the government and the board with a five-year strategic plan and committed to implement it. It would be a major embarrassment for the CEO to go back to the government and say we need more money. There had been an original budget of some 5.2 million dollars for hardware and software. After the IPACS cancellation, our main objective was to see if we could stay within those targets yet complete our functional and plan requirements with another project. In summary, the cancellation of the IPACS project had a moderate impact on GVH as it did not negatively affect its existing operations but had some legitimacy threatening effects. The remainder of this section examines the factors and events that contributed to the apparent containment of the crisis impact. 136 Chapter, 4 IPACS Project Importance The IPACS project was important to GVH for three reasons. Firstly, it was part of a strategic initiative aiming to drastically improve the future operations of the hospital by reengineering its processes. Even though this system was not critical to current operations, the management felt that its development was essential to the future success of the organization. Given the increasing external pressure to reduce costs and improve patient care, the hospital felt that the implementation of sophisticated information systems was one of the few ways that it would allow it to compete in the new regulatory and competitive environment. IPACS was perceived as a critical aspect of a long-term strategy that would enable GVH to survive the hospital closings and cost-cutting measures of the newly implemented regionalization plan. An IS manager commented on this perception: There was a strong feeling among user management that the systems were in fact a key component of the hospital's business strategy. They thought that many problems would have been solved if we'd had a good hospital IS. Factually probably less than half of those were really IS problems. Many of them were operational problems you'd get even if IS did exist. Interestingly, the strong focus on the cost saving features of the new system contributed to an adversarial attitude towards its introduction: I think that the clinical side of the organization didn't really understand what it was going to do for them. I think people in healthcare have always had a little bit of trouble figuring out how systems are going to make their life better. They have ideas around patient data management and external communication that the IS people and the vendors look at you blankly and say "well it doesn't do this and, well, no it doesn't do that." In our case, the conceptualization around these systems started as a means to collect financial and administrative data so they were not specifically designed to support the clinical decision-makers. In the end clinical decision-makers started to get really suspicious that were just being used to collect information that was going to get used against them by administration. 137 Chapter 4 Secondly, IPACS was a large project to which a significant amount of resources was allocated. The project cost was about $6 million representing almost four percent of GVH's total annual revenue. IPACS was the largest project ever undertaken by GVH and was the most important component of its five-year strategic IS plan. Its implementation required the restructuring of the MIS department and the hiring of two project managers (one responsible for the administrative applications and the other for the clinical systems). IPACS was to be used by virtually all departments at GVH and thus required the cooperation and involvement of a large number of end-users from many departments. The large size of the project (in terms of cost, time, and staff) made IPACS a consequential project with high priority for GVH. In fact, all other IS related development and maintenance work was placed on hold while the IPACS project was being developed: IPACS was a very large project for us and required all the staff and time we could dedicated to it. Everything else went on hold. After the consultants came in, all efforts and energies were directed towards achieving the strategic plan. So, all the ad hoc development work stopped and any new requests were ignored. I mean, if you had a real problem, they would give you a hand but for the most part there was no movement other than IPACS. Because of the lack of up-keep during these years, when the project was cancelled our old systems were in a bad shape. Many other hospitals that were using the same software continued to upgrade to newer, better versions but we hadn't because we were expecting this big hospital-wide system to solve our problems. Thirdly, the symbolic value of IPACS contributed to its perceived importance. Due to the adverse economic conditions, the provincial government (as well as most public and private organizations) was under a lot of pressure to reduce costs. Given the potential cost-reducing effects of IPACS, the provincial ministry of health (MOH) provided strong support and publicity to the project. As one participant commented, "the senior managers took their case to the provincial government, to the ministry of health and of course to the 138 Chapter 4 hospital board so they got a lot of highly visible support and approval for what was in fact the very first full scale hospital IS implementation in the province." In summary, it appears that the IPACS project was significant for both the organization and the provincial government. Despite its high importance, the impact of its failure did not create a consequential crisis for GVH. This finding contradicts hypothesis one, which proposes that a positive relationship between project importance and crisis impact exists. An explanation for this finding will be presented when the events that took place prior to the crisis are described. Controllability of IPACS' failure Clearly, the majority of the responsibility of the failure lies with the system's vendor, IBAX. Indeed, IBAX's management team, after reviewing the project's condition about two years after its initiation, concluded that it was not capable of completing the project in a profitable fashion. Thus, it decided to cooperate with GVH in canceling the agreement and abandoning the project. As an implicit acknowledgment of its responsibility, it agreed to refund all money paid during the project by GVH for the software and its services. Most of the participants' responses were consistent with attributions of responsibility to IBAX. However, a number of them commented on GVH's senior management responsibility for it. In general, these participants indicated that they partially blamed the senior management of the hospital for the fate of the project: 139 Chapter 4 I think about forty percent of the responsibility belongs to IBAX. Thirty percent to senior management and the other thirty percent to the Datacom consultants who advised the hospital during the project. IBAX over committed as most vendors will, but they seriously over-committed. However, I blame our president who ignored the users and managers' concerns and proceeded to work with IBAX based on the consultant's advice. That was a big mistake. Had he not done that, we wouldn't be here talking about the project right now. Of course, the consultant who was advising him deserves part of the blame because I believe he did not properly carry put his evaluations in an objective manner. Another respondent was even more critical of senior management's responsibility for the crisis: I suppose the primary responsibdity has to lie with the senior administration that made the decision. Certainly you can read lots in the literature that says "don't believe in vaporware." We've all made the mistake of believing it cause we wanted to believe it. I think that was the case here. Our administration wanted to believe in it. Even though it had information from the user community and to some extent from IS that we were skeptical and didn't think the system would work for us, it did not do anything about it. If the administration had listened to the community, this would have been prevented. Somebody should have stopped and said "you are right, this is not going to work so let's cut our losses and stop it now." In summary, most of the participants believed that main fadure cause was IBAX's inability to deliver the promised systems. Because this was an external cause, outside the control of the hospital, the apparent controllability of the failure was relatively low. However, there was a perception that senior managers should have been able to foresee the problems with IBAX's solution and should have taken appropriate actions to cancel the project during its very early stages. This apparent ability of senior administrators to stop the project creates some internal controllability. Its moderate levels are consistent with the modest levels of the IPACS crisis impact, as suggested by hypothesis two. 140 IPACS Pre-crisis Stage Chapter 4 During the vendor selection and the initial development stages of the IPACS project, GVH neglected a number of signs signaling significant problems. According to the participants, during the requirement identification process, a number of events took place that should have alerted senior management. For example, the users expressed strong concerns about the lack of critically needed functionality in the proposed applications. In fact, when asked to review the proposed IBAX applications, none of the involved department managers expressed satisfaction. A review of their memos, which were issued just a few weeks before GVH selected IBAX as its vendor, indicates that the proposal suffered from many significant deficiencies: • During the proposal evaluation process, the manager of the radiology department contacted users at another hospital, which was currently installing IBAX systems. Based on his informal review, he found that their systems did not perform in a satisfactory fashion because of a number of problems, including: frequent system unavailability, which sometimes lasted for 5-6 days; user dissatisfaction due to lack of key functionality; and non-delivery of promised features by Baxter. Due to the problems with the IBAX applications, the users had to write their own custom applications and were currently looking for a replacement system. After describing the above facts, he refused to endorse IBAX's proposal in his memo. • The memo by the manager of health data resources expressed many concerns about the 141 Chapter 4 vaporware nature of the proposal and concluded that "no product has been demonstrated and I am not comfortable blindly accepting that Baxter will deliver the required product as requested." A similar issue was identified by the director of nursing who stated in her memo that "the adequacy with which their efforts will meet our needs must be believed in blind faith, as there is nothing to see and no guarantee that what we require will, in fact, be possible... I have grave concerns that the basic product falls short of our requirements." • A number of managers felt that the proposed systems would not be able to match the functionality of the current systems. In her memo, the vice president of support services indicated that "the functionality of the system proposed by Baxter/IBM, complete with the latest commitments, represents a less complete solution to this department's needs compared by the alternate vendor." A similar concern was expressed by the manager of material management department who indicated that the proposal "represents a system that has less functionality than currently available." In addition to the end users' concerns, the management of the hospital ignored warnings by the MIS department about several key technical issues. In fact, the manager of the MIS department resigned shortly after the selection of IBAX because senior management ignored all his concerns regarding the technical feasibility of the project. Despite the above signals, senior management continued its denial during the early stages of the IPACS project. According to participants, during the first year of the project a series 142 Chapter 4 of events took place that should have served as additional warning signs. Firstly, a number of departments (such as radiology, laboratory, pharmacy, ICU, etc.) asked to be excluded from the contract because they felt the relevant modules could not adequately meet their needs. Because of their strong opposition to the system, the administration agreed to let them select third party packages that could better serve their needs. Secondly, the users rejected virtually all applications when asked to test them. Among the first ones to be tested by the users was the material management (MM) module. A user explained the users' reaction to its introduction: The staff identified a lot of problems in the system... The finance people were not willing to accept the system. They didn't like the way moving average price was calculated, they didn't like the way entries were posted to the general ledger, they didn't like a lot of things. [This] created a lot of resistance among users who felt that the customizations were not satisfactory. The rejection of the systems continued as more systems were made available for testing. Following the rejection of the MM module, the users rejected the accounts receivable (AR) and capital assets tracking (CAT) applications. This was followed by rejections of the first clinical systems to be developed: the operating room (OR) and admission, discharge, and transfer (ADT) modules. After this initial stage of denial, GVH began preparing itself to deal with the impeding failure of the project. As the following two sections will indicate, this preparation effort was initiated and greatly facilitated by the newly hired MIS director who joined GVH just a few months after the initiation of the project. Initially, the concerns of the users and MIS staff had not worried the new manager who remained optimistic about the project who 143 Chapter 4 described his first reaction to their concerns as follows: The systems were delivered slightly behind the schedule. When they arrived they were immediately tested exhaustively by our staff and by our users. That was the first sign of trouble. The users came to me in revolt and said that the systems that they'd been delivered were awkward, cumbersome, not very Canadianized and not as functional as the systems they had already. The systems that the hospital was using at that time were considered to be outdated systems from a local company. However the users demonstrated to me that the new Baxter product was more labor intensive to use. Although it contained a lot more information it was missing some of the essential information that they needed. At the same time there were some technical hitches with it. My technical staff came to me with deep concerns about the quality of the code of the product. Because it was RPG3, which was not perhaps the most up to date language, any modifications that were made to this product... made it run in a very machine intensive fashion. Luckdy we had a good-sized machine and even though it ate up a lot of machine cycles we were not too concerned. The staff was, however, concerned with the fact that the modifications left a lot of redundant code in the system because the product was so old that the people who were updating did not want to disturb any of the base product. They would simply go around it rather than eliminate it. So we had in fact huge software files, much of which was redundant code. It was left in there cause to take it away might bring the whole thing down. So this was some of the technical reasons. None of which individually was cause for major concern. They were manageable situations. As the user departments, however, continued to sequentially reject the new applications during testing, the new MIS director became more concerned. In consultation with the senior managers, he undertook several steps to avoid the manifestation of a major crisis. Specifically, he pursued the following steps in order to protect the hospital's operations from a potential failure of the IPACS project: • In response to the systems rejection by users, all development work was placed on hold. The new director asked that no conversion, from the old to the new systems, was to take place until after the major issues identified by the users and MIS staff were satisfactorily addressed by the vendor. An IS staff commented on this state of the 144 Chapter 4 project: We had gotten to the point where we did all of the conversion preparation. We got ready to move all of the data over but we were still waiting for the [updates]. We knew we couldn't proceed without a specific list of features being met and that was the code that we were waiting for. IBAX was supposed to be rewriting the front end but they hadn't come back to us to get the specifications. We had a long list of detailed specs for a lot of the functionality changes but we were never asked for them. This was where the red flags where raised so we never converted to the new systems. Basically, we said "we were not going to do this until we get the actual working code." • The MIS director contacted the vendor and conveyed the concerns of the users and MIS staff. He engaged in lengthy negotiations with IBAX attempting to find specific solutions to the functionality and technical issues. In fact, the vendor was asked to prepare a formal presentation summarizing how it was planning to address the identified shortcomings. An involved IS staff member commented on this effort: We realized the deadlines weren't being met we said okay, we think there is a problem here and we need to sit down and negotiate with IBAX. That's what the new MIS manager did. He sat down and negotiated with the IBAX team along with the people at the VP level. He told them that 'These are the milestones we expected to have been met by now and we want to know what you plan to do about it. We recognize that you have fallen off your path because of the amount of work that was required so we want to set a new plan. We want you to recognize that these are our minimum needs in order to move forward and want to know when you feel realistically these things can be met." We deliberately did not implement the new systems because we felt that if we implemented them and had to go back then we would be in a worse position. • After the users reviewed and rejected IBAX's recovery proposal, the MIS director engaged in intense negotiations with it to terminate the original partnership agreement and recover the financial resources that GVH spent during the project. This was indeed achieved about three years after IPACS' initiation. 145 Chapter 4 • Finally, the MIS director successfully engaged in negotiations with IBM, the hardware vendor, to allow GVH to change the hardware order to fit the needs of a future project that was planned to replace IPACS. IBM agreed to accommodate this request. As the above accounts and events indicate, following an initial period of denial, GVH engaged in a serious pre-crisis preparation effort. This preparation enabled GVH to protect its operations from the failure of IPACS (as none of them were converted to the new systems) and to recover millions of dollars from the vendor thereby minimizing the financial loss to GVH. This positive effect of pre-crisis preparation on the impact of the crisis is consistent with hypothesis three. The key factors that influenced the initiation of this preparation effort are examined next. Escalation of Commitment in the IPACS project According to participants' accounts, senior managers of the hospital ignored the warning signs of the failing project before the arrival of the new MIS director. Despite the above "red flags," the management's support continued to escalate for a prolonged period of time. An executive described this process: I believe the project problems came to light progressively over a long period of time. As you can imagine, at various points, we went to the supplier with an issue and asked them what they were going to do about it and they gave us assurances that they're going to fix it or replace it. We believed them. Usually they partially completed what they'd committed to do but not sufficiently to solve the problem. The notion that this project was not going to work was the result of an escalation process rather than a sudden vision. The process took over a two-year period. It 146 Chapter 4 was ultimately escalation to the point where we all realized that the supplier could not deliver but they did not say that until they'd had brand new management to come in to look at their ability to do that. Previous levels of management at the supplier organization had committed to doing their best to fix it if we didn't mind waiting a little longer. So, we gradually forced the escalation to a point where it was not acceptable anymore. The view that senior management was motivated by escalating commitment was shared by many participants. A brief summary of their comments is shown in Table 4-6. Consistent with hypothesis five, the evidence indicates that the importance of the project combined with the high levels of support by senior administrators contributed to this high level of escalation. The following comment by a senior manager addresses this issue: Many managers were not willing to accept the major problems transpiring in the project. You see, once you've committed a heck of a lot of money to a project, you tend to want to save it rather than pull the plug when in fact it is sometimes better to pull the plug. I think that's what happened here. We were thinking that if we put in that little extra effort, a little bit more money, we'd make it work. So, we thought that many of the problems would go away if we just ignore them. We were wrong. But because this was such a high level project, the pressure to go on with it was high. Yes, it was the president's solution as everyone seems to think but it was a solution that most of us thought would help the hospital strategically by computerizing its operations. We badly needed that. As the above comment indicates, another factor that contributed to the escalation to this project, was the president's support to it. This high level of support was attributed to his familiarity with the Datacom consultants and vendor from his previous employment. A manager commented on the effect of this relationship: Our president came from St. Mary's where he had a relationship already with IBAX, which he brought here. He forced upon this hospital the decision to select IBAX. Therefore this hospital didn't really have a true selection process to decide the system. He said this is what you're going to get. Now it's a little subtler than that but that's how it happened. And meanwhile the system went down at St 147 Chapter 4 Mary's because it wasn't working well, but this guy didn't necessardy know that. Table 4-6: Role Ordered Matrix: Pre-crisis Warning Signs P o s i t i o n S a l i e n t c h a r a c t e r i s t i c s C o m m e n t s Senior managers Manager involved i n the project M a n y t imes the users voiced concerns about what the systems could and couldn't do. Most of us thought tha t they were jus t causing noise because they didn't l ike the systems. We fel t tha t once the systems were instal led, they would be used. So, we kept going on w i thou t paying at tent ion to, wha t we assumed were, ins igni f icant issues. I t wasn't u n t i l the M I S director came to us and said ' this is not work ing ' t ha t we began to pay more at tent ion. Manager involved i n the project W h a t happened here is very simple. I f you wan t something badly enough you fool yourself. Denia l is a wonder fu l mechanism and I t h i n k that 's wha t we d id dur ing th is project u n t i l i t was cancelled three years after i ts in i t ia t ion . Senior manager not involved i n the project M a n y of us recognized tha t there were major issues w i t h th is project very early i n the project. B u t our president kept pushing saying tha t we must t r y harder and i t w i l l benefit the whole hospital . So that 's wha t we did, but i t tu rned out tha t s imply prolonged the inevi table. Non-management employees End-user I know tha t many users felt very strongly tha t th is system was not going to meet the i r needs. We told tha t to both the I B A X consultants and our managers. Some departments fel t so strongly about th is that they insisted tha t they be allowed to buy other systems. They ignored the rest of us. When we were asked to test the system, we said again "this is not good enough." The response was "make i t work." Eventual ly , when other departments reacted the same way and I B A X said they couldn't do wha t we wanted, they decided to p u l l the p lug. IS staff Our M I S director knew tha t th is was not going to work f rom the very beginning. When the managers ignored his pleas, he decided to qui t ra ther than go along w i t h i t . We kept te l l ing them tha t the problems could not be resolved unless I B A X did a lot of addi t ional customization work. The RGP code was so old and complicated, we didn' t want to touch i t . The administ rators believed I B A X who kept promis ing bu t not del ivering. Because th is was such an impor tan t and strategic project, they wanted to make i t work no mat te r what . Due to the president's apparent support, the project enjoyed the commitment of many senior managers who wanted to appear supportive of the strategic initiatives. As a user commented: Most of the support for this project came from the president. I don't think the VPs had any alternative except to support whatever decisions had been made. I mean that is where you make your commitments as far as a total organization is concerned. It seems that the president asked them to lend their visible support to the project to make it successful. I guess they were thinking they were doing a good 148 Chapter 4 thing by ignoring our concerns. As it turned out, we were right and they were wrong. Consistent with the above accounts, the evidence shows that many warning signs during the vendor selection process and the early stages of the project were ignored because of the senior management's lack of acknowledgement and high commitment to the project. In fact, it appears that some senior managers were so committed that they put pressure on end-users to support it without fully considering their concerns. The following comment by an involved department manager describes the pressure exerted by one such over -committed senior manager: Because at the time I was in charge of a department, I was asked to review the proposed systems. In my memo, I said that the systems could not meet our needs. It was very clear to my staff and myself that they weren't going to work for us. After the administrators received my memo, they came back and told me that our response was not appropriate. In the end, I was forced to write a new memo which said that "overall the Baxter system as it described in the original response plus in the addendum is acceptable to my department." This new memo was written on December 18, just a few days before the hospital formally announced that IBAX was selected as the vendor. Basically, it was like "we are going with IBAX and you have to sign off whether you like it or not." We had to show support. We expressed our concerns but the response we got was "This is what we're doing, too bad." Interestingly, the arrival of the new MIS director had a significant, negative effect on the initial escalation of commitment. Indeed, the literature indicates that the introduction of an uncommitted decision-maker in an escalating failure situation will often lead to its termination (Staw and Ross, 1987; 1993; Brockner, 1992). Because the past performance on the project is not seen as a reflection of his own competency, he is more likely to objectively assess the situation and abandon the project (Brockner et al. 1992). Many users commented on the de-escalation impact of the arrival of the new director: 149 Chapter 4 I believe that the fact that Andrew came in later and didn't have any history with the project contributed to the managers' realization that there was a major problem with the project. Because he was unburdened by the politics of the project, he was able to go up to the administrators and to let them know that this was not going to work. Even though a number of us had raised the same issues he raised, they were wdling to listen to him but not us. I guess he had more credibdity than we did because we were seen as non-supportive from the very beginning. In summary, it appears that the initial escalating commitment of the senior management contributed to the denial of warning signs. The de-escalation effect of the new director's arrival led to the recognition of the impending fadure, the implementation of a number of preparatory tactics to minimize its impact, and the eventual abandonment of the project before its conversion. This pattern strongly supports the negative relationship between escalation of commitment and pre-crisis preparation that is proposed by hypothesis four. Interestingly, another de-escalation event took place soon after the arrival of the new director. Both the senior managers of the IBAX and its American parent corporation, Baxter Systems (which was the result of a joint venture between IBM and Baxter), were replaced during a series of management shakeouts. After examining the situation with the IPACS project, the new IBAX management team readdy admitted that they were not able to satisfy the requirements of the contract in a profitable fashion and willingly cooperated with its cancellation. According to the MIS director, this behavior was a drastic change from the attitude of the previous, over-committed IBAX management team, which consistently assured GVH (without fully examining the concerns) that the project would be completed successfully: We went to the new CEO of Baxter, who was a good turn around artist, and explained that we had been given these contractual agreements and assurances by 150 Chapter 4 IBAX's previous senior management. He did not commit the typical mistake of assuring that they would meet all of our requirements. He said he'd get back to us once his people had taken a look at it... They came back to us and said "in all honesty, we cannot do this. It's not businesslike and it may not even be technically feasible and there is strong concern on our part about creating such a unique environment for GVH because it would result in extremely high long-term costs." Whistle-blowing in the IPACS project Consistent with hypothesis seven, the evidence indicates that the seriousness of the potential failure of IPACS worried a number of individuals and motivated them to engage in whistle-blowing. As one put it, "I was very concerned about the hospital being stuck with a six million dollar system that couldn't work or do what we needed. I've been working here for many years and I was tired of seeing the hospital struggling all the time. We finally had the opportunity to do something good for our staff and our patients and I didn't want to waste the opportunity by ignoring the fact that IBAX was really a poor system and a bad choice of us. So I kept going up telling people that we must do something to stop this insanity." Due to the strong support that the project received from senior management, and especially the president of the hospital, such efforts were fruitless. An involved IS staff member described her attempt to inform a vice-president about the project's troubles: There was a lot of concern raised. There were a lot of people who felt that we made a bad decision and that the development was not going well. And there were a lot of people who were scared to open their mouths and say that. Even some managers were scared. At one point, I raised a concern cause I'm known to have a bit of a mouth and was told basically "this is the direction we're going and if you won't put it in, we'll find somebody who will." First, I tried to go up the chain of command, but there was no positive response. So, I went to a vice-president. But, I never 151 Chapter 4 really got a chance to voice my concerns cause that was not what anybody wanted to hear. At another point, three of us went to see a vice-president. Unfortunately, that was not successful either. Another participant described her efforts to by-pass her supervisor and inform senior managers about her serious concerns: On several occasions, I tried to make my concerns known to our administrators and the IBAX president. I can remember literally shouting at their president in fact as they promised the moon and they didn't have it. I kept saying "your system won't work for us" and I got overruled a lot. They told me "we'll make it work, we'll fix it, we'll do it." I was told that it wasn't up to me to make the decision and didn't need to worry about it. But I work here, I care about how we spend the money. So finally, I sort of said "I give up." I mean I'd even written some letters to senior executives and they mysteriously vanished. My secretary told me that my backup diskette blew up. I mean, it just was the weirdest thing I ever encountered. The participants indicated that their whistle-blowing attempts were not fruitful, as they were unsuccessful in altering the direction of the project. This contradicts hypothesis six, which proposed that such attempts wdl have a negative effect on the pre-crisis denial. At least two reasons contributed to the ineffectiveness of these attempts. First, it appears that the over-committed senior managers attempted to silence these attempts so that the project wdl continue unaffected. This discouraged the staff from further pursuing their concerns. The following comment by a senior manager describes the result of such attempts: There was a certain bullying. Basically, many people were told, not in so many words, that "you make that decision or I'll make your life..." People gave up. There're some things that aren't that important in your life. Why would you continue to fight it after such a response? You have to understand the psychology of the budding. By the way, I want this tape screwed up after you're through. Secondly, it appears that the president did not perceive the internal staff as credible 152 Chapter 4 sources of information about the status and progress of the project. The participants indicated that he consistently discounted the concerns and opinions of the internal staff members while assigning more weight and credibility to the judgements of the Datacom consultants and the promises of the IBAX staff. The bias of the president to external sources is illustrated in the following comment: The senior administrators, and especially the president, trusted the consultant more than he trusted the in-house people. He always went back to the consultant whenever we raised a concern or wanted to do something different. It was always "Well, we'll bring the Datacom consultant in to tell us what to do." It was always the same story: us saying there is problem and the consultant and president refusing to acknowledge it. Not surprisingly, the above negative response to the internal whistle-blowing efforts had an effect on the attitudes and subsequent behaviors of the whistle-blowers. One of the whistle-blowers commented on this issue: After I raised my voice a couple of times and insisted that I be heard, they treated me like an outsider. They would say "Go away, Jones. Stop talking to us. Get out of here." That was their typical response. So I just left. I simply stopped expressing my views, any views, about the project. The following comments also illustrates the discouraging effects of the lack of acknowledgement of the project problems: Our department was having a lot of trouble with the software. I raised concerns many times. I was a very loud whistle blower. And I was outvoted each time. I know there was a lot high-level stuff flowing on the top and there were lots of other issues going on so I realized it was beyond my control. So I just basically shrugged my shoulders and said "Okay. If you can make it work, wonderful. I don't believe it can work, but I give up." Even though whistle-blowing took place despite the initial high levels of commitment escalation, the above accounts indicate that the management's commitment to the project 153 Chapter 4 and their resistance to validate the identified problems had a negative impact on the whistle-blowers' willingness to continue voicing their concerns. Furthermore, it appears that these behaviors discouraged other potential whistle-blowers from expressing their views: The fact that president made the decision to support it made a big difference in this project. This made it very difficult to be open about the problems. I think there weren't enough people at my level who were aggressive enough to make noise earlier about the problems we saw. The above accounts from actual and potential whistle-blowers indicate that the managers' attitudes and behaviors (which mostly motivated by their commitment to the project) had a suppressing effect on the willingness of individuals to vocalize their views. This supports hypothesis eight. Interestingly, even though there was strong perception about repercussions against whistle-blowers, the actual behavior of senior administrators indicates that such perceived threats did not materialize. In fact, the president promoted one of the most vocal whistle-blowers during the project. As the individual pointed out, this promotion led to (perhaps unintentional) silencing: While I was going around saying that I was really dissatisfied with the project, my vice-president was let go. And a day later I got a phone call from the president asking me if I'd like to be the acting VP of my department. So you see where whistle-blowing gets you. And so I said "okay." But even in that position I wasn't able to change the'decision. I no longer had the time to be very involved in what they were doing with the project. I just couldn't anymore because as a VP you have a whole lot of responsibilities and so staying involved with the project wasn't always possible. 154 IPACS Crisis Stage Chapter 4 As section indicates, the pre-crisis preparation efforts at GVH and the pre-conversion abandonment of the IPACS project avoided the materialization of a major crisis. A major negative consequence of the project's cancellation, however, was the inability of GVH to successfully complete the original strategic IS plan. To deal with this situation, GVH a launched number of initiatives. These initiatives, their intensity and their impact are summarized next. Operational Crisis Management As GVH's existing operations remained virtually unaffected by the cancellation of IPACS, there was no necessity to employ preservation tactics to protect the current processes from the abandonment of IPACS. Instead, all GVH's operational crisis efforts exclusively focused on containment strategies. The goal of these tactics was to minimize the damage caused by the abandonment of the project, especially on the financial assets of the organization, while finding another way to meet the objectives of the SIS plan. Soon after the termination of the IPACS project, the MIS director, in consultation with the senior managers, initiated a new project to implement a new set of systems that would satisfy the requirements of the strategic plan. The new director took a number of steps to ensure the success of this new project, including the following: 155 Chapter 4 • The users were asked to review the original RFP (that was used to solicit IBAX's proposal) and re-prioritize its requirements by removing any non-essential, "bells-and-whistles" features and adding new critical ones that were discovered throughout the faded IPACS project. The involvement of the users was substantial and their needs were carefully documented in the revised RFP. An involved manager explained this process: I'm told to look at the old RFP to see if it's still valid and add what we absolutely have to have. Like we weren't allowed to go blue skying here, but if there were some things we felt we absolutely have to have given the reality of the 90's then we would be allowed to add some of that. So I worked with one of the IS project managers and we did this new RFP and I went back to users and asked them for feedback. We incorporated the newly identified requirements and clarifications as a supplement to our original RFP. We did this for all of the applications. • A shortened proposal solicitation process was conducted. The RFP was sent to only four vendors with established reputations and links to GVH. This was an expeditious process because three years had elapsed since the initiation of the five-year plan, and time was of the essence in terms of the achieving the objectives of the SIS plan. • An existing vendor, Medsys, which was the provider of GVH's existing ADT system, was selected to implement the replacement project. This was beneficial for two reasons. Firstly, by selecting a provider of many of the existing applications, GVH did not have to pay for the acquisition and development of many applications. It simply had to pay for upgrading to newer versions of the software. A participant commented on this issue: We knew that we couldn't replace the ADT and the lab system and a number of our systems for financial reasons. We'd have to keep them because they were providing not everything we needed but they did function and we really needed to look at where we were going to go with our clinical systems. We didn't look elsewhere 156 Chapter 4 because we didn't have the dollars to buy another system that would require a different ADT or a different whatever. We needed a system that could integrate with what we already had cause that's the limit of our resources Secondly, GVH was able to significantly influence the development of newer versions of Medsys' software, as it was a local vendor and at the time was looking for beta testers. A participant discussed this benefit: One of the advantages with having gone with Medsys is that we had a lot of input into the prototype and we continue to do so. A number of our staff participated in a couple of design meetings when Medsys was originally building their order entry product. After a two-day meeting, based on our feedback they threw the whole thing out and started over using some of the newer technology and concepts. This made us feel very good about the process. Our physicians also had a lot of input. They were able to go and sit down with the developers and go walk through the screen inch by inch and field by field and say "yes that will work or no it won't." As a result, this was a very friendly clinical system. • The sequence of the application upgrades was carefully planned to ensure that critical legacy systems experiencing functionality problems (such as the ADT system) and systems that could deliver the most impact were developed first. A manager commented on the rationale for this prioritization strategy: As you know, lots and lots of the literature says that you should give clinical people applications that provide immediate, tangible benefits to increase the likelihood of early adoption and successful use. Well, one of the biggest benefits that people want is lab results. Physicians want to look up lab results on the wards, that's one of the biggest benefits that they see. We also considered establishing a similar link with radiology, but radiology didn't have a system, so what were we to communicate with? The only really good clinical departmental system we had was in the lab so it was logical to say "Alright, the first phase of Medsys project would be the lab. We'd give the clinical staff the lab results first using a lookup function. Get used to the technology and keyboard without having to worry about screwing things up so that's what we did. • Because the remaining funds from the canceled IPACS project were limited, individual 157 Chapter 4 departments were encouraged to develop their own departmental systems using their operating funds. A number of departments, including Radiology and Human Resources, took advantage of this opportunity and acquired their own stand-alone systems. Connecting these departmental systems was not a major concern for GVH as it believed that the in-house IS staff would be able to integrate the legacy and stand-alone systems using custom-made interfaces and client/server technology (which had become widely available by then). An IS staff member commented on these integration efforts: By [the mid-1990's], we had implemented a number of interfaces between our stand-alone applications and Medsys had also produced interfaces between their different systems and we were now operating with a better functioning client/server architecture. We had interfaces to pharmacy, to lab, and were working on a few other things. So we felt we were in a very good position even though we hadn't moved forward with the Baxter systems. Initially, these recovery efforts were somewhat intense and received the strong support of the senior management. Unfortunately, no additional resources (such as new funds, outside consultants, etc.) were employed to help with this process. Despite this, the manager who led the recovery effort felt optimistic about the success of the crisis response efforts: I feel GVH coped quite well. If you can take out the whining which is always a very big component of organizational politics and the selective amnesia, what you're left with is a management team that when they were actually asked to belly up to the bar and do something about this they actually did do it. They were supportive of the steps we were taking, in negotiating with the supplier. They were supportive of resetting our strategy and going through the evaluation process a second time. And, if you take away the insubstantial issues of the whimpering and complaining and worrying and fretting that is a natural factor of every activity in today's health care sector, I think GVH's was a fair success story in coping with a crisis. 158 Chapter 4 Despite the optimistic assessment by this manager, the GVH's response to the operational crisis suffered from two major shortcomings. After receiving a positive review by the Datacom consultants (which is described in the next section), the intensity of the recovery effort was reduced drastically. In fact, a number of the applications that were included in the SIS plan were still incomplete (some of them were never initiated) by the completion of this study's data collection phase. The efforts to integrate the departmental systems also became secondary and were never fully implemented resulting to a number of isolated islands of information. Many departments continued to implement and administered the own networks and systems. In fact, out of the 54 systems and 25 networks in GVH's existing IS portfolio, only 30 systems and 15 networks are managed by the MIS department. The lack of support and integration has had a negative impact on the ability of GVH to achieve its original strategic goals. To this date, no integrated system exists at GVH. A department manager commented on this issue: After this experience, we found that there was the appearance of openness and a willingness to help with MIS projects. Gradually what we found were all these formal processes that made it very difficult to get any sort of assistance. Suddenly, you had to fill out fill out forms, to go meetings only to be told "gee, we can't do anything for you." It was constantly dumped back to the users mostly because there were no resources available. The administrators turned their attention elsewhere and stopped worrying about the strategic impacts of MIS soon after the audit verified that the systems were complete, which they weren't. As a result, we had to use our departmental funds to bring in consultants to build a network for us because the MIS department had no resources. And I am supposed to manage it solely on my own, including the technical stuff. This pattern of moderately intense crisis management efforts that took place soon after the IPACS cancellation combined with the decreased attention that the crisis received as time went by is highly consistent with hypothesis nine. 159 Chapter 4 The second shortcoming of GVH's crisis attempts was the lack of attention to employee communication and morale issues. A number of participants indicated that internal communication tasks became secondary during the crisis response and were not adequately addressed. This further contributed to the demoralization of the involved staff. The following comment by an involved individual addresses this issue: After a while it became clear that the members of the senior management did not understand their managerial responsibility for communication. All expectations for communication were left totally on the shoulders of the MIS department. It was done very informally and many affected individuals and groups were not receiving relevant information about how the hospital was going to address their IPACS related problems. Now, you also have to understand that there is a lot of selective communication going on or at least selective listening. There are things that people don't want to say and there are things that people don't want to know about. We have a little bit of both. An example of such "selective" communication took place during a subsequent audit of the SIS plan (which was critical of the MIS department). The following comment by an IS staff member describes how it was conducted and its effect on her attitude: There was an audit that was done about a year before the end of the SIS plan period. That whole audit thing really ticked a lot of us off. The questions and the list of users were put together without us even knowing about it. All the stuff went to the Datacom consultant. The questionnaires were distributed without our knowledge or involvement. I first heard about this from one my users who called and said "I got this thing, what should I write down?" and I was like "I don't know what's going on." And there was a little of an uprising. I went to the MIS director and said "what the hell is going on?" and he said "well, we had to put this together in a hurry" and he didn't have the time to run it past us before it went out. And after all this fuss, they did it again. When the consultant prepared the audit, it was distributed to certain individuals within the hospital. And not all of them received all pages. When the results came back we saw bits and pieces of the report but not the whole report. Specifically I asked to see the report and I was told that I would not see it. When I saw part of it, I was torn. I do not personally mind receiving praise and or criticism if it is justified and if it's done in a constructive wajr. I mean, that's how we all grow and hopefully do better jobs. But, to have it done in such a 160 Chapter 4 way that it makes it look like some of what had gone on a hospital wide basis was as a result of this group who were so far down the chain that it had no input into the decision, I resented it. Legitimacy Crisis Management According to the participants, a major motivation for the crisis response that took place was the threat against the reputation and credibdity of the senior managers due to their apparent inability to successfully implement the government-approved SIS plan. Given that this was a large, heavily funded, highly publicized project, its cancellation created a predicament for the hospital. The following comment by an IS employee illustrates the legitimacy impact of the cancellation: I certainly believe that the most significant consequence of this project was an image issue for the hospital. This was a highly visible project that received a large chunk of money, over five million dollars, and there was a need to show results. We had to satisfy an external need for accountability for the ministry. Plus, anytime anyone has a big project go sour on him, there is the standard issue of the damage to our external image and then internally there is the usual feeling of failure. From an IS point of view, it's not something I like to have on my record but it's there. To address this threat, the hospital conducted an audit of the SIS plan implementation. The motivation for this audit was explained by another participant: By the time we got to the end of the five-year period, we faced a major issue. Because of the fact that this was a five million plus dollar investment, it was still a very visible, very public project. The government ministry was still interested on the periphery of it and the board needed to have some accounting. So, the hospital commissioned a post-implementation study. This study looked very carefully at the objectives that we'd set out with and the financial and operational parameters and concluded that in fact we had implemented the functionality that we'd set out to implement. It concluded that we'd done it on time within the five-year time line arid in fact slightly under budget. 161 Chapter 4 Interestingly, the audit was conducted by the Datacom consultant who formulated the original SIS plan and advised the hospital to select IBAX as the vendor for the IPACS project. The commissioning of the Datacom consultant to conduct the post-implementation audit served two functions from a legitimacy restoration standpoint. Firstly, it allowed GVH to signal that independent, outside monitors (the consultants) were objectively assessing the status of the project. As MIS consultants as seen as "experts" in conducting such evaluations, their opinions carry more significance than mere assurances and opinions of the internal hospital staff. Secondly, the long-standing, close relationship between the president and the consultant, coupled with their intimate involvement with the formulation of the SIS plan and the selection of IBAX, increased the pressure for a more positive assessment. This was a critical issue as GVH needed to demonstrate that the cancellation of the project did not cost the hospital additional resources and did not affect its ability to successfully conclude the SIS plan. This motivation is discussed in the following comment: At the time, we were trying to save the day for the hospital. We needed to show that there were results from the investment. Even though the Datacom consultant was mostly to be blamed for the failure, we hired him to do the audit. This way we could say yes, we cut our relations with IBAX, but we put in an interim solution, did it with the money that we got back, ended our five-year strategic plan with all the things we said we were going to do it. We just did it with a different company rather than IBAX. Despite the fact that the audit took place over a year before the conclusion of the five-year period, it provided a verification of the "success" of the SIS plan by predicting that over ten uncompleted and yet-to-be initiated applications would be successfully implemented. The report concluded that: 162 Chapter 4 Based on [their] independent review and user feedback, foundation financial systems have by and large been satisfactorily replaced/upgraded and based clinical foundation systems have been successfully implemented in the relatively short two years since the failed IBAX implementation effort was terminated... The MIS department has implemented successfully all of the functions enumerated in the strategic plan and then some and has remained within the five-year one-time cost and operating budgets contemplated in 1990... Assuming that all implementation objectives stipulated for the end of the [current year] and currently in progress are met, this budget will have been adhered to in all material respects. Accordingly, it is important that the hospital declare a (well-deserved) success. Unfortunately, the actual results of the recovery project did not match the audit's predictions. A number of the specified applications were never completed. In other cases, additional funding from operational accounts was used to implement and upgrade many applications but because such funds were limited their upgrades were not extensive. Nevertheless, the participants indicated that the early validation that was bestowed by the audit served as an effective legitimation management tool. At the same time, it had a negative effect on the level of attention and support from senior administrators as exposure to external stakeholders was diminished. This significantly reduced the pressure to actually complete the remaining applications, eventually leading to the incomplete conclusion of the SIS plan. In addition to the use of the consultant audit as a "monitoring" strategy, GVH pursued a number of "disassociation tactics" to respond to the legitimacy threat. Firstly, it distanced itself from the main cause of the failure, IBAX, by signing and publicizing a termination agreement. Secondly, the MIS director who was in charge of the incomplete recovery effort left the hospital soon after the conclusion of the SIS implementation period. Lastly, the hospital board dismissed the president of the hospital soon thereafter. 163 Chapter 4 In summary, the evidence shows that because of the nature of the IPACS crisis impact, the hospital pursued a number of initiatives aiming to address both the operational and legitimacy liabilities caused by the project cancellation. This is consistent with hypothesis ten. IPACS Post-crisis Stage When asked about organizational changes that occurred as a result of the IPACS crisis, participants offered diverse, sometimes inconsistent opinions. As table 4-7 indicates, most lower-level employees believed that little or no learning took place, while senior-level managers and the IS managers were more likely to indicate that a significant amount of learning took place. Despite the apparent diversity in these opinions,15 there is ample evidence to suggest that a number of organizational changes, albeit mostly informal, took place as a result of the IPACS crisis. Firstly, the MIS director instituted a large number of committees and working groups to ensure that senior managers, users, and IS personnel were intimately involved in all MIS-related decision-making activities. As part of this change, three steering committees were 151 speculate tha t diversi ty i n these opinions is more indicat ive of the communicat ion and morale issues at G V H ra ther t h a n the organizat ional learn ing and adaptat ion process. 164 Chapter 4 Table 4-7: ] lole Ordered Matrix: Opinions About Organizational Learning Position Salient characteristics Comments Senior Managers Uninvolved executive The hospital took many of the lessons tha t i t learned f rom this experience and careful ly applied to ensure tha t we improve our M I S procedures. There is a whole new decision-making and author i ty structure i n place to ensure tha t the users and technical people's opinions are heard and fu l ly considered. Involved manager A major lesson we learned was to look at a l l the in format ion funct ions of the hospital and br ing them together. To do this, we pu t a new set of committees and work ing groups i n place. This ensures tha t the needs of whole the hospi ta l are considered and a l l affected staff part icipates i n the relevant decisions. Non-management employees End-user I t h i n k we ind iv idua l ly learned some lessons. We a l l knew the lessons bu t i t d idn' t mean tha t we had the author i ty to use the knowledge tha t we learned. We now know tha t user needs and feedback are very impor tant . B u t whether we can always apply th is depends on the management's wi l l ingness to l is ten to them. IS manager Certa in changes took place to ensure tha t th is won' t happen again. I t h i nk the needed organizat ional st ructure is i n place now. This structure ensures tha t some of the high-level IS decisions aren't made i n isolation. IS staff member I f we ever had a lot of money again and they decided 'gee, our systems are gett ing old again, let's go look for new ones again, I couldn't guarantee tha t same th ing wouldn ' t happen again and that 's a sad commentary. established. The senior steering committee, consisted of business executives, department managers and IS managers, was charged with the monitoring of the overall MIS operation and the formulation of its strategic objectives. The business systems committee, with members from administrative departments and IS, was responsible for decisions related to administrative IS projects; the clinical systems committee, with members from the clinical staff and IS, was responsible for the planning and development of clinical applications. A number of working groups (such as education, research, IT architecture, etc.) were also established to address other specific areas related to MIS. Even though this structure ensured the involvement of affected personnel, it had a major drawback: it heightened the formality of the decision-making process making it very cumbersome and lengthy. The 165 Chapter 4 following comment by a clinical manager illustrates the effects of this structure: The decision process became very slow. Each decision usually involved two, three, four meetings. We had a whole bunch of committees and whde that at least helped us make sure that there was some kind of input or some kind of involvement of more people in the organization, rather than just a couple of key user people and the senior management who was relatively removed, it was very cumbersome. There was a senior steering committee and then under that there was a clinical group, then there was a records group, a technical group, an education group and a bunch of other ones. It was very complicated. But it helped us get somewhere. It used to be that the IS dept would decide out of the middle of nowhere to establish a new standard and move us all to a new software. Now maybe that was the best decision but they didn't ask anybody. The new structure ensured that we were all involved in or at least consulted before any major decisions were made. Secondly, the interface between the MIS department and the organization was strengthened in at least two additional ways. The person who was in charge of the quality programs at GVH (and directly reported to the president) was assigned the responsibility of managing the MIS department. Before this, the MIS manager reported to a vice-president instead of directly to the president. This change illustrates the increased importance of MIS management and ensures the close integration between the hospital's business needs and IS plans by placing a "business manager" in charge of it. The following comment by the new director addresses discuss the motivation behind this change: The reason behind this change was to bring the business and the MIS sides of the hospital closer to each other. Most of the stuff I worked at for the last five years has to do with redesigning the way we deliver clinical care, i.e. clinical core process improvement. It was the feeling of the CEO that I as the person who was leading the process redesign issues should also be heavily involved in influencing information systems development to support the changes. These two sides were too disconnected. IS could potentially go off in one direction and it not meet the business needs. So, I was assigned to coordinate this whole process and manage the MIS department at the same time. There is a sense that was what required was the leadership of someone who knew the business and knew where the business needed to go, so that was the reason behind it. I don't know anything about IS but I know the business really well because of my 20 some years in clinical care. 166 Chapter 4 To further rectify the communications issues between IS and the business units at GVH (which were seen as part of the IPACS failure cause), the hospital initiated an informal internship program. The president of the hospital explained this initiative: It used to be that we had all of these clinical people here and all these technical people there but there was little communication between them. So I thought "I got to have a translator, I have to have an information management needs/deliverables translator." Somebody who can take what the clinical staff thinks they want and explain it to the technical people to have them understand how to help us organize the system to deliver what the clinical people want. We think we're starting to understand that better. And to deliver this interface we have been hiring hospital information sciences students from the university in Saxton. They are absolutely wonderful. We take usually 8-10 of those students every semester and we just bring them in and say, "charming young student go and talk to these doctors and these programmers and you're going to go back and forth and make both parties happy. This is your project. You have to make the programmers understand what the patient admitting system for the ophthalmology department looks like. You've got four months to do it in. Good luck and away you go." And they're great. So we're starting to understand that sort of thing. And, I think as we're beginning to understand all of the rest of that we're getting more comfortable with it. As we reorganize in time what we may end up doing is taking the technical management side of MIS and, at least a lot of it, we could just farm it out. We're in the healthcare business. Why do I want somebody worrying about the networks? Lastly, the IPACS crisis caused GVH to begin examining some of its organizational routines regarding the formulation of contracts. GVH felt that its existing contract negotiation and formulation processes were inadequate and did not fully protect it against vendors who were not able to deliver the promised products, such as IBAX. This change, however, was informal and did not result in a policy implementation. A manager commented on this initiative: I feel that was important learning that took place as a result of this experience. For example, one specific instance that has come up is the whole issue of contracts. There's been a lot of discussion about what should go into contracts, how contracts should be structured, how the deliverables should be stated, what kind of recourse the hospital should have in case of non-performance and many other issues. I mean people saw that even though that was not successful at least the hospital got 167 Chapter 4 something back that they could reinvest in something else. So I think that being really careful that the hospital's goals is covered as much as possible. I certainly noticed that in the relationships with vendors are formed differently now. It used to be that even when the vendors were fairly new, people just sort of trusted them. Now, they are establishing as much legal recourse as is possible. They really approach the relationship with vendors in a different way than they would have done in the past. In summary, it seems that the empirical evidence about organization learning at GVH is consistent with hypothesis eleven. The events and most accounts indicate that GVH engaged in some organizational learning and adaptation as a result of the IPACS crisis. At the same time, the evidence suggests that there was increased formality in decision-making processes due to the introduction of committees and other formal procedures. Even though the literature treats these two events, organizational change and organizational formality, as mutually exclusive phenomena (Occasion, 1995), this study's evidence contradicts such assertions. It appears that their coexistence is indeed possible when the increased formality is the intended purpose of the planned organization adaptation and not simply the result of rigidity-creating, massive crises. Unfortunately, the side effect of such rigidity events, coupled with the lack of resources, hinders future experimentation and development work, something that can partly explain the current incomplete state of the SIS plan. Summary of GVH Case Findings The case evidence suggests that the proactive abandonment of the IPACS project averted a major crisis for GVH. The hospital took a number of preparatory actions to avoid 168 Chapter 4 conversion to the systems, something that would adversely affect its operations and increase the financial damage to the organization. These preparation efforts were initiated and facilitated by an uncommitted new MIS director. It appears that his arrival had a significant de-escalation effect on the behavior of senior managers who up to that time were very supportive of the project's continuation. Even though the moderate impact of the IPACS crisis spared GVH from many potential troubles, it contributed to the low intensity of the crisis response effort. After the hospital rectified the legitimization threat issue (by receiving and publicizing a favorable audit report), it failed to allocate the financial and staff resources needed for the completion of the various applications. As a result, a number of them remained incomplete and the hospital still doesn't have an integrated, organization-wide system. Finally, it appears that GVH pursued some organizational changes in response to this crisis that contribute to an increased formality and rigidity further inhibiting future changes and experimentation. A summary of the main case events is presented in Table 4-8. Table 4-8: Case Dynamics Matrix of the IMIS Project Stage Antecedents Events Outcomes Pre-crisis H i g h importance of the project and strong support by president create an escalating commi tment s i tuat ion Warn ing signs are in i t i a l l y ignored u n t i l the new M I S director arrives. He more fu l ly considers the signs and takes a number of steps to avoid a fai lure Project was cancelled before i ts conversion avoiding a major crisis Crisis The cancellation has an impact on the image of the hospi ta l but no impact on the exist ing operations of the hospi ta l The crisis response efforts are focused on signal ing the successful completion of the SIS plan. L i t t l e at tent ion and resources are given the applications i n the "replacement" project A number of applications remain incomplete and GVH does not possess an integrated hospital-wide system Post-crisis The moderate impact of the crisis necessitates the need for changes The M I S decision-making and report ing structure change to reflect lessons. These changes lead to increase r ig id i ty The new structure makes i t di f f icul t to "experiment" w i t h new ideas and implement new projects 169 Chapter 4 To summarize the empirical assessment of the theoretical model, I display the research hypotheses and indicate whether or not they were supported by the case data in Table 4-9. Table 4-9: Summary of Hypothesis Assessment in the GVH Case N u m b e r H y p o t h e s i s S u p p o r t 1 Project importance w i l l lead to greater ISD crisis impact Negative; Even though th is was an impor tan t project i ts cancellation d id not create a signi f icant crisis for the hospital 2 Fai lure controUability w i l l lead to greater ISD crisis impact Positive; Both the controUabil i ty and the magnitude of the IPACS crisis were moderate 3 Pre-crisis preparat ion w i l l lead to lower ISD crisis impact Positive; GVH's preparat ion efforts helped avoid the mater ia l izat ion of a signi f icant crisis and mi t igated against i ts potent ia l impact on i ts operations 4 Managers' commitment to the project w i l l lead to lower pre-crisis preparat ion Positive; the i n i t i a l denial of negative in format ion resulted i n the cont inuat ion; the de-escalation caused by the ar r iva l of the new M I S director had a positive impact on preparat ion efforts 5 Project importance w i l l lead to greater commitment to the project Positive; the importance of the project to the organization's strategy and i ts size contr ibuted to the escalation of their commitment to i t 6 Whist le-b lowing w i l l lead to greater pre-crisis preparat ion None; there is no evidence ind icat ing tha t whist le-blowing at tempts were successful i n ending the pre-crisis denial 7 Project importance w i l l lead to greater whist le-b lowing Positive; The seriousness of the potent ia l crisis had a mot ivat ing effect on whist le-b lowing 8 Managers' commi tment w i l l lead to lower whist le-b lowing Positive; the part ic ipants indicated tha t the behavior and att i tudes of over-committed managers inf luenced thei r decision to engage i n whist le-b lowing 9 ISD crisis impact w i l l lead to greater crisis management Positive; The in tens i ty of the crisis response was moderate as there were no affected operations. Resources and support were not readi ly available and fur ther decreased when the legi t imacy th reat was d imin ished 10 H i g h ISD crisis impact w i l l lead to both operat ional and legit imacy crisis management Positive; G V H at tempted to protect i ts image by signal ing tha t i t had completed the SIS p lan on t ime and w i t h i n budget; th is was not an intense effort and was selectively implemented w i t h i n the organization 11 ISD crisis impact w i l l lead to greater post-crisis organizational learning Positive; both organizat ional adaptat ion and r ig id i ty took place as a resul t of the moderate level of the f inancia l impact and the legit imacy threat 12 Fai lure control labi l i ty w i l l positively moderate the relationship between the ISD crisis impact and post-crisis organizational learning Not assessed; Because of the moderat ing effect in this relat ionship, i t cannot be assessed i n w i t h i n case analysis; i t requires more than one data point and w i l l be examined i n the between-case analysis 170 Chapter 4 4.1.3 Royal Canadian University Case Findings Even though the NICS project represented a $4 million investment for RCU, its cancellation had no significant impact on its operations and image. A number of events and factors contributed to this low impact of the cancellation of the numerically intensive computing service (NICS). These are described in Appendix Three and discussed throughout this section. A state-event network depicting these events and related factors is shown in Figure 4-3. NICS Crisis Impact Other that the opportunity cost of the resources consumed by the NICS project, RCU did not experience any other major consequences as a result of its abandonment. At the time of its cancellation, the system was used by less than twenty users. The accounts of these users were transferred to alternative services that offered similar (and sometimes more sophisticated) services and software than NICS. As a result of NICS well-managed cancellation, the university's teaching, administrative, and research activities remained unaffected by its abandonment. In fact the vast majority of the thousands of users at RCU did not pay attention to its introduction and most of them weren't even aware of its short-life and eventual cancellation. Virtually all participants also verified the non-significant impact of the abandonment. Characteristically, an administrator of an academic unit indicated that "after this machine was decommissioned, we didn't hear any comments or see any reaction; it sunk without a ripple." Similarly, an IS manager, working in the 171 Chapter 4 University Computing Center (UCC), pointed out that overall this failure "was a blip that lasted three years of effort and one year of service" and had no negative effect on the user community. As he put it, "I don't recall anyone walking down the hall to me and say 'Hey, Andy, do you remember that stupid machine you guys used to run? The one that you called a supercomputer?' I just haven't heard a word about it since its decommission." The evidence indicates that the impact of NICS cancellation on the image of the university was inconsequential as well. The whole incident of its decommission was contained within a small part the university community (i.e., the administration, UCC staff and a small number of affected users) and attracted no publicity or external exposure. In fact, the only public, written comment about its cancellation was a four-line announcement on page four of a 32-page UCC newsletter stating that "NICS will be discontinued on approxirnately June 15th this year. The IBM 3090, on which this service was provided, is being returned to IBM because we lack the funds to continue this service. The staff will be happ]^  to assist NICS clients in migrating to our expanded UNIX service, described in a separate announcement." According to participants from both RCU and IBM, the return of the mainframe to the IBM and the cancellation of the lease did not have an adversarial impact on the relationship of the two parties. It appears that both parties recognized that changes in the external environment, beyond the control of the two organizations, were primarily responsible for the failure of the project and thus did not attempt to blame each other. In fact, an IBM executive who was involved with the project indicated that the NICS project had a positive 173 Chapter 4 effect on the relationship between IBM and RCU: The relationship with RCU was not impacted very much by this project. If nothing else, we got to know RCU and its management much better. I think probably the fact that we worked closely with them trying to focus on the project and its problems, although it turned out to be unsuccessful, certainly budt a better set of relationships between them and us, I suspect. Secondly because we basically stepped up and did what was right my guess is that we probably bought our selves a lot of credibihty. The only material consequences of the failure that was identified by participants was the opportunity cost of the resources and time investment that were allocated to the project. This issue is summarized in the following comment: I would say that only major result of this incident was the financial loss to the university. We basically spent three mdlion dollars plus the salaries for three-four people working full time to install and maintain the system for a service we could get using a different system for less than a million. But, I think the biggest problem was the delay of two-thee years in moving to new technologies. And I wouldn't be surprised if the university isn't still suffering from that. So, the money could have been spent better, more wisely. About the cost of the delay, who knows how to put a dollar value on the delay in moving to better, newer systems. But, in my opinion it has held up the evolution of the IT services at this university. In summary, there is seems to be a consensus among administrators, UCC staff and end-users that the abandonment of NICS had no major consequence to the university operations or image. Some of them even indicated that this incident was, in relative terms, a non-consequential one: The cancellation of the service did not severely affect the services we offered. In fact, if you were to ask most people to list the biggest failures faced by the university in the recent past, I don't think the vast majority of them would mention the cancellation of NICS as one of them. To understand the factors and events that contributed to this low impact of the NICS abandonment, we will next review two key characteristics of the project, importance of the 174 Chapter 4 system and controllability of the failure, and the events that took place at RCU before its cancellation. NICS Project Importance This project was initiated due to high pressure from interested science researchers who needed access to sophisticated computing facilities to conduct their scientific research. The initial idea for such facilities received the support of the president and a vice-president of the university who felt that they could have a significant positive impact on the university's research activities. Even though the project was highly regarded by the involved researchers as a very important one, it was not perceived as such by the vast majority of the university community. These researchers were a small group of faculty members and were concentrated in just three faculties. Overall, the planning and implementation of NICS was of little importance to the rest of the university, including its staff, students, and most administrators and faculty members. As the goal of the project was to simply provide intensive computational facilities to researchers, it did not affect the main teaching and administrative operations of the university and did not receive widespread publicity. Other than the support of the senior administrators who felt that this was a strategic project for the university, NICS received little political importance and momentum. The project was not publicized outside the university and thus its implementation was immaterial to its external image. The project was politically important, however, to the 175 Chapter 4 cultivation of a close relationship with IBM, one of the university's major financial donors. As one IBM executive pointed out: In the minds of many people, the NICS project was part of a bigger plan. It was part of RCU and IBM's existing and future relationship. At the time, I think the university was relatively predisposed to work with IBM. I recall that at the time we were talking about having a major computer lab out here and RCU was one of the candidate partners for it. The sad part is that lab was really tied to some air traffic control bids and it never happened. RCU employees expressed a similar sentiment. The following comment by one of them illustrates the role of the university's relationship with IBM in this project: IBM interacts with the university at many levels. It interacts with the university on different kinds of computers and different faculties and different kinds of uses so presumably all these different interactions were taken into account when the final [vendor selection] decision was made. The result in the end was that the university decided that when factors other than the price performance ratio that we were looking at narrowly on this project were taken into account, IBM could make a proposal that would benefit the university better overall. That may well be the case. I mean, there are other things that come into play when you look at this from the president's office... Most of us, however, were not part of that assessment. Interestingly, due to two factors, the importance of the relationship with IBM was diminished during the implementation of NICS. Firstly, due to the availability of more powerful and less expensive computers, there was no need to have "IBM machines" to conduct intensive computing. As the new RISC-based machines could easily match, and usually exceed the performance of the IBM mainframes, these mainframes lost a lot of their symbolic value as the only powerful computers in the marketplace leading to the well-known adversarial effects on IBM's competitiveness in the early 1990's. Secondly, another computer-related facility that was contemplated during the time of the NICS vendor selection period (which would offer great advantages to RCU, making a working 176 Chapter 4 relationship with IBM a more desirable one) did not come to fruition (because the government did not award its implementation to IBM). As the following sections will show, these external changes during the early part of the project contributed to its lowered political importance and made its cancellation a less difficult choice. In terms of its financial costs, NICS was a sizable project. The overall estimated cost of the project was about $4 million for a four-year period, representing about one and a half percent of the university's annual operating revenue. In summary, the NICS project was a moderately significant undertaking for the university as it was a sizable investment and had some political importance related to RCU's relationship with IBM. However, as the project received no external support or visibdity and its scope was limited to a small part of the university community (i.e. researchers with intense computational needs) and was not material to the routine operations of RCU, the overall importance to the whole university was not substantial. This level of moderate importance, coupled with the virtually no adversarial impact of its cancellation, is inconsistent with hypothesis one, which posits that the crisis caused by the failure of such a project is expect to have some consequential impact. Controllability of NICS' failure Participants from both RCU and IBM indicated that the main reason for the fadure of NICS was drastic changes in the computing environment. At the time of NICS 177 Chapter 4 introduction, powerful RISC workstations were being introduced in the marketplace. This new technology greatly facilitated decentralized computing. This was a dramatic change in the computing environment as virtually all intensive computing up to that point in time was performed centrally on large mainframes and supercomputers. Due to the advances in the marketplace and the uncertainty about the potential success of this new decentralization trend, it was very difficult for many managers to select an optimum solution for their organizations from the decentralization-centralization spectrum. This was the case at RCU as well. The decision-makers (users and administrators) had great difficulty ascertaining the most appropriate configuration for the NICS facility and whether it should be based on the traditional centralized model or the newly introduced decentralized mode of computing. A member of the vendor selection committee commented on this difficulty: The workstation technology was changing very rapidly. Throughout the discussions, there were proponents of the workstation solution, the clustered workstation solution, the multi processor approach as well as proponents of the very expensive CRAY approach. Some felt that the only solution was the purchase of "big iron." Others were making the decision between doing it on a central machine and their own PCs. The would have runs that would take perhaps days to do on a PC but there was no problem in terms of cost once you bought the machines - cost is fixed. There are not problems in terms of scheduling - you don't have to worry about anyone else's workload. And because the style of computing was changing, you could, for example, break a problem up into small pieces that they could run a piece overnight and come back the next morning and look at the results and continue from that point. [This] change in computing at the time created a big question for us. The high levels of uncertainty that existed at the time mitigated the RCU's apparent responsibility for the failure, as such conditions make it very difficult (even for competent managers) to effectively forecast and proactively act to respond to drastic changes in the 178 Chapter 4 environment. This difficulty in foreseeing and avoiding the materialization of the failure is illustrated by the inability of the selection committee to reach a decision about which configuration would be the most appropriate for NICS (it selected four possible configurations instead). The apparent lack of controllability in preventing this failure was also verified by many accounts, including many by individuals who had an adversarial relationship with the president's office (who selected the IBM proposal). The following comment by such an individual provides support to the assumption of low controllability: Technically the service was successful. Utilization when it was not charged out was almost 100 percent. The work that we were doing with IBM on AIX was more or less leading edge. Was it the right one from the economic point of view? Absolutely not. A few of us knew that from the beginning, but not everyone recognized that. Major changes in hardware and end-user computing style made this a very difficult decision. Most of the people, including some industry experts, did not know what to expect. So, everyone did what he or she thought was the best for the university. There was no malicious intent. It just didn't turn out to be the right thing. The inability of RCU's management to accurately foresee the changes in the computing environment was verified by the accounts of involved IBM employees as well. These accounts also acknowledged that IBM's early attempts in developing Unix-based machines (such as the one used by NICS) were not successful, further reducing the responsibility of RCU. As one IBM manager put it: From our point of view as well as RCU's point of view there was a bit of anxiety about whether this solution was really going to make sense giving the changes in the industry. Certainly some RCU people questioned whether this was going to be the right technology in the long term, but many others thought it would be a good solution. IBM did everything it could to adjust to the new environment. But, as you may know, when IBM was getting into the Unix area, it kind of stumbled a couple times in terms of the basic boxes it was making. There is no doubt in my mind that both IBM and RCU worked really hard to make this work. The fact of the matter though is that the technology evolved so rapidly that it quickly made NICS an ineffective solution. The price/performance you could get out of this thing was just nowhere near the price/performance you get out of smaller dedicated machines. 179 Chapter 4 As the above accounts clearly indicate, the fadure of the NICS project was attributed to the drastically changing environment and the inability of IBM to respond to the changes by delivering a successful system. Indeed, because of the early troubles that IBM had with its ATX operating systems, the announcement of NICS was delayed on multiple occasions. As a result, IBM donated $300 thousand to the university to cover the cost of these delays. This action further validates the responsibdity of IBM and the low internal controllability of this failure. As an RCU senior administrator simply put it, "the reason that NICS fell by the wayside is that IBM was not able to keep pace with the technological advances and it was not able to deliver a technologically competitive product. It's that simple." In summary, it appears that RCU had little opportunity to avoid the cancellation of NICS. This lack of an apparent responsibility on behalf of RCU removes any potential legitimacy threat and contributes to the low impact of the NICS crisis. This finding is consistent with hypothesis two. NICS Pre-crisis Stage Many UCC staff members indicated that during the vendor selection process, the senior administrators of the university ignored their voiced concerns about the financial and technological feasibility of the proposed system due to its high level of commitment to the IBM proposal. The following comment is indicative of the viewed shared by the UCC staff: The original decision to purchase an AIX system was viewed with total astonishment by most of the people on the technical side. They couldn't understand why the decision was made. It was extremely clear to the technical people. The 180 Chapter 4 trend of moving to smaller machines was not a new trend. It was clear that advances in RISC based systems would have dominated the mainframe market. These participants hypothesized that this initial apparent denial by senior administrators during the vendor selection process was due to the uncertainty in the computing trends, which is described in section Because of this uncertainty, it was very difficult to ascertain the vahdity of the concerns raised by the technical personnel. As an UCC manager pointed out, UCC personnel was partly responsible for this situation: We as computer professionals had a clear idea of the direction computing was going. However, the president's office didn't have the same information we had. We did not communicate that to them effectively at all. We should have been aware that this was a political process and should have been able to adapt it instead of treating as a mere technological decision. So, the senior management didn't know what they were doing frankly. They didn't know the technical aspects. According to the senior administrators, their strong support towards a centralized UNIX service (instead of a departmentalized collection of smaller machines) was motivated by the overall benefits of the university's relationship with IBM and the status of computing facdities at RCU the time. As one administrator put it, I don't deny that certain individuals in the computing center did not think that IBM was the best solution. But at that time, because of the prices IBM was offering and the promises we got, it was a very good solution for us. I think we had a closet desire to have a supercomputing solution, a big machine. The other alternatives, such as Cray, were way out of our reach... Also, if at the time any faculty had come up and said "gee, give us the money and we will run our cluster of sdicon graphics," we would have done that but they were also not emotionally ready to take the responsibility. Despite the early commitment of senior managers to the IBM solution, their attitude changed quickly after the first early warning sings of its impeding fadure. The fact that their high commitment did not escalate was facilitated by three events. Firstly, because of 181 Chapter 4 bugs in the system, the machine could not be put in operation for a number of months past its original availability date. This resulted in multiple delays, which began to worry the administration. As a result of these delays, the vice-president with the cooperation of UCC contacted IBM and negotiated a $300 thousand payment to the university to cover the cost of the delays. This clearly indicates that the administrators were monitoring the progress of the project and took appropriate actions to minimize the impact of its problems. Secondly, two new managers were hired while the system was being readied to be in full-production. The first manager was an associate director of UCC who quickly realized the poor price/performance ratio of NICS and began making plans for an alternative, comparable service. The other manager was hired to fill the newly established position of an associate vice-president (AVP) of information and computer systems. This position was created by the senior administrators to provide a better interface between UCC and senior management, improve the relationships between these two groups and to provide a strategic direction for UCC, which up to that point was traditionally regarded as a service, cost center. Their arrival, coupled with their lack of prior involvement with the project, had a de-escalation effect on the attitude of senior administrators. The AVP described his initiation to the project: My initial awareness had to do what I think was about 300 thousand dollars, or something of that neighborhood, of IBM donations. From what I was told, essentially IBM gave the university that amount because it really hadn't delivered what we had anticipated. I had a discussion with the VP about this. As I dig deeper to better understand the situation, I was getting the feeling that this project was not going to take off. In fact, because we were moving towards a cost-recovery model I was worried that when we eventually put the service in production it would not generate enough money for the next lease payment that was coming up. UCC, which was part of my portfolio, was expected to cost-recover all of its investments 182 Chapter 4 and I didn't think that was possible with this system. So, I began examining the issue in more detail and kept the administrators closely informed and involved with all the decision-making. Thirdly, the presence of unambiguous early warning information about the future economic viability of the system pressured the AVP and the administrators to take decisive actions to prevent the materialization of a failure. Such information included the fact that usage (and as a result, revenue) dropped to almost nil when the service was put in production and user charging was initiated. Until that point, the users who were involved in beta testing and were receiving free access to it were fully utilizing the machine. However, when it ceased to be a free resource, their behavior changed drastically. A UCC staff member described this event: There were a number of technical problems that meant we couldn't charge for the service initially but those eventually got resolved and at the point they turned charging on we went from about 100 percent utilization to about 7 percent. Basically the system was being used by a whole number of people who simply didn't have the money to pay for computing. Graduate students were using it; some researchers were using it. The assumption that they made going into the project was that there would be funds available for this style of computing. However, as it turned out, the university budgets were being cut, researchers were not getting access to large amounts of grant money, and nobody had the money to pay for the service. At the same time, personal computing was becoming more powerful and affordable. And so from their point of view, the decision people were making was: do I do run my programs on my PC or do I do it on NICS? If I can do it on the mainframe for free, then I'll do that. Then I use my PC for word processing too. If I have to pay for it however, I'm going to bring it back and put it on my PC. So, when we actually got the charging operational on NICS, on that particular date, the use went from 100 percent to less than 7 percent. In the first day of the service we generated something like $3.87! In responses to these events and the increased concerns about NICS ability to generate enough revenue to cover its remainder lease payments, RCU took a number of steps to manage the pre-crisis situation. These pre-crisis preparation steps included the following 183 Chapter 4 actions: • RCU negotiated with IBM to minimize the negative consequences of the delays due to the AIX software bugs and recover some of the financial investment in it. As mentioned earlier, IBM donated $300 thousand to partly compensate RCU for the opportunity cost of these delays. In addition, it agreed to extend the early support plan that was provided to RCU free-of-charge until the system became fully operational. • The new AVP, with the close cooperation of the involved VP, led a team of UCC managers and legal professionals to examine the potential return of the system to IBM before the conclusion of the contract. The team reviewed all documents that were prepared during the early negotiations between RCU and IBM and the life of the project. This process and its results prepared the leadership of RCU to be effective in its negotiations with IBM. The team concluded that RCU could be able to return the system to its vendor before the conclusion with the agreement under a "no funding" clause. According to a senior administrator, this was perhaps the most critical element of RCU's pre-crisis preparation strategy: You see, this arrangement was a lease, not an outright purchase agreement. During the negotiations we told IBM that we couldn't make such a large investment in this machine given the changes and uncertainty in the technology. They understood our predicament and agreed to make this a lease. So, we had a lease with a very clear cance