How to Prevent IT Project Failures

The Issue

For the past year I have been doing research on the causes of IT project failures and on how to prevent them. Here is a summary of what I have leaned. More information is available on my web site: www.ghco.biz.

More than forty years after the advent of third generation computing, the IT profession overall still doesn’t know how to execute IT projects predictably and successfully. 70% of all IT projects fail, a number that has been documented in numerous surveys conducted by many organizations in many countries. This number is startling, and a bit frightening when you recall that IT expenditures constitute more than half of all capital expenditures by American businesses.

Maybe we are too prone to use sports as metaphors for business. If a baseball player consistently bats .300, he is likely to get a multi-year, multi-million dollar contract. Why shouldn’t a CIO who bats .300 (which is the same as saying that 70% of his projects fail) also get a multi-year, multi-million dollar contract?

Several possible explanations occur to me. One is that the baseball player’s career is very short and he should be compensated for a lifetime during the few years he plays. On the other hand, is a CIO’s career really any longer? Current statistics say that it is not. Or maybe it is because anyone interested can see for himself how good a job the batter is doing while it is almost impossible for a spectator to see how good a job the CIO is doing. Or maybe because the ball player is more fun to watch. Resolving this compensation anomaly would be interesting, but we have a better chance of increasing the CIO’s batting average, so let’s look at how we could to that.

The Costs

The costs of these failures are substantial. Here is an analysis of a hypothetical company based on industry averages.

Revenue	$100 MM
IT budget @ 5% of revenue	$5 MM
Application development budget @ 20% of IT budget	$1 MM
Total budgets of failed projects @70%	$700,000
Budget overruns @ 50%	$350,000
Average project length	2 years
Average schedule over-run of project @30%	0.6 year
Average planned ROI of projects	25%/year
Foregone profits of late projects @ 0.6 x 0.25 x $700,000	$105,000
Total annual losses because of budget and schedule overruns	$455,000

Looked at another way, preventing project failures can increase the productivity of a system development department by 45%.

Root Cause Analysis

What does it mean to say an IT project is a failure? A project is a failure if the relevant business executives say it is. Here is a reasonably comprehensive list of things that might cause a business executive to make that judgment. Call them indicators of failure.

1. End product of the project does not meet real business need.
2. End product of the project does not support organizational strategy.
3. Project implementation was chaotic and disruptive.
4. Project was not implemented or was soon abandoned.
5. Degree of project success or failure is unclear.
6. Success or failure of future projects is unpredictable.
7. Project exceeded budget.
8. Project was finished late or not at all.
9. Final product lacks originally planned functionality.

Items 1-6 above have to do with the business effects of the project; iems 7-9 are more focused on the execution of the project by IT.

My root cause analysis of IT project failures identified these seven generic root causes:

• Incomplete project planning and evaluation.
• Project plan misses non-technical issues.
• Roles and responsibilities of users, senior. management, and IT are not well understood and agreed to by all parties.
• Bad or non-existent communications among interested parties.
• Inadequate project governance.
• Lack of post audit procedures and project archive
• Inconsistent application of good practices.
  

In the course of the root cause analysis, several things became clear.

• Most of the project failures – but certainly not all of them – have non-technical causes.
• Many of these causes exist outside of the IT function and hence beyond the direct control of IT.
• The relationships between the indicators of failure and the root causes are many and complex. For example, “end product does not meet real business need” might be caused by bad project planning, or by inadequate project governance. Similarly, each root cause may influence more that one bad result. For example, inadequate project governance may lead to budget overruns, schedule overruns and/or chaotic or disruptive implementation.
• Although it may be expedient to attack the root causes one at a time, you should remember these interactions and not be surprised when fixing one root cause does not cure the specific problem you are addressing.

Preventing Project Failures Before They Occur

A program to prevent these failures should include these elements.

• A careful analysis of the “as is” situation. This analysis will almost certainly show that some of the generic root causes have already been taken care of, and it may also identify company specific root causes not included in the generic list.
• An educational program for all the relevant constituencies, including senior corporate management and senior business unit management as well as the IT community.
• A business process redesign of the project management function to address the needs identified by comparing the “as is” situation with the results of the root cause analysis.
• Institutionalizing the new business process by coaching the project team through at least one project.

This may sound like a complex and onerous process, but it really is not. It will be a little awkward for the first project, but the payoff will be substantial.

<><><><>