In-Depth

The Tyranny of On-time and On-budget

Is delivering every project on-time and on-budget a worthy goal or a warning signal of deeper problems?

• By Jim McGee
• 02/22/2005

Are you troubled by routine reports of how many IT projects fail? Me too. But I'm troubled about something different than most.

Conventional wisdom claims that something like 50 to 70 percent of all IT projects fail. Most of this wisdom seems to trace back to a series studies started in the mid-1990s by the Standish Group. The basic facts wiggle around from year to year, and different sources with an axe to grind publish updates on this survey from time to time, but the meme seems to trace back to this work. Other than as a way to either beat up on IT management or to sell project management services by systems integrators, is there any important insight buried in this data?

Increasingly, I think not.

IT project management grew out of construction project management and large-scale engineering design projects: large, complex undertakings with lots of moving parts and lots of dependencies. Over the years, we've developed a rich set of tools and techniques for planning and managing these kinds of efforts. Yet we continue to miss deadlines and overrun budgets routinely. More diligence in applying tools and techniques isn't the answer.

The problem starts with the tyranny of the notion of "on-time and on-budget." Suppose you delivered every project you ever worked on on-time and on-budget. Would that be a good thing for you or your organization? I can win every race I run if I pick the competition carefully enough, but I won’t get any better as a runner. An organization that completes all of its projects on-time and on-budget isn’t likely to be getting any better in its competitive environment either.

This leads us a level deeper. Asking how many of my projects should finish on-time and on-budget is equivalent to asking what kinds of risks I want for what kinds of rewards. That’s a more interesting question to explore.

Getting an answer starts with asking yet another question—what does the landscape of projects in my organization look like? In most organizations, getting a decent inventory of active projects turns out to be a harder problem than you would think.

First, "project" is a pretty slippery term. When both a 6-week effort to create some new reports and a 3-year ERP rollout can be labeled a project, you have some challenges in getting to reasonable comparisons.

Second, your resource pools don’t always line up neatly with projects. Despite efforts to match staff to particular application areas or organizational units, there’s usually a fair degree of noise in the way projects and resources get mapped against each other that leads to confusion.

Finally, the level of discipline and precision around setting schedules and budgets varies immensely even within organizations.

All problems with data collection aside, even a crude inventory enables important conversations about priorities and project mix. Categorizing projects with the following simple scheme helps focus the conversation.

There are three types of projects that use IT to deliver some form of business value:

• Stay in Business projects
• ROI projects, and
• Innovation projects

Stay in Business projects are the ones you have to do to keep the IT lights on; dealing with new rules and regulations, upgrading to new software releases, and the like. Trying to calculate an ROI for these projects is an artificial exercise. You want to control costs and effort, but trying to quantify business benefits and returns doesn’t yield a lot of incremental value.

ROI projects, on the other hand, are those that appropriately support trade-off debates about which reasonably well-understood efforts are likely to provide the most quantifiable business value. Do we invest in collecting cash more quickly with a lock-box application or reduce turnover in our call centers by improving the way we capture and share knowledge about customer problems and solutions? These are the kinds of projects where both costs and potential returns can be estimated with some confidence and where we can review how well we manage to those estimates.

Innovation projects are more difficult to assess. They are the experiments we need to run to understand whether we can create the opportunity for ROI projects. They are about learning what can be done with technology new to our organization or by using technology to create new channels or new processes. These are projects where the investment buys new knowledge and insight for the organization, not financial returns.

A healthy organization will have a balanced mix of projects. Some will be judged on their ability to meet time and budget estimates, some by how quickly they begin to generate returns, and some by what they teach us. The management task is to get the conversation underway.