Project Failure-The Numbers, Why, and What It Means

  • Written By: Olin Thompson
  • Published On: June 11 2005



Introduction

Information technology (IT) projects fail regularly—considerably missing expectations, drastically overrunning budgets, significantly missing their deadlines, and far too often having to be abandoned entirely. Research shows us that this is the rule, not the exception. Research also tells us why. What is the impact of failure on enterprises, IT professionals and software and services providers? Does it have to be this way?

Failure Facts

First, let's look at the facts relative to all IT projects. These facts give enterprises an overall impression of the risk involved with IT projects. Since a large percent of IT projects involve application products or external services, we will then investigate the reasons for failure for these projects and the impact on the companies involved.

The Standish Group (http://www.standishgroup.com) has been doing surveys on all types of IT projects since 1994. Their research, published under the title CHAOS, reveals some facts that, to most, will be astonishing.

For the last year that figures are available, 2001, The Standish Group CHAOS database shows a staggering 31.1 percent of projects being canceled before completion. Further results indicate 52.7 percent of projects cost 189 percent of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars.

For successful projects, the proportion of projects that are completed on time and on budget is only 16.2 percent. And, even when these projects are completed, many are no more than a mere shadow of their original specified requirements. Projects completed by the largest American companies have only about 42 percent of the originally proposed features and functions. Smaller companies do better, but there is still a pretty large gap. A total of 78.4 percent of their software projects will get deployed with only 74.2 percent of their original features and functions.

For purposes of the study, The Standish Group classified IT projects into three resolution types:

Succeeded: The project is completed on time and on budget, with all features and functions as initially specified.

Challenged: The project is completed and operational but over budget, over the time estimate, and offers fewer features and functions than originally specified.

Impaired: The project is canceled at some point during the development cycle.

To summarize, the Standish Group's research shows that being over budget is common. Delivering projects late is normal. Delivering less functionality than was originally planned is nothing special. In short, project failure is almost standard operating procedure.

Failure Causes

A number of studies have focused on why projects fail. A study from Peerstone Research (http://www.peerstone.com) focuses on projects that involve application software products and external services, commonly called implementation projects. This research tells us that the number one reason for obstacles to success is that senior executives fail to lead. However, the second through seventh reasons all focus on shortcomings on the part of the software or services vendor.

Although the number one reported cause of failure is senior executives failing to lead, we expect that this is rarely stated within enterprises with failed or challenged projects. Call it denial or politics; we expect the number one reason is usually left unstated. The result is that the blame falls to issues two through seven, where the blame is clearly placed outside of the organization on the software vendor or service provider.

Failure Implications

Many IT professionals and vendors would dispute these findings. We often hear vendors say, "That does not reflect our customers' experience."

You could focus on the accuracy of these studies or run your own analysis. The issue, however, is that the failure rates and causes reflect what many people consider to be the truth. These perceptions on the part of senior level executives and others lead to difficulty in getting new projects approved and projects being viewed under a microscope once underway. The environment for IT projects is not a pleasant one for most enterprises and their suppliers, and not a productive one either.

The fact that these perceptions exist means that IT professionals, project managers, software vendors, and service providers all have to deal with the perception in order to be successful. Remember, perception is reality.

Failure Implications and Recommendations—Enterprises

Given the perception of high IT project failure rates and a belief that vendors and service providers are the main cause, IT decisions are frequently heavily scrutinized. Management sees risk in all IT projects and demands that the risk is proactively addressed. Proactive risk management typically leads to IT professionals and other decision makers performing significant due diligence on potential suppliers.

Reference checking is more important than many enterprises consider it. Insist on talking to other enterprises that have used the products and services being evaluated. Try to talk to individuals who are in the same role as you are in your enterprise. Talking to your counterpart gives you a greater understanding of the challenges and opportunities when dealing with the suppliers.

When discussing a supplier with references, ask about the issues (two to seven above) that the Peerstone study discuss relative to the suppliers. When evaluating an offering, remember that people provide services; interview the supplier personnel who will be actually working on your project. The supplier may have many good people, but will you have access to them?

Failure is often defined relative to what was planned rather than what was possible. Set realistic expectations for both the project and the results. Communicate this plan with frequent updates on progress to maintain alignment between expectations and results.

Failure Implications and Recommendations—Vendors and Service Providers

Given the perception of high failure rates and the view that suppliers are typically at fault, suppliers should not be surprised at long sales cycles, no-decision decisions, high cost of sales, and in-depth due diligence. Suppliers can assume that they are selling into a skeptical environment. A stated or unstated concern over risk is always part of the decision-making process. These are factors that suppliers must address.

Suppliers must understand the failure implications on the buyers (as stated above) and what this means to their sales process. The best way to overcome the perception of risk is to demonstrate success. Suppliers must highlight that their product and services are proven in a setting similar to the environment faced by the prospect. Ideally, references should be of the same size and from the same industry as the prospect with individual contacts being in the same role as the person making the call or visit. Correctly matching references to the potential buyer gives the prospective buyer more confidence in the solution and the suppliers.

Since the fear of failure will be part of the consideration, suppliers must effectively communicate those things that reduce the odds of failure. Highlight project management, testing, education, and proven methodologies. Discuss executive involvement on the part of the prospect's executives and how your executives will be involved to maintain open communications at this level.

Given the perceptions of the buyers, the supplier's credibility will be challenged. A successful supplier must take proactive steps to enhance their credibility in the eyes of the buyer.

Summary

Not all projects will be successful. The perception among enterprises is that this is all too common. IT professionals and suppliers must recognize this commonly held perception and deal with it proactively. IT professionals must accept this perception and work with senior management to eliminate both risk and the perception of risk. Suppliers should provide proof of success and proactively communicate risk abatement techniques.

About the Authors

Jim Brown has over fifteen years of experience in management consulting and application software focused on the manufacturing industries. Brown is a recognized expert in software solutions for manufacturing and has broad knowledge of applying enterprise applications such as product lifecycle management, supply chain management, and ERP to improve business performance. He served in executive roles for software companies specializing in manufacturing solutions before starting his consulting firm, Tech-Clarity, Inc.

Olin Thompson is a principal of Process ERP Partners. He has over twenty-five years experience as an executive in the software industry. Thompson has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry.

 
comments powered by Disqus