Understanding the Nature and Extent of IS Project Escalation: Results from a Survey of IS Audit and Control Professionals Mark Keil Dept. of Computer Information Systems College of Business Administration Georgia State University PO Box 4015 Atlanta, GA 30302-4015 (404) 651-3830
[email protected] Abstract Runaway IS projects continue to be reported regularly in the trade press, but surprisingly little is known about: (1) how widespread the problem actually is, and (2) the factors that cause it to occur. Many runaway IS projects appear to represent what can be described as escalating commitment to a failing course of action. A survey of Information Systems Audit and Control Association (ISACA) members was undertaken in order to understand more about the prevalence of IS project escalation and the factors that cause it. The results are startling: Escalation occurs in 30-40% of IS projects and projects that escalate are rarely completed and implemented successfully. What is more, escalation appears to be caused by a combination of project management as well as psychological, social, and organizational factors.
1. Introduction Recent estimates suggest that runaway information systems (IS) projects are costing U.S. organizations billions of dollars each year in both cost overruns and failed projects [7]. The problem of runaway projects was first observed back in the early 1970s when Stephen Keider, in industry consultant, observed that some IS projects never seem to terminate. "Rather," he said, "they become like Moses, condemned to wander till the end of their days without seeing the promised land" [8]. More than twenty years later we still have software projects that fit Keider's description. In this paper, the term runaway is used to describe an information systems (IS) project that seems to take on a life of its own, continuing to absorb valuable resources without ever reaching its objectives [8, 13, 14]. While runaway systems projects have been the focus of numerous press reports [1, 4, 6, 12, 16, 18], little is
Joan Mann MIS/DS College of Business & Public Administration Old Dominion University Hughes 2096 Norfolk, VA (757) 683-3488
[email protected] known about how commonly this problem occurs or what can be done to identify and prevent runaway projects. The Standish Group--a Massachusetts-based consulting organization--estimates that in 1995 alone, U.S. companies spent $81 billion on canceled software projects and an additional $59 billion in cost overruns for software projects that would eventually be completed [7]. Since literally billions of dollars may be at stake, preventing runaway IS projects should be of great concern to IS professionals. While it is true that most runaways are eventually terminated or significantly redirected, there is evidence suggesting that these projects are allowed to continue for too long before appropriate action is taken. While the monetary costs associated with these runaways is quite visible, less tangible costs include: (1) the failure to solve real business problems for which the system was intended, and (2) the opportunity costs associated with spending valuable resources on a failing IS project when these resources could have been put to alternative uses. For all of these reasons, it is important to understand more about the actual frequency of this phenomenon, the factors that promote runaway projects, and the steps that IS professionals can take to minimize the risks to their organizations.
2. Background Many runaway IS projects represent what can be described as continued commitment to a failing course of action, or "escalation" as it is called in management 1 literature [2]. Escalation of commitment to an IS project
1
Escalation does not necessarily imply an increasing rate of investment over time, but rather, refers to a growth in the cumulative amount of resources
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
has been documented in the literature [9, 10], but little is known about the actual prevalence of this phenomenon among IS projects. Previous research suggests that escalation is a complex phenomenon that may be influenced by many different factors. Figure 1 groups these factors into four categories based on a typology proposed by [17]. Project Factors
Psychological Factors
Project
Social
Escalation
Factors
Organizational Factors
Figure 1: Typology of factors that influence escalation behavior Project factors include the costs and benefits associated with the project as well as the expected difficulty and duration of the project. Projects are more prone to escalation when they involve a large potential payoff, when the project requires a long-term investment in order to receive any substantial gain, and when setbacks are perceived as temporary problems that can be overcome [17]. Psychological factors are those that cause managers to become convinced that things do not look so bad after all, or that persistence will eventually pay off [2]. Two such factors include the manager's previous experience in handling similar projects and the degree to which the manager feels personally responsible for the outcome of the project [17]. Generally speaking, projects are more prone to escalation when there is a previous history of success and when there is a high level of personal responsibility. Another psychological factor is the human tendency to "throw good money after bad" in an effort to turn around a failing project, or the so-called "sunk cost effect" [5]. Finally, managers may also engage in a type of self-justification behavior in which they commit additional resources because to do otherwise would be tantamount to admitting that their earlier decisions were incorrect. Social factors can also promote escalation. These factors include competitive rivalry that may exist between different groups in an organization, the need for external invested over time. commitment.
justification, and social norms that dictate what is considered as socially acceptable behavior [15]. Projects are more prone to escalation, for example, when competitive rivalry exists between the group that is funding the software development project and the group that is to serve as the targeted customer or user. Escalation is also more likely to occur when external stakeholders have been led to believe that the project is (or will be) successful or when social norms of behavior favor "staying the course" in the face of adversity. Finally, organizational factors--those involving the structural and political environment that surrounds a project--can also promote escalation. These factors can include political support for the project from powerful managers, the extent to which a manager's power or political fortunes are tied to the success of the project, and the degree to which the project becomes institutionalized with the goals and values of the organization [17].
3. Research objectives and methodology The purpose of this study was: (1) to gather information concerning the frequency of IS project escalation (that is, headlines aside, how often does this problem occur in practice?), and (2) to identify the factors that may cause IS project escalation to occur.
3.1. Approach used to gather data To gain insight concerning these questions, a survey was developed and administered to a large sample of IS audit and control professionals selected from the U.S. membership database of the Information Systems Audit and Control Association (ISACA). IS auditors were chosen as subjects for the study because it was felt that they would provide an unbiased perspective given their prescribed job role. A mail survey was chosen as the most cost effective means of collecting data on a large number of projects. To guard against low response rate, which is viewed as the major risk of conducting a mail survey [11], we followed several key steps from Dillman’s “Total Design Method” (TDM) [3]. TDM is a widely accepted approach for maximizing survey response rates, thus minimizing the potential bias that can result from non-response. The cover letter accompanying the survey was carefully crafted to meet TDM guidelines. The paragraphs of the letter, for example, were designed to convey the importance of the research question, the value of the results that could be obtained, and the critical importance of each individual’s input. The goal behind doing this
Thus, escalation can be thought of as continued
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
was to motivate people to feel rewarded by returning the survey. To provide anonymity for participants and to maintain control over the membership database, the ISACA research organization handled the addressing of both the letters and the outgoing envelopes. Survey recipients were instructed to return their completed survey directly to the researchers in a pre-addressed business-reply envelope, but the identities of the individual respondents were withheld from the researchers, thus encouraging a candid response to the survey questions. To further improve the response rate (while maintaining subjects’ anonymity), a follow-up postcard was sent to all survey recipients) reminding individuals to complete and return the survey if they had not already done so. The follow-up reminder was timed to arrive two weeks after the initial mailing.
chose to focus only on those factors that could most reasonably be linked to escalation behavior.
3.2. Sample selection
The psychological, social, and organizational factors derived from the escalation literature and included in the survey are shown in Table 2.
The sampling design used in this study was to select a sample of ISACA members who would be most likely to be involved in information systems development. Toward this end, the study was focused on internal and external IS auditors. By using the ISACA membership database which contains self-reported job category information, we were able to limit the pool of potential participants to those individuals who were likely to have the greatest exposure to information systems development projects. This pool of individuals--representing all U.S. ISACA members who described themselves as an IS Audit Manager, IS Auditor, Internal Auditor, or External Auditor--included approximately 2500 ISACA members in the U.S.
3.3. Survey development and pre-testing The survey itself was based on a careful review of both the software project management literature and the escalation literature aimed at determining the set of factors most likely to be associated with project escalation. Based upon this review, the survey included both project management related factors as well as a set of psychological, social, and organizational factors derived from the escalation literature. The project management related factors included in the survey are shown in Table 1. The six project management related factors included in the survey represent common themes found in our review of the software project management literature. While there are other project management related factors (e.g., staffing problems), that could have been included, we
Table 1: Project management factors included in the survey Factor Specification Estimation
Planning
Resources Monitoring Control
Definition The degree to which the project team adequately understood user needs. The degree to which the project team adequately projected the timeframe of the project and the resources needed to complete the project. The degree to which the project team adequately addressed issues of scheduling, risk identification and manpower assignments. The degree to which there were sufficient resources allocated to complete the project. The degree to which the project team was able to spot problems in the project. The degree to which the project team was able to get the project back on track when problems arose.
Table 2: Psychological, social, and organizational factors included in the survey Factor Need for Justification
Sunk cost/ completion level Goal Congruency Information Asymmetry Research and Development Perspective Strategic Importance
Definition The degree to which the Primary DecisionMaker(s) are likely to feel responsible for the outcome of the project and the extent to which withdrawal would cause them to lose face. The degree to which the amount already invested or the percent completed influences the decision to continue. The degree to which the project’s Primary Decision-Maker(s) and Senior Management share the same goals. The degree to which Senior Management has the same project status information as the Primary Decision-Maker(s). The degree to which the project is perceived to have a large up-front cost, long-term payoff structure, or large potential payoff if successfully completed. The degree to which the project is perceived as critical to the organization’s ability to compete or survive.
To increase the reliability of the survey instrument, multiple questions were developed to measure each of the underlying factors identified in the literature search. Two different versions of the survey instrument were then developed: one focused on gathering information about cases of IS project escalation and the other focused on projects that did not escalate. The purpose of the latter version of the survey was to provide a reference point, or baseline, to determine whether the pattern of factors associated with projects that escalate is significantly different from the pattern of factors associated with projects that do not escalate.
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
The survey was pre-tested during Spring 1995 with a sample of seven IS audit and control professionals selected from the ISACA membership. Each member who participated in this pre-test was interviewed inperson for a period of approximately one hour during which s/he was asked to complete the survey in the presence of one of the researchers. During these interviews, participants were encouraged to identify questions that did not make sense as worded, were difficult to interpret, or could not be easily answered. Interviewees were also encouraged to suggest additional factors that might cause escalation to occur, but which were not captured on the survey. Both versions of the survey were pre-tested in the same manner. The pretesting was concluded after seven interviews when it became apparent that no new wording problems or escalation factors were surfacing. The pre-testing with ISACA members resulted in several modifications to the survey instrument based on the comments and feedback that were received. Following the pre-test, a pilot test was conducted in which the survey was administered to a sample of approximately 300 IS audit and control professionals. The size of the pilot was determined based upon an estimate of survey response rate and the number of variables on the survey that would be subjected to statistical analysis. The purpose of the pilot, which was conducted during Summer 1995, was to evaluate the reliability and validity of the instrument and to “fine tune” the instrument before administering it on a largescale basis. The pilot also provided information on expected response rates which was useful in validating the estimated sample size that would be needed in the full-scale administration of the survey. For the pilot, the 300 members were split evenly between those asked to select an escalated project and those asked to select a nonescalated project. This was done to determine if the potential response rate would be similar for both versions of the survey and to insure that there would be enough completed surveys to compare the reliability and validity of the two versions. The results of the pilot revealed that both versions of the survey instrument had good reliability and validity and similar response rates. There were, however, several measurement items that were reworded or dropped based on the results of the pilot. These changes were made in an effort to further improve the quality of the survey instrument.
3.4. Administration of the full-scale survey Following the pilot study, the administration of the full-scale survey took place during Fall 1995. The full-
scale administration involved 2,231 ISACA members and represented those individuals who met one of the four job categories described earlier and who had not participated in either the pre-test or pilot phases of the study. For the full-scale administration of the survey, a decision was made to split the sample 70:30 so that 70% of the participants would receive the escalation version of the survey and 30% would receive the non-escalation version of the survey. This was done to maximize the size of the escalation sub-sample while insuring an adequate number of projects in the comparison group. In all cases, the decision was random as to whether a participant received an escalation or a non-escalation survey. Participants who received the escalation survey (n = 1,549) were asked to select a project that they were familiar with that fit the definition of project escalation (i.e., a troubled project--either abandoned or completed-that continued to receive resources even though the respondent believed that the project should have been discontinued or redirected). In contrast, participants who received the “non-escalation” version of the survey (n = 682) were asked to select a completed project that progressed smoothly enough that the respondent never thought it should be discontinued or redirected. Having selected a project that met the desired criterion, respondents in both versions of the survey were then asked to answer more than 50 questions designed to measure whether certain factors that might be associated with escalation were present and, if present, the importance of the factor in explaining why the project was continued. It is important to note that the two different versions of the survey were identical except for the instructions regarding what type of project to select, thus allowing the non-escalation survey group to serve as a baseline for comparison purposes. In addition to questions that were to be completed about a specific project (one that escalated or one that did not), both versions of the survey contained an identical set of questions designed to: (1) gather demographic information, and (2) gauge the frequency of escalation based on the observations and experience of the respondents.
4. Results and discussion 4.1. Response statistics and non-response bias tests Table 3 summarizes the response rates for the two different versions of the survey. In total, 579 surveys were returned, yielding a 26% response rate overall. Nearly sixty percent of the surveys received were fully
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
completed.2 In this and the next three sections of the paper (i.e., sections 4.1-4.4) we discuss the results of the combined analysis which includes both versions of the survey. Table 3: Survey response rates for the two different versions of the survey Survey Type Escalation survey Non-escalation survey (control group) Total
# Sent 1,549 682
# Retrnd 420 156
Rspns. Rate 27% 23%
2,231
576
26%
# Fully Completed 243 91 334
As mentioned earlier, non-response bias can be a significant hindrance in the interpretation of results from a mail survey. Non-response represents a threat when those individuals who respond to the survey differ in a systematic way from those who choose not to respond. If this happens, any extrapolation from the sample to the population becomes suspect because the sample may no longer be representative of the population from which it was drawn. One method of testing for non-response bias is to compare attributes of the survey respondents with attributes of all individuals receiving the survey. In this study, the state of residence was known for everyone in the sample. Regional non-response bias was calculated by first assigning each state to a region and then comparing the regional frequencies of respondents to regional frequencies of the full mailing list using the chisquare test. The chi-square test indicated there was no significant difference between the respondents and the full mailing list on region. Using the date that a survey was returned, an alternative to the chi-square test was used to evaluate non-response bias based upon several other demographic fields including: experience, industry category, number of employees, and number of IS employees. By grouping the surveys that were received into two “waves” (n= 366, n=210, respectively) based on the date returned, it was possible to determine whether later respondents were significantly different from earlier respondents on any of these variables.3 In this type of wave analysis, responses from later waves are considered to be surrogates for nonrespondents.
Using non-parametric statistical tests (e.g., MannWhitney and Kruskal-Wallis), there was no discernible difference between the two waves on any of the above variables. While the above tests cannot guarantee the absence of any non-response bias, they strongly suggest that the responses received are representative of the population that was surveyed.
4.2. Survey respondent demographics Survey respondents had an average of 8.7 years of experience as an information systems audit and control professional. Seventy-two percent of the respondents described themselves as IS auditors or IS audit managers. The remaining respondents were external auditors or carried some other job title. The survey sample included organizations of various types and sizes. Figure 2 shows the different types of organizations included in the survey and Figure 3 indicates the size of the organizations in terms of number of employees.
Other 22% Transp 2%
Mfg 13%
Health 3%
Govt 17%
Trade 4%
Figure 2: Types of organizations in the survey sample (valid n=484)
500-999 7%
1,0004,999 28%
2
Surveys that were partially completed generally included demographic information as well as estimates of escalation frequency. Fully completed surveys included this information as well as complete answers to a series of more than 50 questions pertaining to a particular project selected by the respondent. 3 For this analysis, returned surveys were split into two waves, those received within two weeks of the initial mailing (i.e., before the follow-up mailing could have been received and acted on) and those received after the follow-up mailing.
Financial 39%
100-500 9%
10,000 36%
5,0009,000 19%
Figure 3: Size of organizations in the survey sample in terms of number of employees (valid n=485)
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
Consistent with the broad size range of organizations surveyed, the survey sample included organizations with both large and small IS organizations.
stages of a project (as opposed to the end of a project) will be in a better position to observe escalation and to understand the factors associated with it.
4.3. Respondents’ level of exposure to information systems projects As mentioned earlier, survey respondents had, on average, considerable job experience in the IS audit and control area, suggesting that they would be in a good position to have observed escalation even if it occurs infrequently. However, given that auditing IS development projects is but one of many job tasks undertaken by IS audit and control professionals, one concern in a survey of this type is whether the respondents have a sufficient level of exposure to IS projects to answer questions concerning the factors that may cause project escalation. To address this concern, the survey included two questions designed to gauge the respondents’ degree of association with IS projects. The first question concerned the respondents’ role in IS projects. A reasonable assumption is that IS audit and control professionals who have more contact with a project will be in a better position to observe escalation and to understand the factors associated with it. The survey results, shown in Figure 4, revealed that approximately half of the respondents were associated in a very significant way with the IS projects they reported on. At a minimum, these individuals were responsible for evaluating projects on a regular basis and sometimes served as a member of the development team or even the project manager.
Other 22%
Evaluated Once or Twice 30%
Project Manager 5%
Team Member 11%
Regularly Evaluated 32%
Figure 4: Survey respondents’ role in IS projects (valid n=335) As a second means of assessing the degree of association with IS projects, respondents were asked to indicate the phase when they first become associated with a project. A reasonable assumption is that IS audit and control professionals who become involved at the early
Impl 10%
Post-Impl 7%
Planning 24%
Testing 13%
Coding 7%
Design 15%
Analysis 24%
Figure 5: Phase at which respondents’ become involved in IS projects (valid n=329) The survey results, shown in Figure 5, suggest that approximately half of the respondents became associated at a very early stage (i.e., during planning or requirements analysis) with the projects they reported on. Therefore, based on both their role and the phase at which they became involved, the majority of the respondents’ should have been well-positioned to provide knowledgeable answers to escalation-related questions.
4.4. Frequency of escalation One of the primary purposes of this research was to determine whether or not project escalation was a frequently occurring phenomenon. Before presenting the results on this point, it should be noted that relying on IS auditors as a means of estimating the frequency of escalation represents a possible limitation of this study. It is possible, for example, that auditors may be called in more frequently on large, complex, or troubled projects. If so, the estimates that auditors provide regarding the frequency of escalation may be somewhat inflated. Based on both pretest and follow-up interviews with approximately a dozen IS auditors, however, it would appear that many firms routinely assign auditors to the majority of their system development projects without much regard as to the relative size or health of the project. Moreover, as the survey data suggest, it is often the case that IS auditors are assigned to a project from the outset before there could be any real signs of trouble. Recognizing the above as a possible limitation, both versions of the surveys contained an identical set of question items designed to measure the frequency of escalation. One indication of the actual frequency of
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
escalation can be derived from a survey question that asked “of the last 5 projects with which you have been associated . . . how many were cases of project escalation?” To examine this question, a restricted view of the dataset was prepared which included only those respondents who had experience with at least five projects coupled with three or more years of relevant job experience (n=361). Respondents with little job experience or those with exposure to less than five projects would not have been able to answer the question in a meaningful way. Thus, this approach was believed to be necessary in order to insure that the escalation frequency estimates derived from the dataset reflect the experience of subjects who have had enough exposure to IS projects to comment on the frequency of the escalation phenomenon.. Respondents included in this analysis had an average of 10.5 years of work experience as an IS audit and control professional. The results of the analysis are shown in Figure 6. As shown in Figure 6, 81% of the respondents indicated that one or more of the last five projects they had been associated with were cases of project escalation. The mean response was 1.92, suggesting that escalation occurs (on average) in 38% of all IS projects. As a means of cross-checking, or triangulating, to gauge the frequency of IS project escalation, respondents were also asked: “Of all the projects with which you have been associated during your years as an information systems control professional, what percentage would you classify as cases of project escalation?” To remove any ambiguity in the question, escalation was clearly defined as “troubled projects which continued to receive resources even though you thought the project should have been discontinued or redirected.” Using the same sub-sample of experienced IS audit and control professionals (n=361), the mean response to this question was 0.304 indicating that escalation occurs in 30% of all IS projects. Finally, as an additional means of triangulation, the question was asked in a slightly different way: “In your judgment what percentage of all IS development projects are cases of project escalation.” The mean response to this question was 0.383 indicating that escalation occurs in 38% of all IS projects. Taken together, the three measures described above provide a remarkably consistent view of how frequently IS project escalation occurs; the data strongly suggest that 30-40% of all IS projects involve some degree of project escalation.
Of the last 5 projects with which you have been associated, how many were cases of project escalation? 30%
28%
25% 20%
20%
19%
16% 15% 10% 10%
8%
5% 0% 0
1
2
3
4
5
Figure 6: Observed frequency of escalation based on last five projects (n=361)
4.5. Duration of escalation Having determined the frequency at which escalation occurs, it is appropriate to ask: “How long is the duration of escalation?” This was operationalized by calculating how long projects were allowed to continue after the point at which an IS auditor believed they should have been terminated or redirected. By capturing key dates in the escalation survey, it was possible to calculate the number of months of escalation. Escalation time among the projects surveyed ranged from 1 month to 255 months (i.e., 21 years!). As shown in Figure 7, nearly 75% of the projects escalated for two years or less. Among projects that escalated, the average escalation time was 21 months with half of the projects escalating for 15 or more months.
40% 35% 30% 25% 20% 15% 10% 5% 0% 112 mo
1324 mo
2536 mo
3748 mo
4960 mo
>60 mo
Figure 7: Duration of escalation (n=243)
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
4.6. Comparison of projects that escalated and those that did not Having established that escalation occurs rather frequently and with some duration, it is important to ask whether projects that escalate are really different from projects that do not escalate. To answer this question, we focus on the results that were obtained from the sample of fully completed surveys on escalated projects (n=243) and compare these results with those that were obtained from the sample of fully completed surveys on non-escalated projects (n=91). The comparison reveals that projects that escalate are significantly different (from nonescalated projects) along dimensions that are managerially relevant. Figure 8, for example, shows the degree to which escalation and non-escalation projects exceed their budgets and schedules. As shown in the figure, projects that escalate run between 2-3 times their original budgets and schedules, whereas projects that do not escalate exceed their original budgets and schedules by an average of about 20%. As another point of comparison, more than 82% of the projects that escalated also exceeded their budgets, whereas only 48% of the non-escalation projects exceeded their budgets. In addition, 91% of the projects that escalated exceeded their original schedule as compared with 58% of the nonescalation projects. 160% 140%
7 6 5 4 3 2 1
Escalation projects
Non-escalation projects
Figure 9: Comparison of escalation and nonescalation projects4 The severity of the escalation problem comes into clearer focus when one examines the final outcome of the projects that escalated, as shown in Figure 10. As indicated in the figure, less than one quarter of the projects that escalated were completed and implemented successfully. In contrast, 84% of the projects in the nonescalation sample were completed and implemented successfully. This suggests that reducing the incidence of project escalation is one way to achieve higher success rates in IS projects.
120% 100%
Escalation projects
80%
Other 5%
Completed and Successful 23%
Non-escalation projects
60% 40% 20% 0% %Over Budget
Abandon before Completion 18% Completed, never Impl 5%
%Longer than Expected
Completed, then Withdrawn 8%
Figure 8: Degree to which escalation and non-escalation projects exceed their budgets and schedules Figure 9 compares escalation vs. non-escalation projects along these and other dimensions. As shown in the figure, escalation projects were larger in size, more complex, and more costly than non-escalation projects. They were also judged to be significantly less successful than projects that did not escalate.
Completed, Less than Successful 18%
Partially Completed 23%
Figure 10: Final outcome of escalated projects (valid n=243)
4
All questions were similar to the following: Compared to other IS projects undertaken in your organization was this project . . . smaller in size 1 2 3 4 5 6 7 larger in size
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
4.6. Factors associated with escalation Having established that escalated projects are different from non-escalated projects, it is important to understand what factors are associated with project escalation. As mentioned earlier, the survey included a number of project management factors as well as psychological, social, and organizational factors that might be associated with escalation. The purpose of this portion of the survey was to determine the degree to which these various factors were believed to be associated with escalation. Table 4 shows the most frequently cited project management factors that were judged to be present in cases of project escalation. The percentages reflect the fraction of respondents who indicated that a particular factor was present. As indicated in the table, there were seven different project management factors that were commonly present in the sample of projects that escalated. Each of these factors was cited by at least 70% of the respondents. Moreover, each factor was judged to be important (averaging 4.0 or higher on a 5-point scale that ranged from “not important” to “extremely important”) in explaining why an escalated project continued. The list of project management factors associated with escalation suggests that better estimation of time, scope, and required resources, better monitoring and control, and better planning, would go a long way toward reducing the incidence of project escalation. Table 4: Most frequently cited project management items associated with escalation 1. Underestimation of time to complete the project (83%) 2. Senior management did not monitor project closely enough (78%) 3. Underestimation of necessary resources (77%) 4. Size or scope of project underestimated (75%) 5. Inadequate project control mechanisms (72%) 6. System specifications kept changing (71%) 7. Inadequate planning (71%)
Table 4, alone, however, doesn’t reveal the whole story, as there also appear to be a number of psychological, social, and organizational factors associated with the projects that escalated. Table 5 shows the most frequently cited psychological, social, and organizational factors that were judged to be present in cases of project escalation. The percentages reflect the fraction of respondents who indicated that a particular factor was present. As indicated in the table, there were nine different psychological, social, and organizational factors that were commonly present in the sample of projects that escalated. Each of these factors was cited by at least 50% of the respondents. Four of the nine items were judged to be important (averaging 4.0 or higher on a
5-point scale) in explaining why an escalated project continued. Table 5 contributes to our understanding of escalation by confirming that there are in fact psychological, social, and organizational factors that contribute to escalation; in other words escalation involves more than simple mismanagement of projects. The list of psychological, social, and organizational factors suggests that escalation is exacerbated by situations in which: abandonment would make the primary decision-maker “look bad,” completion is seen as important to the organization’s ability to compete, the primary decision-maker distorts or conceals negative information concerning the project, or the organization has a loose/informal process for justifying projects. Table 5: Most frequently cited psychological, social, and organizational items associated with escalation 1. Primary decision-maker repeatedly expressed support (85%) 2. Abandonment would make the primary decision-maker look bad (76%)* 3. Senior management provided continued funding or protection (75%) 4. Primary decision-maker expressed a “we have come too far to quit now” attitude (70%) 5. Primary decision-maker initiated project or was extensively involved with it (70%) 6. Completion seen as important to organization’s ability to compete (64%)* 7. Failure would have a negative impact on primary decisionmaker (57%) 8. Primary decision-maker distorted or concealed negative information (55%)* 9. Loose/informal process for justifying projects (54%)* *denotes that item was rated as important (i.e. > 4 on a 5-point scale)
5. Conclusions The results of this study indicate that IS project escalation is a frequent occurrence and that it is driven by a combination of project management as well as psychological, social, and organizational factors. Armed with this knowledge, IS professionals should not underestimate the important role that psychological, social, and organizational factors can play in the successful management of IS projects. In the past, IS managers have relied upon traditional project management techniques to control IS projects. While the traditional approaches are useful, they are based on a rational approach to project management and thus tend to ignore some of the other dimensions that seem to be associated with project escalation.
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
6. References [1] Betts, M. "Feds Debate Handling of Failing IS Projects," Computerworld, November 2, 1992, p. 103. [2] Brockner, J. "The Escalation of Commitment to a Failing Course of Action: Toward Theoretical Progress," Academy of Management Review (17:1), 1992, pp. 39-61. [3] Dillman, D.A. Mail and Telephone Surveys, John Wiley & Sons, New York, 1978.
[11] Kerlinger, F.N. Foundations of Behavioral Research, Holt, Rinehart and Winston, New York, 1986. [12] Kindel, S. "The Computer That Ate the Company," Financial World, (161:7), March 31, 1992, pp. 96-98. [13] Lyytinen, K. and Hirschheim, R. "Information Systems Failures--A Survey and Classification of the Empirical Literature," In Oxford Surveys in Information Technology, P. I. Zorkoczy (Ed.), 4, Oxford University Press, Oxford, 1987, pp. 257-309.
[4] Ellis, V. "Audit Says DMV Ignored Warning," Los Angeles Times, August 18, 1994, pp. A3-A24.
[14] Meredith, J. "Project Monitoring For Early Termination," Project Management Journal (19:5), 1988, pp. 31-38.
[5] Garland, H. "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), 1990, pp. 728-731.
[15] Ross, J. and Staw, B.M. "Organizational Escalation and Exit: Lessons From the Shoreham Nuclear Power Plant," Academy of Management Journal (36:4), 1993, pp. 701732.
[6] Gibbs, W.W. "Software's Chronic Crisis," Scientific American, (273:3), September 1994, pp. 86-95.
[16] Rothfeder, J. "It's Late, Costly, Incompetent--But Try Firing a Computer System," Business Week, November 7, 1988, pp. 164-165.
[7] Johnson, J. "Chaos: The Dollar Drain of IT Project Failures," Application Development Trends (2:1), 1995, pp. 41-47. [8] Keider, S.P. "Why Projects Fail," Datamation, December, 1974, pp. 53-55. [9] Keil, M., “Pulling the Plug: Software Project Management and the Problem of Project Escalation,” MIS Quarterly, (19:4), December 1995, pp. 421-447.
[17] Staw, B.M. and Ross, J. "Behavior in Escalation Situations: Antecedents, Prototypes, and Solutions," In Research in Organizational Behavior, B. M. Staw and L. L. Cummings (Ed.), 9, JAI Press Inc., 1987, pp. 39-78. [18] Tomsho, R. "Real Dog: How Greyhound Lines ReEngineered Itself Right Into a Deep Hole," The Wall Street Journal, October 20, 1994, pp. A1-A6.
[10] 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), 1995, pp. 67-87.
Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE
1060-3425/97 $10.00 (c) 1997 IEEE
