A Taxonomy of an IT Project Failure: Root Causes

[Abstract] This article explores the root causes of IT projects failure of various IT application domains. The primary focus is to address the various issues responsible for IT projects failure to understand the root causes of the failure. The literature review indicates that failure of IT projects can be attributed to six generic root causes, the main categories of the taxonomy. This study investigates the root causes of failure from two major areas: common factors of failure and specific causes existing, which generalize the taxonomy. The study concludes that any reason of IT project failure can be related to one of the six categories in the taxonomy independent of the application domain. Keywords] IT project failure; taxonomy; root causes Introduction Failure has been synonymous with many IT projects over the last four decades. Reasons for failure have been attributed to technological difficulties, organizational and functional problems, managerial issues, and many other reasons. Traditionally, a project should deliver agreed upon functionality on time and within estimated budget according to Keider (1974) and Saleh (2005). A comprehensive study conducted by Standish Group International in 1995, which included several thousands of IT project revealed that only 16% of those projects were finished on time, and within the estimated budget; 32% were terminated before they were completed, while the remaining 52% involved costs higher than the original estimates and were completed behind their schedule (Standish Group, 1994). Another study conducted in the UK by Oxford University and Computer Weekly in 2003 reported, strikingly, that only 16% of the IT projects reviewed were considered successful (Sauer & Cuthbertson, 2003). IT projects have been considered a tough undertaking and have certain characteristics that make them different from other engineering projects and increase the chances of their failure. Such characteristics are classified in seven categories (Peffers, Gengler & Tuunanen, 2003; Salmeron & Herrero, 2005): 1) abstract constraints which generate unrealistic expectations and overambitious projects; 2) difficulty of visualization, which has been attributed to senior management asking for over- ambitious or impossible functions, the IT project representation is not understandable for all stakeholders, and the late detection of problems (intangible product); 3) excessive perception of flexibility, which contributes to time and budget overrun and frequent requests of changes by the users; 4) hidden complexity, which involves difficulties to be estimated at the project's outset and interface with the reliability and efficiency of the system; 5) uncertainty, which causes difficulty in specifying requirements and problems in implementation of the specified system; 6) the tendency to software failure, which is due to assumptions that are not thought of during the development process and the difficulty of anticipating the effects of small changes in software; 7) the goal to change existing business processes, which requires IT practitioners' understanding of the business and processes concerned in the IT system and good processes to automate and make them quicker. Such automation is unlikely to make a bad process better. One can categorically observe that project management in most IT organizations currently ranges from undisciplined to chaotic. Few organizations are armed with the necessary infrastructure, education, training, or management discipline to bring project initiatives to successful completion. Research indicates that more than half of all IT projects become runaways -overshooting their budgets and timetables while failing to deliver the expected outcomes. Project management of complex IT projects is challenging, even when measures of success are known and understood. The practical management of IT projects finds significant difficulties as follows (Rodriguez-Repiso, Setchi & Salmeron): IT projects are often poorly defined, codes of practice are frequently ignored, and, in some cases, not many lessons are learned from past experience. …

[1]  Kathryn Cormican,et al.  Auditing best practice for effective product innovation management , 2004 .

[2]  Thompson S. H. Teo,et al.  Facilitators and Inhibitors for Deploying Business-to-Business E-Commerce Applications: A Multi-Method, Cross-Cultural Study , 2001, ICIS.

[3]  Kalle Lyytinen,et al.  Information systems failures—a survey and classification of the empirical literature , 1988 .

[4]  David Baccarini,et al.  The Logical Framework Method for Defining Project Success , 1999 .

[5]  Gary S. C. Pan.  Information systems project abandonment: a stakeholder analysis , 2005, Int. J. Inf. Manag..

[6]  Ashley A. Bush,et al.  Reconciling user and project manager perceptions of IT project risk: a Delphi study 1 , 2002, Inf. Syst. J..

[7]  Jay Liebowitz,et al.  Information Systems Project Failure: A Comparative Study of Two Countries , 2002, J. Glob. Inf. Manag..

[8]  Jose L. Salmeron,et al.  An AHP-based methodology to rank critical success factors of executive information systems , 2005, Comput. Stand. Interfaces.

[9]  Chris Sauer,et al.  Fit, failure, and the house of horrors: toward a configurational theory of IS project failure , 1997, ICIS '97.

[10]  Chris Sauer,et al.  Why information systems fail: a case study approach , 1993 .

[11]  Terry Williams,et al.  The Need for New Paradigms for Complex Projects , 1999 .

[12]  F. W. McFarlan,et al.  Portfolio approach to information systems , 1989 .

[13]  Brenda Whittaker,et al.  What went wrong? Unsuccessful information technology projects , 1999, Inf. Manag. Comput. Secur..

[14]  Kweku Ewusi-Mensah,et al.  Critical issues in abandoned information systems development projects , 1997, CACM.

[15]  John K. Christiansen,et al.  Understanding IS implementation by estimating power of subunits , 1996 .

[16]  Robin Gauld,et al.  Public sector information system project failures: Lessons from a New Zealand hospital organization , 2007, Gov. Inf. Q..

[17]  R. Block.  The politics of projects , 1983 .

[18]  P Morris,et al.  Why IT Projects Fail , 1997 .

[19]  Yasser Saleh,et al.  An alternative model for measuring the success of IS projects: the GPIS model , 2005, J. Enterp. Inf. Manag..

[20]  B. Boehm.  Software risk management: principles and practices , 1991, IEEE Software.

[21]  John J. Sosik,et al.  Why Information Systems Projects are Abandoned: A Leadership and Communication Theory and Exploratory Study , 2000, J. Comput. Inf. Syst..

[22]  Andrew Taylor,et al.  IT projects: sink or swim , 2000 .

[23]  Capers Jones,et al.  Patterns of Large Software Systems: Failure and Success , 1995, Computer.

[24]  Kalle Lyytinen,et al.  Identifying Software Project Risks: An International Delphi Study , 2001, J. Manag. Inf. Syst..

[25]  Michael J. Gallivan,et al.  The Importance of Organizational Culture Fit: A Technology Implementation Success Story , 1997 .

[26]  Rajiv Sabherwal,et al.  Determinants of Commitment to Information Systems Development: A Longitudinal Investigation , 1996, MIS Q..

[27]  Grady Booch,et al.  When bad things happen to good projects , 1994 .

[28]  Leslie P. Willcocks,et al.  Risk assessment and information systems , 1993, ECIS.

[29]  Joseph Natovich,et al.  Vendor Related Risks in IT Development: A Chronology of an Outsourced Project Failure , 2003, Technol. Anal. Strateg. Manag..

[30]  Kurt R. Linberg.  Software developer perceptions about software project failure: a case study , 1999, J. Syst. Softw..

[31]  Michael D. Myers,et al.  Executive information system failure: a New Zealand case study , 1997, PACIS.

[32]  Tuure Tuunanen,et al.  Extending Critical Success Factors Methodology to Facilitate Broadly Participative Information Systems Planning , 2003, J. Manag. Inf. Syst..