Myths of Failed Projects

How many times have you heard frightening statistics on the number of IT projects that “fail”? It is common to hear numbers well above 50%. Does this match your experience in the real world or those projects you have heard about? In my experience, the percent of truly failed projects is much less then that.

The key to determining the real percentage is, of course, to define what is meant by “failure”. I do not know what criteria the various surveys or analysis use and I’m not going to attempt to refute any published studies. But at the start, I will define a successful project as follows:

A successful project is any that provide positive business value over the life of the product of the project.

By this measure, a project could be well over budget and behind schedule at the end of the project, but so long as a viable product is created that delivers positive business value in excess of the cost of the project, it could be deemed successful.

Should we toss out completely measures such as Earned value and Cost performance Index? No, these are valuable in tracking how well a project is proceeding according to plan. These measures, however, only address how well the project team did their planning, not necessarily the value the product of the project brings to the organization. The measurement of “on time and within budget” are subservient to the real statistics that should be tracked, which must be a measure of business value.

If you are a Project Manager, you could argue that it may take years to determine project success based on this definition. You would be right in some cases. But in many cases, it can be rather easy to determine success by the time of project close. For example, a project that replaces an aging, expensive system with a new system based on commodity hardware and software components can be shown to have a payback period within a few months or a year after the project is closed.

It is true that things can go wrong after a project is done and the team is long gone. Only the passage of time will ensure that you know exactly what the payback is and how rapidly it occurred. I know of few organizations that track projects over the necessary spans of time that would be required. That is unfortunate, but a reality, since managers tend not to care about how old projects performed, only how they will get the next one done on time.

Is it worthwhile tracking project performance in this manner? I would suggest that any project manager would be well advised to do this to the greatest extent possible. Track your projects for at least a year a after completion and see how they are performing.

A PM might argue that this metric is outside of his control. He could argue “it’s not my fault if the organization dropped the ball after the project closed”. That might well be true, but it is also important for you to understand why the product did not succeed, it that was the case. Update your lessons learned on the project with information that could be helpful for the next project.

If Project Managers can take a long view of project success, they have a much better chance of being perceived as skilled managers. If we can show that our projects did in fact deliver business value we can all get beyond these myths of so many failed projects.