"Business, Sauder School of"@en . "DSpace"@en . "UBCV"@en . "Iacovou, Charalambos L."@en . "2009-06-30T20:39:10Z"@en . "1999"@en . "Doctor of Philosophy - PhD"@en . "University of British Columbia"@en . "This study describes a conceptual framework that portrays information system project\r\nfailures as organizational crises. The main assumption of this study is that such failures\r\nwill invariably happen and thus there is a need to make them less costly and more\r\nbeneficial to organizations. To identify the behaviors and factors that influence an\r\norganization's ability to effectively manage a project failure, this dissertation reviews the\r\ncrisis management literature. Based on this review, a three-stage model is formulated. To\r\nunderstand the mechanisms underlying this model, a number of hypotheses (which are\r\ninformed by a number of related organizational behavior areas) are generated. These\r\nhypotheses focus on three key crisis management factors: the organization's ability to\r\npromptly detect an impeding failure, its capacity to manage the failure's impacts, and its\r\npropensity to learn from it. To empirically assess the validity of the conceptual model,\r\nthree case studies of Canadian public organizations were conducted. The empirical\r\nfindings provide strong support to the model's conjectures and indicate that project failures\r\ngenerate several crisis-related behaviors and responses. More specifically, the findings\r\nsuggest that an organization's proactive preparation for a failure can have a significant\r\nmoderating effect on its impact. However, the findings clearly show that an organization's\r\nability to promptly detect (and prepare for) a failure is impeded by behaviors that are\r\nmotivated by escalation of commitment. Such behaviors lead to a prolonged pre-crisis\r\ndenial period and have a suppressing effect on whistle-blowing, which is pursued as a\r\ndenial-curtailing strategy by non-management participants. The empirical findings\r\ndescribe both operational and legitimacy tactics used by organizations to cope with the\r\naftermath of a project failure and indicate that credibility restoration is a significant\r\nconcern during large crises. Finally, the empirical evidence indicates that organizational\r\nlearning and adaptation are more likely to follow major project failures than less\r\nsignificant ones. This contradicts threat-rigidity arguments and provides support to the\r\nfailure-induced learning theory."@en . "https://circle.library.ubc.ca/rest/handle/2429/9886?expand=metadata"@en . "16872237 bytes"@en . "application/pdf"@en . "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 \u00C2\u00A9 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 1.3.2.1. The Negative Effects of ISD Crises 13 1.3.2.2 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 3.2.1.1 The Northern Utilities Case 77 3.2.1.2 The Green Valley Hospital Case....'...| ' \"^ \"..!\"\"!\"!!\"!\"\"\"\"\"\"I\"!\"I!l78 3.2.1.3 The Royal Canadian University Case 81 3.2.2. Data Collection 84 3.2.2.1 Interviews 84 3.2.2.2 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 4.1.1.1 IMIS Crisis Impact 101 4.1.1.1.1 IMIS Project Importance 103 4.1.1.1.2 Controllability of IMIS' failure ; 105 4.1.1.2 IMIS Pre-crisis Stage 106 4.1.1.2.1 Escalation of Commitment in the IMIS project 110 4.1.1.2.2 Whistle-blowing in the IMIS project 114 4.1.1.3 IMIS Crisis Stage 118 4.1.1.3.1 Operational Crisis Management 120 4.1.1.3.2 Legitimacy Crisis Management 124 4.1.1.4 IMIS Post-crisis Stage 128 4.1.1.5 Summary of NU Case Findings 131 4.1.2 Green Valley Hospital Case Findings 134 4.1.2.1 IPACS Crisis Impact 135 4.1.2.1.1 IPACS Project Importance 137 4.1.2.1.2 Controllability of IPACS' failure 139 4.1.2.2 IPACS Pre-crisis Stage 141 4.1.2.2.1 Escalation of Commitment in the IPACS project 146 4.1.2.2.2. Whistle-blowing in the IPACS project 151 4.1.2.3 IPACS Crisis Stage 155 4.1.2.3.1 Operational Crisis Management 155 4.1.2.3.2 Legitimacy Crisis Management 161 4.1.2.4 IPACS Post-crisis Stage 164 4.1.2.5 Summary of GVH Case Findings : 168 4.1.3 Royal Canadian University Case Findings 171 4.1.3.1 NICS Crisis Impact 172 4.1.3.1.1 NICS Project Importance 175 4.1.3.1.2 Controllability of NICS' failure 177 4.1.3.2 NICS Pre-crisis Stage 180 4.1.3.2.1 Escalation of Commitment in the NICS project 186 4.1.3.2.2. Whistle-blowing in the NICS project 188 4.1.3.3 NICS Crisis Stage 191 4.1.3.3.1 Operational Crisis Management 192 4.1.3.3.2 Legitimacy Crisis Management 194 4.1.3.4 NICS Post-crisis Stage 195 4.1.3.5 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). \u00E2\u0080\u00A2 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). \u00E2\u0080\u00A2 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). \u00E2\u0080\u00A2 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). \u00E2\u0080\u00A2 According to a survey of 150 corporate IS managers by the Center for Project Management, half of all projects become runaways (LaPlante, 1995). \u00E2\u0080\u00A2 According to Gibbs (1994), for every six new large-scale systems that are put into operation, two others are canceled. \u00E2\u0080\u00A2 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. 1.3.2.1. 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). 1.3.2.2 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 \u00E2\u0080\u0094 > Crisis Mamgement \u00E2\u0080\u0094 \u00E2\u0080\u00A2 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 3.2.1.1 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. 3.2.1.2 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. 3.2.1.3 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). 3.2.2.1 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. 3.2.2.2 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 \u00E2\u0080\u0094 support ing evidence PRE-PRE+ Preparat ion \u00E2\u0080\u0094 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 4.1.1.1 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: \u00E2\u0080\u00A2 inability to meet a legal requirement to produce financial statements; \u00E2\u0080\u00A2 A/P problems could result in payments to incorrect firms and/or missed payments and/or lost discounts; \u00E2\u0080\u00A2 no management information to operate the company; \u00E2\u0080\u00A2 inability to effectively track sick/leave time [while] basic payroll is being met with some manual effort; \u00E2\u0080\u00A2 a lack of reliable inventory system could seriously impact service if parts are not available when required; \u00E2\u0080\u00A2 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. 4.1.1.1.1 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 4.1.1.1.2 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: \u00E2\u0080\u00A2 the selection of an inexperienced project manager; \u00E2\u0080\u00A2 a lack of effective change control; lack of a contingency plan; \u00E2\u0080\u00A2 inadequate staffing and resource allocation; and \u00E2\u0080\u00A2 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. 4.1.1.2 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: \u00E2\u0080\u00A2 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; \u00E2\u0080\u00A2 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.\" \u00E2\u0080\u00A2 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)! \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 The abrupt discontinuation of the monthly progress reports four months before the conversion date without a justification. Interestingly, no manager or commissioner questioned this. \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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. 4.1.1.2.1 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. 4.1.1.2.2 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. 4.1.1.3 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 4.1.1.1) 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. 4.1.1.3.1 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: \u00E2\u0080\u00A2 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). \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 An additional $200 thousand were allocated by NU's management to the recovery project. \u00E2\u0080\u00A2 The project team met every morning to discuss daily progress, identify key issues and review the day's work schedule. \u00E2\u0080\u00A2 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. 4.1.1.3.2 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. 4.1.1.4 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. 4.1.1.5 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. 4.1.2.1 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 4.1.2.1.1 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. 4.1.2.1.2 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 4.1.2.2 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: \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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.\" \u00E2\u0080\u00A2 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: \u00E2\u0080\u00A2 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.\" \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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 \u00E2\u0080\u00A2 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. 4.1.2.2.1 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.\" 4.1.2.2.2. 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 4.1.2.3 IPACS Crisis Stage Chapter 4 As section 4.1.2.1 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. 4.1.2.3.1 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 \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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. 4.1.2.3.2 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. 4.1.2.4 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. 4.1.2.5 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. 4.1.3.1 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. 4.1.3.1.1 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. 4.1.3.1.2 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. 4.1.3.2 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 4.1.3.1.2. 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: \u00E2\u0080\u00A2 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. \u00E2\u0080\u00A2 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 cancellation clause with no penalty to the university. And when we did come to cancel the thing, there were many people that felt that we couldn't do that. And I said \"of course, we can do that.\" I actually remember pulling all the files and records and contracts I had in my office and showing them to the associate VP, who was not here when we signed the contract with IBM. And then these people said that I was right and we could in fact cancel the contract. 184 Chapter 4 \u00E2\u0080\u00A2 The new AVP informed IBM that RCU was considering the return of the system soon after it noticed the drastic drop in usage. The two parties engaged in intense negotiations for months. Initially, IBM was reluctant to accept the return of the system without the purchase of new hardware. A participant commented on IBM's actions: [IBM] was aware of our intentions very early because this was a partnership ... It was quite clear [to IBM] that a major part of the NICS project was defined on its revenue capability; the ability of UCC to actually charge for it. So I think they started looking at alternatives probably at the same time as RCU began looking as well. However, what they considered to be fixed in their deliberations was the dollar amount, 1.9 million dollars [the amount of the last two lease payments]. They assumed that they would be getting that money. And they started offering other alternatives that were relied on IBM server configurations. And so they were considering options, anything, any product that they had in the end as long as that 1.9 million doUars came in. As part of these negotiation efforts, IBM's sent an unsolicited proposal to RCU suggesting the replacement of NICS with a number of RS/6000 IBM workstations. RCU rejected this proposal and informed IBM that it would exercise the cancellation option before the third payment of the lease was due. \u00E2\u0080\u00A2 To address the needs of researchers for low-cost, numerical analysis computing facilities, UCC acquired three, low-cost RISC-based computers (a Sun SPARCstation 2 and two Silicon Graphics computers) using operating funds and began offering a new UNIX service (as an alternative to NICS). Due to the low cost of the hardware, the usage rates for this service was significantly lower than the NICS rates. Thus, because this new service was able to satisfy the computing needs of the majority of the researchers at much lower rates, it quickly became very popular. Within a few months of its operation, there were over 900 active accounts on this service (compared to less 185 than 80 on NICS). Chapter 4 The above actions that were taken by RCU before the cancellation of NICS greatly mitigated the potential negative impact of its cancellation by achieving two goals. First, RCU managed to minimize the financial loss by canceling the lease before the third payment. Given that the street value of the system was estimated to be less than $50 thousand while the amount of the third and fourth lease payments was almost $2 million, these actions allowed the university to avoid making the last two payments conserving a significant amount of financial resources. Second, the introduction of the new, alternative UNIX service contributed to the smooth transition from the NICS system to the lower cost, RISC-based service. This lowered the impact that the eventual decommission of NICS had on the user community. As these positive effects of the pre-crisis preparation efforts, it is clear that the above actions contributed to softening (if not completely eliminating) the blow created by the abandonment of NICS. The positive relationship between the preparation efforts and the low impact of the crisis is consistent with hypothesis three. 4.1.3.2.1 Escalation of Commitment in the NICS project Initially, the senior administration of the university strongly supported the NICS project. It was clear to all participants that the administration was highly committed to IBM's proposal despite warnings from both UCC staff and users. A UCC staff member illustrates this sentiment in the following comment: IBM's proposal was not included in the short list of the selection committee, let 186 Chapter 4 alone be the top choice. Certainly the opinion of most of us was that [the selection of IBM's proposal] was a decision that made at very high levels at the university for political reasons that had to do nothing whatever with the technical suitability of the solution but had do to with a relationship with IBM. That remains my opinion to this day. Due to the de-escalation events described in the previous sections, in response to the early warning signs, the administration acknowledged the existence of the problems and did not escalate its commitment to the project. In fact, the senior administrators were highly supportive of and involved with the pre-crisis preparation efforts. This finding is consistent with hypothesis four, which posits that lower levels of commitment during the pre-crisis stages are more likely to lead to a crisis preparation effort. As pointed earlier, among the factors that significantly contributed to the de-escalation of commitment in this case are the de-escalation effects of the arrival of the new managers and the lowered importance of NICS and the university's relationship with IBM. As the pre-crisis events indicate, both the AVP and the new associate director of UCC were very proactive in carefully examining the early warning signs and taking a number of steps to prepare for the cancellation of the system. One of these newly hired managers commented on the effects of his late arrival in the project: I think I personally learned a lot from this whole experience. I didn't have anything at stake going into the project. I was involved in the administrative side as the system was being launched. I got inserted into the process directly when I was hired for [this] position. So, I think my perception and outlook was probably quite a bit different than those of other people because I didn't have any emotional stake in the process up to that point. I think I was able to take a step back and look at the meta-issues and try to direct it from there. And I don't know if I would have been able to do that if I was as emotionally tied to the project as some of the other people were. 187 Chapter 4 The evidence in the RCU case indicates that during the early stages of the project, when its importance to the relationship with IBM was relatively significant, the senior management commitment to it was also high. However as the perceived importance of the system and relationship decreased during the life of the project, its commitment was also lowered. This positive association between the importance of the system and the managers' escalating commitment is consistent with hypothesis five. The following comment by an involved administrator clearly illustrates this relationship between these two constructs: Initially, the president and many others thought that it would be very good to have a supercomputing facility here. In fact, most of them believed that it was the only way to get access to intensive computing and felt that IBM was really helping the university in that respect. As more and more of them realized that smaller, less expensive machines could offer similar services, their support to the project decreased. They tuned into the fact that there were other ways to get the same results with cheaper machines. Having a large mainframe to do the intensive computing wasn't necessary, or even recommended, all of a sudden. I think this realization made them change their attitude towards the future of this project. 4.1.3.2.2. Whistle-blowing in the NICS project Even though a number of participants strongly opposed the project, there is very little evidence of whistle-blowing in this project. In fact, the interviews identified only one UCC employee and no users who engaged in whistle-blowing.16 Based on the accounts of a number of participants, this individual expressed his opposition to this project to a senior administrator of the university, who unfavorably responded to it using threats. Even 1 6 Even though th is employee has left UCC, he was contacted and asked to part ic ipate i n th is study. He refused to do so ind icat ing tha t he was unfa i r ly t reated by RCU's administ rators dur ing th is and other projects. 188 Chapter 4 though this was an isolated incident, it contradicts hypothesis six, which assumes that whistle-blowing has a positive effect on the initiation of pre-crisis preparations. The apparent low level of whistle-blowing in this case was caused by a number of factors. The first factor relates to the quality of negative information during the selection process. At the time, the information that existed about the potential troubles of NICS was ambiguous. Changes in the computing technology and end-user preferences were not clearly identifiable so it was very difficult for the opponents of the solution to decisively demonstrate that the project was not going to succeed. According to the literature, such lack of unequivocal negative evidence makes whistle-blowing less likely to be effective and thus less likely to be pursued (Near and Miceli, 1996). Another contributing factors was the relatively low seriousness of the potential failure risk to the whole university. Given that the project was not viewed (by most members of the university community) as a critical aspect of RCU's operations, many of them did not consider its troubles significant enough to do something about it. One UCC employee describes this attitude, which is the main motivator behind hypothesis seven: Although IPAS was a major project, it wasn't important enough for people to fight against it. We knew that eventually the administration would have had to do something about its economic condition, but we were not too worried about it because we focused our energy on making sure that the users were protected from its troubles. Because of the relative low seriousness of the project's troubles to the whole university community, it seems that the UCC supported its implementation instead of continue to 189 Chapter 4 fight it. This behavior, which further suppressed the possibility of whistle-blowing is described in the following comment: Once the decision was made it was our baby. And it doesn't matter if you don't like the baby to begin with, you still have to work with what you have, you still have to offer the services based on resources we have. So I think we took the point of view of doing everything we possibly could to make that system work. We worked with IBM in solving a whole number of technical issues that contributed to IBM's getting the product out to the marketplace faster than they would have without our people. A third factor that contributed to the lack of whistle-blowing was the visible support that the university administrators afforded to the IBM proposal. This level of senior support, coupled with the weak political position of many UCC staff members, which according to Near and Miceli (1996) has a mitigating effect on whistle-blowing, made it very difficult for them to have their opinions considered. Many accounts by UCC personnel indeed indicate that despite a number of attempts to raise their concerns (within the established reporting channels), they concerns were not validated and, at times, their expression was forcefully suppressed. According to their accounts, this had a suppressing effect on their willingness to voice their concerns by bypassing the established reporting channels. This evidence is consistent with hypothesis eight and is supported by the following comments by UCC staff describing their efforts and the silencing effects of the administrators' behavior: I have a vague memory of in fact being told that [our concerns] was not something we should raise as an issue. I was told that the politics would have been very much against us and we'd have just looked negative and refusing to cooperate and we'd have been fighting senior management that was determined to see this project through to the end. I'm not sure how this project has affected my propensity to voice my opinion. You know you've made a pretty strong stand if you've gone to the point of where you're been told to shut up. Essentially, it was \"if you don't like it, quit.\" That's what we were told. 190 Chapter 4 It didn't do any good saying that we had problems with this system because the decisions were made outside UCC. I don't think any of us had the ear of the president' office. Those of us who said things developed the reputation for being troublemakers. A couple of technical people who had said things at the VP's level were at the point where they were being shut out. They had the reputation as being negative towards IBM and therefore anything said was not being taken seriously. People were basically jeopardizing their own careers by arguing levels about the UCC director. In fact, both of these individuals left UCC because of they way they were treated by the administration. I might have written a recommendation to buy this machine, but it was not genuine. It wouldn't mean that I agreed with the recommendation I might have written. Why would I write such recommendation you may ask. Why do you think? Because I was told to. There's quite a difference working as a staff member on this campus and working as an academic. The idea of academic freedom does not extend down to staff members. We felt that the management of UCC was not representing our point of view. They were just basically doing what they were told by the president's office. Most of us were not convinced that the management of the computing center made any significant attempt to argue our position. They basically were playing the \"yes man\" role there. That was my impression. I can look at this from a distance and say \"if they'd have argued all it would have done is wreck their careers\" and maybe that's the case but I don't really know. 4.1.3.3 NICS Crisis Stage Due to the fact of that the failure of NICS was proactively managed by RCU, the impact of its cancellation was relatively inconsequential for RCU. As one participant succinctly put it, \"it sunk without a ripple.\" As a result, there was not a significant pressure for RCU to engage in intensive crisis response efforts. Indeed, the evidence shows that RCU did not engage in any substantial crisis response efforts nor did it allocated substantial resources to manage the abandonment of NICS. It simply let UCC manage the cancellation of the 191 Chapter 4 system and the transition of the users from NICS to the already installed Unix service. This modest level of RCU's crisis management efforts is consistent with hypothesis nine. 4.1.3.3.1 Operational Crisis Management After RCU secured the agreement of IBM to return the system, its main concern was to ensure that the involved users were not adversely affected by the decommission of the computer. Specifically, it wanted to ensure that (1) the existing users of NICS could easily transfer their work to other services and (2) future interested researchers would have easy access to an intensive computing facility. To address these two issues, the administration of UCC took a number of actions to in order to fully understand the needs of the affected the users and expand its Unix services before the actual abandonment of NICS. To examine the needs of the remaining NICS users (as many of them proactively moved their accounts to the new Unix service), an associate director of UCC interviewed all of them and summarized their responses in a report. Based on the information that was collected, the UCC staff assisted each user in identifying alternative services and transferring their data and programs to the new services. In most cases, this simply meant transferring them to the new Unix service; in a few others, the staff helped the users transfer the programs and data files to individually acquired workstations. According to a UCC manager this transition was successfully completed before the abandonment of NICS, contributing to the inconsequential impact of its cancellation: We were very careful to look at the whole situation from the users' point of view. At the time we began looking at replacements we had probably between 15 and 20 major users of the system. What we did is we went out to those users and we did a 192 Chapter 4 survey looking at their current needs, their future needs, their dependence on NICS. And we looked at the sources of funding they had because of course the funding model was important as well. Quite frankly when the system did go out very few people noticed. We involved the users very early in the process, they were aware of what we were doing. They were interested in cheap cycles. Incidentally, the transition to the new services was welcome by users: When we informally announced the cancellation and our transition plans to the users, there was a collective sigh of relief. It was widely supported by pretty near everybody. There were some minor internal politics issues as there was a desired by one academic unit to run its own numerical analysis service and offer it to other units, but we said \"no, it's more appropriate to use the structure we have to do this rather than build compartmentalized services.\" Other that that, the transition was very smooth and greatly supported by the users. Interestingly, one participant pointed out that this trouble-free transition from NICS was significantly facilitated by its earlier troubles! Because of the initial lack of user buy-in and software bugs, very few users became \"attached\" to the service: We basically went out of our way to ensure that every NICS users received access to comparable, if not better, service. There were other legacy systems that we had the worst time with some users being moved off them. But, not in this case. There was no noise. I have an opinion on why that was so. I don't know whether it's helpful or not, but I think it goes back to the original decision of buying the machine. Many of the users wanted a different machine. I believe that if we had gone with the kind of machine they wanted, it may have been more difficult to get out of it. Also, given the slow start up due to the difficulties with AIX, I have a feeling there was not a great buy-in on the part of the users. To address the second issue, the need for additional capacity for Unix services, the scope of the user-needs study was enlarged to include an assessment of their future needs as wed. After conducting interviews with a number of users, the associate director proposed four possible configurations that would allow UCC to expand its existing Unix service. After receiving the approval of senior administrators, UCC acquired a number of RISC 193 Chapter 4 computers costing about $600 thousand and providing over ten times the computing power of NICS. Incidentally, the formal announcement of the additional Unix services and the abandonment of NICS were announced in the same issue of UCC's newsletter. 4.1.3.3.2 Legitimacy Crisis Management Consistent with hypothesis ten which posits that an organization's response to a small ISD crisis will primarily focus on its operational impacts, RCU engaged in no notable legitimacy restoration tactics during the NICS crisis. As the university managed to contain the impacts of the crisis and the news about the cancellation of NICS within its community, there was no threat against its external image, and thus no strong pressure to engage in such tactics. The only threat concerning external stakeholders was the potential impact on the relationship with IBM. However, as the quotes from the IBM managers in the early parts of this section indicate, the cancellation of NICS had no significant adverse effect on IBM's relationship with RCU. Despite this, two minor efforts were undertaken to address this potential threat. Firstly, the administration of the university on a number of times ensured, both verbally and in writing, that the new Unix service was not \"similar in scope or function\" to the NICS service. By offering such accounts, the administrations conveyed the idea that RCU was not merely replacing NICS for a cheaper alternative, but rather introducing a new type of service that was made possible through advancements in hardware technology. Secondly, UCC acquired one RISC computer from IBM as part of its Unix capacity expansion plans. An involved manager commented on the significance of this purchase: 194 Chapter 4 We included a RISC RS6000 system from IBM in our capacity study report. Even though it was not necessary, it was part of the political aspects of the process. In a sense, we wanted to show that we didn't cut them out. It could have been a Sun system or a Silicon Graphics system but the purchase of the RS6000 says to them 'you are not out of the game. It's not IBM that we are throwing out when we throw out NICS, just the mainframe style of computing.' So, that was a zero cost option as it took into account the political realities of the situation. 4.1.3.4 NICS Post-crisis Stage According to the participants, no organizational adaptation or learning took place as a result of this crisis. The evidence about the facts in the case also corroborates the lack of change in organizational routines. Despite the apparent lack of formal organizational learning, a few senior- administrators indicated that some individual, informal learning took place. However, as the following account by one such administrator indicates, such learning was not persistent: I don't think much has changed here, except perhaps the way we structure our contracts with external organizations. I would like to believe that there has been a change in the view that you do not sign away your rights on a long-term basis. Because of the way we dealt with IBM, we are very reluctant to get into long term deals with outside people. But, now that I think about it, history proves me wrong. We just signed a long-term contract with Pepsi. And there are some others. I guess, we didn't learn much. UCC staff members verified the lack of learning as well. The following comment by one of them suggests that RCU is actually repeating some of the same errors it made in the NICS project: We have another project underway that has all the external manifestations of this particular project. This is another mainframe migration project. It was initiated by senior management as a directive to the academic units of campus. It told the units to come up with alternative services because a major mainframe service would be turned off in the near future. UCC initially was going to respond. They were told 195 Chapter 4 not to at one point. They ended up responding anyway now they are partners with an external vendor in this project. The external vendor is driving the project and our technical people are being ignored again. So, I see the potential for this happening all over again and again. So, it appears that the senior administration didn't learn from the project al all. Even thought the cancellation of NICS was not consequential enough to have an effect on organizational learning, it appears that it had a significant rigidity effect on UCC. A number of respondents identified a number of changes in the decision-making, communication, and daily interactions of UCC that are indicative of an increased formalization. Many of these changes related to the negative impact that the cancellation of the service had on the already rocky relationship between the UCC staff and senior administration: This project had a big impact on the morale of the technical people whose professional opinions were ignored by the university. In fact the cost to the university is more in the technical expertise that they lost as a result of this project rather than the dollar cost. People left UCC because they felt that were not treated professionally. And those that remained isolated themselves from the administration. Basically, this significantly widened the rift between the technical people and the president's office. As a result of this negative effect on UCC's morale and relationship with the rest of the university, a number of threat-rigidity manifestations took place following the NICS crisis. These included the following: \u00E2\u0080\u00A2 Further lowering of the political status of UCC lessening its ability to influence key IT-related high-level decisions. The following comments illustrates the problems associated with this lowered status: I still don't think the administration have a clear understanding of the implications 196 Chapter 4 of computer technology. They are still relying on vendors for information about what we should be doing before they rely on information from the technical people here. And that's a tough issue to rectify because anything we say is perceived as self-serving. It's sort of unfortunate that the president's office will rely on and believe in information outside its organization before it relies on information from inside. And this trend has had a tremendous negative effect on the overall attitude of the UCC staff. \u00E2\u0080\u00A2 Increased internal cohesiveness of the UCC group. Even though the NICS crisis increased the closeness of the UCC group (the \"in-group\"), it contributed to an adversarial attitude towards the administration (the \"out-group\"). This manifestation of rigidity was explained by one UCC staff member: I think the UCC group became a more cohesive group as a result of this experience. It became more cohesive internally but more separate from the rest of the university. They are wdling to help and support each other but not as willing to put long hours for the university. In general, this thing brought people together in that there was a common enemy, the president's office. It didn't improve morale but brought people closer together. \u00E2\u0080\u00A2 A reluctance to make decisions. As a UCC manager pointed out, A major difference that I noticed since this project is a reluctance to make decisions. Essentially the staff has to be wary of any decisions they make because of the fact that the president's office or anybody along the line from the president's office on down is more likely to intercede and reverse it. And that's happened time and time again. At one point, UCC was going to open a student computer lab in the facility across the street. It was well planned and justified. It was clearly their domain, they expected great demand and expected to fully cost recover it. The week it was supposed to open, a senior manager told them that they couldn't do that! This goes to show you why most of them are not wdling to make significant decisions anymore. They simply don't feel that their decisions wdl have any impact anyway. \u00E2\u0080\u00A2 An increased attention to political issues. As a UCC staff member indicates, even though this change was, in his opinion, essential it restricted decision-making: The NICS project made us realize that we must take into account the political environment and dynamics at the university whenever making a decision, 197 Chapter 4 formulating a plan, or presenting a proposal outside our group. The political landscape became important to us. Even though it allows us to present our ideas and decisions in a more politically correct way it distracts us from focusing on our expertise which is technical decision making. \u00E2\u0080\u00A2 Increased formality in decision-making situations. The following comments is representative of a number of accounts focusing on this noticeable change: My own feeling is that there is a tendency to \"cover your ass\" here. There is a tendency to do all sorts of things that we didn't use to before. It certainly related to a reduced feeling of security. As a result, there are few more things down in memos that wouldn't have been put down in memos previously. A little less trusting of the verbal conversations between folks. Not internally, but definitely in our interactions with other departments. \u00E2\u0080\u00A2 Increased amount of bureaucratic processes and decreased personal discretion. A staff member commented on this change and its effect on his work: I noticed that there was a higher degree of formal meetings and other bureaucratic stuff. Basically, it was \"we're going to meet once a week and review this and this and this and we're going to talk over the same set of problems every week.\" This made it very difficult to focus on technical stuff such as work on computer projects. Everything had to be discussed over and over again before it was approved. As the above evidence clearly indicates UCC has indeed experienced a rigidity effect as a result of this crisis. In summary, even though the impact of the NICS crisis was not severe enough to induce organizational learning, it had significant threat-rigidity effects on the operations and relationships of the UCC staff making future adaptation and experimentation less probable. This finding is consistent with hypothesis eleven. 198 Chapter 4 4.1.3.5 Summary of RCU Case Findings The case evidence indicates that RCU was highly successful in promptly detecting the impeding failure of NICS and taking appropriate actions to proactively manage it. This early awareness and subsequent pre-crisis preparation was greatly facilitated by the relatively low importance of the project, the arrival of two new key decision-makers, and the existence of clear evidence indicating its poor performance and profitability. Due to the intense pre-crisis efforts of RCU, the university managed to almost eliminate the impact of the cancellation. As a result, the management of its post-crisis period was relatively straightforward and did not require substantial effort or resources. Despite the early success of RCU in managing the NICS crisis, the evidence indicates that it failed to effectively manage its long-term rigidity effects. The case findings indicate that (1) some of the same mistakes were being repeated as no changes in the operations and organizational routines of the university took place and (2) the NICS crisis had a significant impact on the morale of the UCC staff. More importantly, the lack of appropriate learning had an adverse effect on UCC's decision-making and adaptation abilities due to a number of threat-rigidity behaviors. A summary of these main case events that took place during the stages of the NICS crisis is shown in Table 4-10. 199 Chapter 4 Table 4-10: Case Dynamics Matrix of the IS [ICS Project Stage A n t e c e d e n t s E v e n t s O u t c o m e s P r e -c r i s i s Despite the project's low overal l importance, strong support by senior managers leads to the in i t i a t i on of the project The de-escalation effects of the h i r i ng of new managers and the presence of unambiguous negative in format ion lead to an intense pre-crisis preparat ion effort R C U was wel l -prepared for the cancellat ion of the NICS and the t rans i t ion of affected users C r i s i s The wel l -managed cancellat ion of NICS had no signi f icant impact on the operations or image of the univers i ty The crisis response efforts are extremely l im i ted and simply focused on the conclusion of the t rans i t ion p lan and the expansion of the new service The impact of the crisis was wel l-contained w i t h i n the univers i ty and required l i t t le post-crisis efforts to be successful Pos t -c r i s i s The low impact of the crisis fai ls to establish a need for organizat ional change Even though the univers i ty d id not engage i n organizat ional adaptat ion, the NICS crisis had negative impact on the morale and relat ionships of R C U leading to a r ig id i ty effect The heighten formal i ty and r ig id i ty makes i t di f f icul t to adapt and experiment; some sings show that R C U is repeat ing some of the same mistakes 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-11. 200 Chapter 4 Table 4-11: Summary of Hypothesis Assessment in the RCU 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 None; the project was moderately impor tan t to RCU, but i ts abandonment had no signi f icant impact 2 Fai lure control labi l i ty w i l l lead to greater ISD crisis impact Positive; Bo th the control labi l i ty and the magni tude of the NICS crisis were low 3 Pre-crisis preparat ion w i l l lead to lower ISD crisis impact Positive; R C U intensive pre-crisis efforts contr ibuted to avoiding the mater ia l izat ion of a fa i lure and prepared the univers i ty to better manage i t 4 Managers' commitment to the project w i l l lead to lower pre-crisis preparat ion Positive; the lack of escalation of commitment contr ibuted to the fac i l i ta t ion of the pre-crisis efforts 5 Project importance w i l l lead to greater commitment to the project Positive; in i t ia l l y both importance and commitment were h igh; subsequently, the lowered importance of the I B M systems due to the in t roduct ion of new technologies contr ibuted to a de-escalation effect 6 Whist le-b lowing w i l l lead to greater pre-crisis preparat ion None; there is no evidence support ing tha t whist le-blowing contr ibuted to the in i t i a t ion of pre-crisis preparat ions 7 Project importance w i l l lead to greater whist le-b lowing Positive; both the project's importance and whist le-blowing were relat ively moderate i n N ICS i 8 Managers' commitment w i l l lead to lower whist le-b lowing Positive; the i n i t i a l h igh commi tment of managers had a discouraging effect on potent ia l whist le-blowers 9 ISD crisis impact w i l l lead to greater crisis management Positive; The intensi ty of the crisis response was low as both the operat ional and legi t imacy impacts of the cancellation were inconsequential 10 H i g h ISD crisis impact w i l l lead to both operat ional and legit imacy crisis management Positive; R C U made no signi f icant at tempts to restore i ts image given tha t the crisis impact was not major 11 ISD crisis impact w i l l lead to greater post-crisis organizational learning Positive; the smal l impact of the cancellation contr ibuted to the r ig id i ty of UCC operations and fai led to create a need for visible organizat ional change 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 than one data point and w i l l be examined i n the between-case analysis 201 Chapter 4 4.2 BETWEEN-CASE FINDINGS The previous sections in this chapter summarized the empirical findings related to the hypotheses and constructs of interest. This section will further assess the hypotheses by contrasting the behaviors and variables in the three cases. Unquestionably, the within-case findings indicate that the behaviors in the cases differ significantly (i.e. the cases do not represent literal replications). For example, in the NU case, the organization failed to prepare for the crisis and had to spend enormous resources to manage its impact and ensure that the organization learned from it. In the GVH case, the organization took a number of actions to manage the pre-crisis stage of the IPACS project. Despite this, the hospital never fully completed the planned systems. In the RCU case, the university was quite successful in avoiding the materialization of a consequential crisis by proactively managing the pre-crisis and crisis stages. Unfortunately, the successful response of RCU to the crisis ceased before the long-term effects of the crisis, such as a lowered morale and increased rigidity, were adequately addressed. Despite the apparent lack of uniformity in the organizational responses and the impacts of the crises, this section will demonstrate that these inter-case differences are due to theoretically predictable reasons. The cross-case comparisons indicate that the cases represent theoretical replications and thus further strengthen the arguments about the generalizability of the hypotheses and the applicability of the crisis-management perspective to the study of ISD failures. 202 4.2.1 Crisis Impact Chapter 4 Hypothesis one indicates that projects of high importance will lead to greater ISD crises. The findings in the NU case provide empirical support to this conjecture. In that case, the significance of the IMIS project was consequential and so was the impact of its failure (see Table 4-12 for a summary of the constructs of interests). The findings in the GVH and RCU cases, however, seem to contradict the hypothesized positive relationship between the project's importance and the impact of its failure. In the GVH case, even though IPACS was an important project for the hospital, its abandonment did not lead to major consequences. Even though the IPACS project was larger in size (both in absolute and relative terms), and as significant, in scope and political value, as the IMIS project (in the NU case), the magnitude of its impact on the operations and image of GVH was significantly lower than that of the IMIS crisis. Similarly, despite the moderate importance of the NICS project, RCU suffered virtually no negative impact as a result of its cancellation. Overall, it appears that in both GVH and RCU, the actual impacts of the failure were significantly lower than the hypothesized ones. Despite these seemingly conflicting empirical results, the findings about the pre-crisis preparation efforts of these organizations provide a helpful explanation for this inconsistency. Even though I originally anticipated (as part of hypothesis three) that the level of pre-crisis preparation will have a positive, direct effect on the impact of the crisis, the findings indicate that the pre-crisis preparation efforts may have a moderating effect. 203 s 2 i -B . I i \u00E2\u0080\u00A2\u00E2\u0080\u00A2B .3 : g \u00C2\u00A3 : & \u00C2\u00B0i 1 co cu CD ^ c e . * s i | I .2 o 7 3 \u00E2\u0080\u0094' CU 0) 1 CO X I CO ~ P -o 3 .5? S3 S .5? \u00C2\u00A7 5 a .s a f +J co c a a S 3 a a ^ CD o 13 tJ \u00C2\u00A3 3 CD T 3 I I co s a aj CD 2 I o \u00C2\u00B0 \u00C2\u00AB & O CO ts S s g CO a -a -C^-( CO 3 3 \u00C2\u00AB 5 -\u00C2\u00B0 a \u00C2\u00A7 S a a B -2 S o . \" to 'ZX o. o a \u00C2\u00BB 8 cu ^ cu co >> 7 3 .-a c 7 3 CO '3J CU 0) - H 9 > ~ 2 \u00C2\u00BB CD a o o O o u -3 CU: T3 CU u CU o i 73 O 7 3 a CO a j> s a \u00E2\u0080\u00A2\"3 a 'v z -2 a a cu 7 3 co o > a \"S CD tyj io O 6 5 to ai l o ^ '3 13 ^ a >. s .CU X a co ft 2 i a CJ s .a ; 3 9 3 . 3 _cu \u00E2\u0080\u00A29 \u00E2\u0080\u00A2\u00C2\u00AB \"3. 3 \"2 \" HH CO CO s a S g \u00C2\u00AB ?, g a Z 3 3 a g a w P ft &0 cu a a. s c \"2 co co cu t)0 > . CO O 8 2 \u00E2\u0080\u009E J3 S ft M ci cu X ft ^ a g co rr, a g CO ho cu .2, + J x .a CO +J a \u00C2\u00AB \u00E2\u0080\u00A2Si s -t-\u00C2\u00BB Q> CO 2 \u00C2\u00AB 5 a 7 3 7 3 CU CU \u00E2\u0080\u00A2? \"S 3 ts ~ > g a a s \u00E2\u0080\u00A2g \" = S .2 .9 co \u00C2\u00A32 a o cyj ^ ft 1 1 CU CO S 3 CO J a m CO I I 111 CU * 3 t l \u00C2\u00AB3 o O a o a 3 S \u00C2\u00A7 4) S -S '5 s a .2 * to OCO M a .2 a a 7 3 h M S Chapter 4 In other words, I believe that appropriate preparations efforts mitigate the impact of the crisis by deducing its potential negative consequences. The findings strongly support this modified hypothesis. In the case of the two major projects (IMIS and IPACS), the imminent failure of one of them (IPACS) was promptly detected and benefited from a number of pre-crisis preparation efforts avoiding any adverse effects on the operations of the hospital. In the NU case, the signs of fairing IMIS project remained undetected leading to the serious impairment of many internal operations and a visible public failure. The hypothesized mitigating effects of pre-crisis preparation were also clearly evident in the RCU case, where the well-planned and executed cancellation of the service had no adverse effects on the user community. Based on these findings, I believe that there is an interaction effect between project importance and pre-crisis preparation on the eventual impact of the ISD crisis (see figure 4-4). Consequential failing projects that remain undetected and do not benefit from pre-crisis preparation efforts will lead to major crises (such as the one found in the NU case). Conversely, major projects (such as IPACS and NICS) whose early warning signs are promptly detected allowing them to benefit from timely pre-crisis preparation efforts are less likely to turn into such major crises. Based on this interaction effect, I conclude that the cross-case analysis provides additional support to hypothesis one while necessitating the revision of hypothesis three as follows: Hypothesis 3: Pre-crisis preparation will negatively moderate the relationship between project importance and ISD crisis impact. 205 Chapter 4 Figure 4-4: Interaction between Project Importance and Pre-crisis Preparation Impact N U High G V H Low R C U # Mod. Importance \u00E2\u0080\u00A2 Pre-crisis preparation Low High This finding is consistent with empirical findings in the CM literature (Meyers and Holusha, 1986; Fink, 1986; Smith, 1990; Banerjee and Gillespie, 1994; Pearson and Clair, 1998) and the, somewhat limited, existing empirical literature on IS failures. Both case (Flowers, 1996) and survey (Ewusi-Mensah and Przasnyski, 1991) studies clearly indicate the positive relationship between project importance and the magnitude of the crisis. Also, Jones (1996, p. xxvii) has implicitly identified this moderating effect of pre-crisis preparation by simply stating that \"early recovery of the problem [in IS development] leads to a higher recovery rate.\" Hypothesis two posits that the impact of an ISD crisis is also influenced by the apparent controllability of the failure. The case findings consistently follow this hypothesized pattern. In both cases of crises with serious impacts (NU and GVH), the evidence suggests that the involved organizations bear some responsibility for failing to take preventive 206 Chapter 4 actions, as they were able to do so given that the failures were foreseeable and (at least partially) controllable. Conversely, in the case of RCU, where the cause of the failure was attributed to unmanageable, external factors, the eventual impact of the failure (and its negative effect on the image of the organization, in particular) was inconsequential. This clear pattern of the positive association between the two constructs, controllability and impact, across the three cases provides additional support to hypothesis two. This pattern is consistent with related OB literature (Schlenker, 1980; Staw et al., 1981; Pearson and Clair, 1988) and the evidence presented in a number of public IS failure cases (cf. Flowers, 1996). 4.2.2 Pre-crisis Stage The first pre-crisis behavior that was investigated in this research project was the commitment of senior managers to the failing projects. The case findings uniformly support hypothesis four, which proposes that high levels of commitment will make pre-crisis preparation efforts less likely to take place. Interestingly, the initial commitment of senior management teams was high in all three cases. However, these initial high levels of commitment did not remain constant throughout the projects. In the NU case, the management's commitment continued to escalate until well after the failed conversion of the systems. This prolonged denial did not allow NU to acknowledge the crisis and thus it did not take any efforts to prepare for it. In the other two cases, the high levels of commitment were negatively impacted by the arrival of previously uninvolved, 207 Chapter 4 uncommitted decision-makers. Due to the deescalating effects of these arrivals, the commitment and strong support of senior managers was reduced enabling the organizations to take appropriate actions to manage the upcoming crises. A cross-case of the findings indicates that lower levels of escalating commitment are associated with pre-crisis preparation, while higher levels of commitment prevented organizations from undertaking such preparation. Based on the between-case comparison, the findings provide further support for hypothesis four. Hypothesis five suggests that a factor that significantly influences the escalation of commitment in a failing project is its perceived importance. The case findings are consistent with this conjecture. In the two cases of the high importance projects (IMIS and IPACS), the commitment of the involved managers escalated for a prolonged period before an acknowledgment of the projects' problems took place. In the RCU case (where the overall importance of the project was less significant), the initial period of high level of commitment was significantly shorter (and after it the level of commitment did not escalate). In addition to the arrival of the new-decision makers (which also happened in the GVH case), unambiguous evidence and the shrinking importance of the project blocked potential escalation at RCU. In sum, the evidence in the three cases studies and the cross-case analysis provide significant support for escalation of commitment assumptions, including the de-escalation effects of the introduction of uncommitted decision-makers (Staw and Ross, 1987). These 208 Chapter 4 empirical findings are consistent with CM (cf. Meyers and Holusha, 1986; Dutton and Jackson, 1987; Peason and Clair, 1998), the escalation of commitment literature (Staw and Ross, 1987; 1993; Brockner, 1992) and recent empirical work on escalating commitment in MIS (Keil, 1994; Keil, 1995). Also, the evidence about the de-escalation effects of new decision-makers is consistent with Keil (1995)'s findings. The second pre-crisis behavior that was investigated in this research project was whistle-blowing by non-management employees. According to hypothesis six, it was anticipated that such behavior would make the undertaking of pre-crisis preparation efforts more likely by identifying key problems in the project and contributing to the de-escalation of management's commitment. The empirical findings failed to support this hypothesis indicating that whistle-blowing was not effective. Even though multiple whistle-blowing attempts took place in all three projects, in no case did they have a positive effect on the initiation of the preparation efforts. Near and Miceli (1995) utilized resource dependence (Pfeffer and Salancik, 1978) arguments to provide an explanation for such ineffective whistle-blowing attempts. They indicate that an organization is less likely to positively respond to whistle-blowing attempts when it perceives the action under attack by the whistle-blowers (i.e., the continuation of the project) as important and beneficial to its goals. Indeed, the lack of a significant relationship between whistle-blowing and crisis preparation can be explained by the attitudes and behaviors of the senior managers in the cases (which clearly indicate that they thought the projects were important for their organizations) and their unfavorable responses to whistle-blowing. The findings related to escalation of commitment clearly 209 Chapter 4 support such an explanation. Near and Miceli (1995) also argue that the likelihood of successful whistle-blowing is further reduced by ambiguous evidence. Based on this study's findings, this seems to be an important factor in IS projects as well, as the early warning evidence that exists in the initial stages of failing IS projects tend to be intangible and difficult to interpret. As the evidence shows, some managers indicated that they had difficulty ascertaining whether user complaints were reflective of a temporary negative attitude or a more serious problem. I suspect that this ambiguity in early warning sings contributes to making ISD projects ineffective targets for whistle-blowing. According to hypothesis seven, I anticipated that in cases of projects of high importance, whistle-blowing behaviors are more likely to take place because of the potentially serious repercussions of the failure to the organizations. The within-case findings are consistent with the hypothesized positive relationship between the project's importance and the likelihood that whistle-blowing will take place. In both cases of high importance projects (NU and GVH), there was evidence of intense whistle-blowing efforts. In the RCU case, where the project importance was less significant the intensity of such efforts was also more contained. This cross-case pattern provides additional support to the hypothesis and is consistent with empirical research on whistle-blowing in organizations (Miceli and Near, 1985; Victor et al., 1993; Dworkin and Baucus, 1995). Hypothesis eight attempted to empirically assess the linkage between whistle-blowing and escalating commitment constructs. The hypothesis posits that escalating commitment will 210 Chapter 4 . have a suppressing effect on the undertaking of whistle-blowing. The accounts in within-case findings clearly indicate that the attitudes and behaviors of (over)committed managers had a discouraging effect on potential whistle-blowing. Even though the initial high commitment displayed in the cases did not prevent whistle-blowing from taking place altogether, the evidence consistently shows that behaviors motivated by the high commitment (such as \"labeling\") had a suppressing effect on subsequent whistle-blowing behavior. A comparison between the levels of commitment and whistle-blowing in the three cases indicates that whistle-blowing was high (despite the high initial levels of commitment) in both the NU and GVH cases. Moreover, in the RCU case, both commitment and whistle-blowing were low. This comparison is inconsistent with hypothesis eight. Even though it does not directly support the hypothesized relationship, I suspect that this unexpected finding in the cross-case analysis is due to the simultaneous enhancing effect of project importance (which appears to exert greater influence than that of managers' commitment). Further empirical investigation is needed to tease out the effects of commitment and importance on whistle-blowing. 4.2.3 Crisis Stage Hypothesis nine suggests that a positive association exists between the impact of the crisis and the intensity of the organizational response to it. The case findings clearly support this proposed relationship. In the NU case, where the IMIS crisis had major consequences on the operations and image of the organization, a number of tactics were pursued to 211 Chapter 4 manage both the operational and legitimacy impacts. These tactics included, a project audit study, hiring of consultants, two recovery projects, implementation of manual systems to address the needs of affected operations and a number of image restoration efforts. In fact, the financial resources that were allocated to manage the crisis exceeded the cost of the IPACS project itself. In the GVH case, where the effect of the crisis was less severe, the response of the hospital was more contained. In addition to the completion of an audit study, the response simply focused on the implementation of the planned applications without allocating any additional resources to manage these post-crisis efforts (leading to the incomplete status of a number of applications). In the RCU case, both the impact and the response of the university were significantly more modest than those in the other two cases. A cross-case comparison clearly supports the hypothesized relationship between the crisis impact and the magnitude of the organizational response. This finding is congruent with both CM arguments and the results of earlier case studies (Kanter, 1983; Fink, 1986; Meyers and Holusha, 1986; Dutton and Jackson, 1987; Quarantelli, 1988; Smith, 1990; Booth, 1993) and Dutton (1986)'s findings. Hypothesis ten indicates that because larger crises are more threatening to the image of the involved organizations, they are more likely to lead to the implementation of both operational and legitimacy restoration tactics. Indeed, in the two cases where the impacts of the crises were relatively significant and imposed a threat to the external images of the involved organizations (NU and GVH), the organizational responses included both types of crisis management tactics. As expected, these tactics were targeted towards the affected 212 Chapter 4 \u00E2\u0080\u00A2 external stakeholders and their intensity was relative to the legitimacy threat. In the third case, the threat to the credibility of the organization (RCU) was negligible and thus no major legitimacy restoration efforts were pursued. In summary, both the within-case findings and between-case comparisons provide support for hypothesis ten and are consistent with arguments made by CM researchers (Meyers and Holusha, 1986; Smith, 1990; Pearson and Clair, 1998). 4.2.4 Post-Crisis Stage Hypothesis eleven allowed the empirical investigation of competing arguments between the failure-induced learning and threat-rigidity theories. The findings clearly reject the threat-rigidity conjectures and provide considerable support to failure-induced learning arguments. In the case of NU, where the impact of the crisis was consequential, a number of changes in the organizational routines and decision-making structure took place, reflecting the lessons that were learnt during the crisis. In fact, the evidence shows that some of the newly acquired knowledge was successfully applied in the implementation of the recovery projects. In the other two cases (GVH and RCU), where the crisis impact was less significant, so were the changes in organizational routines. The findings on rigidity effects demonstrate the exact opposite trend. Both the case findings and the between-case contrast show that the higher the impact of the crisis, the more likely that the involved organizations will pursue organizational adaptation and the less likely that it will engage in threat-rigidity behaviors. This finding is consistent with the failure-induced learning 213 Chapter 4 theory (Hedberg, 1981; Miles and Cameron, 1982; McKinleyt, 1984; Sitkin, 1992; Bolton, 1993; Miller, 1994) and contradicts threat-rigidity research (Staw et al., 1981; Cameron et al, 1987; Sutton, 1990; Occasion, 1995). Hypothesis twelve assesses a recent argument by Mone et al. (1998) suggesting that the relationship between the impact of the crisis and organizational adaptation is non-linear. Mone et al. (1998) put forward this argument in an effort to reconsolidate the conflicting findings of empirical studies on crisis-based learning. According to Mone et al. (1998), controllability of the failure is expected to play a moderating effect on the relationship between the crisis impact and organizational adaptation. By comparing the findings in the three cases, I am unable to unambiguously indicate whether such an effect is indeed present. The between-case comparison (see Figure 4-5) indicates that both controllability and crisis impact appear to be linearly related to organizational learning. This finding is consistent with at least two possible explanations. Either the crisis impact acts as a full or partial mediating factor between controllability and learning or controllability indeed moderates the relationship between the crisis impact and learning. Due to the equivocality of this result (cf. James and Brett, 1984; Baron and Kenny, 1986), I find it to be inconclusive. 214 Chapter 4 Figure 4-5: Interaction between Controllability and Impact Learning, High Mod L o w N U High Impact G V H Mod. Impact R C U L o w Impact L o w M o d High Controllability 4.2.5 Summary of Findings A summary of the hypothesis assessment is presented in Table 4-13. Based on this assessment, I present a list of the supported hypothesis (see Table 4-14) and a modified research model (see Figure 4-6). As the findings clearly indicate, the empirical investigation generated extensive evidence that is consistent with most of the hypotheses. This positive assessment provides an initial support to the application of the CM frameworks and concepts to the phenomenon of IS project failures. I find that indeed IS project failures are significant enough to generate crisis-related behaviors and responses and, therefore, the application of CM concepts to their study is both appropriate and useful. 215 Chapter 4 Table 4-13: Summary of Hypotheses Assessment N u m b e r H y p o t h e s i s N U Case G V H Case R C U Case B e t w e e n -case 1 Project importance w i l l lead to greater ISD crisis impact \u00E2\u0080\u00A2 X X T 2 Fai lure control labi l i ty w i l l lead to greater ISD crisis impact \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 3 Pre-crisis preparat ion w i l l lead to lower ISD crisis impact \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 T 4 Managers' commitment to the project w i l l lead to lower pre-crisis preparat ion \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 5 Project importance w i l l lead to greater commi tment to the project \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 6 Whist le-b lowing w i l l lead to greater pre-crisis preparat ion X X X X 7 Project importance w i l l lead to greater whist le-b lowing \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 8 Managers ' commitment w i l l lead to lower whist le-b lowing \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 X 9 ISD crisis impact w i l l lead to greater crisis management \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 10 H i g h ISD crisis impact w i l l lead to both operat ional and legit imacy crisis management \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 11 ISD crisis impact w i l l lead to greater post-crisis organizational learning \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 \u00E2\u0080\u00A2 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 N/A N/A N/A X J = Supported X = Not supported ^ = Interact ion effect A number of patterns emerge from these empirical results (see Table 4-14 and Figure 4-4). Firstly, it appears that managers are significantly affected by escalating commitment to the project making its discontinuation less likely. Eventual discontinuation of escalating commitment is affected by the introduction of uncommitted decision-makers in the process, the increasing presence of unambiguous negative evidence, and the decreasing importance of the project. Secondly, it appears that whistle-blowing is a strategy that is pursued by project team members in ISD failing projects in an effort to curtail the pre-crisis denial. The seriousness of an impeding failure of a strategic project motivates potential whistle-blowers, despite the managers' commitment to the project. However, because of escalation 216 Chapter 4 effects, such efforts are rendered ineffective and further whistle-blowing is discouraged from taking place. These findings strongly support commitment escalation and whistle-blowing arguments. Thirdly, the evidence provides strong support to CM arguments about the intensity and nature of organizational responses to crisis events. The empirical findings show that the intense focus of CM strategies on operational and external legitimacy issues occurs at a significant cost. I found that the impact of the crisis on employee morale was a common under-addressed liabdity. Indeed, in all cases, the fadures of the projects had a significant adversarial impact on both users and IS staff (and the relationships between them), but little was done to address this issue. Fourthly, the research findings indicate that organizational learning and adaptation is more likely to follow major ISD crises than less significant ones. This contradicts threat-rigidity arguments and provides support to the failure-induced learning proposition. Table 4-14: Listing of Supported Hypotheses Number Hypothesis 1 Project importance wdl lead to greater ISD crisis impact 2 Fadure controUability will lead to greater ISD crisis impact 3 Pre-crisis preparation wdl negatively moderate the relationship between project importance and ISD crisis impact 4 Managers' commitment to the project will lead to lower pre-crisis preparation 5 Project importance will lead to greater commitment to the project 6 Project importance will lead to greater whistle-blowing 7 ' ISD crisis impact will lead to greater crisis management 8 Managers' commitment will lead to lower whistle-blowing 9 High ISD crisis impact will lead to both operational and legitimacy crisis management 10 ISD crisis impact will lead to greater post-crisis organizational learning 217 Chapter 4 Figure 4-6: Revised ISD Crisis Model 218 Chapter 5 CONCLUSIONS Every company needs people who have made mistakes and then made the most of them. Bill Gates 219 Chapter 5 5.1 IMPLICATIONS FOR RESEARCH The conceptual framework that was formulated and assessed as part of this dissertation study provides a well grounded model for integrating existing research endeavors on IS failures. It provides a conceptual basis for understanding the key issues related to the management of project failures and therefore can guide research in this area, which to date remains largely atheoretical. In addition to the potential usefulness of the conceptual model to the MIS discipline, the research described in this report has a important implications for conceptual and empirical inquiries in other organizational research areas as well. Firstly, this investigation illustrates that non-disastrous events such as ISD failures (even when their consequences are fully contained within the boundaries of the involved organizations and/or its immediate stakeholders) lead to the manifestation of crisis-based behaviors. To the best of my knowledge, this work represents the first systematic attempt to apply CM concepts (which were predominantly generated by research on large, public disasters from a perspective that was external to the affected organizations) to settings involving smaller, internal organizational incidents. The results clearly show that the applicability of these concepts enhances one's ability to understand and predict the key factors and behaviors involved in such situations. This creates a new opportunity for CM researchers to study previously ignored organizational phenomena such as internal ISD crises to enhance the existing body of knowledge and perhaps identify differences between 220 Chapter 5 internal and external crises. The frequency of IS project failures further enhance their attractiveness as potential research subjects for empirical CM studies. Secondly, this research shows that failing IS projects lead to internal whistle-blowing in organizations. This investigation revealed, however, that whistle-blowing was ineffective in ceasing the prolonged periods of denial that exist in such projects. Even though a number of variables suppressing the impact of whistle-blowing were identified in this study (such as the escalating commitment by managers, the lack of unambiguous evidence supporting the whistle-blower's arguments, etc.), there is a need to more systematically assess such factors. According to Near and Miceli (1995), virtually no empirical research investigating whistle-blowing effectiveness has been pursued to date. I believe that IS failure situations can provide useful data for identifying and studying the variables affecting whistle-blowing and its effectiveness. Thirdly, this empirical investigation revealed that commitment-based attitudes have a suppressing effect on the likelihood and success of whistle-blowing. It also revealed a number of behaviors (such as negative labeling strategies) that are manifestations of such attitudes. To the best of my knowledge this research represents the first attempt to empirically examine the linkage between escalating commitment and whistle-blowing. By doing so, it highlights the role of non-management participants in commitment of escalation situations. Unfortunately, both MIS and escalation research have largely neglected the role of such participants. It is imperative that future work takes into 221 Chapter 5 account the behaviors of such individuals (and their impacts) in order to provide a holistic perspective of the key events and processes that affect (and are affected by) project fadures. The integration of the role of non-management participants in escalation and IS failure studies is consequential for two additional reasons. Their neglect ignores a potential source of de-escalation, which can be very important in terminating failing projects in organizations. Also, it discounts the importance of (and research attention given to) the long-term effects of escalation on the morale, attitudes and future behaviors of subordinates. As the case findings indicate, commitment-based behaviors have important ramifications on these factors and thus deserve the attention of both managers and researchers alike. Fourthly, this investigation provided significant support to crisis-based learning arguments. Given the significant discrepancies that exist in the empirical research, it is important to pursue additional investigation until reconciliation between the failure-induced learning and threat-rigidity theories is achieved. Interestingly, this study's findings are not consistent with the arguments made by Mone et al. (1998) in one such recent reconciliation attempt. This study's findings contribute to reconciliatory efforts by dlustrating that increased formalization and adaptation are not mutually exclusive and can take place at the same time. This contradicts a major assumption in the chasm between the two competing theories. The case results show that increased formalization can be the desired effect of organizational learning in response to an IS project failure (such as in the GVH case). Because for years many IS departments lacked the formality 222 Chapter 5 and planning required to successfuUy execute large, complicated projects, their recent fadures may motivate the introduction of such formal procedures in their operations. Thus, the study of IS project fadures can provide insights that could lead to another potential explanation for their differences between these two theories. Finally, the study of organizational learning in response to IS project failures can provide additional insights to the organization learning literature, as the existing research on crisis-based learning has focused exclusively on the study of external, environmental events as the basis of organizational crises. FinaUy, and perhaps most importantly, this investigation highlights the need for the identification of a set of effective crisis management practices that can help organizations manage their IS project fadures. The MIS research community has a duty to address this need. This can be accomplished in two possible ways. The MIS literature can draw from the extensive CM literature to identify relevant strategies and practices that can be successfully used in IS failure situations. The research undertaken as part of this dissertation represents such an attempt. Alternatively, the research community can identify such practices by surveying the ISD crisis-related practices of IS professionals and empirically assessing their effectiveness. To date, only one such attempt has been made (Iacovou and Dexter, 1998). 223 Chapter 5 5.2 IMPLICATIONS FOR PRACTICE The findings of this study have important implications for both managers facing potential IS failure situations and those seeking to avoid being placed in that position. Overall, this research highlights the importance of treating failing IS projects as a crisis, a complex organizational phenomenon, and not as a mere technological issue. This will enable managers to identify a number of CM-related objectives and strategies to effectively manage the project failure situations. The first lesson that this research highlights is the high importance of prompt detection and the timely initiation of plans to avert the failure or the preparation of contingency plans to effectively cope with it. As the results show, this is not an easy task due to an escalation in commitment that is usually present in situations involving failing IS projects. To reduce the effect of the commitment, Staw and Ross (1987) recommend a number of de-escalation tactics. These tactics can be applied to the context of IS project failures as follows: \u00E2\u0080\u00A2 Administrative Turnover: By engaging previously uninvolved decision-makers in the process, the likelihood that pre-failure evidence will be identified and be acknowledged is significantly enhanced. The findings clearly support this suggestion. Although the replacement of project managers may not always 224 Chapter 5 be a feasible option, the addition of independent consultants or the rotation of other executives in the organization as project advisors could achieve the desired results because of the addition of alternative perspectives to the project decision-making process. \u00E2\u0080\u00A2 Bifurcated Decision Procedures: This requires that the implementation of a project is separately treated and managed from the initial decision to initiate it. In other words, managers who make the decision to embark on a course of action (such the initiation of the project, the selection of a specific vendor, etc.) should be different from those actually managing the implementation of the selected solution. This tactic needs to be implemented with caution, however, as its inappropriate, superficial use can be detrimental in the context of IS development. As the findings indicate, one of the reasons that all three projects failed was because relatively uninformed senior managers made the initial decisions while the subsequent implementation responsibility was left to lower-level project managers. Thus, it is imperative that both the initial and subsequent project decisions are made by informed, knowledgeable managers after securing the input and support of users, senior managers and IS staff. It is important to recognize that mere user involvement is not sufficient in ensuring the success of a project. In the three cases, both users and IS staff were highly involved in the implementation of the systems, but very few of them were supportive of and committed to them. 225 Chapter 5 \u00E2\u0080\u00A2 Excuses and other de-binding elements: Senior executives can take a number of steps to make it easy for involved managers to distance themselves from a losing course of action. For example, they can do this by proactively informing the involved project managers and the rest of the organization that potential failure is always a possibility due to external or collective factors, thereby reducing their perceived responsibility for it. Of course, this tactic needs to be embedded in a larger organizational culture in which scapegoating and retaliation are strongly discouraged. The following tactic addresses how such culture can be cultivated. \u00E2\u0080\u00A2 Support for Failure: Although failure in organizational settings can be costly, there are a number of ways to manage it without using threats as the main avoidance motivator, as such threats can freeze managers into defending a failing project. Managers are more likely to admit the existence of problems when the potential penalties for failures are not severe and well known in advance than when they are faced with unknown, potentially politically-motivated retributions. Staw and Ross described the implementation of such policy in a firm: A large computer firm, for example, puts managers in a \"penalty box\" for key mistakes, making them ineligible for major assignments for one year. After this penalty period, managers are restored to full status in the organization and are again eligible for running major projects. Such a compromise between support for failure and demands for competence may hold wide 226 Chapter 5 potential in many organizations attempting to reduce commitment in escalation situations. (1987, p. 73) \u00E2\u0080\u00A2 Unambiguous Negative Feedback: Because of the ambiguity involved in most failing IS projects, it is important to provide appropriate opportunities and settings to involved individuals to voice their concerns and identify problems associated with the progress and direction of a project. These can be done in a number of ways, including the establishment of formal feedback channels (such as group and individual meetings, anonymous written feedback, etc.) and the seeking of multiple sources of feedback (such as users, IS staff, uninvolved outside consultants, etc.) multiple times throughout the project. It is important to note that seemingly insignificant elements of the feedback mechanisms, such as the location and timing of feedback meetings, can have a detrimental impact on the willingness of participants to be forthcoming with their ideas and concerns. For example, in one of the cases, a few participants indicated that because the project feedback meetings were also doubled as team-building sessions and were held informaUy whde the participants were having lunch in the employee cafeteria. Because of this, it was almost impossible for them to express a dissenting view, as it would go against the groups' cohesiveness values. \u00E2\u0080\u00A2 Bringing Phase-Out Costs Forward: By requiring that the costs of 227 Chapter 5 withdrawal are calculated in advance and be incorporated in project proposals and plans, involved decision makers will be more informed decisions about the risks and magnitude of the potential organizational loss due to a failure. Such an approach provides a more formal way for justifying the abandonment of a failing project as it enables project managers to clearly show the potential savings (in terms of opportunity cost) that can arise from a project cancellation. A comparison between the costs and benefits of the \"continuation\" versus \"abandonment\" options could be presented during pre-determined intervals throughout the project, providing an opportunity to involved individuals to publicly discuss the cancellation option. \u00E2\u0080\u00A2 Deinstitutionalization: When a specific IS project is viewed as means of a larger plan aiming to benefit the organization's overall interests and goals (such as in the case of RCU), it is important to separate the project from its institutional context. To achieve this, the involved decision-makers can be asked to justify the project in two distinct ways: based on its linkage to the overall purpose of the organization (its institutional merits) and by using a more traditional investment valuation technique (to assess its economic merits). This makes escalation less likely as it reveals the economic value of the project without political considerations. It is important to note that manifestations of several of above recommendations are 228 Chapter 5 already part of certain development methodologies (such as the systems development life cycle). For example, many of them mention the need of periodic feedback, stage completion audits, continuous user feedback etc. Unfortunately, as this research shows such suggestions are frequently ignored. Thus, there is a need to better highlight these requirements when teaching and applying these methodologies and perhaps better formalize the above suggestions in each method by establishing clear requirements that achieve the desired de-escalation effects. The second major lesson from this research relates to the importance of effective crisis management. To be effective in managing a crisis, the CM literature and several practitioners have identified a number of critical success factors (cf. Mitroff et al., 1987). Based on this study's findings, three of them are likely to be problematic in the context of IS fadures and are discussed next: \u00E2\u0080\u00A2 Train managers to be crisis management leaders: Most executives, including IS managers, have received little or no education on how to manage crises (Smith, 1991) restricting the ability to effectively cope with them (Mitroff et al., 1989). Given that the management of crises requires a number of specialized managerial attributes, Richardson (1993) recommends the incorporation of crisis cases in management education and training. For example, IS students and professionals can be exposed to issues related to the management of IS project failures by discussing relevant cases in system 229 Chapter 5 analysis and design and project management courses. I believe that both organizations and individuals can benefit from such training as it can sensitize managers to key aspects of IS project failure situations, provide them with a portfolio of crisis management tools, and highlight the importance of contingency planning during IS projects (which is non-existent in most IS departments). \u00E2\u0080\u00A2 Identify and communicate with all affected parties: As the results show, during an ISD crisis, managers tend to focus their efforts on \"getting the recovery task\" accomplished and addressing the interests of external stakeholders. While both of these duties are critical, internal communication seems to be undervalued and somewhat neglected in the case of IS project failures. This neglect of internal communication issues is critical because it prevents managers from understanding and addressing the impacts of the failure on the (often demoralized) project team members and other affected users. Indeed, the evidence in the case studies clearly shows that because very little was done to manage internal communication during the aftermath of the failures, employee morale and IS-user relationships significantly suffered. \u00E2\u0080\u00A2 Finish all unfinished business: The case evidence points out that after the intense, acute crisis of the IS project failure was over, the organizations significantly reduced the time and resources spent managing its aftermath. The 230 Chapter 5 managerial attention shifted to the routine operations of the organizations, leaving behind a number of incomplete tasks associated with the fadures. In certain instances, this left affected users in worse positions than they were in when the project was initiated. Neglecting to complete all project recovery tasks can lead to an increased dissatisfaction among the users and contribute to a cynical attitude towards the abdities of the involved managers and departments (including MIS). Finally, it is important for individuals managing IS project failures to address the long-term adaptation issues of IS project fadures to ensure that not only them but the whole organization benefits from the learning value of its crisis. To ensure that appropriate learning will take place in response to a project fadure, I offer the following advice: \u00E2\u0080\u00A2 Conduct a post-mortem audit: Even though many organizations avoid conducting post-mortem audits fearing that it would re-open \"old wounds\" (Ewusi-Mensah, 1997), it is imperative that the organization takes actions to identify the root causes of the fadure in order to accurately focus its adaptation on the relevant problem areas. To avoid blaming and scapegoating, it is important to focus on structural, situational factors and perhaps delay the implementation of the audit untd after the political finger-pointing that tends to happen immediately following crises has subsided. External consultants can assist with this process, although I believe that most organizations are perfectly 231 Chapter 5 capable of conducting their own audits. It is important, however, that this process be as neutral and open as possible and involve all affected parties. The evidence from the GVH case shows that excluding certain parties or not communicating the results to them can lead to the rejection of the audit's findings, distrust and further demoralization. \u00E2\u0080\u00A2 Change organizational routines to reflect the lessons learned: To ensure that the whole organization retains the knowledge acquired during the failure, it is important to formalize it by implementing new (or modifying existing) policies, introducing new tools, or altering the decision-making and communication structures of the organization to ensure that the learning is sustained beyond the tenure of the involved individuals. In addition to their benefits to the organization's future undertakings, such actions also help restore the credibility of the involved groups. \u00E2\u0080\u00A2 Apply newly acquired knowledge on future projects: For an organization to reap the benefits of newly acquired knowledge, it must support and effectively diffuse and apply the policies reflecting the new learning. It is also important to apply such knowledge to assess its effectiveness, ensure that it reflects the appropriate lessons, and fine-tune it. For example, in GVH case, even though the initial committee-based structure that was put in place in response was a step in the right direction, its initial configuration proved to be overly rigidifying 232 Chapter 5 and required additional adjustments before reaching a more appropriate form. \u00E2\u0080\u00A2 Remove Rigidity-Enhancing Effects: In response to certain project fadures, MIS departments and other organizational groups tend to become more political and bureaucratic in their decision-making, making future adaptation and experimentation (which are key in maintaining flexibility in IS operations and developments) more difficult. Thus, it is important for managers to assess whether rigidity-related effects are present in the aftermath of the failures, and, if needed, take steps to alleviate the fears and distrust that may motivate them. 5.3 LIMITATIONS Unquestionably, IS project failures and the organizational responses to them are complex organizational phenomena that require the application of rigorous research methods to fully understand them. Even though I believe that this research has made an important first step towards such understanding, I recognize that it suffers from certain limitations. These limitation include the following issues: \u00E2\u0080\u00A2 Perceived lack of generalizability due to limited sample: A number of researchers tend to question the generalizability of case-based findings arguing that most case samples are too small and not representative. Indeed, for this dissertation I 233 Chapter 5 only studied three project failures in Canadian public organizations. However, as I have argued in Chapter Three, the generalizability of the findings is not based on a sampling logic, but rather on a theoretical logic. In other words, my goal was not to identify commonly used specific behaviors that take place during project failures, but rather to identify specific patterns in these behaviors. In this sense, the supported hypotheses (as shown in Table 4-14) represent the results of this study. Given that they are highly congruent with extensive empirical and conceptual research and were empirically validated by the evidence in the case studies, I believe that they are generalizable. \u00E2\u0080\u00A2 Historical focus of data collection: Another potential problem arises from the fact that the data collection in two of the cases took place after the organizations had managed their crises (for the third one, the data collection took place during the crisis and post-crisis stages). Arguably, the assessment of historical events based on interview data can be problematic due to a number of shortcomings associated with biased and selective memory. However, I believed that I managed to adequately address this threat by triangulating the evidence using archival data and documentation. \u00E2\u0080\u00A2 Limited focus of empirical investigation: As it was indicated in Chapter three, the scope of questions during the interviews was limited to the constructs and relationships identified in the conceptual model. Even though this enabled me to more accurately 234 Chapter 5 assess the applicability of the CM framework in the context of ISD failures (which was the chief goal of this study), it prevented me from focusing on all relevant factors associated with such situations. This focused approach in data collection and analysis did not allow me to provide a holistic description of each case as it biased the emphasis of the descriptions and analysis on CM constructs. \u00E2\u0080\u00A2 Potential threat to internal validity: As I was the sole reviewer and coder of the raw data that was collected during this study, there is a possibility that the results are biased. Ideally, multiple raters should be utilized to review, code and analyze the data. Unfortunately, due to the sensitive nature of this study, the companies were unwilling to let additional individuals access the raw data. Thus, to gain their full cooperation I had to promise them that my advisor and myself would be the only ones who would be able to view the raw data. To counter the potential of a bias, however, multiple participants reviewed (and validated) each case summary. \u00E2\u0080\u00A2 Need for self-censoring: Due to the sensitive, and at times controversial, nature of the behaviors and events that took place in these cases, there was a great need to protect the identities of the involved parties. Such strict anonymity was necessary to secure the trust and cooperation of both the organizations and individuals involved. However, my main concern with anonymity was not confined to protecting the identities of the parties from potential readers. At times, the participants exphcitly requested that their comments not be included in any published reports, especially 235 Chapter 5 when they were describing situations that involved a very small number of participants and thus could easily identify them as participants or informants. While I respected the wishes of these participants, their requests somewhat limited my ability to include specific comments in this report. This limitation could potentially raise an ethical issue associated with the need to balance true and complete research reporting versus protecting the anonymity of the source (Adler and Adler, 1993). Despite this controversy, I am confident that the omission of these accounts did not materially impact any of main findings of this research. 5.4 F U T U R E R E S E A R C H To continue the investigation of IS project failures from a CM management perspective, a number of studies can be pursued. To enhance the validity of the research model by statistically assessing its propositions, a large-scale survey will be implemented. Such a survey (and other field or experimental studies) can enhance the validity of the model and fine-tune its major assumptions through method triangulation. As a first step, I plan to formulate and validate survey instruments that will allow the operationalization of the main constructs of interest. In addition to the implementation of a survey study to replicate and further validate the findings, I have identified a number of issues (based on the empirical findings) that my 236 Chapter 5 future research studies will address. These include the following: \u00E2\u0080\u00A2 What are the conditions and factors that influence the effectiveness of whistle-blowing efforts in failing IS projects? As the findings show, despite the presence of such efforts, there was no evidence indicating that they were effective in the discontinuation of the pre-crisis denial. Given the detrimental effects of such denial, it is critical to understand how whistle-blowing can affect it. Near and Miceli (1995)'s theoretical model can provide the conceptual foundation for such a study in the context of IS project failures. Also, it is important to more systematically investigate the conflicting effects of project importance and commitment on whistle-blowing as they both appear to influence it. A survey study (combined with appropriate statistical tools) will enable us to better understand the relationship between the three constructs. \u00E2\u0080\u00A2 Which practices are most effective in managing the various stages of the crisis in the context of IS project failures? Research projects addressing this issue could identify, study and empirically evaluate practices that are effective in (1) detecting, (2) managing and (3) learning from IS project failures. Some work related to detection has been done in the past (cf. Ginzberg, 1981; Ked et al, 1994; Ked, 1995), but the other two areas remain neglected. This study identified a number of operational and legitimacy tactics used by organizations to manage their crises, but did not evaluate the effectiveness of 237 Chapter 5 each one. In the future, surveys and experiments can be conducted to evaluate the suitability of the various tactics under different failure scenarios. \u00E2\u0080\u00A2 Is the post-crisis adaptation that takes place in response to major ISD crises a result of internally-motivated learning or just another strategic tool in managing the legitimacy threat posed by such crises? A large-scale study will enable me to discriminate between these two potential motivators and provide further insight to the debate centered on crisis-based learning. Furthermore, the findings suggest that major project failures will lead to the introduction of changes in MIS departments. This view can be contrasted with non-fadure learning theories (such as the diffusion of innovation perspective) to identify which of the two apparent motivators for learning (the liabdities caused by a failure and the innovation's relative advantage) can better explain adaptations in MIS departments. This contrast can be empirically assessed using a survey that investigates the introduction of new innovations in IS development processes (such as the adoption of new CASE tools, planning methodologies, etc) vis-a-vis factors related to prior IS failures and diffusion concepts. In summary, I believe that this research has contributed to the existing body of knowledge on IS project fadures, by offering an alternative perspective, that of crisis management. However, the struggle in understanding, managing and ultimately preventing such failures 238 Chapter 5 is far from over. Therefore, we, as MIS researchers, have an obligation to continue to study their causes, implications and ways to manage both, and consider this research project as part of the early steps in achieving this goal. 239 Bibliography 240 Bibliography Abrahamson, L.Y., Garber, J. and Seligman, M.E.P. (1980). Learned helplessness in humans: An Attributional Analysis. In Garber, J. and Seligman, M.E.P. (Eds), Human Helplessness: Theory and Applications, 3-34. Academic Press, New York. Ackoff, R.L. (1967). Management Misinformation Systems. Management Science 14(4), B147-156. Adler, P.A. and Adler, P. (1993). Ethical Issues in Self-Censoring: Ethographic Research on Sensitive Topics. In Renzetti, C M and Lee, R.M. (Eds), Researching Sensitive Topics pp. 249-266. Sage Publications, Newbury Park, CA. Alter, S. and Ginzberg, M.J. (1978). Managing Uncertainty in MIS Implementation. Sloan Management Review 19, 23-31. Anonymous (1989). Air Force Misses Target. Computing Australia, 21 August. Ashforth, B.E. and Gibbs, B.W. (1990). The Double-edge of Organizational Legitimization. Organizational Science 1, 177-194. Bandura, A. (1986). Self-efficacy: The Exercise of Control. Freeman, New York. Banerjee, M.M and Gillespie, D.F. (1994). Linking Disaster Preparedness and Organizational Responses Effectiveness. Journal of Community Practice 1(3), 129-142. Barki, H. and Hartwick, J. (1994). Measuring User Participation, User Involvement, and User Attitude. MIS Quarterly 18(1), 59-82. Baron, R.M. and Kenny, D.A. (1986). The Moderator-Mediator Variable Distinction in Social Psychological Research: Conceptual, Strategic and Statistical Considerations. Journal of Personality and Social Psychology 51(6), 1173-1182. Baronas, A.M.K. and Louis, M.R. (1988). Involvement Leads to System Acceptance. MIS Quarterly 12(1), 111-124. Bateman, T. (1983). Resource Allocation After Success and Fadure: The Roles of Attributions of Powerful Others and Probabilities of Future Success. Working paper, Texas A&M University, Department of Management, College Station, TX. Baton, L. (1990). Crisis Management: Selecting Communications Strategy. Management Decision 28(6), 5-8. Beaudoin, T. (1988). Planning for the Worst. Management Review (August), 7. Benbasat, I., Goldstein, D.K. and Mead, M. (1987). The Case Research Strategy in Studies of Information Systems. MIS Quarterly 11(3), 369-386. 241 Bibliography Betts, M. (1992). Feds Debate Handling of Failing IS Projects. Computerworld (November 2), 103. Bies, R.S. and Sitkin, S.B. (1992). Explanation as Legitimization: Excuse-Making in Organizations. In, McLaughlin, M.L., Cody, M.J. and Read, S.J. (Eds), Explaining One's Self to Others: Reason Giving in a Social Context, 183-198. Lawrence Erlbaum Associates, Hillsdale, NJ. Billings, R.S., Milburn, T.W. and Schaalman M.L. (1980). A Model of Crisis Perception: A Theoretical and Empirical Analysis. Administrative Science Quarterly 25, 300-316. Bignell, V. and Fortune, J. (1984). Understanding Systems Failures. Manchester University Press, Manchester, UK. Boehm, B.W. (1981). Software Engineering Economics. Prentice-Hall, Englewood Cliffs, NJ. Bonnieux, F. and Rainelli, P. (1993). Learning From the Amoco Cadiz Oil Spill: Damage Valuation and Court's Ruling. Industrial and Environmental Crisis Quarterly 7(3), 169-188. Booth, S. A. (1993). Crisis Management Strategy, Routledge, New York. Bostrom, R.B. and Heinen, J.S. (1977). MIS Problems and Failures: Socio-technical Perspective-Part I: the Causes. MIS Quarterly 1(3), 17-32. Brockner, J. (1992). The Escalation of Commitment to a Failing Course of Action: Toward Theoretical Progress. Academy of Management Review 17(1), 39-61. Brockner, J., Houser, R., Birnbaum, G., Lloyd, K., Deitcher, J., Nathanson, S. and Rubin, J.Z. (1986). Escalation of Commitment to An Ineffective Course of Action: The Effect of Feedback Having Negative Implications for Self-identity. Administrative Science Quarterly 31, 109-126. Bolton, M.K. (1993). Organizational Innovation and Substandard Performance: When is Necessity the Mother of Innovation? Organisation Science 4(1), 57-75. Brooks, F. (1975). The Mythical Man-month. Addison-Wesley, Reading, MA. Brown, R. (1991). Value-Added Associations: The IS/CEO Relationship. Systems/3X and AS World 19(2), 28-35. Cameron, K.S., Whetten, DA. and Kim, M.U. (1987). Organizational Dysfunction of Decline. Academy of Management Journal 30(1), 126-138. 242 Bibliography Cerullo, M.J. (1980). Information Systems Success Factors. Journal of Systems Management (December), 10-19. Cringley, R.X. (1994). When Disaster Strikes IS. Forbes ASAP (August 29), 60-64. Cyert, R.M. and March, J.G. (1963). A Behavioural Theory of the Firm. Prentice-Hall, Englewood Cuffs, NJ. DAveni, R. A. and MacMillan, I.C. (1990). Crisis and the Content of Managerial Communications: A Study of the Focus of Attention of Top Managers in Surviving and Failing Firms. Administrative Science Quarterly 35, 634-657. DAunno T. and Sutton, R.I. (1992). The Responses of Drug Abuse Treatment Organisations to Financial Adversity: A Partial Test of the Threat-Rigidity Thesis. Journal of Management 18(1), 117-131. Dearden, J., McFarlan, F.W., and Zani, W.M. (1971). Hollister Manufacturing. In Managing Computer-based Information Systems p. 341-361, Irwin, Homewood, IL. Denzin, N.K. and Lincoln, Y.S. (1994). Introduction: Entering the Field of Qualitative Research. In Denzin, N.K. and Lincoln, Y.S. (Eds), Handbook of Qualitative Research pp. 1-17. Sage Publications, Thousand Oaks, CA. DeSanctis, G. (1983). Expectancy Theory as an Explanation of Voluntary Use of a Decision Support System. Psychological Reports 52(1), 247-260. Dickson, G.W., Leitheiser, R.L., Nechis, M. and Wetherbe, J.C. (1984). Key Information Systems Issues for the 1980's. MIS Quarterly 8(3), 135-148. Doll, W.J. and Ahmed, M.U. (1983). Managing User Expectations. Journal of Systems Management (June), 6-11. Dutton, J. (1986). The Processing of Crisis and Non-crisis Strategic Issues. Journal of Management Studies 23(5), 501-517. Dutton, J.E. and Jackson, S.E. (1987). Categorizing Strategic Issues: Links to Organizational Action, Academy of Management 21(1), 76-90. Dutton, J.E. and Jackson, S.E. (1988). Discerning Threats and Opportunities. Administrative Sciences Quarterly, 33 370-387. Dworkin, T.M. and Baucus, M.S. (1995). Internal vs. External Whistle-blowers: A Comparison of the Whistle-blowing Process. Paper presented at the Academy of Management Meeting, Vancouver, BC, Canada. 243 Bibliography Earl, M.J. and Feeny, D.F. (1994). Does the CIO Add Value? Information Week (June 6), 62. Eisenhardt, K M . (1989). Budding Theories from Case Study Research. Academy of Management Review 14(4), 532-550. Ellis, V. (1994). Audit Says DMV Ignored Warning. Los Angeles Times (August 18), A3, A24. Ellis, V. (1995). Embattled Director of DMV to Step Down. Los Angeles Times (October 11), A3. Ewusi-Mensah, K. (1997). Critical Issues in Abandoned Information Systems Development Projects. Communications of the ACM 40(9), 74-80 Ewusi-Mensah, K. and Przasnyski, Z.H. (1991). On Information Systems Project Abandonment: An Exploratory Study of Organizational Practices. MIS Quarterly 15(1), 67-86. Ewusi-Mensah, K. and Przasnyski, Z.H. (1995). Learning From Abandoned Information Systems Development Projects. Journal of Information Technology 10, 3-14. Fink, S. (1986). Crisis Management. Amacom, New York. Fiegener, M. and Coakley, J. (1995). CIO \"Impression Management.\" Journal of Systems Management 46(6), 56-61. Fiol, C M . and Lyles, M.A. Organizational Learning. Academy of Management Review 10(4), 803-813. Fischer, F. (1991). Risk Assessment and Environmental Crises: Toward Integration of Science and Participation. Industrial Crisis Quarterly 5(2). Flowers, S. (1996). Software Failure: Management Failure; Amazing Stories and Cautionary Tales. John Wdey and Sons, West Sussex, England. Fontana, A. and Frey, J.H. (1994). Interviewing: The Art of Science. In Denzin, N.K. and Lincoln, Y.S. (Eds), Handbook of Qualitative Research pp. 361-376. Sage Publications, Thousand Oaks, CA. Forester, R. and Morrison, P. (1990). Computer Unreliability and Social Vulnerability. Futures 22(5), 462-74. Fortune, J. and Peters, G. (1995). Learning From Failure: The Systems Approach. John Wdey and Sons, West Sussex, England. Frangini, M. (1991). Turnover High Among IS Executives. Computing Canada 17(7), 1. 244 Bibliography Friedman, T. (1995). It's Not Witchcraft So Don't Burn IT. PC Week 12(15), E12. Garland, H. (1990). Throwing Good Money After Bad: The Effect of Sunk Costs on the Decision to Escalate Commitment to an Ongoing Project. Journal of Applied Psychology 75(6), 728-731. Gephart, R.P. (1984). Making Sense of Organisationally Based Disasters. Journal of Management 10, 205-225. Giacalone, R.A. and Rosenfeld, P. (1989). Impressions Management in the Organization. Lawerence Erlbaum Associates, Hillsdale, NJ. Giacalone, R.A. and Rosenfeld, P. (1991). Applied Impression Management. Sage Publications, Newbury Park, CA. Gibbs, W.W. (1994). Software's Chronic Crisis. Scientific American 27(3), 86-95. Ginzberg, M.J. (1981). Early Diagnosis of MIS Implementation Failure: Promising Results and Unanswered Questions. Management Science 27(4), 459-478. Gladden, G.R. (1982). Stop the Life-Cycle: I Want to Get Off. Software Engineering Notes 7(2), 35-39. Gladwin, T.N. and Kumar, R. (1987). The Social Psychology of Crisis Bargaining: Toward a Contingency Model. Columbia Journal of World Business (Spring), 23-31. Goldberg, A.I., Dar-el, E.M. and Rubin, A.E. (1991). Threat Perception and the Readiness to Participate in Safety Programs. Journal of Organizational Behaviour, 12, 109-122. Graham, J.W. (1993). Book Review of \"Blowing the Whistle: The Organizational and Legal Implications for Companies and Employees.\" Administrative Science Quarterly (December), 683-685. Green, S. (1995). DMV Saddles with $18 Million Lemon. The Fresno Bee (May 14), A4. Greenberg, D.B., Miceli, M.P. and Cohen, D.J. (1987). Oppositionists and Group Norms: The Reciprocal Influence of Whistle-blowers and Co-workers. Journal of Business Ethics, 6, 527-542. Guba, E.G. and Lincoln, Y.S. (1994). Competing Paradigms in Qualitative Research. In Denzin, N.K. and Lincoln, Y.S. (Eds), Handbook of Qualitative Research pp. 105-117. Sage Publications, Thousand Oaks, CA. Habermas, T. (1975). Legitimation Crisis. (Trans. T. McCarthy), Beacon, Boston, MA. 245 Bibliography Hamel, J., Dufour, S. and Fortin, D. (1993). Case Study Methods. Sage Publications, Newbury Park, CA. Hamdton, N. (1995). Reducing Project Risk: Defining Requirements. Enterprise Systems Journal 10(9), 16-24. Hedberg, B. (1981). How Organizational Learn and Unlearn. In, Nystrom, P.C. and Starbuck, W.H. (Eds.), Handbook of Organizational Design 1, 3-27. Oxford University Press, New York. Hedberg, B., Nystrom, P.C. and Starbuck, W.H. (1976). Camping on Seesaws: Prescriptions for a Self-Designing Organisation. Administrative Science Quarterly 21, 41-65. Hermann, OF. (1963). Some Consequences of Crisis Which Limit the Viability of Organizations. Administrative Sciences Quarterly 8, 61-82. Herriott, R.E. and Firestone, W.A. (1983). Multisite Qualitative Policy Research: Optimising Description and Generihzability. Educational Researcher 12, 14-19. Hersen, M. and Barlow, D.H. (1976). Single-case Experimental Designs: Strategies for Studying Behaviour. Pergamon, New York. Hoder, I. (1994). The Interpretation of Documents and Material Culture. In Denzin, N.K. and Lincoln, Y.S. (Eds), Handbook of Qualitative Research pp. 393-401. Sage Publications, Thousand Oaks, CA. Huber, G.P. (1991). Organizational Learning: The Contributing Processes and the Literatures. Organizational Science 2(1), 88-115. Huberman, A.M. and Mdes, M.B. (1994). Data Management and Analysis Methods. In Denzin, N.K. and Lincoln, Y.S. (Eds), Handbook of Qualitative Research pp. 428-444. Sage Publications, Thousand Oaks, CA. Hume, L.S. (1996). SEC Extends Investigation of Denver Airport Bond Disclosures, Muse Says. The Bond Buyer (February 16), 36. Iacovou, C. and Dexter, A. (1998). Managing Runaway Projects: A Delphi Survey. Presented at the Sixth European Conference on Information Systems, Aix-en-Provence, France. Ives, B. and Olson M.H. (1984). User Involvement and MIS Success: A Review of Research. Management Science 30(5), 586-603. 246 Bibliography Jackson, S.E. and Dutton, J.E. (1988). Discerning Threats and Opportunities. Administrative Science Quarterly 33, 370-387. James, L.R. and Brett, J.M. (1984). Mediators, Moderators and Tests for Mediation. Journal of Applied Psychology 69(2), 307-321. Jander, M. (1987). CASE Tools: Changing the Way MIS Works. Computer and Communication Decisions 19(12), 98-104. Jones, Capers. (1996). Patterns of Software Systems Failure and Success. International Thompson Computer Press, Boston, MA. Kanter, R.M. (1983). The Change Masters. Simon & Schuster, New York. Kast, V. (1990). The Creative Leap: Psychological Transformation Through Crisis. Chiron Publications, Wilmette, IL. Keider, S.P. (1984). Why Systems Development Projects Fail. Journal of Information Systems Management 1(3), 33-38. Keil, M., Mixon, R., Saarinen, T., and Tuunainen, V. (1994). Understanding Runaway Information Technology Projects: Results from an International Program based on Escalation Theory. Journal of Management Information Systems, 11(3), 65-85. Keil, M. (1995). Pulling the Plug: Software Project Management and the Problem of Project Escalation. MIS Quarterly 19(4), 421-448. Keil, M., Mixon, R., Saarinen, T. and Tuunainen, V. Understanding Runaway Information Technology Projects: Results from an International Research Program Based on Escalation Theory. Journal of Management Information Systems 11(3), 67-87. Kemerer, C F . (1987). An Empirical Valuation of Software Cost Estimation Models. Communications of the ACM 30(5), 416-429. Kidder, L. and Judd, C M . (1986). Research Methods in Social Relations (5th Edition). Holt, Rinehard & Winston, New York. Kiesler, S. and Sproull, L. (1982). Managerial Response to Changing Environments: Perspectives on Problem Sensing from Social Cognition. Administrative Science Quarterly, 548-570. King, J.L. and Applegate, L.M. (1997). Crisis in the Case Study Crisis: Marginal Diminishing Returns to Scale in the Quantitative-Qualitative Research Debate. In Lee, A.S., Liebenau, J. and DeGross, J.I. (Eds), Information Systems and Qualitative Research, pp. 28-30. Chapman & Hall, London. 247 Bibliography Kubler-Ross, E. (1969). On Death and Dying. Macmillan, New York. Kuzel, A.J. (1992). Sampling in Qualitative Inquiry. In Kvale, S. (Ed), Doing Qualitative Research, pp. 31-44. Sage, Newbury Park, CA. Kvale, S. (1988). The 1000-Page Question. Phenomenology & Pedagogy 6(2), 90-106. LaPlante, A. (1995). Scope Grope: Odds Are Your Latest IS Project Could End up a Runaway Train. Computerworld (March 20), 81-84. Lee, R.M. and Renzetti, C M . (1993). The Problems of Researching Sensitive Topics: An Overview and Introduction. In Renzetti, C M and Lee, R.M. (Eds), Researching Sensitive Topics pp. 3-13. Sage Publications, Newbury Park, CA. Levitt, B. and March, J.G. (1988). Organizational Learning. Annual Review of Sociology 14, 319-340. Lin, E. and Ashcraft, P. (1990). A Case of Systems Development in a Hostile Environment. Journal of Systems Management 41(4), 11-14. Lin, E. and Hsieh, C. (1990). Dysfunctional User Behaviour in Systems Development. Journal of Information Systems Management 7(1), 87-89. Locke, E.A. and Latham, GP. (1990). A Theory of Goals and Performance. Prentice-Hall, Englewood Cliffs, NJ. Lucas, H.C (1975). Why Information Systems Fail. Columbia University Press, New York. Lynch, R.M. (1987). MIS Project Risk and Applications Development Approach. Industrial Management and Data Systems (May-June), 22-26. Lyytinen, K. and Hirschheim R. (1987). Information Systems Failures: A Survey and Classification of the Empirical Evidence. Oxford Surveys in Information Technology 4, 257-309. Markus, M.L. (1983). Power, Politics, and MIS Implementation. Communications of the ACM 26(6), 430-444. Markus, M.L. (1991). Victims and Shareholders: The Dilemmas of Presenting Corporate Policy During a Crisis. Academy of Management Journal 34, 281-305. Markus, M.L. and Robey, D. (1988). Information Technology and Organizational Change: Causal Structure in Theory and Research. Management Science 34(5), 583-598. 248 Bibliography McFarlan, F.W. (1981). Portfolio Approach to Information Systems. Harvard Business Review 59(5), 142-150. McKeen, J.D., Guimaraes, T. and Wetherbe, J.C. (1994). The Relationship Between User Participation and User Satisfaction: An Investigation of Four Contingency Factors. MIS Quarterly 18(4), 427-451. McKinley, W. (1984). Organizational Decline and Innovation in Manufacturing. In Bozeman, B., Crow, M. and Link, A., Strategic Management of Industrial R&D, 147-159. Lexington Books, Lexington, MA. McKinley, W. (1993). Organizational Decline and Adaptation: Theoretical Controversies. Organisation Science 4(1), 1-9. McPartlin, J.P. (1992). The Collapse of Confirm. Information Week (October 19), 12-19. Meredith, J. (1988). Project Monitoring for Early Termination. Project Management Journal 19(5), 31-38. Merton, R.K., Fiske, M, and Kendall, P.L. (1990). The Focused Interview: A Manual of Problems and Procedures (2nd Edition). Free Press: New York. Meyer, A.D. (1982). Adapting to Environmental Jolts. Administrative Science Quarterly 27, 515-537. Meyers, G.C. and Holusha, J. (1986). When It Hits The Fan: Managing Nine Crises of Business. Houghton Mifflin Company, Boston. Miceli, M.P. and Near, J.P. (1984). The Relationship Among Beliefs, Organizational. Position, and Whistle-blowing Status: A Discriminant Analysis. Academy of Management Journal 27(4), 687-705. Miceli, M.P. and Near, J.P. (1985). Characteristics of Organizational Climate and Perceived Wrongdoing Associated with Whistle-blowing Decisions. Personnel Psychology 38, 525-544. Miceli, M.P. and Near, J.P. (1988). Individual and Situational Correlates of Whistle-blowing. Personnel Psychology 41, 267-281. Miceli, M.P. and Near, J.P. (1989). The Incidence of Wrongdoing, Whistle-blowing, and Retaliation: Results in a Natural Occurring Field Experiment. Employee Responsibilities and Rights Journal 2, 91-108. 249 Bibliography Miceli, M.P. and Near, J.P. (1992). Blowing the Whistle: The Organizational and Legal Implications for Companies and Employees. Lexington Books, New York. Miceli, M.P., Near, J.P. and Schwenk, C.R. (1991). Who Blows the Whistle and Why? Industrial and Labor Relations Review 15(1), 113-130. Miles, R.H. and Cameron, K.S. (1982). Coffin Nails and Corporate Strategies. Prentice-Hall, Englerwood CHffs, NJ. Miles, M.B. and Huberman, A.M. (1984). Qualitative Data Analysis: A Sourcebook of New Methods. Sage, Beverly Hills, CA. Miles, M.B. and Huberman, A.M. (1994). Qualitative Data Analysis: An Expanded Sourcebook. Sage, Thousand Oaks, CA. Miller, D. (1994). What Happens After Success: The Perils of Excellence. Journal of Management Studies, 31(3): 325-358. Miller, D. (1996). A Preliminary Typology of Organizational Learning: Synthesizing the Literature. Journal of Management 22(3), 485-505. Mirelli, J.F. (1995). Solving the CIO Dilemma. Information Week (March 20), 188. Mitchell, E. (1993). Crisis Management: Weathering the Storm. Public Relations Journal 49(2) 11-13, 25. Mitroff, I.I. (1988). Crisis Management: Cutting Through the Confusion. Sloan Management Review (Winter) 15-20. Mitroff, 1.1., Shrivastava, and Udwadia, F. (1987). Effective Crisis Management. Academy of Management Executive 1(4), 283-292. Mitroff, I.I, Pauchant, T.C., and Shrivastava, P. (1988). The Structure of Man-made Organizational Crisis: Conceptual and Empirical Issues in the Development of a General Theory of Crisis Management. Technological Forecasting and Social Change, 33, 83-107. Mitroff, I.I., Pauchant, T., Finney, M., and Pearson C. (1989). Do (Some) Organizations Cause Their Own Crises? Cultural Profiles of Crisis Prone Versus Crisis Prepared Organizations. Industrial and Environmental Crisis 3, 269-283. Mone, M. A , McKinley, W. and Barker, V. L. Ill (1998). Organizational Decline and Innovation: A Contingency Framework. Academy of Management Review 23(1), 115-132. 250 Bibliography Monge, P.R. (1990). Theoretical and Analytical Issues in Studying Organizational Processes. Organizational Science 1(4), 406-430. Mone, M.A. and Baker, D.D. (1992). Antecedents and Consequences of Personal Goals: An Empirical Evaluation. Motivation and Emotion 16, 297-321. Morin, E. (1993b). Enantiodromia and Crisis Management: A Jungian Perspective. Industrial and Environmental Crisis 7(2), 91-114. Morgan, H. and Soden, J. (1973). Understanding MIS Fadures. Database 5(1). Morse, J.M. (Ed) (1992). Qualitative Nursing Research: A Contemporary Dialogue. Sage, Newbury Park, CA. Naumman, J.D. and Jenkins, A.M. (1982). Prototyping: The New Paradigm for Systems Development. MIS Quarterly 6(3), 29-44. Near, J.P. and Jensen, T.C. (1983). The Whistle-blowing Process: Retaliation and Perceived Effectiveness. Work and Occupations 10, 3-28. Near, J.P. and Miceli, M.P. (1985). Organizational Dissidence: The Case of Whistle-blowing. Journal of Business Ethics 4, 1-16. Near, J.P. and Miceli, M.P. (1986). Retaliation Against Whistle Blowers: Predictors and Effects. Journal of Applied Psychology 71(1), 137-145. Near, J.P. and Miceli, M.P. (1987). Whistle-Blowers in Organizations: Dissidents or Reformers? In, Cummings, L.L. and Staw, B.M. (Eds), Research in Organizational Behavior 9, 321-368. JAI Press, Greenwich, CT. Near, J.P. and Miceli, M.P. (1995). Effective Whistle-Blowing. Academy of Management Review 20(3), 679-708. Newman, M. and Robey, D. (1992). A Social Process Model of User-Analyst Relationships. MIS Quarterly (June), 249-265. Occasio, W. (1995). The Enactment of Economic Adversity: A Reconciliation of Theories of Fadure-induced Change and Threat-rigidity. In, Cummings, L.L. and Staw, B.M. (Eds), Research in Organizational Behavior 17, 287-331. JAI Press, Greenwich, CT. Orlikowski, W.J. and Baroudi, J.J. (1991). Studying Information Technology in Organizations: Research Approaches and Assumptions. Information Systems Research 2(1), 1-27. 251 Bibliography Oz, E. (1994). When Professional Standards are Lax: The CONFIRM failure and its lessons. Communications of the ACM 37(10), 29-41. Parmerlee, M.A., Near, J.P. and Jensen, T.C. (1982). Correlates of Whistle-blowers' Perceptions of Organizational Retaliation. Administrative Science Quarterly 27, 17-34. Patterson, B. (1993). Crisis Impact on Reputation Management. Public Relations Journal 49(11), 48, 47. Pearson, C M . and Clair, J.A. (1998). Reframing Crisis Management. Academy of Management Review 23(1), 59-76. Pearson, C M . and Mitroff, I.I. (1993). From Crisis Prone to Crisis Prepared: A Framework for Crisis Management. Academy of Management Executive 7(1), 48-59. Perrow, C. (1981). Normal Accident at Three Mile Island. Society 18, 17-26. Perrow, C. (1984). Normal Accidents: Living with High-risk Technologies. Basic Books, New York. Petroski, H. (1985). To Engineer is Human: The Role of Failure in Successful Design. Macmillan, New York. Pfeffer, J, (1981). Management as Symbolic Action: The Creation and Maintenance of Organizational Paradigms. In, Cummings, L.L. and Staw, B.M. (Eds), Research in Organizational Behavior, 13(1), 1-52. JAI Press, Greenwich, CT. Pfeffer, J. and Salancik, G.R. (1978). The External Control of Organizations. Harper & Row, New York. Phililiber, S.G, Schwab, M.R. and Samsloss, G. (1980). Social Research: Guides to a Decision Making Process. Peacock, Itasca, IL. Quarantelli, E.L. (1988). Disaster Crisis Management: A Summary of Research Findings. Journal of Management Studies 24(4), 373-385. Rai, A. and Howard, G.S. (1994). Propagating CASE Usage for Software Development: An Empirical Investigation of Key Organizational Correlates. OMEGA 22(2), 133-147. Ragin, C.C. (1987). The Comparative Method: Moving Beyond Qualitative and Quantitative Strategies. University of California Press, Berkeley, CA. Reilly, A.H. (1992). The Technology of Effective Crisis Management: More Than The Daily Routine. Journal of High Technology Management Research. 252 Bibliography Reilly, A.H. (1993). Preparing for the Worst: the Process of Effective Crisis Management. Industrial & Environmental Crisis Quarterly 7(2), 115-143. Reilly, A.H. (1993b). The Technology of Effective Crisis Management: More Than the Daily Routine. The Journal of High Technology Management Research 4(1), 27-46. Renzetti, C M and Lee, R.M. (1993). Researching Sensitive Topics. Sage Pubhcations, Newbury Park, CA. Richardson, B. (1993). Why We Need to Teach Crisis Management and to use Case Studies to Do it. Management Education and Development 24(2), 138-148. Robey, D. (1979). User Attitudes and Management Information System Use. Academy of Management Journal 22(3), 527-538. Rosenfeld, P.M. and Giacalone, R.A. and Riordan, CA. (1995). Impression Management in Organizations. Routledge, New York. Ross, J. and Staw, B.M (1986). Expo86: An Escalation Prototype. Administrative Science Quarterly 31(2), 274-297. Ross, J. and Staw, B.M. (1993). Organizational Escalation and Exit: Lessons From the Shoreham Nuclear Power Plant. Academy of Management Journal 36(4), 701-732. Rothfeder, J. and Driscoll, L. (1990). CIO is Starting to Stand for 'Career is Over'. BusinessWeek (February 26), 3147,78 Rubin, J.Z. and Brockner, J. (1975). Factors Affecting Entrapment in Waiting Situations: The Rosencrantz and Guildenstern Effect. Journal of Personality and Social Psychology, 31, 1054-1063. Sannella, D. (1988). A Survey of Formal Software Development Methods. Working paper ECS-LFCS-88-56, Laboratory for Foundations of Computer Science, University of Ediburgh. Schlenker, B.R. (1980). Impression Management. Wadsworth, Belmont, CA. Scott, M.B. and Lyman, S.M. (1968). Accounts. American Sociological Review 33, 46-62. Seley, J.E. and Wolpert, J. (1988). Issues in Emergency Planning for Nuclear Accidents: The Three Mile Island Context. Industrial Crisis Quarterly 2(2), 171-184. Seligman, M. (1975). Helplessness: On Depression, Development and Death. Freeman, San Francisco. 253 Bibliography Senn, J.A. (1978). A Management View of Systems Analysts: Failures and Shortcomings. MIS Quarterly 2(3), 25-32. Shaw, T. and Jarvenpaa, S. (1997). Process Models in Information Systems. Working paper, MSIS Department, University of Texas at Austin. Shrivastava, P. (1993). Crisis theory/Practice: Towards a Sustainable Future. Industrial and Environmental Crisis 7(1), 23-42. Sitkin, S.B. (1992). Learning Trough Fadure: The Strategy of Small Losses. Research in Organizational Behavior, 14, 231-266. Smith, D. (1990). Beyond Contingency Planning: Toward a Model of Crisis Management. Industrial Crisis Quarterly 4(4) 263-275. Smith, D. (1991). Hints of a Break at the Leading Edge. The Higher (September 27), 16. Smith, D. and Sipika, C. (1993). Back from the Brink - Post-Crisis Management. Long Range Planning 26(1), 28-38. Snyder, C.R. and Higgins, R.L. and Stucky, R.J. (1983). Excuses: Masquerades in Search of Social Grace. Wdey, New York. Snyder, C.R., Higgins, R.L. (1990). Reality Negotiation and Excuse-Making: President Reagan's 4 March 1987 Iran Arms Scandal Speech and Other Literature. In Cody, M.J. and McLaughlin, M.L. (Eds), The Psychology of Tactical Communication, 207-228. Multilingual Matters, Clevedon, PA. Somers, M.J. and Casal, J.C. (1994). Organizational Commitment and Whistle-Blowing. Group and Organization Management 19(3), 270-284. Stake, R.E. (1994). Case Studies. In Denzin, N.K. and Lincoln, Y.S. (Eds), Handbook of Qualitative Research pp. 237-247. Sage Publications, Thousand Oaks, CA. Standish Group International. (1995). The Chaos Report. Paper avadable at http://www.standishgroup.com. Starbuck, W.H. Greve, A. and Hedberg, L.T. (1978). Responding to a Crisis. Journal of Business Administration 9(2), 112-137. Starbuck, W.H. and Milliken, F.J. (1988). Challenger: Fine-tuning the Odds Untd Something Breaks. Journal of Management Studies 25(4), 319-339. 254 Bibliography Staw, B.M. (1976). Knee-deep in the Big Muddy: A Study of Escalating Commitment Paradigm. Organizational Behavior and Human Performance 16, 27-44. Staw, B.M. and Fox, F. (1977). Escalation: Some Determinants of Commitment to a Previously Chosen Course of Action. Human Relations 30, 431-450. Staw, B.M. and Ross, J. (1987). Behavior in Escalation Situations: Antecedents, Prototypes, and Solutions. In B.M. Staw and L.L Cummings (Eds.), Research in Organizational Behavior (9), JAI Press, Greenwich, CT, 39-78. Staw, B.M.. Sanderlands, L.E. and Dutton, J.E. (1981). Threat-Rigidity Effects in Organizational Behavior: A Multilevel Analysis. Administrative Science Quarterly, 26: 501-524. Stokes, J. (1995). Denver Airport Finally Cleared for Takeoff. The Houston Post (February 26), CI. Stokes, J. (1996). Airport is a White Elephant No More. The Des Moines Register (January 21), 1. Street, M.D. (1993). Cognitive Moral Development and Organizational Commitment: Two Potential Predictors of Whistle-blowing. Journal of Applied Business Research 11(4), 104-110. Suchman, M.C. (1995). Managing Legitimacy: Strategic and Institutional Approaches. Academy of Management Review 20(3), 571-610. Sutton, R.I. (1990). Organizational Decline Processes: A Social Psychological Perspective. In, Cummings, L.L. and Staw, B.M. (Eds), Research in Organizational Behavior 12, 205-253. JAI Press, Greenwich, CT. Tait, P. and Vessey I. (1988). The Effect of User Involvement on System Success: A Contingency Approach. MIS Quarterly (March 1988), 91-108. Terpstra, D.E. and Baker, D.D. (1988). Outcomes of Sexual Harassment Charges. Academy of Management Journal 31, 185-194. Terpstra, D.E. and Baker, D.D. (1992). Outcomes of Federal Court Decisions on Sexual Harassment. Academy of Management Journal 35, 181-190. Thompson, J.D. (1967). Organizations in Action. McGraw-Hill, New York. Tsang, E.W.K. (1997). Organizational Learning and the Learning Organization: A Dichotomy Between Descriptive and Prescriptive Research. Human Relations 50(1), 73-89. 255 Bibliography Turner, J.A. (1982). Observations on the Use of Behavioural Models in Information Systems Research and Practice. Information and Management 5(3), 207-213. Tushman, M.L. and Romanelli, E. (1985). Organizational Evolution: A Metamorphosis Model of Converge and Reorientation. In, Cummings, L.L. and Staw, B.M. (Eds.), Research in Organizational Behaviour 7, 171-222. JAI Press, Greenwich, CT. Vessey, I. (1995). CASE Tools as Collaborative Support Technologies. Communications of the ACM 38(1), 83-95. Victor, B., Trevino, L.K. and Shapiro, D.L. (1993). Peer Reporting of Unethical Behaviour: The Influence of Justice Evaluations and Social Context Factors. Journal of Business Ethics 12, 253-263. Wholey, J. (1979). Evaluation: Performance and Promise. Urban Institute, Washington, DC. Wilder, C. (1990). Turnover: The IS Occupational Hazard. Computerworld (July 30), 51. Weiner, B. (1988). An Attributional Theory of Motivation and Emotion. Springer-Verlag, New York. Weick, K.E. (1988). Enacted Sensemaking in Crisis Situations. Journal of Management Studies 25(4), 305-317. Weinsten, D. (1979). Bureaucratic Opposition. Pergamon Press, New York. Whyte, G. (1986). Escalating Commitment to a Course of Action: A Reinterpretation. Academy of Management Review 11(2), 311-321. Wilks, S. and Dyson, K. (1983). The Character and Economic Context of Industrial Crises. In K. Dyson and S. Wilks (Eds.), Industrial Crisis: A Comparative Study of the State and Industry, Martin Robertson, Oxford, 1-25. Yin, R.K. (1981). The Case Study Crisis: Some Answers. Administrative Science Quarterly 26, 58-65. Yin, R.K. (1982). Studying the Implementation of Public Programs. In Williams, W. et al (Eds), Studying Implementation: Methodological and Administrative Issues, pp. 36-72. Chatham House, Chatham, NJ. Yin, R.K. (1994). Case Study Research. Sage Publications, Thousand Oaks, CA. 256 Appendix 1 NORTHERN UTILITIES CASE HISTORY I think the signs were there very early. We didn't figure them out until way later. N U senior manager 257 Appendix 1 1. Company Overview Northern Utilities (NU) was established in 1920 to distribute electricity and gas to the residents of the town of Alexandria, a suburb of a major metropolitan area in Canada. During the first year of its operation, NU distributed electricity to a few dozen customers and serviced less than a hundred streetlights. Today, NU is among the largest municipal service providers in Canada and services around 135,000 electric and 89,000 gas customers (see Table Al-1) NU consists of two legal entities: the electric and gas utilities. A public commission of three elected members, including the mayor of Alexandria, oversees both utilities. A general manager and four directors manage NU's operations. Each of the directors manages one of NU's four divisions: electric, gas, customer services, and corporate support (see Figure Al-1). The electric services division is responsible for managing the acquisition and distribution of electricity. The gas services division manages similar activities related to the distribution of Table Al-1: Summary of Operations Electric Service 1995 (in 1994 (in 1993 (in thousands) thousands) thousands) Revenue $336,425 $336,101 $336,045 Cost of Supply $295,320 $291,234 $291,098 Oper. Expenditures $34,210 $34,305 $33,987 Customers 135 133 132 Gas Service 1995 (in 1994 (in 1993 (in thousands) thousands) thousands) Revenue $60,512 $60,201 $59,834 Cost of Supply $48,069 $45,292 $44,127 Oper. Expenditures $22,047 $21,933 $21,002 Customers 89 88 88 gas. The customer services division is an integrated service department providing a single point of contact to both electric and gas customers. The corporate support division manages the internal operations of the organization including accounting, human resources, and information systems. As the latter two divisions provide services to both utilities, their operating expenses are treated as overhead and are allocated to the two utility divisions. 2. Information Systems Department Computers were first introduced to Northern Utilities in the 1970's and until 1980 they were used exclusively by the finance department. In 1980, NU acquired a customer billing commercial package. Both the financial and customer applications were written in COBOL and were supported by a large number of in-house programmers. Since 1980, NU has made significant investments in information technology. In the early 1980s, a $1.4 million supervisory control and data acquisition (SCADA) system was developed. 1986 saw further advances into the use of computers with the acquisition of a computerized purchasing system. The same year computer-aided engineering systems were introduced in the 258 Appendix 1 engineering department. By the early 1990's, NU replaced its original customer bulling application with a customer information system (CIS). CIS, a third-party program written in business basic, is the largest apphcation currently maintained by the department. In 1992, in an effort to move away from mainframe operations, NU acquired Oracle database software that was used for the development of many applications, including the transformer information, optimal preventative maintenance, street light, and demand maintenance information systems. Figure Al-1: Northern Utilities Organizational Structure Commission General Managei Cliff Stone Director Gas John McHenry Director Electric Didrik Faye Director Customer Service Derek Gagnie Director Corp. Support Don Smith Most of the company's current applications reside on two IBM RS/6000 powerservers. To support NU's communication and data systems, the department has instaUed an extensive wide-area, 350-node network. This network is distributed among four sites that are linked by fiber cables. The network is used for voice, data, and PBX links. Because NU's uses only a small percentage of the network's capacity, it has recently begun providing network services to outside parties. In 1994, the company's network infrastructure was featured in a computer magazine as an exemplar of reliable network architecture. The IS department is part of the NU's corporate support division (see Figure Al-2). The department currently employs 19 IS professionals and operates with a total annual budget of $2 million. Untd recently, the IS department had a staff of about 40 individuals. In the early 1990s, the IS department was downsized because the COBOL-based financial and customer billing systems were replaced and NU no longer needed the programming staff. With the increased sophistication of software packages and the avadability of outsourcing services, NU decided that its IS department would focus on maintaining and operating the existing systems, supporting the users, and diminish its development work. At part of this downsizing, NU dismissed many of its programmers, the IS manager, and the assistant manager (who have been employed by NU for 25 and 17 years respectively). The current manager, Ray Green, was promoted to manager of programming operations and another 259 Appendix 1 individual was hired as the manager of the support operations. Shortly after this reorganization, the manager of support operations left, the two areas were merged, and Green became the manager of IS services. Figure Al-2: Corporate Support Organizational Chart Director Corp . Support Don Smith Manager Financial Serv John Linas 14 Manager Safety & Training 4 Manager Purchasing 5 Manager Property Manager Info. Sys. Ray Green 18 Manager Human Res. Manager Stores M anager Fleet & Equipment 25 Note: The number inside the box indicates the number, o f people in the department Secretary Software Coordinator Systems Programmers 2 Computer Operators 2 Senior E n d User Programmers Support 5 6 Operations Analyst Like many other IS departments, NU's department is mostly viewed as providing a support service. Users report low satisfaction with its services. As one manager pointed out: The IS staff used to be powerful when everything was running off that mainframe, so they had the big say on how things were done. When PCs came in and things started running on smaller machines and packaged software, they started to lose their grip. 3. Project Background In the early 1990s, NU held a series of planning sessions to establish a new strategic direction. After considering recent environmental changes (such as the recession) and expected future trends (such as governmental shifts toward utility deregulation), NU attempted to improve its service quality, human resource management, and overall financial position. As part of these initiatives, NU downsized its employee base (from about 550 to 450 employees) and reorganized its 10 divisions into the four depicted in exhibit 2. The management of NU created this new organizational structure, consisting of the two main utility divisions and the two integrated support divisions, in order to reduce costs (by 260 Appendix 1 merging duplicate services in the two utilities), improve customer service, and to facilitate better communication between the commission and NU's senior management. Another initiative, which resulted from these strategic sessions, was the development of a new internal management information system (IMIS). The corporate support division initiated this project in order to implement a new integrated accounting system that would replace many aging legacy applications. These included the current work orders, general ledgers, budgeting, general journals, accounts payable, miscellaneous accounts, accounts receivable, labor distributions, payroll, purchase orders, material requisitions, inventory, committed stock, CU estimating, and job costing systems. These mainframe systems had gone through a substantial number of hard-code modifications to incorporate many changes since their initial development. As a result of this patchwork approach, it became very difficult to maintain and further update the applications.17 As one director of NU observed: Our existing financial systems were, in a word, old enough to vote. They were homegrown systems running on a mainframe written in COBOL. They'd been mish-mashed. The documentation was nonexistent or insufficient for most parts. The people who had written parts had come and gone. So whenever you wanted to change something, you basically ended up having to recode the entire system. Because of the changing nature of our business, we made a fundamental decision to replace these systems with more flexible, client-server database systems. As part of the changes that followed the strategic planning sessions, NU's management began to radically alter many of its internal organizational processes. One such major change was the institutionalization of a new internal accounting system based on activity-based costing (ABC). Having realized the close interconnection between activity-based management (ABM) and the financial reporting capabilities of the future IMIS system, these two efforts were merged, essentially transforming the IMIS development process into a strategic, reengineering project with a greatly expanded scope. As one of the project leaders commented: IMIS started out as a financial IS project. By the time we had begun implementing, its scope was so large that we expected that it should solve all ills and maybe get at world hunger while we're at it! 4. Vendor Selection To manage the planning of this project, a small team of corporate services staff was formed in 1993. The team developed a formal business case and sent a request for information (RFI) to several vendors. After a review of the responses, NU decided that the project was indeed viable and a package solution would be the appropriate choice. In August 1993, a four-person vendor selection team was formed and a request for proposal (RFP) for a package solution was send to the five top-ranked firms that responded to RFI and five system integrators, including Oracle Corporation. Even though Oracle was not among the top five potential 1 7 By the 1990s, and as a resul t of a l l these accumulated system modif ications, the accounting database was using a 44-character-long key to keep track of al l the current transactions! 261 Appendix 1 vendors (based on the RFI responses), it was included in the RFP pool because at the time it had just announced the introduction of a new project accounting software. By October 1993, NU received four proposals for the project, ranging in cost from less than two million to over four million dollars. The least expensive proposal was from Oracle. In addition to its price, Oracle's proposal was appealing for two other reasons. First, the proposed systems would be based on an open, relational database technology that would easdy support integration with future systems. Second, Oracle's management was interested in entering the Canadian utility services sector and saw this as an opportunity to develop \"a showcase in the public utilities market to leverage additional opportunities that may arise.\" Thus, the potential for a successful partnership was great for both parties. Despite these advantages, Oracle's proposal did not receive the full support of the selection committee. Many users felt that the proposed solution, which consisted of nine applications from the Oracle's suite of manufacturing and project accounting products and one custom-written time-card management system, was not appropriate for the unique processes of a utility company: There were a lot of pitfalls in a lot of the packages and most of them had to do with the fact that our accounting rules are unique because of all of our legislation. We're actually dealing as two different companies. So you've got all of the utility rules that are governed by the power act. And then you've got the gas utility that's governed by additional accounting legislation. So trying to get one package that will accommodate the variations that will have to exist was really difficult. A comment from another participant indicates that simdar concerns were also raised within Oracle: I found out that some of Oracle's consultants recommended that they turn down the job because they didn't feel there was a good fit between their product and our business. If you look at what we do, we're a utility; we don't make anything per se. We don't manufacture cars or widgets. We're a service organization and we were buying a manufacturing package! Why is a utility buying something that is designed to deal with a company that produces an end product? You can stretch it. We build poles. That is a stretch. Also, the project accounting systems were designed more for a consulting firm, like an architect or accounting audit firm\u00E2\u0080\u0094companies that deal with projects. Those systems have a front end, a back end; they charge salaries on their statements. We don't. Our business is very different. NU management's most serious concern with Oracle's proposal was the lack of integration among some of the applications in the proposed solution. The Oracle applications were developed as stand-alone products for the most part. Even though there was standards for data interchange between these applications, many of the needed interfaces did not exist and had to be developed. As part of the proposal, Oracle offered to implement these interfaces for NU if its management was willing to pay for the development costs. Given these concerns with the Oracle proposal, the vendor selection committee rejected it. 262 Appendix 1 Because of the project's importance for Oracle, the president of Oracle Canada entered into negotiations with NU's general manager to formulate a more attractive proposal. These negotiations took place during the first half of 1994. As part of this process, Oracle conducted a rescoping exercise, costing $30,000 to NU, to refine the project's scope and activities. After the completion of the rescoping project, an agreement was reached for the development of a strategic partnership. Under this new plan, Oracle agreed to absorb the development costs for the application interfaces, assuming it could resell any software developed for NU. The agreement was signed on September 22, 1994. Support for this agreement within NU, however, was not universal. A number of key users were not supportive because they recommended against the purchase at this time due to their concerns with the functionality of the proposed systems. At the executive level, two of the directors thought that NU would be better off developing its own system in partnership with CIS's vendor. They argued that a custom solution would cost less and be completed sooner than the proposed Oracle solution. 5. Project Management Plan The proposed solution for the development of the IMIS project consisted of 10 Oracle applications, the interfaces among them and a customized interchange program that would allow IMIS to interact with its bank's payment system. The 10 Oracle applications that were included in IMIS were: \u00E2\u0080\u00A2 Project accounting (PA) \u00E2\u0080\u00A2 Material requirements planning (MRP) \u00E2\u0080\u00A2 Bill of materials (BOM) \u00E2\u0080\u00A2 Work in progress (WIP) \u00E2\u0080\u00A2 Inventory (INV) \u00E2\u0080\u00A2 General ledger (GL) \u00E2\u0080\u00A2 Purchasing (PUR) \u00E2\u0080\u00A2 Accounts payable (AP) \u00E2\u0080\u00A2 Human resources (HR) \u00E2\u0080\u00A2 Time-card (TC) To implement these applications, Oracle's development methodology, Application Implementation Methodology (AIM), was customized to accommodate NU's specific needs. The adopted methodology required that each of the above applications go through the following stages before completion: 1. Operations Analysis: Definition of NU's current and future detailed needs using the team storyboarding approach. 2. Education: Training of an implementation team on the new software. 3. Solution Design: Definition of how the software would be used to meet NU's needs. 4. Building: Creating and testing specific interfaces and configuring the software according to the solutions design. 5. Documentation: Tailoring of the software's technical and user reference to NU's specific use. 6. Transition: Data conversion activities 263 Appendix 1 7. Production: Releasing the software and fine tuning the system through a full business cycle. According to the timeline in the project proposal, the original completion date for the IMIS applications was August 1995. This was later changed to January 1, 1996 (see Figure Al-3). The proposal also indicated that, with the exception of the HR application, all applications would be delivered to the users at once. This was an attempt to (1) save the cost of developing temporary interfaces between the old systems and the new IMIS applications and (2) enable the company to fully switch to ABC at the beginning of the fiscal year. The production date for the HR application was set to February to gain a symbolic, early win. Figure Al-3: IMIS Project Gantt Chart Phase Stage Oct 94 Nov Dec 94 94 Jan 95 Feb 95 Ma Ap r r 95 95 Ma y 95 Jun 95 Jul Aug Sep 95 95 95 Oct 95 Nov Dec Jan 95 95 96 1 Operations Analysis 2 Education 3 Solutions Design 4 Build 5 Documentation 6 Transition 7 Production (HR) According to the alliance agreement, the partnership was to be governed by two groups: the project team and the coordinating committee. The project team, which was responsible for the day-to-day operations of the project, consisted of four individuals: a project manager and integration network representative from NU and a project manager and a director of consulting from Oracle. The coordinating committee was responsible for overseeing the project, making decisions about scope modifications, and resolving any differences between the involved parties. This committee consisted of NU's commission chairman and general manager and the president of Oracle Canada. To ensure complete cooperation between the two parties, major decisions regarding the project required the unanimous consent of all of the project management team and coordinating committee members. In reality, IMIS was a user-led project. The two project managers ran it with the help of several application leaders. NU's project manager was John Linas, manager of financial services. NU also selected the director of the gas services division, John McHenry, to act the project's executive sponsor. Oracle subcontracted an independent consultant, Helen Roberts, to be its project manager and assigned a number of consultants to the project. For each application, an application team of about five (mostly clerical) staff was established. As the project progressed, however, most of the application teams shrunk to two people: the application leader and one Oracle consultant. To monitor the progress of the project, the 264 Appendix 1 project leaders and application leaders met every Thursday over lunch to discuss the progress of the various applications.18 Also, the project managers prepared monthly project status reports for NU and Oracle's executives. In general, the IMIS project team lacked two important resources: critical IT know-how and project management experience. The IS department played a minor role in the IMIS project, partly because it lacked client/server (C/S) skills and partly because there was a personality conflict between NU's project manager and IS director.19 Regarding project management skills, Oracle's project manager had never managed a project using Oracle's development methodology and NU's project manager had no prior management experience on a project of this size. Linas had only been involved in a one IS implementation of a small accounting application in his previous job. The selected application leaders also lacked needed project management skills. One stated: A major issue was the people chosen to head up the teams. You had a very mixed bag of people. There was an application leader who is a strong union individual who has been with the organization for many years. You were asking this person to create and develop a system looking right from operations analysis right through to implementation. You're asking him to think freely and all his working life he's been told what to do, when to do it, and how to do it. So he took one look and said \"well what we do in our department works really well, we'll just make Oracle do the same thing.\" Overall, we had very inexperienced people on the project team. None of us had ever implemented a system. None of us have done process re-engineering. None of us had done any of the things being asked to do. I had to write training manuals. I've never written a training manual in my life. I taught a few dozen classes on a specific IMIS application, but I don't like teaching. The people on the teams just did not have the skill set needed. The estimated total cost for the Oracle software and the development services exceeded $2 million. The standard price for the software applications alone was $1.5 million, but as part of the partnership agreement, Oracle agreed to charge only $616,000 (plus $125,000 annual support fees) for it. For the development, integration, and training services, Oracle offered two options to NU. The first option offered a guaranteed fixed price of $1.5 million. The second option offered these services at a discounted consulting rate. Oracle estimated that the price for the second option would be about $1 million. NU's senior management, hoping to minimize the cost of the project, selected the second option. This resulted in the incorporation of Oracle's standard consulting agreement in the partnership document. According to this agreement, any savings occurred during the project would be shared on a 50/50 basis. In case of any overruns attributed to Oracle, Oracle would only be liable up to the amount accrued in its share of the project savings entitlement! Oracle also retained the right to resell any 1 8 A l l N U staff involved i n the I M I S project continued to perform their regular duties i n addit ion to implement ing the project. The executive sponsor continued to be the gas services divis ion director; i n addi t ion, he was overseeing another project on rate changes and complet ing an M B A degree at a local Univers i ty . 1 9 Indicat ive of th is confl ict is the fact tha t the d is t r ibut ion l is t of the project status report, wh ich was prepared by Linas, d id not include the IS director u n t i l four months after the in i t i a t ion of the project, when L inas was asked to do so. 265 Appendix 1 software that was developed during this project to other utilities. 6. Project History The IMIS development process began in October 1994. The Oracle database software was instaUed on a RISC6000 machine and six new PCs were acquired. During the next four months (November 1994 to January 1995), the project activities focused on the first two stages of the development process (education and operations analysis). An application leader described this process: We started off with what we called a \"story boarding\" approach. We went out and started interviewing basically who we felt to be the main users of the information. Users being who would be putting information in as well as getting information out. And asked them from their point of view how they needed the system to work. What did they need to be able to put in it? What did they need to be able to get out of it? And we started documenting all of the things that were deemed to be necessary and from that we started analyzing how we could put it all together. And at the same time we were being trained on the Oracle packages so we're dealing with what can we do functionally in the system and what do this people want done. It was a real learning process for everyone on the team because no one had done this before. No one had reviewed the processes. There was talk even from the Oracle consultants that we should be doing a re-engineering process and our management deemed that to be unnecessary or that if any obvious re-engineering was needed that we could do it part and parcel of the implementation process. By January 1995, two applications were in the solutions design stage (phase 3) and the remaining eight in the operations analysis stage (phase 1). At that time, the implementation of the HR application was postponed untd May 1995 because of \"ineffective training due to software problems and key staff unavadability.\" In February, feedback information sessions took place and, according to the status report, \"these sessions provided a confirmation that the implementation teams are on the right track in meeting the users' detaded needs.\" In spite of this, during the next nine months (February 1995 to September 1995), little progress was made. During this period, the completion dates for the different applications were postponed eight times (see Table Al-2) and none of them had progressed beyond phase 3! 266 Appendix 1 Table Al-2: Stage Completion Delays Status report for Applications status January 95 8 applications in phase 1&2 - stage completion set for February; 2 applications in phase 3 - stage completion set for April. February 95 All applications in same stage as in January; Stage completion dates for four of them extended by up to two months. March 95 1 application progress to stage 3; Stage completion dates for five of them extended by up to two months. April 95 1 application placed on hold; Remaining nine in the same stage as in March; Stage completion dates for four of them extended by one additional month. May 95 6 applications progress to stage 3; stage completion for one of them extended by one month Stage completion for 8 applications in stage 3 set for July. June 95 All applications in same stage as in May; Stage completion for one of them is extended by one month. July 95 All application in same stage as in June; Stage completion for all of them extended by up to two months. August 95 All application in same stage as in July; Stage completion for five of them extended by one month. September 95 All application in same stage as in August; Stage completion for all of them extended by up to two months. The delays were attributed to three major factors: \u00E2\u0080\u00A2 HR department's rejection of the Oracle application: The adoption of the HR application, which was expected to create an early symbolic win for the IMIS project, was strongly opposed by the HR department staff for several reasons. The application lacked the necessary functionality needed to accommodate the needs of the HR operations. Despite earlier promises to HR staff that the application would be customized to support all key HR processes (such as grievance tracking), the application felt short of the HR personnel's expectations. Training of the HR staff was also problematic. The Oracle training manuals arrived weeks late, the network and applications were unable causing a substantial amount of down time, and key users were not available for training. Lastly, and most important, there was a personality conflict between the HR acting manager and the project manager.20 By April 1995, the relationship between the HR management and IMIS project management had seriously deteriorated. The allocated budget for the HR 2 0 The manager of the H R department was a strong supporter of the I M I S project (albeit w i thou t the fu l l support of her staff). Th is manager went on matern i ty leave dur ing the early par t of 1995. The assistant manager, who became the act ing manager of the department, felt t ha t the funct ional i ty of the H R applicat ion was inadequate and resisted i ts adoption. 267 Appendix 1 application was fully consumed and the acting manager was not satisfied with it. She rejected the application and begun investigating other alternatives (including a potential upgrade of the current system). In light of this development, it was decided that a final decision about the fate of the HR application was to be made by June. This deadline was postponed several times during the next five months. During this period, the HR application was placed on hold while the HR department and the project manager negotiated without success. This delay had a significant impact on development work done for the other applications as most of them were designed to be highly dependent on the data contained in the HR application. Coincidentally, in August 1995, Oracle announced the introduction of a new version of its HR application with additional functionality and a Windows-based interface. At that point, it was decided that the HR department was to adopt the new Oracle HR application and an additional $50,000 would be allocated for its implementation. The executive sponsor reflected on this issue and its impact: 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. 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. \u00E2\u0080\u00A2 Scope modifications: Throughout the project, IMIS' future functionality was significantly altered on several occasions. These modifications were the result of new accounting policies and work schedules, subsequent identification of functionality gaps in the applications, and the integration of additional processes which were not originally included in the scope of IMIS. A project team member commented on these changes: After our feedback sessions, we thought we had a handle on what it was needed to complete the project, knowing what we had this year in front of us to get this done. But, every month, every two months, somebody would change the rules. In the process of reviewing the requirements of the system, we asked if we were coming up with the right solution to meet everyone's needs. Invariably, someone would turn around and go \"Well, maybe no\" or \"Yeah, that's a good idea but I think I'd rather do it this way.\" And it kept changing and changing... And you just could not get two steps ahead because every time someone else would want to change it. \u00E2\u0080\u00A2 Lack of support and resources: The project team lacked both internal and external resources to successfully advance the project. Executive support to the IMIS project was 268 Appendix 1 sporadic. For example, during certain feedback sessions no senior managers were present despite multiple invitations. In general, allocation of resources to the project was not a major priority during the initial stages of the project: The project team was poor at getting resources because we relied on individual managers to give resources to the projects and they had other priorities. This wasn't a priority for them. If it wasn't a priority, it didn't get the resources; so the load fell to a couple of select people. Support from Oracle was also poor. Training manuals arrived several weeks late, software did not always properly function during training sessions, and many of the consultants who were assigned to the different applications were inexperienced. Because of the extensive delays that occurred during the first nine months in 1995, the team came under a lot of pressure during the fall of 1995 to complete the project so that IMIS could go live as originaUy scheduled on January 1, 1996. To achieve this, the project managers pursued a number of \"shortcuts.\" For example, it was decided that certain activities, such as budget preparation, were to be performed by another software that would be determined at a later stage. Also, many critical development activities were shortened, postponed, or totally eliminated. The focus of the project management shifted to conversion activities (phases 6 and 7), whde most application teams never completed many of the previous stages (phases 3, 4, and 5). Some of the shortcuts are outlined below: \u00E2\u0080\u00A2 Communication tasks became secondary: The customized documentation for the different applications was never developed. Thus, most users had to rely on Oracle's technical, user-unfriendly manuals for assistance. Also, it seems that communications by application leaders and other users raised with the project managers were not communicated to the senior executives. During two quality assessments conducted by Oracle, in June and October 1995, concerns were voiced about the ability of the MIS department to support a client/server environment. In addition, application leaders raised serious concerns with the functionality of the applications on at least two occasions. Despite these issues, the two project managers gave assurances to the senior managers that the projects would be delivered on time. Simdar assurances were given during the weekly meetings between McHenry and Linas. In September 1995, Linas ceased producing the monthly status reports. No senior executives questioned this in spite of the project's high profile. \u00E2\u0080\u00A2 Major design issues were ignored: Critical interface and functionality design issues were not addressed for a number of applications (including the HR application) and the interfaces between IMIS and other existing systems. The following excerpt from, an emad to the project manager illustrates the magnitude of this problem: It is now December 8th, three weeks to production and from a payroll viewpoint we have not discussed the interface between HR, PA, and payroU. 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. 269 Appendix 1 \u00E2\u0080\u00A2 Testing was not completed: Even after some of the above design issues were dealt with, several applications went into production without fuUy testing their functionality. Almost all applications went into production without testing their interfaces with the other IMIS applications. \u00E2\u0080\u00A2 Production regions were not properly developed: To minimize the risks of software fadure and errors, the set-up data (\"production region\") for the applications must be developed from scratch after successfully completing the testing and before converting to the new systems. According to Oracle experts, this requirement is an extremely critical step (and was clearly documented as such in the original project specifications). The project managers, however, decided to skip this critical step and constructed the production regions by simply copying the \"integration regions\" (i.e., the set-ups that were constructed during application leader training and testing).21 This decision turned out to be highly problematic, as data in the test region were erroneous and incomplete. \u00E2\u0080\u00A2 User training was postponed: Because most of the applications were not ready and fuUy tested before the conversion date, aU training sessions for the users were postponed untd after the \"live date.\" The above actions raised serious concerns within the project team and increased resistance. To reduce resistance, managers were asked to increase their support to the project. In a memo from senior management, it was pointed out that: 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 aU 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. Despite this increased support from upper management, several application leaders raised concerns about the viability of project. In November, a leader wrote a memo, to the project manager, recommending that the conversion be a parallel one and its \"cut off' point be postponed untd June 30, 1996. Simdar suggestions were made when the test data were copied into the productions regions. In an emad to the project manager, an application leader indicated that \"aU the application leaders have decided that they are not in a position to use the production region as it stands now (a mirror image of the integration region).\" After considering this, the project manager replied that \"as of 3:45pm on December 28th, it was decided that we will use the production region as it stands [because] there are no Oracle resources avadable to help back out the region and the project managers feel there is a minimal risk in using it.\" 2 1 This decision was made despite protests by application leaders and the IS department, which would eventually be responsible for the maintenance of I M I S . 270 Appendix 1 Project management spent the later part of December preparing for the conversion. Because not all new systems would be available for on-line processing and the old systems would not be operating after the conversion, it was decided that some processes would be done manually, such as time card data entry, payments to vendors, etc., for an interim period until the new systems could become fully functional. 7. The IMIS Project Crisis NU ceased the operations of the old systems, as planned, on December 31, 1995 even though only three of the ten applications (INV, WIP and BOM) were ready for use. By the third week of January 1996, the project leader, John Linas, left the organization. The executive sponsor, John McHenry, informally took over to oversee the project management's activities. Within a short period of a few weeks, all allocated funds were consumed and Oracle requested an additional $100,000 to continue working on the IMIS project. NU paid the requested amount and hired the then Oracle project manager, Helen Roberts, to be its own internal project manager. By mid-February, all additional funds were also exhausted and Roberts left. At that time, Roberts indicated that the project was \"essentially completed.\" In reality, many applications continued to be nonfunctional, completion deadlines were being postponed multiple times, and the relationship with Oracle significantly deteriorated.22 In spite of these major problems, in March 1996 NU and Oracle co-sponsored a party to celebrate the successful implementation of IMIS! The lack of functional information systems to support the internal operations of the organization, for an extended period of several months, had several consequences for NU. Specifically, the organization was unable to accurately perform the following key operations after January 1, 1996: \u00E2\u0080\u00A2 Control current financial activity: Because the 1996 budget data and actual financial transactions were not entered into IMIS, NU could not monitor its internal operations and cost its current projects. As an executive pointed out, \"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.\" \u00E2\u0080\u00A2 Produce financial statements: Because of the unavailability of detailed records and staff, NU could not satisfy legal regulations requiring that financial statements be produced and submitted to auditors within a specified time period after the end each quarter. Because of the lack of complete financial information, projects could not be appropriately cost. The delay in the preparation of quarterly statements necessitate the renewal of software licenses for the old systems (which contained the 1995 financial information) costing NU tens of thousands of dollars. Most importantly, it placed the whole organization in a significant legal predicament. \u00E2\u0080\u00A2 Process payments: Because of the lack of detailed, easily accessible records, NU was 2 2 Subsequent test ing revealed tha t the process of recording the t ime sheet data and post ing i t to the GL involved seven steps. By the t ime Roberts left, only the f i rs t two of these steps were implemented and tested. 271 Appendix 1 unable to track purchases and issue timely payments to its vendors. Even though most purchases were made on a \"net 30\" basis, some vendors were not receiving payments for four to five months after delivering their services and products. Thousands of payments were made with handwritten checks to keep the vendors satisfied. \u00E2\u0080\u00A2 Track payroll activities: Because the timecard application and the interface between the time card modules and the HR application were far from completion, the HR department issued thousands of paper timecards to capture the payroll data. These timecards were used for almost all of 1996 to keep track of employee attendance. The paper cards were manually processed, on an exception basis only, creating incomplete payroll records for most employees. \u00E2\u0080\u00A2 Control inventory: Because of problems with the MRP application, the organization was not able to accurately track its inventories. In March 1996, after having recognized the serious ramifications of the IMIS project crisis, NU's senior management conducted the IT consulting unit of their auditors, KPMG, to assess the state of the project and provide recommendations for its recovery. 8. Project Recovery The project audit consisted of a series of interviews during the first two weeks in April and cost $25,000. KPMG's audit identified weak project management as the primary cause for the project's failure. Regarding the current state of the project, it found that: \u00E2\u0080\u00A2 There was no confidence in the functionality and rehability of the applications because of lack of testing, (for example, accounts in the AP application did not balance with accounts in GL); \u00E2\u0080\u00A2 Critical applications (such as the timecard module) were unfinished; and \u00E2\u0080\u00A2 There was a significant backlog in data entry that prohibited the production of financial statements placing NU at serious risk. The study concluded that the project was \"recoverable\" and recommended a short-term recovery plan and a long-term stability framework. With strong project leadership and support, KPMG estimated that the financial statements could be generated by June 1996 and an \"acceptable\" system could be functional by September 1996. To achieve these milestones, however, NU needed to hire a full-time project manager, secure Oracle technical resources from a third party, seek the support of its internal IT staff, free the application leaders from their other duties, negotiate with Oracle to fulfill its remaining obligations, and introduce a strict change control process to manage the scope of the project. NU's senior management followed the recommendations in KPMG's report and assigned the executive sponsor as the full-time recovery project manager. They also hired an experienced KPMG project manager to guide the \"project recovery\" team, costing an additional $200,000. The recovery effort was initiated in May 1996 and remained fairly intense for the first few weeks. The recovery team met every morning to discuss its progress and prepared weekly reports and presentations to senior managers. The first set of financial statements was produced in August 1996. The statements could not be readily reconciled, however, because 272 Appendix 1 the different applications did not process the transactions with unique foreign keys. Given that there were about 650 projects in the system, it was very difficult to trace each transaction from the GL apphcation to the specific projects in the PA application. Thus, the reconciliation of the financial statements became a very lengthy process further delaying the production of subsequent quarterly statements and other operations. As the project's executive sponsor pointed out, the accumulating data backlog became an important issue simply because of its large magnitude: One of the things that I never appreciated was that every day that data piles up and doesn't get processed you're getting further and further behind. It gets to the point where every single day becomes critical. One of the reasons it took us until August to get all the data on the system was that by the time we finally got the system working, (which was the beginning of July), there was so much data that you physically couldn't run the six months worth of data. We actually had to segment it into individual months and run it in batches. Each batch took several days, almost a week. So by the time we got the thing working, it took us five more weeks to process all the data through! The recovery process continued for several months. A few applications did not become operational untd the early part of 1997. The time card module became operational in February but its automated interface to NU's payroll system was never implemented due to security concerns with the module. Testing of all IMIS applications was not completed untd the Spring of 1997. During this testing it became apparent that many of the issues associated with the HR, timecard and payroll systems could not be addressed satisfactordy by the current version of the Oracle suite software. Overall, the fadure of the IMIS project cost NU millions of hard and soft dodars. The general manager estimated that the total of this project was about $5 million. Ironically, the coordinating committee, comprised of the NU and Oracle executives, never met during any of the events that took place in this project! Partly because of the IMIS project fadure, another project was initiated and another KPMG consultant was hired in October 1996 to act as an interim Chief Information Officer (CIO). The goal of this project was to study NU's IT organization and infrastructure and develop a new mission and objectives for the IS department. This project lasted a few months and resulted in several organizational changes in the IT organization. The MIS department was reorganized into four units and McHenry became the new CIO of the organization reporting directly to NU's general manager. The new four units of the MIS department are: database management (which oversees the administration of the organizations' databases), network operations (which managers the network infrastructure), end user support (which is responsible for staffing the help desk and providing assistance to all users), and applications support (which is responsible for maintaining, upgrading and developing software applications). In 1997, Oracle announced the release of a new version of its software suite. This new release provided additional functionality that could rectify some of the payroll issues in NU's 273 Appendix 1 systems. Thus, N U decided to upgrade all nine of its applications to the new release.23 Price Waterhouse was hired to implement this upgrade project. According to the contract, Price Waterhouse was 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. According to the new CIO, the terms of the contract reflect some of the learning that took place as a result of their past experience with Oracle. The upgrade project cost a total of $750 thousand. It commenced in July 1997 and was completed, on time and within budget, on November 12, 1997. The H R appl icat ion could not be upgraded by i tsel f so N U decided to upgrade a l l Oracle applications. 274 U Appendix 2 G R E E N V A L L E Y HOSPITAL CASE HISTORY It takes humility and guts to admit that you made a mistake. When we stop covering up and allow people to be human and make mistakes then we'll make good things. G V H Employee 275 Appendix 2 1. The Hospital Green Valley Hospital (GVH) was established in 1897 by the Sisterhood of the Holy Cross. Today GVH is among the major teaching and research hospitals in Canada. GVH provides care for about 200,000 patient days per year using a facility of about 500 beds. Its annual revenue exceeds $160 million and is increasing by about 9 percent annually. Sixty percent of the patients serviced by GVH live in Oxford, a major Canadian city where the hospital is located. GVH currently employs about 3,200 staff; about 500 of them are physicians. Five senior executives\u00E2\u0080\u0094the president and CEO and four vice presidents (VPs)\u00E2\u0080\u0094manage the administration of the hospital. The VP of medicine is responsible for the medical and research activities of the hospital. The VP of patient services is in charge of the nursing and lab staff. The VP of finance is responsible for the financial operations of the hospital. The VP of administration manages the auxiliary staff and services. During the late 1980's, the Canadian health care sector faced severe budget cuts due to adverse economic conditions. The provincial government initiated a series of annual budget cuts and introduced stricter cost control measures in most public organizations, including hospitals. At the same time, the provincial government was planning the implementation of a \"regionalization policy\" that would allow it to further reduce costs and improve the quality of the province's health care services. Under this new policy, the decision-making and oversight responsibilities were transferred from the individual hospital boards of directors and the provincial Ministry of Health (MOH) to regional boards. These regional boards were responsible for allocating funds to the various health care providers in their regions and for overseeing their operations. The membership of the various boards consisted of both elected and appointed members. According to the MOH, the shift of responsibility to the boards would enable the regions to remove duplication, to increase synergies through better coordination, and to better prioritize fund allocations due to their localized knowledge of their communities' health care needs. To prepare the hospital for this transition and to improve its strategic position, GVH hired Mr. Donald Smith as its new president and CEO in 1988. Smith had recently gone through a similar transition at St. Mary's hospital (which is located in another Canadian province). Soon after his hiring, the new president placed a new senior management team in place and restructured the senior management portfolio. As part of this restructuring, he abolished the position of the VP of administration and created two new positions: VP of corporate services and VP of professional and support services. One of the major goals of this new management team was the radical reengineering of the operations of the hospital to improve the quality of care provided to the patients and the efficiency of its operations. Based on his previous experience at St. Mary's, Smith firmly believed that the deployment of sophisticated clinical and patient costing systems could significantly enhance the ability of the hospital to achieve its strategic goals. 276 Appendix 2 2. The Management Information Systems Department Until the early 1980's, information technology received little attention and support from GVH's senior management. Virtually all of GVH's computer applications were designed to support the hospital's accounting and financial processes and provided no support to the clinical staff. Almost all of these programs were developed in-house on an ad hoc basis through informal cooperation between interested users and the four computer professionals (two computer operators and two programmers) employed by the hospital. All of the computer applications developed before 1983 resided on the sole IBM mainframe computer owned by the hospital. The first attempt to introduce planning in the development of GVH's information systems (IS) took place in 1983. The administration of the hospital hired Arthur Andersen to conduct an IS needs review of the hospital. Based on that review, the consultants recommended the acquisition of a patient admission, discharge, and transfer (ADT) system to computerize the hospital's basic patient management functions. A number of interested users, assisted by the Arthur Andersen consultants, developed a request for proposal (RFP) for such a system and began considering several alternatives. As a user explains, this process was cut short by the provincial MOH: At the time, we thought that we would like to choose SMS [as the vendor]. However, that fell through the floor when Medsys, a newly developed hospital information systems organization, came into the market and the then deputy minister said '\"thou shalt,'\" and the sweetener was that if we took this particular software it'd be free. It was hard to argue with free, as we didn't have a lot of money. So our people said 'fine,' and a few of us got the job of implementing the Medsys ADT system. To manage the implementation of the new systems and establish a formal management information systems (MIS) department, the hospital hired its first MIS director, Mr. Ian Crooks, in 1985. The MIS department was placed in the portfolio of the VP of finance because virtually all existing IS applications supported the hospital's financial operations. Despite this attempt to formalize the MIS department, the new director introduced little planning in its operations: Our new MIS director was one of these really sort of laid-back guys who wasn't high on formal processes. He basically said to people like me '\"what do you need?'\" And we said, '\"Gee I think we need X.'\" And he said 'okay' and a month later he'd have somebody working on it. It was wonderful. We ended up with an operating room booking system that is still being used\u00E2\u0080\u0094he got that from a free tape from another hospital. He said \"let's see if we can make this work\" and we did. In a simdar fashion, we budt our own in-house relief booking system to manage our casual staff because we couldn't get anybody to agree to buy one. So one of the programmers built a little system in about a month. We put it in, in 1985 and we're still using it. I trained somebody on it yesterday. We also built an ambulatory care scheduling system and other applications. So most of our systems we did just ad hoc. But we got somewhere. 277 Appendix 2 Under Crook's leadership, the MIS department continued to act in a largely ad hoc fashion with little senior management support and involvement until the arrival of the new president. Due to the conflicting styles of President Smith and Crooks, the MIS director quit in 1988. A participant explained the conflict between their management styles: Ian was pretty good at ad hoc response, and when people asked for something, they got it. But there was no integrated way of going out and seeking input, and there wasn't a lot of direction. So when Don Smith came he said we need direction and he brought in a consulting group to work with us. And Ian basically decided that he wasn't all that keen with the direction because there was a whole lot more structure and formality being put into place and that wasn't his style. He was a doer, he wanted to get on with it, he didn't want to sit around in meetings forever. He was not really your strategic, political kind of person. And he was not about to play political games with Don. And the more the people wanted him to play games, the quieter Ian would get, and that's why he quit. To replace Crooks, a new MIS director, Mr. Doug Carpenter, was hired. Carpenter's management style was more formal than that of Crooks and was congruent with the president's management philosophy. Carpenter initiated a number of formal processes and established an organizational structure in the MIS department (see Figure A2-1). By 1989, the department employed nine full-time-equivalent staff and had a budget of $1 million. Figure A2-1: MIS Organizational Chart Management Information Systems Department Director | Departmental Secretary |_ Manager - Production Communication/Hardware Specialist Operators Assistant Director/ Manager - Hospital IS (HIS) Admin. Analysts 1 Clinical Analysts 3. Project Background By the late 1980's GVH had developed a large number of stand-alone applications to support the administrative and financial operations of the hospital. Despite this, the hospital's administration and clinical staff were dissatisfied with the existing information systems for two reasons: 278 Appendix 2 \u00E2\u0080\u00A2 Lack of integration: Due to the ad hoc approach that was used in early IS developments at GVH and due to the lack of a formal IS strategy and planning process, the various departmental systems were not integrated. Even though this lack of integration was not a major concern until recently, the current pressure from the provincial government to better control costs, eliminate waste, and improve patient care made integration highly desirable: We wanted to improve patient care and we felt that we needed to connect the systems together in order to do our business better. We didn't like the idea that we were putting all this patient demographic data into a computer in multiple, different departments. We felt that this duplication and waste were just no longer acceptable, that even if they were systems supplied by different vendors there had to be integration. And the units were writing and rewriting things, and this was the beginning of budget cutbacks. We'd gone through one set of budget cutbacks, which started to drive this whole process. We knew that it was only going to get worse through time. So we had to do something to become more efficient and improve patient care. \u00E2\u0080\u00A2 Lack of clinical systems: Virtually all of GVH's existing systems were exclusively developed to support the hospital's financial and administrative functions. The lack of clinical systems to support the medical staff impeded their ability to consistently provide high-quality care to the patients. For example, all communications between the medical staff and the support units in the hospital, such as the admitting department, laboratory, and dietary unit, were paper-based (and often in batch mode), making coordination and the efficient allocation of resources very difficult. The following comment by a medical staff member illustrates the difficulties caused by the lack of effective communication systems: It used to be we did all the discharges at ten in the morning, so the world thought the patient was gone when, in fact, many times the patient was still there in his bed until five o'clock at night when the family came to pick him up. Meanwhile, newly admitted patients were arriving and were being sent to the still-occupied beds. This made our jobs very difficult. We needed a solution that would allow us to do the discharges and transfers in real time as they happened. To rectify this situation, the new management team initiated a strategic reengineering effort. The goal of this effort was to \"treat the patient smarter\" by improving care quality, internal communication, coordination, and resource allocation and by reducing wastage and costs by emphasizing \"specific patient costing\" and \"continuous quality improvement.\" A new director of resource management, Ms. Martha Kelly, was hired to lead hospital-wide projects focusing on this reengineering effort. Also, a renewed emphasis was placed on IS development. The following comment illustrates the close coupling between information technology (IT) and the key hospital processes: We wanted to implement process improvements and find ways of treating the same patients smarter. We began by evaluating the care that different physicians provided to the patients. If you look at what different physicians do, you will realize that they treat their patients differently because they all learned at different places. 279 Appendix 2 From beginning to end, that process of treatment performed by only one physician may be good. But, when a different physician tries to look after another's patients, you usually get problems with patients because he tries to look after the patient the way another doctor would, and things are missed. Even when treatments are clinically effective, you may have problems with the cost of the specific treatment. Even though a treatment may have been the best at one point in time, there may be a newer way of doing the same thing that is less expensive. Or, it could be that the newer way is more expensive and yet is not proven to be more effective. So the physicians began examining the way they did their business. They said, \"Okay, for all of these kinds of treatments, let's put guidelines in.\" They went through all the literature, went through all of their processes, and determined optimum procedures. For example, they put guidelines in for how often and under what circumstances they have a patient's blood gasses checked when a patient is on a respirator. In such cases, they need to monitor the patient carefully because they don't want to give him too much oxygen because it can cause brain damage. So you want to make sure that you're monitoring frequently enough. They found out that whenever certain things happened you may need to perform some sort of a procedure on it, but you don't just do it because you \"want to make sure.\" In the last 10 years there have been so many lawsuits and malpractice allegations that physicians have over time increased the checking that they do just because they're concerned. So, to move forward with that kind of change, we needed to provide sophisticated computer support. We discovered through this process that you could only implement so many guidelines in a manual method. To do this you really need to have a computer as a source of reminders for people, particularly in a teaching hospital like GVH. We have staff who are residents and are new every year and we have nursing students who rotate every six weeks. So there's a huge overhead administratively to make sure that these guidelines that we've implemented are passed on to all the new people coming in so that we don't lose ground. To aid the hospital in the development of a comprehensive IS strategy that would support and implement the reengineering initiatives, President Smith hired Datacom Consulting. Smith had developed a good working relationship with Datacom at his previous position at St. Mary's Hospital, where a major IS implementation supported by Datacom was in progress. After an initial review, Datacom identified a strong dissatisfaction with the services provided by the MIS department and pointed out that the fragmented and unstructured nature of the existing systems could not adequately support the new initiatives. To rectify this situation, a strategic information systems (SIS) planning session was initiated in March 1988. After a series of meetings and interviews with the users, the consultants drafted a five-year SIS plan. Among the plan's major objectives was the \"implementation of an integrated management information system capable of providing by-product MIS guidelines and patient-specific 280 Appendix 2 costing information.\" Specifically, this new integrated system was to provide \"as good as or better\" functionality to each of the departments supported by stand-alone applications whde enhancing patient care and nursing unit management, integrating financial and patient care information, and providing electronic links to some of the existing systems used by the pharmacy, lab, and other departments. The plan identified a number of specific applications that would be implemented as part of the SIS implementation. Soon after the completion of the SIS plan, GVH, with the help of Datacom, initiated a procurement process to meet the objectives of the plan. The goal of this process was to identify a commercially avadable \"turnkey\" integrated patient administration and care system (IPACS) that could be fully implemented within four years. To identify such a system, an RFP was prepared and sent to five hospital IS vendors. All five replied with proposals. After a preliminary review and considerable debate among key users, IS staff, and senior administrators, three of the proposals (including one by Medsys) were classified as unsatisfactory due to lack of needed functionality. The remaining two vendors were invited to provide more-detailed proposals and conduct on-site product demonstrations. During the evaluations of the two proposals, there was strong disagreement about the ability of the proposed systems to meet the needs of the hospital. Specifically, the president favored the system proposed by IBAX.2 4 The majority of the users opposed IBAX's proposal because they did not feel it would satisfy their needs. According to GVH's senior management, IBAX's proposal was particularly attractive for three reasons: IBAX's proposal (1) was the least expensive among all submitted (being priced at $5.2 million), (2) supported flexibility and scalabdity, and (3) promised extensive customization of Baxter's existing software products to fit the needs of the Canadian health care sector. Given the recent entry of IBAX into the Canadian marketplace, GVH executives felt that there was strong pressure for IBAX to create a first-class Canadian system: In its proposal, IBAX admitted that this was their first large-scale Canadian hospital implementation. They wanted to use GVH as the basis for the development of a definitive large-scale hospital product for the Canadian market. In order to do that they had to move in two steps: First, the base product would be given some generic major enhancements to bring it up to larger hospital scale and Canadian scale. And then there were some specific customizations for GVH. Even though the scale of modifications was extensive, the company appeared to have the financial depth to undertake this, given that Baxter was behind it. 2 4 Ibax was a joint venture between IBM and Baxter Systems. The purpose of this venture was to \"sell computer software to hospitals and physicians\" in the \"$6 billion American market for health-care information services.\" Even though Baxter Systems was based in the United States, a new Canadian company, Ibax, with about 40 employees was formed to serve the Canadian market. Ibax was currently implementing a major IS project at St. Mary's Hospital, which was Smith's previous employer. Many users attributed Smith's strong support toward the Ibax proposal to his Datacom and Ibax connections at St. Mary's and became quite resentful. To protest Smith's favoritism, they nicknamed G V H \"St. Mary's North\" and were bringing President's Choice grocery bags to work! 281 Appendix 2 According to the users, however, IBAX's proposal suffered from serious shortcomings. The users were not convinced that the proposed systems would offer the needed functionality because the IBAX products were developed for and marketed toward the U.S. health care industry, whose operations and requirements differ significantly from those of the public Canadian health care sector. In addition, many users felt that the existing, in-house-developed, stand-alone applications provided better functionality than various IBAX software modules. The MIS manager also expressed concerns about the technology used in the Baxter systems. These systems were developed using RPG3 2 5 and the AS400 IBM machines to satisfy the needs of medium-size hospitals. Even though IBAX promised to customize their systems to fit the needs of larger tertiary hospitals, such as GVH, the MIS director felt that limitations of the original technology would make such customizations more difficult. To alleviate the concerns of the users and the IT director, IBAX conducted intense discussions with the hospital staff to better identify their needs. IBAX also provided GVH staff with the opportunity to conduct on-site reviews of two Canadian sites that were implementing IBAX systems. Based on these discussions and visits, the users identified a number of necessary custom modifications. IBAX revised its original proposal to reflect the specific requirements of the GVH staff. The managers of the various user departments were asked to review the revised proposal. In September 1989 all involved department managers prepared memos summarizing their evaluations. All managers expressed serious concerns about the proposed systems and did not endorse the proposal. Some of them who conducted their own on-site evaluations by contacting their colleagues at other hospitals implementing IBAX's systems identified several concerns with the systems and IBAX's support services in their memos. The following extract from one of these memos indicates the seriousness of their concerns: The adequacy with which their efforts wdl 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, despite enhancements, falls short of our requirements. Despite these concerns with the proposed systems, less than a month after the managers' feedback was received the senior administration of the hospital tentatively selected IBAX as the preferred vendor for implementing IPACS. This caused a great deal of dissatisfaction among involved users and IS staff. In response to this decision, the second MIS, manager, Doug Carpenter, resigned. According to a tentative understanding between GVH and IBAX, the finalization of the agreement was conditional on successful contract negotiation, approval by the provincial MOH, and receipt of the required provincial government funding. During the subsequent 2 5 RPG3 is a \"punch-card emulator\" programming language tha t was a developed i n the 1970s. This language was developed to help migrate applications f rom a punch card envi ronment to a newer data entry environment. Because Baxter 's systems were w r i t t e n i n RPG3, the i r applications had certain technical pecul iar i t ies l im i t i ng the i r abi l i ty to be easily customized and integrated w i t h other applications. 282 Appendix 2 negotiation phase, IBAX staff conducted about 50 additional on-site users interviews. Over 120 detailed custom modifications were identified and documented in the final draft of the proposal, increasing the cost of the proposal by $700,000. During these negotiations, the senior administration of the hospital submitted the proposal to the hospital board and the provincial MOH. As this was the first full-scale IS implementation in the province, the project received significant political support by the provincial government. By December 1989 the hospital had received the approval of both the board and the ministry. In January 1990, at a pubhc signing ceremony, a \"master agreement\" for the five-year implementation of the IPACS project was formalized between IBAX and GVH. According to the agreement, IBAX was to implement a number of financial and clinical applications for the hospital. The financial applications would be based on the Software 2000 application suite26 and Baxter's material management software. The clinical systems, mostly patient management applications, would be based on Baxter's software that was developed and marketed in the United States. A number of applications (including the hospital's laboratory, pharmacy, radiology, and ICU systems) were excluded from this agreement because their users felt that IBAX's systems were inferior to their existing systems. To implement the proposed system, GVH was to acquire the needed hardware from IBM. The hardware included an AS/400 model B70 computer with 96 MB of memory and eight communication lines, seven 800-MB disks, 106 dumb terminals, 56 workstation printers, and two high-speed printers. The implementation of IPACS was to last five years, from 1990 to 1995, and cost about $5.9 million. 4. IPACS Project History To prepare for the development of IPACS, a number of changes took place within the MIS department. Two project managers (one for the finance and other administrative systems and the other for clinical systems) and network staff were hired to complement the existing skills base. Also, the department was restructured to better accommodate the needs of IPACS. The department's new structure is shown in Figure A2-2. Finally, a search for new IS director was initiated in early 1990. The two project managers worked closely with end users to form informal planning committees for each of the applications. The purpose of these teams was to provide feedback to IBAX consultants, evaluate the development progress, and assist in the training of other users. Many physicians, clinical support staff, and clerical personnel became heavily involved in this process. All of them, however, continued to perform their regular duties. 2 6 This was a th i rd -par ty software suite tha t was to be customized by Ibax to f i t the needs of G V H and the Canadian heal th care sector i n general. 283 Appendix 2 Figure A2-2: MIS Organizational Chart (1996) D i r e c t o r S e c r e t a r y P r o j e c t M a n a g e r F i n a n c e & A d m i n i s t r a t i v e S y s t e r P r o g r a m m e r A n a l y s t s (-4) C o m p u t e r O p e r a t o r s (6) P r o j e c t M a n a g e r C l i n i c a l S y s t e m s M a n a g e r T e c h n i c a l S e r v i c e s D a t a b a s e A d m i n i s t r a t o r S y s t e m s A d m i n i s t r a t o r N e t w o r k M a n a g e r N e t w o r k & P C I n s t a l l e r s (2) To prioritize the development of the various applications, GVH and IBAX decided to begin the implementation of the financial systems before initiating the development of the clinical systems. This was done for two reasons: First, the financial applications, which were based on the Software 2000 suite, required fewer modifications and customizations than Baxter's clinical systems. Second, the existing financial systems were in a bad shape. As one administrator put it: Our finance software was a disaster. It was a very old system that was just hopeless. It crashed more than it ever ran. And so everybody agreed that it was a pretty high priority. We realized that we couldn't run a business if we didn't have the right financial information. Managers need that kind of information. We needed the GL and other functions to work and to be reasonably timely. So all of us, clinical personnel and everybody else, said '\"that's great, fine, go ahead and we won't worry about the clinical stuff for a while.\" The first part of 1990 was devoted to the implementation of two applications: general ledger (GL) and accounts payable (AP). Due to the highly standardized nature of these applications, their implementation required minimal customization. Both applications were operational by the middle of 1990, and their users were relatively satisfied with them. After the completion of the first two applications, the IPACS project team shifted its focus on the implementation of the materials management (MM) application. This application was part of the Baxter (not Software 2000) program suite. Due to a number of issues raised by finance and accounting personnel, its implementation proved to be more difficult than those of the previous two applications: The staff identified a lot of problems in the system. Even though the materials management people who were involved with the system were ready to go live, 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 other things. So we called in some more IBAX consultants and we said, \"This isn't going to work and we cannot go live.\" We had several meetings with them. They actually took two of us down to Florida to 284 Appendix 2 help them come up with the necessary functions and calculations. This delayed the delivery of the MM application and created a lot of resistance among users who felt that the customizations were not satisfactory. While the implementation of the MM application was in progress, a new MIS director, Mr. Andrew Divon, was hired. In addition to managing the MIS department; Divon was charged with the overall responsibility of the IPACS project. At the same time, the MIS department was moved from the portfolio of the VP of finance to that of the VP of corporate services. Incidentally, there was a major reorganization at IBAX at the same time. Its CEO was dismissed by the senior of administration of Baxter Systems.27 This had a serious implication for GVH: The original commitments between IBAX and GVH were both contractual and personal to a degree because there was a strong personal relationship between the CEO of IBAX, the CEO of GVH, and a couple of the local IBM senior staff. They had a very good relationship that made for easy smoothing out of any wrinkles that occurred. After these management shakeups, we did not have that anymore. By the early part of 1991, the MM application was put into operation and the implementation of three financial applications\u00E2\u0080\u0094human resources payroll, accounts receivable (AR), and capital assets tracking (CAT)\u00E2\u0080\u0094was initiated. The users strongly resisted the introduction of the AR and CAT modules because they did not provide the needed functionality. These applications also created additional workload for the users because a number of processes that were previously performed by the existing applications would have to be performed manually after the introduction of the IPACS modules. While GVH and IBAX were negotiating a solution to the AR and CAT introduction issues, the implementation of two clinical systems (OR and ADT) was also initiated. Despite earlier promises by Baxter to highly customize these two products, the actual customizations did not meet the demands of the clinical staff. A participant described the reception of the OR application by the nursing staff: So IBAX says we're going to bring in OR-star\u00E2\u0080\u0094that was the product that they were touting. Well, the people in the OR took one look at it and said, '\"No, this won't work.\" They felt that it didn't match what was in the RFP. The users felt that the OR application was not going to work and was not, in any way, better than what they currently had at the time. It was worse than what they had! We said, \"We don't want this system until you can provide us with a decent wait list system.\" As you know, in Canada, wait fisting is really important. Our government requires information about our average waits, about every patient who has surgery. They want to know what was the longest wait, what was the shortest wait, and a whole bunch of other junk that we have to send to the ministry. This new system didn't even have a wait list because in the States wait lists aren't an issue. So they took that system, they merely changed the date format, they put it in mditary time, and 2 7 Three months after th is incident, the senior management team of Baxter Systems (who f i red the Canadian CEO of Ibax) was f i red as wel l (by Baxter's administrators) ! 285 Appendix 2 that was all the customizing they did! So the people in the OR were not happy. The staff and the nurses in the OR are \"one breed of cat.\" I mean, you just don't fight with them. And they said absolutely no! I mean they would have scalped anybody that would have tried to change their system. That's how strongly they felt. So they basically said, \"Sorry, count us out. We refuse. We'll stay with what we got. Get out of here. We're not going to have anything to do with it.\" The ADT application suffered from similar functionality shortcomings and was rejected by the involved users. In addition, there were a number of technical problems associated with the ADT software: The version of the product that was due to be delivered in 1991 was delivered behind schedule. When it arrived, it was 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 system that they'd been delivered was awkward, cumbersome, not very Canadianized, and not as functional as the system they had already. The systems that GVH was using at that time were considered to be outdated systems. However the users demonstrated that the new Baxter product was more labor intensive to use. Even though it contained a lot more information, it was missing some of the essential information that they needed. Baxter's system was functionally rich, particularly if you were a U.S. hospital\u00E2\u0080\u0094there was a lot of front-end accounting and patient accounting going on. At the same time there were some technical hitches with it. The technical staff had 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, the modifications that were made to this product made it run in a very machine-intensive fashion. Luckily we had a good-size machine, and we were not too concerned. We were, however, concerned with the fact that the way modifications were made left a lot of redundant code in the system. Because the product was so old, the people who were updating it and enhancing it did not want to disturb any of the base product, and they would simply go around it rather than eliminate it. So we had, in fact, huge software files, much of which was redundant code that was left in there because to take it away might bring the whole thing down. By the middle of 1992, the implementation of the ADT program came to a virtual standstill. As one project participant recalls: We had gotten to the point where we did all the conversion preparation. We got ready to move all of the data over, but we were still waiting for the update in the features. 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. The inability to develop a satisfactory ADT application had serious implications for the 286 Appendix 2 whole IPACS project because most of the other applications were dependent on the data that was to be captured and stored in ADT. Frustrated IS staff and users approached the executives of GVH and demanded a resolution to this situation. The newly hired director of MIS and the VP of corporate services put the whole IPACS project on hold and initiated discussions with IBAX in order to find a solution. IBAX conducted a presentation at GVH recommending the replacement of the systems under development with a suite of brand new systems that were about to be announced by Baxter. According to a project participant, their recommendations did not impress the GVH staff: The presentation itself was very slick, but it was very clear that they had such a hefty user base to support and limitations in terms of their working capital that we could not really expect to see any of the new systems for two years. So, we went to the new CEO of Baxter, who was a good turnaround artist, and explained that we had been given these contractual agreements and assurances by 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. It took about four to five months for that to happen because it took a while for the new management team to get established. 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 that would result in extremely high long-term costs.\" They were not prepared to allocate the staff to do it. They had a large user base of generic users from the U.S., and for the amount of money that we had been contracted to pay, they could not deliver the systems. After a detailed review of the project status and lengthy negotiations between Baxter, IBM, and GVH, the three parties reached a mutual agreement in 1992. According to the \"termination agreement,\" IBAX was to return all the payments that GVH made for the software after subtracting about half of the project's incidental expenses. In return, GVH would state that Baxter had completed all of their contractual obligations.28 Even though IBM did not refund any of the payments made for the hardware, it agreed to let GVH exchange some of the hardware that was not needed due to the project's cancellation. The cancellation of this project left GVH in a major predicament. Even though it had upgraded some of the financial systems using Baxter's and Software 2000's applications, none of the legacy clinical systems were upgraded, leaving the clinical staff with almost no computerized support once again. Also, because GVH was planning on having its ADT system replaced, it had not kept up with its vendor's release updates. As a result, the vendor was making noises about ceasing its support for GVH's ADT system. Perhaps the most critical aspect of the project's cancellation was the fact that the widely publicized implementation of the SIS, which was initiated three ago, had consumed over $2 million with almost no results! Six months after th is agreement was signed, Baxter Systems closed down Ibax's Canadian operations. 287 Appendix 2 5. The Recovery Project Due to the political pressure to complete the implementation of the SIS plan within the original budget and time schedule (by the end of 1995), the IS senior managers began prioritizing the SIS activities. They asked each user department to promptly review the current state of their systems and rank their needs in terms of replacing them. Also, the users were asked to review the original RFP and update it to better reflect their current needs. This process was described by one of the managers: I'm told to look at the old RFP that we'd done for IPACS to see if it's stdl valid and add what we absolutely have to have. We weren't allowed to go \"blue-skying\" here. But, if there were some things we felt we absolutely had 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. So, we incorporated the newly identified requirements and clarifications as a supplement to our original RFP. We did this for all of the applications. At the same time, GVH invited four hospital system vendors\u00E2\u0080\u0094including the supplier of its existing ADT system, Medsys\u00E2\u0080\u0094to demonstrate their current software. GVH's senior administration quickly decided to examine the possibility of selecting Medsys to be the supplier of the new systems. GVH submitted the revised RFP to Medsys and gave it the \"first right of refusal.\" This was done for several reasons: \u00E2\u0080\u00A2 By selecting Medsys, GVH did not need to replace all of its existing systems, because Medsys supplied a number of them, including ADT. This would allow GVH to selectively upgrade and replace criticaUy needed applications in a piecemeal fashion whde retaining existing functioning applications. Thus, GVH would be able to keep the cost and implementation time of the recovery project to a minimum. A participant explained the rationale behind this decision: We didn't go out to the market because the idea was that if Medsys would meet our requirements and our needs, either with its existing or planned applications, then it would save us a lot of money because we wouldn't have to buy a new ADT system. We could continue to struggle along with the other systems until we' found something better. \u00E2\u0080\u00A2 Medsys had recently announced the development of new hospital systems with significantly enhanced functionality (compared to the previous generations of Medsys applications). Its new products included new patient management software and new clinical workstation systems. Its new applications were based on a client/server architecture, allowing the integration of its products with GVH's existing and other third-party applications. This was quite beneficial for GVH: We knew that we couldn't replace the ADT and the lab system and a number of other 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 288 Appendix 2 look at where we were going to go with our clinical systems. We didn't look elsewhere 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 because that was the limit of our resources. By that time 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. \u00E2\u0080\u00A2 Medsys was a local vendor and was very interested in working with GVH to fully develop its new software. Medsys offered to use GVH as one of its two beta testing sites, allowing the users to provide feedback and direction to their future software development efforts. The GVH staff favorably received this opportunity for their participation in the software design process: One of the advantages with having gone with Medsys is we had a lot of input into that prototype, and we continue to do so. A number of our staff participated in a couple of design sessions 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 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. I think that one of the reasons why health care hasn't adopted the technology the way the retail industry has is because it hasn't been useful. The technology has got too many limitations to be useful for the kind of work that we do. I have to say I borrowed this one from a physician friend of mine, but \"physicians and nurses do not think linearly.\" What we do is pattern recognition. Unless the systems can support this kind of thinking, they are not very valuable to us. After receiving Medsys's response to GVH's RFP, a newly established clinical systems advisory committee29 conducted a user review. According to the review, the committee concluded that \"the proposed systems provide for most of GVH's requirements and do it in an acceptable way.\" An agreement to implement the systems was signed between Medsys and GVH in 1993. According to the agreement, the Medsys patient care systems would be implemented utilizing the residue of funding left from the cancellation of the IBAX contract. 2 9 Th is was one of three committees established by the new M I S director to coordinate the implementat ion of the various systems and improve the cooperation between M I S and the rest of the hospital . The other two committees were the business systems steering committee and the senior steering committee. 289 Appendix 2 The implementation of the Medsys clinical systems began with the lab communication and ADT systems. This decision was explained by one of the managers: Lots and lots of the literature says that you should give clinical people applications that provide immediate tangible benefits. 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 \"all right, the first phase of the Medsys project would be the lab.\" We'd give the clinical staff the lab results first using a lookup function to get used to the technology and keyboard without having to worry about screwing things up, so that's what we did. We implemented that first. We then also said because we now have a network connection in the wards we'll do the discharges and the transfers on the nursing unit. That's been problematic. The problem is when you're faced with looking after patients or updating a computer system, guess which the nurse does first.... So we have a bit of a problem with the updates, and that drives admitting crazy. While implementing the various Medsys applications, a number of departments, such as Human Resources (HR) and Radiology, decided to acquire their own systems using third-party vendors. As the available funds were extremely limited, stand-alone business cases were developed to justify the acquisition of these applications. For example, the HR department was able to justify the acquisition of a new payroll system by estimating the savings that the hospital would receive from insourcing its payroll operations from a service bureau. In most cases, the integration of these systems with the other hospital systems was facilitated by client/server-based interface engines. In 1994, about a year before the conclusion of the five year SIS plan, president Smith commissioned Datacom again to conduct a formal audit of the whole SIS implementation. The consultants conducted interviews with the users and MIS staff from March until July. At the same time, the MIS department prepared its own \"audit and progress report,\" reviewing the existing IS portfolio. This report was incorporated in the consultant's audit. The Datacom consultants reviewed the status of 26 applications that were included in the original SIS plan. Out of the 26, seven of them were fully completed, 10 of them were being implemented (or being reworked due to the IBAX failure), and the remaining nine were not initiated or faced major implementation issues, such as unclear requirements or lack of funding, which required additional planning and resource allocation. Their review stated that the majority of the financial systems (GL, AP, MM, AR, patient costing, etc.) had been upgraded or replaced. A number of the clinical systems, on the other hand, continued to face several critical shortcomings. As part of their audit, Datacom also reviewed a number of additional systems which were not part of the five-year SIS plan, including 11 unfunded, unintegrated LANs. 290 Appendix 2 The summary of their audit was published in a 50-page report. Parts of the report were selectively disseminated within the hospital during the fall of 1994. According to the report, the review identified strong dissatisfaction with the project, which was explained as follows: In the five years since the formulation of the IS strategy, the environment has changed dramatically. Over the same period, many of the management and physician staff involved in planning the strategy approved by the board had ceased working at GVH before the termination agreement was reached with IBAX. As a consequence, management and medical staff charged with implementing the IBAX and subsequently the Medsys solutions are, in a substantial number of instances, twice removed from the original \"buy-in\" decision. Clearly, a firm institution-wide recommitment to a new information system plan is needed. Overall, the review provided a positive evaluation of the SIS implementation project. It stated that \"based on the independent review and user feedback, foundation financial systems have by and large been satisfactorily replaced/upgraded and base clinical, foundation systems have been successfuUy implemented in the relatively short two-year interval since the faded IBAX implementation effort was terminated.\" Furthermore, the consultants predicted the successful conclusion of at least 10 incomplete applications which were part of the original IPACS project. Based on their review, they deemed IPACS to be a success: The MIS department has implemented essentially 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 1994 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 and get on as soon as possible with formulating a new plan responsive to new needs. Finally, the consultants recommended the following: \u00E2\u0080\u00A2 The creation of a concomitant IS organizational realignment as there exists \"too much friction, distrust, and poor communicating\" \u00E2\u0080\u00A2 The celebration of the SIS implementation success \"instead of carping about what it (wrongly) perceives others have achieved better or sooner\" \u00E2\u0080\u00A2 The restructuring of the IS steering committees \u00E2\u0080\u00A2 The integration and coordination of IS with other key functions, such as resource utilization management, patient costing, and patient care \u00E2\u0080\u00A2 A workshop to discuss and develop a new SIS plan Despite the optimist predictions of the Datacom consultants, not all of the originally specified applications were completed in 1995. In 1995, the MIS director left the hospital. Martha Kelly, the director of the Quality Data Center, assumed the responsibilities of the MIS director and directly reported to the president. Kelly also oversaw health records, admitting, and quality utilization management of the organization. Kelly explained this reorganization: 291 Appendix 2 Most of the stuff I worked at for the last five years has to do with redesigning the way we deliver clinical care. It was the feeling of the CEO that because of the decisions that were made about organizational restructuring, the person who was leading the system redesign issues should also be heavily involved in influencing information systems development. These areas were too disconnected, so IS could potentially go off in one direction and not meet the business needs. I don't know anything about IS, but I know the business really well, and there was a sense that that was what was required. We needed the leadership of someone who knew the business and knew where the business needed to go. As part of this new organizational change, Kelly created an extensive committee structure with heavy user involvement to decentralize decision making. This structure consisted of a number of committees and integrative working groups. A manager commented on the value of this new structure: I think this structure will ensure that some of these high-level decisions aren't made in isolation. For example, if the patient care working group comes up with some sort of system they want to bring, they've got to get the blessing from the infrastructure working group to make sure from a technical side everything is there and it will work. Then, it's got to go to the top management working group to get their approval. Decision making has improved a lot. Some users, however, did not share this'view: It is more difficult to make decisions now. It's slower and usually involves two, three, or four meetings. We now have a whole bunch of committees. While that at least will help us make sure that there is some kind of input or some kind of involvement of more people in the organization, it's cumbersome. We now have this enormously complex structure. There's an information management advisory group to senior management. And then under that there's a clinical group. There's a records group. And there's a technical group. Sure, at least we're getting somewhere and are trying to set some technical standards. It used to be that the MIS department would decide out of the middle of nowhere to move us all to Microsoft Office, for example. Maybe that was the best decision, but they didn't ask anybody. We now have an education group to take care of these changes. This group, however, hasn't had a meeting for a while. And we've got a research group. So, we've got all these groups that are all related to information management. We're still trying to figure out how to get on with fully implementing the Medsys systems. We have a meeting once a month with this clinical-something working group, and the process keeps going on with no end in sight. In 1996, the board of GVH dismissed President Smith, who initiated the SIS plan. By then, most of the IPACS applications, including lab order entry, the new ADT, triage, and a new patient costing system, were working. Furthermore, a number of additional systems, 292 Appendix 2 which were not part of the original IPACS project, were being developed at G V H . 3 0 A number of the original IPACS applications, however, including the clinic administration, patient-scheduling, and nursing systems were not fully implemented yet. A project participant commented on the overall impact of the IPACS project on the current state of IS at GVH: A failure like this could happen again, and it wouldn't be very different because we are working in a political area. When 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 something goes wrong. Well, sometimes it's better to pull the plug, yet you still feel that if I put in that little extra effort, a little bit more money, I'll make it work, so you always have to contend with that as well. There is so much commitment and momentum you cannot stop. And the other thing is that this was the president's solution, as everyone seems to think, but without him making some very strategic decisions, we wouldn't be as computerized today as we are. Okay, he might have made a bad decision, but he got GVH rolling and he got money committed to computerize and he really put GVH on the map. 3 0 By 1996, there were 54 systems and 25 networks w i t h i n GVH. T h i r t y systems and 15 networks were under the responsibi l i ty of the M I S department whi le the rest were managed by the ind iv idua l departments. 293 Appendix 3 ROYAL CANADIAN UNIVERSITY CASE HISTORY It was a blip that lasted three years of effort and one year of service. R C U employee 294 Appendix 3 1. The University The Royal Canadian University (RCU) was established over 70 years ago and is currently one of the largest universities in North America. RCU employs about 2,000 faculty members in more than 100 academic departments, schools, and research centers. More than 30,0000 students are currently enrolled at RCU. RCU's operating income exceeds $300 million. Provincial government subsidies account for about 85 percent of RCU's revenues and student tuition constitute the remaining 15 percent. Since its incorporation, RCU has been considered as one of the premier research institution in North America. Currently, the university receives about $100 million annually in research grants and contracts. About 100 spinoff companies, with more than $700 million in annual revenues, have been established by RCU to market technology and know-how generated by its faculty. RCU formal administration structure includes the President, the Chancellor, the Board of Governors and the University Senate. The President of the University is RCU's chief executive officer and is responsible for its operations. The Chancellor is elected by the University community and represents the University on official occasions. The 15 appointed and elected members of the Board of Governors are responsible for the administration of RCU's property and revenue. The Senate, which has more than 80 appointed and elected members, is responsible for the academic governance of the university. The daily operations of the university are managed by the President, five Vice-Presidents and twelve Deans (see Figure A3-1). The Vice-President Academic and Provost oversees the operations of the academic units of the University. The Vice-President Administration and Finance oversees many of the administrative departments of the University, including Finance, Human Resources, Plant Operations, Security, the Bookstores, Planning & Development, and Purchasing. The Vice-President External Affairs is responsible for all external university relations, fundraising and development. The Vice-President Research oversees the research activities of the University and manages the relationships with grant agencies and private research organizations. The Vice-President of Student Services oversees many of the support operations of the University, including the Registrar, Athletics, Computing, Telecommunications, Housing, Libraries, and Student Services. 2. University Computing Center In the mid-1950's, RCU's president established a committee to assess the university's interest in \"computing machines and the study of automation in general.\" The committee recommended the purchase of a computer for academic use. Contributions from organizations (in exchange for future computer usage) were sought to help pay for its cost. Local firms contributed $20,000 towards this goal. Interestingly, a number of them declined the university's request because they did not see a reason for using such a machine; one of them even replied to the invitation by stating that \"with reference to your 295 Appendix 3 letter of August 20th, I confess that I am unfamiliar with the electronic computer and its possible uses.\" Figure A3-1: RCU's Senior Administration President VP Academic and Provost VP Administration and Finance VP External Affairs VP Research VP Student Services As a result of the committee and president's efforts, RCU acquired its first computer for $60,000 in 1957. This computer was an Alwac III E, a first generation, single-user computer capable of performing 250 instructions per second. This was the second installation of a computer in Canada; the first one was made by the Department of Defense. Alwac III E became very successful soon after its installation. In its first two years of its operation, it was used by more than 25 university departments and 16 outside organizations. Due to the increased demand for computing services and the introduction of newer, more powerful machines, the Alwac III E was replaced in 1961 by an IBM 1620 computer. These two trends, the introduction of more powerful machines in the marketplace and the increasing demand for computing services, continued to play a key role in the university's computer purchasing decisions for a number of years. By the latel980's, RCU had acquired ten new machines, each providing 2 to 15 times the computing power of its predecessor and primarily utilizing the Michigan Terminal System (MTS) as their operating software. At that time, the annual increase in CPU hours was about 20 percent. The arrival of the first computer in 1957 marked the creation of RCU's computing center (CC) which exclusively supported academic computing. A director and two other individuals were hired to staff the center. The responsibility for overseeing the center's operations was assigned to the VP-Academic. Interestingly, its first director later became the president of the university. In the mid-1960's the university decided to acquire computers to support its administrative services as well. RCU established a data processing center (which was independent of the CC) and it was placed under the responsibilities of VP-finance. 296 Appendix 3 Since then, the organization of computing services at RCU went through a number of structural changes. In 1979, the two operations were merged. In the Fall of 1984, the university decided to put renewed emphasis on administrative computing and migrated its old mainframe systems to the MTS platform. At that time, the academic and administrative operations were again reorganized. The administrative systems staff were moved to a new department, Information Systems Management (ISM), under the supervision of VP-Finance; the academic computing services were moved under the supervision of a newly appointed VP Student Services (who received a mandate for improving the university's computing and networking facilities). In 1989, after an internal review, RCU's administration again restructured its computing services. The CC and ISM were integrated into one department, University Computing Center (UCC) and network related services (data networking, cable plant and telephone services) were moved to a newly established Data Network and Telecommunications (DNET) department. In 1989, the UCC employed over 100 staff (3 management staff, 52 programmers and analysts, 42 operations staff and 7 administrative clerks). The staff was organized in several groups: Office of the Director, Academic Operating Systems, Administrative Operating Systems, Educational Services, Computer Operations, Statistics and Numerical Analysis, and Applications Support. The annual budget for UCC was about $6 mdlion; $3.2 million were spent on salaries. Until the late 1980's these funds were directly allocated to UCC as a line item in the university's overall budget. UCC was linked to the rest of the university in two ways. User input was received through a user committee, the Campus Advisory Board on Computing (CABC). CABC was established in 1968 to \"discuss and comment upon future plans and communicate feedback concerning the operations of the center.\" The interface between UCC and senior management was implemented through a direct reporting relationship between UCC's Director, Bob Lewis, and the VP-Student Services, Dr. John Parker. The following comment by a UCC staff member is representative of the perceptions about the weak relationship between RCU's administration and UCC: The VPs that we reported to did not have a good understanding of what was involved. They had a very high level overview of what was happening. I don't think they had a good understanding of really what was involved in providing a computing environment for either academic or administrative computing. They were not familiar at all with the center's operations. I think this low level of involvement was typical in industries that the computing side was still seen as black magic. Computing services were really only understood by people doing it and by key user groups because they were very aware of what was involved. I don't think senior management ever understood our operations. Indeed, the planning, the execution, the operation of computing services was all done by the technical people alone. Having realized some of the problems associated with this reporting structure and the need for better coordination among the various IS and network departments on campus, in 1990 297 Appendix 3 RCU's senior administration hired Dr. David Williamson as its first Associate Vice-President (AVP) of Information and Computer Systems.31 Among his primary responsibilities was the \"integration of the University's various information technology activities, including the activities of the University Computing Services, Networking and Communications, and Information Systems Management.\" Dr. Williamson commented on the responsibilities of his position: I think the university computing services has always had at RCU, and in fact across the country, a very good reputation as a first class service. The other departments were relatively small and less significant at the beginning, when I started. We sort of expanded the role in a way that made it more integrated over computing and communications. Even though the computing center was quite well respected for what it did, due to changes within the university and in the computing environment in general, the administration saw a need for reorganization and direction and probably for getting on with a different role for the 90s than its role in the past. One of the major internal changes that was taking place at the time was the introduction of a charge back system for computing services. In an effort to better control IS expenditures, the President's office recommended the creation of a \"a decentralized budgetary model which encourages users to make informed choices as to which type of equipment or service is most effective, desirable and affordable for their particular needs.\" Under this model, which was initiated in 1989, all new major IS investments would be cost-recovered and the computer services funds would be allocated to the various academic units instead of the central UCC. These units would purchase the needed computing services from UCC under a charge-back system. The decentralization of the computer funds to the units was gradually implemented. During the first year of this model, only 10 percent of the funds were allocated; eventually 100 percent of all computer funds were allocated to the academic units. One VP of RCU explained the rationale behind this decision: It was a time of change and it was not easy for anybody but with the president being as sort of strong willed as he is he felt, and I agreed with him, that decentralization in the longer term was the best bet. It gave individual units choice of what they wanted to do. And the argument that I used to hear was that there would be a lot of unused MIPS sitting on people's desks if you decentralized it. So, if you take the global view of the university there is a lot of redundant capacity and therefore you can have economies of scale by having a central machine and that's a traditional argument. But then my response to it was that if I drive on a highway I see a lot of redundancy with cars having only one passenger. And the reason why we tolerate that one passenger in a car is the individual freedom, flexibility of the people. UCC personnel expressed strong opposition to this decentralization plan partly because of its potential limiting effects on their discretion and partly because it was poorly implemented. One UCC staff member commented: The decentralization process has been proceeding on an ad hoc basis. Our Since th is change, the Director of UCC has been report ing to the A V P instead of the VP-Student 'services. 298 Appendix 3 organization was so uncertain and the critical thing was that the fee for service transition was never outlined in a planned manner. It wasn't clear whether the university wanted us to become fee for service, whether they were going to force us to or not. What was definitely clear was that none of our customers like the idea and the idea was never ever promoted within the university. There was no process by which the university community was involved and could buy into the idea. This transition to a charge-back system, coupled with the availability of more powerful, small machines which were acquired by the users independently, had a negative impact on the perceived power of UCC. This is clearly reflected in the following comment by an academic department administrator: The computing center was technically a very good organization that kind of lost its way in the middle 80s. At that time they were providing less and less of a service. They were becoming less and less relevant to what was going on in our department because the administrative systems were in place and people were using workstations. The computing services has not been a powerful dept within the university since the late 1980's, when they started to decentralize the funding. 3. Project background During the late 1980's a number of science researchers in Chemistry, Physics, Engineering and other disciplines began lobbying the administration of the university to provide support to researchers with numerically intensive computer needs. This group of researchers, led by a Chemistry professor, requested that the current CPU usage rates be reduced for off-peak, intensive use. In addition, they requested that the university seriously consider the purchase of a numerically intensive supercomputer.32 The president, who felt that \"a first-class university should have first class computing facilities available to its researchers,\" positively responded to these initiatives by establishing a committee to evaluate the needs of researchers and recommend solutions. The committee chaired by the VP-Student Services, decided to examine the feasibdity of a supercomputing facdity at RCU. A large number of interested researchers and members of CABC participated in this process. After considering several alternatives, including the possibdity of jointly purchasing a large supercomputer with two other local universities, the committee concluded that the acquisition of a large, numerically intensive computer was pivotal to the future of the university. In response to this, the President created a university-wide selection committee, composed by researchers and UCC staff members and chaired by two senior science professors, to review potential configurations and recommend a solution to the VP-Student Services for purchase. One of the major concerns that was raised during the initial discussions of the committee was the configuration of the potential solution. The style of computing was rapidly 3 2 A t the t ime, very few supercomputing faci l i t ies existed in Canada. Researchers w i t h large computat ional needs could arrange access to these facil i t ies on their own using thei r research funds. I n 1987, RCU's Faculty of Medicine begun prov id ing U N I X accounts to interested researchers i n other facult ies. 299 Appendix 3 changing from processing on large mainframes to smaller machines due to the introduction of powerful workstations. One of the committee members commented: The workstation technology was changing very rapidly and 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 a \"big iron.\" Others were making the decision between doing it on a central machine and their own personal computers. They 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 machine- the cost is fixed. There are no problems in terms of scheduling - you didn'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. The change in computing at the time created a big question for us. 4. Solution Selection After a number of discussions and meetings, the selection committee decided to issue an RFP for a UNIX-based numerically intensive computer as \"the beginning of a more comprehensive network-based large scale computing.33 The RFP was sent to thirty five vendors in April 1988. Thirteen of them responded to it by September 1988. The proposals received by the vendors varied greatly, both in terms of computer architectures and processing power. The proposed solutions included super-workstations, mini-supercomputers, near-supercomputers, supercomputers and various combinations of these. Among them was a proposal by IBM for an IBM 3090 mainframe using AIX. 3 4 The cost of IBM's proposed solution was about $4 million. During the next three months, UCC staff and the selection committee reviewed the submitted proposals for their technical and financial viability. After narrowing their choices down to four solutions, the committee presented its findings and recommendations to the senior administration of the university. However, due to disagreements among its members, the committee never reached consensus in selecting the \"best\" proposal. These disagreements centered on the scale of the facility, its management (whether it should be done centrally by UCC or by the academic departments) and its exact configuration. Even though IBM's proposal was not among the four selected by the committee, the senior administration of the university expressed a strong interest in IBM's proposed solution and engaged in discussions with IBM to refine the proposal and make it more attractive to the University. The apparent support towards IBM's solution was met with strong resistance 3 3 U N I X is an interact ive, t ime-shar ing open operat ing system, which was invented i n 1969. 3 4 A I X stands for Advance Interact ive eXecutive which is IBM's version of U N I X . A t the t ime, I B M had just announced the development of A IX . 300 Appendix 3 by both researchers and UCC staff members. This resistance was caused by concerns about the cost and poor performance of the IBM 3090 computer and the immaturity and instability of the AIX software. Despite the lack of support by the potential users and UCC staff, the University's senior administration continued its negotiations with IBM untd May 1989. During this time, several project participants formalized their disagreement with the university's decision in a number of memos to the VP-Student Services. In a memo, the chair of the selection committee highlighted that that of all the proposed systems, the best performance was offered by a Cray XMP-14 computer. However neither the capital cost of this computer nor its operating expenses could be met without additional outside funding. After considering \"second-tier\" alternatives, he stated that \"on technical grounds, I believe we should recommend the Convex for vector computing.\"35 Similar concerns were expressed by UCC staff who also supported the Convex solution. In a memo, the UCC director explained the center's recommendation: The Computing Centre recommends that the University purchase the proposed Convex C220 system. The Convex is the superior choice because of its: price, software maturity, performance, and ease of installation and operation. The Cray proposal is operationally very expensive and carries too much risk in terms of future cost and installation difficulty. The IBM proposal is too expensive relative to the performance of the computer. In addition, industry observers currently caution against purchase of low-end IBM 3090 computer for economic reasons. Between January and May 1989, intense negotiations took place between IBM and RCU. As a result of these discussions, IBM modified its initial proposal to make it more attractive for RCU. 3 6 Its modified proposal recommended a three year large scale computing software joint study with the university. Under this study, IBM was willing to give RCU free use of an IBM vector facility for the duration of the study and transfer title of the machine to the university upon its conclusion, waive any license fees for the use of AIX for three years, and offer at least a 50 percent discount for such fees after the completion of the project. IBM was also willing to provide RCU with an early support plan (ESP) for its pre-release version of AIX for a few months untd the product became commercially avadable.37 In addition, IBM indicated that it was willing to assist RCU in securing external funding for the acquisition of the machine. Despite the significant improvements in IBM's proposal, the resistance among the computer center staff remained strong. In an 8-page report to the VP-Student Services, one of the senior programmers strongly opposed the acceptance of the IBM proposal because of its risk. The report listed a number of unsuccessful installations (and some 3 5 Even though the performance of the Convex and I B M solutions were comparable, the cost of the I B M solution was signi f icant ly higher than the cost of the Convex one. 3 6 According to I B M personnel, this \"sweetened\" proposal was an at tempt to par t ly improve i ts relat ionship w i t h the univers i ty and par t l y to enable I B M to better establish i tsel f in the U N I X marke t (as i t had unsuccessfully t r ied to do i n the past). 3 7 I B M did not announce A I X as a commercial product u n t i l March 1990. 301 Appendix 3 \"disastrous\" ones) of the IBM 3090 vector facility and stated that the proposed solution offers low performance and high level of software unreliability at a too high price. The report recommended that, should the university accept the proposal, a special clause was to be added to the contract to enable UBC to return the machine if the system was rejected by the users. After considering the proposal and the recommendations of the committee and UCC, the VP-Student Services selected IBM as the winning vendor. Many of the opponents of the IBM solution attributed this to non-technical reasons:38 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 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. But I think it is true that the technical assessment was not that we buy an IBM. According to the \"Academic Information Systems Joint Study Agreement\" that was signed between IBM and RCU, the university was to receive an IBM 3090/150S mainframe with a vector facility operating the AIX operating system under ESP in June 1989.39 The primary of objective of this study was \"to convert the major scientific applications form a non-IBM LSC environment to an IBM environment using ATX/370 and the Vector Facility.\" The study commenced on July 11 and was to be concluded by July 11, 1992. In a related agreement, RCU was to acquire the hardware through a four-year lease according to the following schedule shown in Table A3-1. In addition, IBM agreed to purchase RCU's Amdahl 5860 computer for $165,000. Finally, these agreements were supplemented by a standard \"Government Term Lease Agreeement\" as RCU was a provincial university. As Figure 2 shows, this agreement included a \"non-appropriation system return clause\" that would allow RCU to return the machine under specific conditions. 3 8 Specifically, the par t ic ipants ident i f ied two other issues tha t may have inf luenced RCU's decision. A t the t ime, as pa r t of another b id, I B M was contemplat ing the establ ishment of a local computer lab to support a i r traff ic control systems and R C U was a candidate site for th is lab. Also, I B M was an impor tan t donor to the universi ty ; according to I B M sources, R C U was among the recipients of the largest I B M donations i n Canada. 3 9 This was a single processor I B M 370 Enterpr ise System Archi tecture (ESA) machine and was rated at 12MIPS. The vector fac i l i ty was rated at 10 MFLOPS. I t had 64 megabytes of centra l storage (the m a x i m u m available on th is model). Two I B M PS/2-70s were used as front-end processors. AIX 's Transparent Comput ing Faci l i ty (TCF) was used to connect these machines so tha t they appear as a single computer to the end users. In i t ia l l y , the fol lowing software was instal led on the NICS: AIX/370 operat ing system, F O R T R A N VS compiler, IBM's Engineer ing and Scientif ic Subrout ine L ib ra ry (ESSL), In te rna t iona l Mathemat ica l and Stat ist ical L ibrar ies ( IMSL) , Numer ica l A lgor i thms Group (NAG) L ib ra ry U.S. Depar tment of Energy Laboratories' SLATEC l ibrary, and standard U N I X ut i l i t ies. 302 Appendix 3 Table A3-1: IM] S Lease Schedule Due Lease charge Period covered July 10, 1989 $415,500 July 10, 1989 - July 9, 1990 July 10, 1990 $650,000 July 10, 1990 - July 9, 1991 July 10, 1992 $1,275,000 July 10, 1991 - July 9, 1993 July 10, 1994 $687,000 July 10, 1993 - July 9, 1995 Figure A3-2: Copy of the Non-Appropriation Contract Clause 21. Leasa Not Cain eel Fable'; Lasata's Obli-gations Absolute. \"Ye '~\u00C2\u00ABase cannot be cancel! Ed or te rm i na ted txca.pl as ex-pressly provided in- this Agreement. Lessee's obligation ta pay sha-1 Tbe abso-lute a.ic unconditional. Swcfi oblfgatlan shall ,iat 2e subject lc any del\u00C2\u00BBy, re-duction. Sftt-nff, defence, counier-\u00C2\u00BB1 aim \u00E2\u0080\u00A2>r compensation for any reason whatsoever. 5uch r?vsr, 1t is understood L'nt L C S S E E ^ shal' make bdjja \"ids recuests for appi*c-'-prlitians i>f sufficient funds to piy far;-the '.eased Product! i-d Financed It Bits, covered uy this Agreement. Shouid sucn ' funds .-iot be appropriated\u00E2\u0080\u009E Lessee miy -terminate, the laAse for ary sucn Leased I PrsrJuct Financed Item at any tfne prior-to th<\u00C2\u00BB enn of Lessee's next fiscal year, in such event Lessee ina, 1 "Thesis/Dissertation"@en . "1999-05"@en . "10.14288/1.0089237"@en . "eng"@en . "Business Administration"@en . "Vancouver : University of British Columbia Library"@en . "University of British Columbia"@en . "For non-commercial purposes only, such as research, private study and education. Additional conditions apply, see Terms of Use https://open.library.ubc.ca/terms_of_use."@en . "Graduate"@en . "Managing MIS project failures : a crisis management perspective"@en . "Text"@en . "http://hdl.handle.net/2429/9886"@en .