Escalat: Escalating Commitment as a Cause of Failed IT Projects
Initial Situation
It is necessary to systematically deal with the causes of Escalation of Commitment in IT projects as well as with the possibilities to develop effective de-escalation technologies for two reasons. First, the relevance of the IT projects that failed due to Escalation of Commitment. Second, the inadequate theoretical and empirical penetration of the Escalation phenomenon in groups.
At the beginning of the project it was not possible to form hypotheses about the relationship between variables because of the low level of knowledge regarding Escalation of Commitment in IT projects. Therefore, a qualitative approach was carried out first – before the quantitative experiment was conducted.
Realization
First, an overview of the state of the theory of Escalation of Commitment was developed. Subsequently, various case studies were carried out and evaluated. The analysis of the case studies built the basis for the design of the Escalat laboratory experiment. Finally, de-escalation activities and technologies were developed. The results were transferred in a reflection of the escalation and IT project management theory.
Value
In our case studies and laboratory experiments we identified the following main factors that promote the creation of Escalating Commitment at the corporate level:
- Ongoing personal conflicts between the project team, the project manager and the project sponsor;
- separation between sales and project implementation responsibilities (e.g. between sales and system technology);
- a customer who does not check milestones and has only little know-how in terms of system development;
- several customers with conflicts of interest that will feed into a common system architecture;
- ill-defined project objectives;
- a project sponsor with high financial resources;
- the lack of independent supervisory authorities (department for quality assurance, senior manager), appropriate project documentation (project plan, test plan, developer’s guide, architecture model) and regular check routines for the IT project and
- the lack of risk management in the project.
Research Funding
Deutsche Forschungsgemeinschaft
DFG-Geschäftszeichen KR 998/6-1