Rethinking Success in Software Projects: Looking Beyond the Failure Factors

  • Darren DalcherEmail author


The notions of success and failure in software projects are confusing. Failure is often considered in the context of the iron triangle as the inability to meet time, cost, and performance constraints. While there is a consensus around the prevalence of project failure, new projects seem destined to repeat past mistakes. This chapter tries to advance the discussion by offering a new perspective for reasoning about the meaning of success and the different types of software project failures.

In order to court project success, practitioners need to rise beyond a fixation with the internal parameters of efficiency, thus bringing forth the effectiveness required to secure project success. The chapter begins by discussing the limited insights from existing project failure surveys, before offering a four-level model addressing the essence of successful delivery and operation in software projects. Following consideration of outcomes and time, the chapter offers a series of vignettes and mini case studies that highlight the rich interplay between the four levels of success, before addressing the types of measures underpinning the four levels and the need to develop a multi-dimensional perspective to obtain a more accurate picture regarding the success of a project.


Project Management Software Project Project Success Business Success Cost Overrun 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


  1. Anon (1979) Contracting for computer software development—serious problems require management attention to avoid wasting additional millions, general accounting office report to the congress by the comptroller general of the United States. FGMSD 80–84Google Scholar
  2. Baccarini D (1999) The logical framework method for defining project success’. Proj Manag J 30(4):25–32Google Scholar
  3. Barnes M (2013) Private communication, September 2013 BBC (2003) BBC Radio 4 news, 15.5.2003.
  4. BBC (2012) London 2012 legacy plan published, 18 September 2012. Accessed 12 Nov 2013
  5. Bloch M, Blumberg S, Laartz J (2013) Delivering large-scale IT projects on time, on budget and on value. McKinsey Finance 45:28–35Google Scholar
  6. Brooks F (1975) The mythical man-month: essays on software engineering. Addison-Wesley, Reading, MAGoogle Scholar
  7. Buxton JN, Naur P, Randell B (1969) Software engineering techniques. In: Proceedings, NATO conference, scientific affair division, BrusselsGoogle Scholar
  8. Charette RN (2005) Why software fails. IEEE Spectr 42(9):42–49CrossRefGoogle Scholar
  9. Cooke-Davies T (2002) The “real” success factors on project. Int J Proj Manag 20(3):185–190CrossRefGoogle Scholar
  10. Dalcher D (1994) Falling down is part of growing up; the study of failure and the software engineering community. In: Proceedings of 7th SEI education in software engineering conference. Springer, New York, pp 489–496Google Scholar
  11. Dalcher D (2009) Making sense of IS failures. Encyc Inf Sci Technol 5:2476–2483Google Scholar
  12. Dalcher D (2010) The LAS story: learning from project failure. In: Turner RJ, Huemann M, Anbari FT, Bredillet CN (eds) Perspectives on projects. Routledge, New YorkGoogle Scholar
  13. Dalcher D (2012) The nature of project management: a reflection on the anatomy of major projects by Morris and Hough. Int J Manag Proj Bus 5(4):643–660CrossRefGoogle Scholar
  14. Dalcher D, Brodie L (2007) Successful IT projects. Thomson, LondonGoogle Scholar
  15. Dalcher D, Genus A (2003) Avoiding IS/IT implementation failure. Tech Anal Str Manag 15(4):403–407CrossRefGoogle Scholar
  16. de Wit A (1988) Measurement of project management success. Int J Proj Manag 6(3):164–170CrossRefGoogle Scholar
  17. Drevin L, Dalcher D (2011a) Antenarrative and narrative: the experience of actors involved in the development and use of information systems. In: Boje DM (ed) Storytelling and the future of organisations: an antenarrative handbook. Taylor and Francis, New York, pp 148–162Google Scholar
  18. Drevin L, Dalcher D (2011b) Narrative methods: success and failure stories as told by information systems users. In: Standing conference for management and organization enquiry, SC’MOI conference, Philadelphia, PAGoogle Scholar
  19. Drevin L, Dalcher D (2011c) Using antenarrative approaches to investigate the perceptions of Information Systems’ actors regarding failure and success. In: Pokorny J, Repa V, Richta K, Wojtkowski W, Linger H, Barry C, Lang M (eds) Information systems development business systems and services: modeling and development. Springer, New York, pp 207–218Google Scholar
  20. Egan J (1998) Rethinking construction, the report of the construction task force. Department of Environment, Transport and the Region, LondonGoogle Scholar
  21. Egan J (2008) Sir John Egan’s speech to the house of commons, 21st April, 2008Google Scholar
  22. Eveleens JL, Verhoef C (2010) The rise and fall of the chaos report figures. IEEE Softw 27(1):30–36CrossRefGoogle Scholar
  23. Fairley RE, Wilshire MJ (2003) Why the Vasa Sank: 10 problems and some antidotes for software projects. IEEE Softw 20(2):18–25CrossRefGoogle Scholar
  24. Flowers S (1996) Software failure, management failure. Wiley, ChichesterGoogle Scholar
  25. Flyvbjerg B, Budzier A (2011) Why your IT project may be riskier than you think. Harv Bus Rev 89(9):83–85Google Scholar
  26. Geneca (2011) Doomed from the start? Why a majority of business and IT teams anticipate their software development project will fail. Geneca, Oakbrook Terrace, ILGoogle Scholar
  27. Glass R (2005) IT Failure Rates—70% or 10-15%. IEEE Softw 22(3):110–112CrossRefGoogle Scholar
  28. Glass R (2006) The Standish report: does it really describe a software crisis? CACM 49(8):15–16CrossRefGoogle Scholar
  29. IBM (2008) Making change work. IBM Global Services, Somers, NYGoogle Scholar
  30. Jones C (1994) Assessment and control of software risks. Prentice-Hall, Englewood Cliffs, NJGoogle Scholar
  31. Jones C (2000) Software assessments, benchmarks and best practices. Addison-Wesley, Upper Saddle River, NJGoogle Scholar
  32. Jones C (2007) Estimating software costs: bringing realism to estimating. McGraw Hill, New YorkGoogle Scholar
  33. Jones C (2008) Applied software measurement: global analysis of productivity and quality. McGraw Hill, New YorkGoogle Scholar
  34. Jones C (2010) Software engineering best practices: lessons from successful projects in the top companies. McGraw Hill, New YorkGoogle Scholar
  35. Jørgensen M, Moløkken K (2006) How large are software cost overruns? A review of the 1994 Chaos report. Inform Softw Technol 48(8):297–301CrossRefGoogle Scholar
  36. Kerzner H (2009) Project management: a systems approach to planning, scheduling and controlling, 10th edn. Wiley, Hoboken, NJGoogle Scholar
  37. Kloppenborg T, Mantel SJ (1990) Tradeoffs on projects: they may not be what you think. Proj Manag J 21(1):13–20Google Scholar
  38. KPMG (2010) KPMG New Zeland project management survey 2010. Http://
  39. Linberg K (1999) Software developer perceptions about software project failure: a case study. J Syst Softw 49:177–192CrossRefGoogle Scholar
  40. Luqi, Goguen JA (1997) Formal methods: promises and problems. IEEE Softw 14(1):73–85CrossRefGoogle Scholar
  41. Lyytinen K, Hirschheim R (1987) Information systems failures—a survey and classification of the empirical literature. Oxf Surv Inf Technol 4:57–309Google Scholar
  42. McManus J, Wood-Harper T (2008) A study in project failure. = ConWebDoc.19584
  43. Morris PWG, Hough G (1987) The anatomy of major projects: a study of the reality of project management. Wiley, ChichesterGoogle Scholar
  44. Munns AK, Bjerimi BF (1996) The role of project management in achieving project success. Int J Proj Manag 14(2):81–87CrossRefGoogle Scholar
  45. Naur P, Randell B (1968) Software engineering. In: Proceedings. NATO Scientific Affairs Division, BrusselsGoogle Scholar
  46. Pinto JK, Slevin DP (1988) Critical success factors in effective project implementation. In: Cleland DI, King WR (eds) Project management handbook, 2nd edn. Van Nostrand Reinhold, New YorkGoogle Scholar
  47. Sauer C, Cuthbertson C (2003) The state of IT project management in the UK 2002–2003. Templeton College, OxfordGoogle Scholar
  48. Sauer C, Gemino A, Reich BH (2007) The impact of size and volatility on IT project performance. CACM 50(11):79–84CrossRefGoogle Scholar
  49. Shenhar AJ, Dvir D (2007) Reinventing project management: the diamond approach to successful growth and innovation. Harvard Business School Press, Boston, MAGoogle Scholar
  50. Standish Group (2000) Chaos 2000. Standish, Dennis, MAGoogle Scholar
  51. Standish Group (2004) Chaos 2004. Standish, Dennis, MAGoogle Scholar
  52. Standish Group (2011) Chaos 2011. Standish, Dennis, MAGoogle Scholar
  53. Taylor A (2000) IT projects sink or swim. The Comp Bulletin, January, Brit Comp SocietyGoogle Scholar
  54. Turner JR (2009) The handbook of project based management, 3rd edn. McGraw-Hill, New YorkGoogle Scholar
  55. Wateridge JH (1995) IT projects: a basis for success. Int J Proj Manag 13(3):169–172CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2014

Authors and Affiliations

  1. 1.NCPMUniversity of HertfordshireHatfieldUK

Personalised recommendations