No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Escalation behavior in information systems development : alternative motivations, experience, and the sunk cost effect /
Abstract
Thesis (Ph. D.)--University of Tennessee, Knoxville, 1993. Vita. Includes bibliographical references (leaves [56]-64).
... Experimental research similar to the research presented in this paper has been done in the US (Schneider 1993;Sabherwal, Sein et al. 1994;Keil, Mixon et al. 1995). In this research, a scenario of a computing project was presented to two groups of undergraduate computing majors who were asked to act as project managers. ...
... Research on escalation situations during the past 20 years have mostly been experiments in psychology and sociology under the headings: knee deep in the big muddy (Staw 1976), entrapment (Fox andStaw 1979;Brockner, Nathanson et al. 1984), too much invested to quit (Teger 1980), escalation of commitment (Staw and Fox 1977;Staw 1981;Staw and Ross 1987a), knowing when to pull the plug (Staw and Ross 1987b), throwing good money after bad (Garland 1990). The escalation research has only recently moved into a computing context (Schneider 1993;Sabherwal, Sein et al. 1994;Keil, Mixon et al. 1995). However, different types of failing projects and remedies against failures have been discussed and suggested since the beginning of computing (Brooks 1975). ...
... If no negative aspects are found, postpone the decision until the next day or the next meeting. Since the final decision to continue a failing project often is made by an individual, the process leading to the decision should be a group effort (Schneider 1993). For this, conflict is a mechanism for facilitating learning, e.g., by the use of a devil's advocate, an individual who plays the formal role of critic to help the decision maker test the assumptions and the logic of the ultimate decision. ...
In computing education, students are given some real-life experience of the development of computer systems. This experience does not usually include project failure and especially not escalation situations with difficult decisions that deepen or compound the problems a project has. We argue that the only way in which students will be able to recognize escalation is by actually experiencing a project that is escalating and that will fail. In the first part of this article escalation and the determinants of escalation are discussed. This is followed by a description of the experiment conducted and the results. From the results of the experiment we conclude that students act in the same way as practitioners do. We claim that if we do not change the way in which students are taught, we perpetuate the problem. We end the article with ideas about how to change computing education to make students aware of but also make them understand, the problem of escalation situations.
... If no negative aspects are found, postpone the decision until next day or next meeting. Since the final decision to continue a failing project often is made by an individual, the process leading to the decision should be a group effort [21]. For this, conflict is a mechanism for facilitating learning, e.g., by the use of a devil's advocate, an individual who plays the formal role of critic to help the decision maker test the assumptions and the logic of the ultimate decision. ...
... Simultaneous with the research on escalation, conducted primarily by organizational behavior researchers, social psychologists have studied the same phenomenon using the term "entrapment" [21]. Entrapment situations are those in which decision makers continue investing their resources in a costly or losing course of action in order to justify the appropriateness of already sunken costs. ...
Many information technology (IT) projects fail. These projects are not within budget, not on time or do not deliver what was promised. Failures in IT projects are more common than failures in any other aspect of modern business. Whereas a large number of projects are obvious failures, some are not. A model of escalation-increasing commitment to a failing course of action-is used to analyze and explain one type of project failure, namely, those projects that seem to take on a life of their own, wasting scarce resources and in many cases never reaching the objectives they were set to fulfil. The paper argues that escalation as a cause of IT project failure has received too little attention in both practice and education. A small case is used to illustrate escalation in an IT project
... Simultaneous with the research on escalation, conducted primarily by organizational behavior researchers, social psychologists did study the same phenomenon using the term entrapment (Schneider 1993). Entrapment situations are those in which decision makers continue to invest their resources in a costly or losing course of action in order to justify the appropriateness of already sunken costs. ...
Information technology projects have been failing and continue to do so. This has been true for the past 20 years. There are no indications that the situation is getting better. However, the escalation literature provides us with a promising theoretical framework for explaining a specific kind of project failure, namely, those projects that seem to take on a life of their own, wasting scarce resources and in many cases never reaching the objectives they were set to fulfill. Abstract Information technology projects have been failing and continue to do so. This has been true for the past 20 years. There are no indications that the situation is getting better. However, the escalation literature provides us with a promising theoretical framework for explaining a specific kind of project failure, namely, those projects that seem to take on a life of their own, wasting scarce resources and in many cases never reaching the objectives they were set to fulfill.
ResearchGate has not been able to resolve any references for this publication.