Subscribe Now Subscribe Today
Research Article
 

A Design of Exit Mechanism for Information System Project De-Escalation



Chieh-Min Chou and Jen-Ming Chen
 
Facebook Twitter Digg Reddit Linkedin StumbleUpon E-mail
ABSTRACT

Information system project had been being notorious for its high ratio of failing to complete as original plan. The consequence of IS project escalation occurs tremendous resources waste and missllocated asked both researchers and practitioners to find solutions. This study intensively reviewed most of relevant theories and provided an analysis of possible solution. Unlike current solutions emphasize on identifying individual antecedent factors that causes IS project escalation and reduce the effect of factor, present study proposed a conceptual novel management process and designed a feasible exit mechanism to address IS project escalation.

Services
Related Articles in ASCI
Search in Google Scholar
View Citation
Report Citation

 
  How to cite this article:

Chieh-Min Chou and Jen-Ming Chen, 2008. A Design of Exit Mechanism for Information System Project De-Escalation. Information Technology Journal, 7: 137-142.

DOI: 10.3923/itj.2008.137.142

URL: https://scialert.net/abstract/?doi=itj.2008.137.142

INTRODUCTION

Information System (IS) project had been being notorious for its high ratio of failing to complete as original plan. According to an investigation (Anonymous, 1999), only 26% of software development projects are successfully closed on planned schedule, within budget and with fulfillment to the all function specification. As for the other projects, 28% were cancelled before the development process completed and 46% were delivered in a way of behind schedule, over budget, or reduced functionality. The phenomenon of almost three-fourth IS projects fail to be completed as plan caused numbers of Information Systems (IS) researchers` interest in attempting to explain and resolve it (Brooks, 1987; Keil, 1995; Ewusi-Mensah, 1997; Keil and Mann, 2000; Sabherwal et al., 2003). IS projects that run wildly over budget and/or far behind the scheduled completion date have been noticed in practitioner community and described as a runaway systems in commercial press (Mehler, 1991). On the other hand, academicians also drew on literature from the fields of organizational behavior, psychology and decision science to frame this problem as an escalation decision process and give it many theoretical reviews. No matter it is called runaway systems or escalated IS project, the consequence that occurs tremendous resources waste and misallocated asked both researchers and practitioners to find solutions.

Previous researches found the factors that promote IS project escalation can be grouped into four categories: project factors, psychological factors, social factors and organizational factors (Keil, 1995). However, with limited empirical studies the correlation between those factors and project escalation is still not very clear. To date the most broadly accepted theory to explain the motive of decision maker to escalate a project is self-justification theory that claimed the decision maker continuously commits resource to a failing course of action for a project because the needs to justify the previous resource allocation decision (Brockner, 1992). In IS project context the complicated organizational and political situation even push the decision makers to be too commit to a project to extricate themselves out of the endless journey (Keil and Mann, 2000). Considering the results obtained from previous researches, this exploratory study attempts to discuss the possible influences to decision makers on deciding to escalate a IS project if a formal exit mechanism existed. Exit mechanism could be defined as a formal or informal institution system of an organization to allow or command decision makers to exit his/her project. Like security exchange market, such as New York Stock Exchange (NYSE), enforces listed company with per share price lower than one dollar for one month be unlisted to prevent those ill-operated or low investment value company continuously absorb valuable capital. The project exit mechanism can play the similar role to prevent decision maker from continuously committing resources to a failing course of action, say, escalating project.

EXPLANATION OF ESCALATION

In many situations, decision makers exhibit a behavior to allocate some resources, in spite of negative feedback is surrounding them, in the hope of attaining some goals after having made an investment but finally find they went nowhere. Organizational and social psychologists and economists called such phenomenon as escalation. By definition, escalation situations include repeated decision making in the face of negative feedback about prior resource allocations, uncertainty surrounding the likelihood of goal attainment and choice about whether to continue (Brockner, 1992). Numerous theories were picked to explain why decision makers escalate their commitments to a failing course of action. According to a viewpoint of expectancy theory, escalation is explained as that decision makers compare the gains and costs after estimating the probability of the goal attainment if additional resources allocated and the value of success. Given the subjective expected utility associated with the decision to allocate additional resources for attaining goal is worth, the escalation decision therefore become reasonable to be made. Based on such theoretical ground, Levi (1982) shown that escalation decision was more likely to be made by decision maker if the negative feedback were seen unstable. Explained by the same theory, Rubin and Brockner (1975) found decision makers persisted a task even if it were failing when they sensed that the goal is closer and the value of success is relative high.

Self-justification theory is another, could be the most accepted, theory to explain escalation. This viewpoint posits that decision makers become entrapped in a previous course of action because they would not like to admit that the prior decision was in vain. Since self-justification is a psychological state, it is rather difficult to prove the theoretical propositions. However, there were still lots of empirical tests conducted by researchers and provide supportive evidences. Staw`s (1976) early study orthogonally manipulated the negative feedback and the need of justification to test the predictions of self-justification theory. The results shown that the mean amount of resources allocated to the previous course of action was higher in the negative feedback/personal responsibility condition than in all other combination and hence supported the proposition that escalation associated with negative feedback and needs of justification. The study conducted by Bazerman et al. (1982) further supported the prediction that escalation will be greater in the high need to justify conditions compared to the low need to justify conditions.

Some authors who are not convinced by the explanation of self-justification theory suggested other perspectives. Whyte (1986) explained the escalation from prospect theory. Originated from Kahneman and Tversky (1979), prospect theory explains individual`s risk-taking propensities under conditions of uncertainty. Simply stated, prospect theory predicts that individuals` risk preference will change depends on if the movement from the reference point is perceived to be in the positive direction or negative direction. As more and more resources are allocated to the failing course of action, according to this theory, decision makers have two alternatives that either they cut their losses or continue to commit themselves to the previous course of action. Given the assumption of loss aversion, decision maker will prefer to allocate additional resources in the hope of turning around the situation rather than to accept the sure loss exercised right after admitting failure. In spite of the dispute continuing, Brockner (1992) criticized this theory did not obtained enough empirical tests` support on explaining escalation phenomenon.

There are other few theories try to give explanation to escalation. Bowen`s (1987) decision dilemma theory suggested that in many cases, the decision makers have not received clearly negative feedback about their initial resource allocation. Therefore, the escalation decision may stem not from the need to justify but rather from the other managerial motives such as economic consideration or curiosity to know consequence of strategic action. Self-presentation theory was borrowed by Brockner et al. (1981) to discuss the effects of an on-looking audience or a social opponent on escalation (Teger, 1980). Researchers found decision makers usually escalated their commitment to a failing course of action just want to save their face. Therefore, self-presentation theory is potentially important in explaining the particular psychological state in escalation decision-making.

As so many theories were contributed to the research topic of escalation, no any particular theory can fully explain the complex phenomenon. Although self-justification theory was mostly supported by numbers of empirical tests, this theory still only provided partial explanation of escalating commitment at best. Managers and scholars need to know the situational and dispositional factors that moderate the relative influence of internal and external justification pressures on the entrapped decision maker (Brockner, 1992).

IS PROJECT ESCALATION AND DE-ESCALATION

The tremendous losses caused by so-called runaway systems had induced practitioners and researchers` notice and proved the necessity of resolving it. Regarding the phenomena of over resource budget and time delay on project completion that associated with runaway systems, especially most of them finally are going nowhere; those IS project in fact is a kind of escalation. A case study of a large-scale expert system development project (named CONFIG project) was first introduced by Keil (1995) to discuss the escalation phenomenon in information systems field. In this case study, the author found the escalation literature provides a promising theoretical base for explaining this type of IT failure. By using the taxonomy provided by Staw and Ross (1987), this longitudinal study investigated specific project, psychological, social and organizational factors that influence IS project escalation. Besides to test the factors in previous escalation literature, this study found some new factors such as the emotional attachment to the project (e.g., regard the project as my baby) and the slack resources and loose management control in IS project context.

IS project is prone to be escalating because of the invisible characteristics and the difficulty to measure the real status of project progress. The worst is, when the escalation phenomenon was identified, the IS project already escalated. Nevertheless, researchers were still trying to discriminate the projects that are prone to be escalated and those are not. Keil and Mann (2000) used different constructs derived from self-justification theory, prospect theory, agency theory and approach avoidance theory to build and test various logistic regression models for their ability to discriminate between projects that escalate and those that do not. While the constructs derived from the four theories were all significant in logistic models, the completion effect construct derived from approach avoidance theory provided the best classification of project with the correct rate over 70%. In addition to the constructs derived from the theories traditionally discussed in escalation literature, another study suggested that the project management constructs seem could provide higher power of discrimination (Keil et al., 2003). According to its findings, a model developed based on project management constructs such as project specification, estimation and monitoring and control can be a better classifier than the models developed based on constructs derived from various escalation theories. For the same objective but more focus on understanding the effectiveness of different methodologies, a comparison study shown that an neural network approach can perform a better job than logistical regression model (Zhang et al., 2003).

By conducting two stimulated experiments, Sabherwal et al. (2003) systematically examined the effects of project, psychological, social and structural factors that influence the decision makers escalating commitment to a failing course of action during four stages of an IS project. The results support escalation in IS project and the project and psychological factors seem to aid escalation.

Compared to the limited studies in IS project escalation, the studies focus on IS project de-escalation even less to see. IS project de-escalation was described as to redirect or to cancel a troubled project (Keil and Robey, 1999). Though literature review, the authors identified 12 factors potentially relevant to IS project de-escalation. By conducting a field survey, both quantitative and qualitative data were collected for analysis. The results shown that change in top management support, external shocks to the organization, change in project champion, consideration of alternative uses of funds supporting a project and visibility of project costs are not significantly different between escalation and de-escalation phases. Like the authors mentioned, while the absence of a significant difference does not prove that those factors are unimportant, it does suggest some interesting possibilities for further investigation. The study also found that the de-escalation is usually triggered by top managers, internal IS auditors and external auditors/consultants. IS users, project team members and IS management all were rarely to trigger the escalation process. These findings are especially interesting because it seems that the IS project core members are hard to extricate themselves from the entrapment of escalation.

Though a longitudinal case study of the IT-based baggage handling system at Denver international airport, Montealegre and Keil (2000) gathered qualitative data on the de-escalation of commitment to a failing course of action and developed a process model to explain the phenomenon. This model divided de-escalation process into four phases. The first phase is problem recognition. The decision makers should be able to recognize negative feedback and respond to external pressure at this phase. The second phase is reexamination of prior course of action. If decision makers pass the first phase, they have to clarify magnitude of problem and redefine the problem. It is a beginning to redirect or turn around the prior failing course of action. Once the problem severity had been identified and redefined, the process goes into third phase to search for alternative course of action. Decision makers have to identify and legitimize a new course of action and manage the impressions at this phase because the internal and/or external stakeholders could oppose the new direction. After the new course of action obtaining well support from stakeholders, the de-escalation process comes in the last phase for implementing an exit strategy. It is about an art to close a fail project gracefully. The key activities should be taken by decision makers at this phase is appealing to stakeholders to accept the results and de-institutionalizing the project. The case of Denver international airport gives researchers a conceptual model to understand IS project de-escalation process. Regarding the problem recognition the first phase to initiate the de-escalation process, some researchers start asking why the negative feedback can not be conveyed to key decision makers for prevent IS project from escalating. Specifically discuss the reluctance to report bad news on troubled IS projects; Smith and Keil (2003) developed a theoretical model to explain this phenomenon.

In this section we reviewed escalation literature both in general and in the IS project context. The various results of the previous studies grant a theoretical understanding to this study as a basis. If an IS project can be accomplished as originally planed, there is no escalation problem need to be discussed. Escalation must start from a project that fails to meet the original plan, in terms of time and budget. Therefore, here we define IS project escalation as a decision-making problem and frame it as this: When decision makers face a goal-unmet IS project with negative feedback, do they want to commit additional resources to complete in the same course of action? Since there were many studies shown the psychological factors such as the need to self-justification will significantly promote the decision makers escalating their commitment to a failing course of action, this study put focus on the relationship between a specific psychological factor, the need to self-justification and the IS project escalation decision. Duo to the special interests in finding a potential management mechanism to reduce IS project escalation, this paper proposed an exit mechanism and discuss it in the latter section.

PROPOSED DESIGN OF EXIT MECHANISM

Can the presence of an exit mechanism moderate the relationship between need-to-self-justification and IS project escalation decision? Figure 1 shows a simple model for describing the relationship among the constructs for discussion.

Previous researches tell us that decision makers are very likely to escalate their commitment to a failing course of action just because they need to justify the prior resource allocation decision is right. The perception of the need-to-self-justification comes from various sources such as the feeling of personal responsibility, job security, or organization culture. No matter what is the reason behind the need-to-justify, decision makers entrapped themselves in an ironic situation: Escalating the project prevents the decision makers from instantly admitting failure and undertaking the responsibility and consequences that sometimes means a demotion.

Image for - A Design of Exit Mechanism for Information System Project De-Escalation
Fig. 1: Conceptual model

Image for - A Design of Exit Mechanism for Information System Project De-Escalation
Fig. 2: An exit mechanism design

However, investing more valuable resources in a failing course of action which only have a very small possibility of success make them eventually will face the difficult decision again with a much worse condition.

Since the need-to-self-justification is a kind of psychological factor, one effective way to reduce its influence is to lower the necessity to explain why the decision makers terminate the project although they decided to initiate this project. The evidence had been provided by some research that found an organization with higher tolerance of failure could reduce the possibility of IS project escalation. Besides reduce the influential power of promoting factor directly, to find a moderator that decreases the relationship between need-to-self-justification and IS project escalation decision can also reduce the possibility of IS project escalation. This study suggests the exit mechanism can play the role. Figure 2 is a flow chart of exit mechanism that is designed for one of the worldwide leading semiconductor foundry company and can be use to elaborate the notion. The semiconductor foundry company has a project governance policy that ask all failed projects to go liquidate when the project due or the budget run out. The project owner hence then can choose to continue or exit this project. If project owner decide to continue, he/she need to seek for another resource and the escalated project will be regarded as a new project. That means even the escalated project finally success, its credits are nothing to do with the first round project. On the other hand, if project owner decide to exit, although he/she will get a punishment to downgrade but still can execute smaller project next time to prove his/her capability.

Given the exit mechanism, all projects are identified as fail and enter liquidation process when the project due but can not successfully closed. In spite of the need-to-self-justification still exist in decision makers` mind; the decision to escalate the project is no use any more because such action is irrelevant to save face.

Although at present there is no research related to the notion we proposed above, this study suggests that the conceptual model can be tested by the similar research design as Sabherwal et al. (2003). In their study, a special designed scenario was provided to participants for simulating a specific decision situation and collecting the response as data for analysis. In present study, the research is designed to ask participants to play the role of project decision makers and give them the same scenario as Sabherwal et al. (2003) but add the proposed exit mechanism presence. Since the other conditions remain the same, we can compare the results with the results of Sabherwal et al. (2003) for understanding the role that exit mechanism can play in present model.

CONCLUSIONS

IS project escalation causes huge amount of time, money and labor waste and the schedule-delayed project can even put the enterprises in dangerous situation if it concerned with competitive strategy. According to empirical investigation, the phenomenon of IS project escalation is not rare and the problem will be more and more severe because the complexity of both business environment and information technology becomes higher and higher. Hence, finding an effective management mechanism to mitigate the probability of IS project escalation is necessary and fruitful to IT managers and researchers. This research reviewed most of theoretical explanations of IS project escalation and analyzed existing IS project de-escalation solutions proposed by other scholars and practitioners. Unlike current solutions emphasize on identifying individual precedent factors that causes IS project escalation and reduce the effect of factor, this paper proposed a management process and designed a feasible exit mechanism to release the psychological defensive attitude that might drive project manager to escalate project.

ACKNOWLEDGMENTS

The authors wish to express their most sincere appreciation to anonymous reviewers, who read the manuscript carefully and gave valuable advice.

REFERENCES

1:  Anonymous, 1999. CHAOS: A recipe for success. Standish Group International, West Yarmouth, MA.

2:  Bazerman, M.H., R.I. Beekun and F.D. Schoorman, 1982. Performance evaluation in dynamic context: The impact of a prior commitment to the rate. J. Applied Psychol., 67: 873-876.

3:  Bowen, M.G., 1987. The escalation phenomenon reconsidered: Decision dilemmas or decision errors? Acad. Manage. Rev., 12: 52-66.
Direct Link  |  

4:  Brockner, J., J.Z. Rubin and E. Lang, 1981. Face-saving and entrapment. J. Exp. Soc. Psychol., 17: 68-79.
CrossRef  |  

5:  Brockner, J., 1992. The escalation of commitment to a failing course of action: Toward theoretical progress. Acad. Manage. Rev., 17: 39-61.
Direct Link  |  

6:  Brooks, F.P. Jr., 1987. No silver bullet: Essence and accidents of software engineering. IEEE Comput., 20: 10-19.
CrossRef  |  

7:  Ewusi-Mensah, K., 1997. Critical issues in abandoned information systems development projects. Commun. ACM, 40: 74-80.
CrossRef  |  Direct Link  |  

8:  Kahneman, D. and A. Tversky, 1979. Prospect theory: An analysis of decision under risk. Econometrica, 47: 263-292.
CrossRef  |  Direct Link  |  

9:  Keil, M., 1995. Pulling the plug: Software project management and the problem of project escalation. MIS Quart., 19: 421-447.
CrossRef  |  Direct Link  |  

10:  Keil, M. and D. Robey, 1999. Turning around troubled software projects: An exploratory study of the de-escalation of commitment to failing courses of action. J. Manage. Inform. Syst., 15: 63-87.
Direct Link  |  

11:  Keil, M. and J. Mann, 2000. Why software projects escalate: An empirical analysis and test of four theoretical models. MIS Q., 24: 631-664.
Direct Link  |  

12:  Keil, M., A. Rai, J. Mann and G. Zhang, 2003. Why software projects escalate: The importance of project management constructs. IEEE Trans. Eng. Manage., 50: 251-261.
CrossRef  |  Direct Link  |  

13:  Levi, A., 1982. Escalating commitment and risk taking in dynamic decision behavior. Unpublished manuscript, Yale University.

14:  Mehler, M., 1991. Reining in runaways. Information Week, December 16, pp: 20-24.

15:  Montealegre, R. and M. Keil, 2000. De-escalating information technology projects: Lessons from the Denver international airport. MIS Q., 24: 417-447.
Direct Link  |  

16:  Rubin, Z.J. and J. Brockner, 1975. Factors affecting entrapment in waiting situations: The rosencrantz and guildenstern effect. J. Personality Soc. Psychol., 31: 1054-1063.
CrossRef  |  

17:  Sabherwal, R., M.K. Sein and G.M. Marakas, 2003. Escalating commitment to information system projects: Findings from two simulated experiments. Inform. Manage., 40: 781-798.
CrossRef  |  

18:  Smith, H.J. and M. Keil, 2003. The reluctance to report bad news on troubled software projects: A theoretical model. Inform. Syst. 13: 69-95.
CrossRef  |  Direct Link  |  

19:  Staw, B.M., 1976. Knee-deep in the big muddy: A study of escalating commitment to a chosen course of action. Organiz. Behav. Hum. Perform., 16: 27-44.
CrossRef  |  Direct Link  |  

20:  Staw, B.M. and J. Ross, 1987. Behavior in escalation situations: Antecedents, prototypes and solutions. Res. Organiz. Behav., 9: 39-78.
Direct Link  |  

21:  Teger, A., 1980. Too much invested to quit. Pergamon Press, New York.

22:  Whyte, G., 1986. Escalating commitment to a course of action: A reinterpretation. Acad. Manage. Rev., 11: 311-321.
Direct Link  |  

23:  Zhang, G.P., M. Keil, A. Rai and J. Mann, 2003. Predicting information technology project escalation: A neural network approach. Eur. J. Operat. Res., 146: 115-129.
CrossRef  |  Direct Link  |  

©  2022 Science Alert. All Rights Reserved