Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects

Context: Software project cancellations are often caused by mistakes made during the project, and such cancellations make a strong economic impact. We analyzed five cancelled software engineering projects. One case was an internal product development project of a company that sells products to its customers. The other four cases were different software engineering projects, and outcomes of these projects were planned to be delivered to external customers. Objective: This study reports a post-mortem analysis of five software engineering projects with the aim of providing more knowledge about the reasons for cancellation decisions and the causes behind those reasons. Methods: The research method is case study. A method for a document-based post-mortem analysis was developed and post-mortem analysis was performed. All project documentation was available for analysis. Results: The reasons for the cancellation decisions were well-known ones. In four cases of five, the outcome of the project was to be delivered to an external customer, but in these cases the causes of the cancellation reasons were not found from the normal project documentation. In these cases the cause of the cancellation originated in a phase before the start of the project and therefore the project was doomed before it was started. Conclusion: It is reasonable to suggest that a remarkable portion of project cancellations are due to mistakes made before the project is started in the case of contract-based software engineering projects.

[1]  Jeffrey K. Pinto,et al.  The causes of project failure , 1990 .

[2]  Neal Whitten,et al.  Managing software development projects (2nd ed.): formula for success , 1995 .

[3]  Alton Yeow-Kuan Chua,et al.  Exhuming it Projects from Their Graves: An Analysis of Eight Failure Cases and Their Risk Factors , 2009, J. Comput. Inf. Syst..

[4]  Geoff Parcell,et al.  Learning to Fly: Practical Knowledge Management from Some of the World's Leading Learning Organizations , 2004 .

[5]  Marjorie J. Cooper,et al.  Tying the pieces together: A normative framework for integrating sales and project operations , 2007 .

[6]  R.N. Charette,et al.  Why software fails [software failure] , 2005, IEEE Spectrum.

[7]  Zbigniew H. Przasnyski,et al.  Learning from abandoned information systems development projects , 1995, J. Inf. Technol..

[8]  Capers Jones,et al.  Why software fails , 1996 .

[9]  Terry Williams.  Identifying the hard lessons from projects – easily , 2004 .

[10]  Neal Whitten.  Managing Software Development Projects: Formula for Success , 1990 .

[11]  Torgeir Dingsøyr,et al.  Postmortem: Never Leave a Project without It , 2002, IEEE Softw..

[12]  Roger Pressman,et al.  Software Engineering: A Practitioner's Approach, 7Th Edition , 2009 .

[13]  Tom DeMarco,et al.  A defined process for project post mortem review , 1996, IEEE Software.

[14]  Kweku Ewusi-Mensah,et al.  Software Development Failures , 2003 .

[15]  Roger S. Pressman,et al.  Software Engineering: A Practitioner's Approach , 1982 .

[16]  R. Yin.  Case Study Research: Design and Methods , 1984 .

[17]  M. Zedtwitz.  Organizational Learning through Post-project Reviews in R&D , 2002 .

[18]  Roger S. Pressman,et al.  Software Engineering: A Practitioner's Approach (McGraw-Hill Series in Computer Science) , 2004 .

[19]  York P. Freund.  Critical success factors , 1988 .

[20]  Uma Kumar,et al.  To terminate or not an ongoing R&D project: a managerial dilemma , 1996 .

[21]  Yi Zhang,et al.  Error Report Driven Post-Mortem Analysis , 2007, 15th IEEE International Conference on Program Comprehension (ICPC '07).

[22]  Walker Royce,et al.  Software Project Management: A Unified Framework , 1998 .

[23]  Isabel M. Ramos,et al.  An evolutionary approach to estimating software development projects , 2001, Inf. Softw. Technol..

[24]  June M. Verner,et al.  Why did your project fail? , 2009, Commun. ACM.

[25]  Kweku Ewusi-Mensah,et al.  Software development failures : anatomy of abandoned projects , 2003 .

[26]  Robert L. Glass,et al.  Project retrospectives, and why they never happen , 2002, IEEE Software.

[27]  Robert L. Glass,et al.  Loyal Opposition - Frequently Forgotten Fundamental Facts about Software Engineering , 2001, IEEE Softw..

[28]  Robert L. Glass,et al.  How not to prepare for a consulting assignment, and other ugly consultancy truths , 1998, CACM.

[29]  G. Moore.  Surviving the project management battle , 1999 .

[30]  Morten Fangel.  To start or to start up , 1991 .

[31]  K. Artto,et al.  Impact of services on project business , 2008 .

[32]  M. D. Myers,et al.  Qualitative Research in Business & Management , 2008 .

[33]  J.S. Reel,et al.  Critical Success Factors in Software Projects , 1999, IEEE Softw..

[34]  June M. Verner,et al.  In-house software development: what project management practices lead to success? , 2005, IEEE Software.

[35]  Jarmo J. Ahonen,et al.  A Case Study on the Success of Introducing General Non-construction Activities for Project Management and Planning Improvement , 2006, PROFES.

[36]  Robert L. Glass.  Extreme programming: the good, the bad, and the bottom line , 2001, IEEE Software.

[37]  J. R. Turner,et al.  Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them , 1993 .

[38]  Robert L. Glass,et al.  Lying on Software Projects , 2008, IEEE Software.

[39]  Karlos Artto,et al.  The marketing strategy of a project-based firm: The Four Portfolios Framework , 2007 .

[40]  Robert L. Glass.  IT Failure Rates--70% or 10-15%? , 2005, IEEE Softw..

[41]  Jim Abraham,et al.  Review of Software project management: A unified framework by Walker Royce, Addison-Wesley Longman, Inc., Reading, MA, 1998 , 2000 .

[42]  Mark J. Tiedeman.  Post-Mortems - Methodology and Experiences , 1990, IEEE J. Sel. Areas Commun..