Understanding the Sources of Information Systems Project Failure

Management Services, Autumn 2007 by McManus, John, Wood-Harper, Trevor

A study in IS project failure

Abstract

Previous research undertaken by the authors in 2002 highlights that only one in eight information technology projects can be considered truly successful (failure being described as those projects that do not meet the original time, cost and quality requirements criteria). Despite such failures, huge sums continue to be invested in information systems projects and written off, for example the cost of project failure across the European Union was 142 billion Euros in 2004. 'Whilst our understanding of the importance of project failure has increased, many of the underlying reasons for failure still remain an issue and a point of contention for practitioners and academics alike. This paper examines through case research some of issues and casual factors of information systems project failure.

Introduction

A predominant paradigm in information systems project management is to view the development and delivery process as a three way trade-off between time, (business urgency). Cost (budget) and quality (product functionality or capability). This paradigm both influences and promotes trade-offs between product functionality, cost and schedule. Trade-offs are mitigated or eliminated entirely through arbitrage or negotiation and despite attempts to make software development and project delivery more rigorous, a considerable proportion of delivery effort results in systems that do not meet expectation and fail to meet user expectations.

Previous research and writings by McManus 4 5 suggest that project management in many software engineering firms currently ranges from undisciplined to chaotic. Few organisations have the infrastructure, education, training, or management discipline to bring projects to successful completion. Research 6 7 8 indicates that more than half of all information technology projects become runaways - overshooting their budgets and timetables while failing to deliver on their goals. The seemingly high level of project failures tied to the time, cost and quality paradigm (frequently reported in the news and professional press) is the motivation for this research, being informed by previous studies into project failure for example, the seminal work undertaken by the Standish Group International, Chaos Report in 1995, 7 and the literature on information systems and the author's own published works and experience in information systems development and project management 1.

Prior research

Prior research by the authors 3 highlights a number of critical causal factors in failed projects. Findings from this earlier research were based on 42 information systems (IS) projects that were completed in the period 1994-2001. These earlier findings included inadequacies in management and technical practices. Management issues accounted for 65% of causal factors identified with failed projects 1 3.

Management causal factors account for 65% of the project failure rate

* Poor leadership in project delivery

* Poor stakeholder communication

* Poor competencies (and skill shortages)

* Poor stakeholder management

* Poor estimation methods

* Poor risk management

* Insufficient management support

Technical causal factors account for 35% of the project failure rate

* Inappropriate and ill defined software requirements

* Inappropriate technical designs

* Inappropriate development tools

* Inappropriate user documentation

* Poor test planning

* Poor technical support

One of the key findings from this earlier research was the lack of stakeholder communication and the need to pass on business and technical knowledge within project community and within the wider management hierarchy. The importance of continuous feedback to each of the participating stakeholders cannot be stressed enough. In particular, details of any mistakes made should be shared with the project community. Based on our analysis of the post implementation audits, there appears a broad consensus that mistakes are acceptable but failure is not. Failure was considered an absolute error that could not be recovered from. It was therefore concluded that success was in fact largely dependent on creating contingency plans and alternate approaches for projects that have a high perceived risk coefficient 1.

This research programme

Adopted methodology

It could be argued that the way research is conducted may be conceived in terms of: the research philosophy subscribed to, the research method employed and the research instruments used in pursuit of the research objective. In the authors view research philosophy may be described as a construct about the way in which data (or information) should be gathered, analysed and used. Research should exhibit both rigour and relevance. The issue of what research approach and methodology might be relevant to information systems project failure has been vastly debated. Earlier research by the authors was undertaken using a 'case' based approach (since much of the material examined came from a single entity systems integration practice). The main attributes of this case based approach may be defined as:

 

BNET TalkbackShare your ideas and expertise on this topic

Please add your comment:

  1. You are currently: a Guest |
  2.  

Basic HTML tags that work in comments are: bold (<b></b>), italic (<i></i>), underline (<u></u>), and hyperlink (<a href></a)

advertisement
Click Here
advertisement
  • Click Here
  • Click Here
  • Click Here
advertisement

Content provided in partnership with ProQuest