A study in project failure

Research 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 in 2004.

The research looked at 214 information systems (IS) projects at the same time, interviews were conducted with a selective number of project managers to follow up issues or clarify points of interest. The period of analysis covered 1998-2005 the number of information systems projects examined across the European Union.

Number of IS projects examined within European Union

Project value in millions of Euros

At what stage in the project lifecycle are projects cancelled (or abandoned as failures)?

Prior research by the authors in 2002 identified that 7 out of 10 software projects undertaken in the UK adopted the waterfall method for software development and delivery. Results from the analysis of cases indicates that almost one in four of the projects examined were abandoned after the feasibility stage of those projects completed approximately one in three were schedule and budget overruns.

Project completions, cancellations and overruns

Of the initial 214 projects studied 51 (23.8 per cent were cancelled) - a summary of the principal reasons why projects were cancelled is given below. Our earlier research elaborated on the symptoms of information systems project failure in three specific areas: frequent requests by users to change the system; insufficient communication between the different members of the team working on the project and the end users (stakeholders); and no clear requirements definitions. Whilst communication between team and end users was still perceived as an issue within some projects; the top three issues from this study are: business process alignment; requirements management; and overspends.

One notable causal factor in these abandonment's was the lack of due diligence at the requirements phase, an important factor here was the level of skill in design and poor management judgement in selecting software engineers with the right skill sets. Equally the authors found some evidence in poor tool set selection in that end users found it difficult to sign-off design work - in that they could not relate process and data model output with their reality and practical knowledge of the business processes.

Key reasons why projects get cancelled

• Business reasons for project failure
• Business strategy superseded;
• Business processes change (poor alignment);
• Poor requirements management;
• Business benefits not clearly communicated or overstated;
• Failure of parent company to deliver;
• Governance issues within the contract;
• Higher cost of capital;
• Inability to provide investment capital;
• Inappropriate disaster recovery;
• Misuse of financial resources;
• Overspends in excess of agreed budgets;
• Poor project board composition;
• Take-over of client firm;
• Too big a project portfolio.

Management reasons

• Ability to adapt to new resource combinations;
• Differences between management and client;
• Insufficient risk management;
• Insufficient end-user management;
• Insufficient domain knowledge;
• Insufficient software metrics;
• Insufficient training of users;
• Inappropriate procedures and routines;
• Lack of management judgement;
• Lack of software development metrics;
• Loss of key personnel;
• Managing legacy replacement;
• Poor vendor management
• Poor software productivity;
• Poor communication between stakeholders;
• Poor contract management;
• Poor financial management;
• Project management capability;
• Poor delegation and decision making;
• Unfilled promises to users and other stakeholders.

Technical reasons

• Inappropriate architecture;
• Insufficient reuse of existing technical objects;
• Inappropriate testing tools;
• Inappropriate coding language;
• Inappropriate technical methodologies;
• Lack of formal technical standards;
• Lack of technical innovation (obsolescence);
• Misstatement of technical risk;
• Obsolescence of technology;
• Poor interface specifications;
• Poor quality code;
• Poor systems testing;
• Poor data migration;
• Poor systems integration;
• Poor configuration management;
• Poor change management procedures;
• Poor technical judgement.

What is the average schedule and budget overrun?

In examining the cases it was noted that the average duration of a project was just over 26 months (115 weeks) and the average budget was approximate 6 million Euros, (Table 5). In many instances information on a project being over schedule and over budget will force senior management to act, however, the search for the underlying factors should begin else where in the projects history.

The pattern that emerges from a synthesis of case data is complex and multifaceted. In a few of the of cases examined the project commentary and history was ambiguous; however, once a decision had been made to support a project which was over schedule or over budget the ends usually justified the means irrespective of the viewpoints of individual project managers or stakeholders.

Cost and schedule overruns (N=69)

What are the major causal factors contributing to project failure?

Judgements by project stakeholders about the relative success or failure of projects tend to be made early in the projects life cycle. On examination of the project stage reports it became apparent that many project managers plan for failure rather than success. 

If we consider the inherent complexity of risk associated with software project delivery it is not too surprising that only a small number of projects are delivered to the original time, cost, and quality requirements.

Our evidence suggests that the culture within many organisation's is often such that leadership, stakeholder and risk management issues are not factored into projects early on and in many instances cannot formally be written down for political reasons and are rarely discussed openly at project board or steering group meetings although they may be discussed at length behind closed doors.

Despite attempts to make software development and project delivery more rigorous, a considerable proportion of delivery effort results in systems that do not meet user expectations and are subsequently cancelled. In our view this is attributed to the fact that very few organisation's have the infrastructure, education, training, or management discipline to bring projects to successful completion.

One of the major weaknesses uncovered during the analysis was the total reliance placed on project and development methodologies. One explanation for the reliance on methodology is the absence of leadership within the delivery process. Processes alone are far from enough to cover the complexity and human aspects of many large projects subject to multiple stakeholders, resource and ethical constraints.

Although our understanding of the importance of project failure has increased, the underlying reasons still remain an issue and a point of contention for both practitioners and academics alike. Without doubt there is still a lot to learn from studying project failure.

Going back to the research undertaken there is little evidence that the issues of project failure have been fully addressed within information systems project management. Based on this research project failure requires recognition of the influence multiple stakeholders have on projects, and a broad based view of project leadership and stakeholder management.

Developing an alternative methodology for project management founded on a leadership, stakeholder and risk management should lead to a better understanding of the management issues that may contribute to the successful delivery of information systems projects.