IT Myth 5: Most IT projects fail

Reality: It all depends on how you define failure

Do most IT projects fail? Some point to the number of giant consultancies such as IBM Global Services, Capgemini, and Sapient, who feed off bad experiences encountered by enterprises. “Sapient is a company founded on the realization that IT projects are not successful,” says Sapient CTO Ben Gaucherin.

Others counter by saying failure is relative. Sure, many projects have minor system glitches or come in over budget, but they don’t rise to the “failure” status that would seriously harm the user’s business.

“If a project is three months late or 5 percent over budget, that may be a disappointment, but it’s not a failure. That’s the case with most IT projects,” says Jim Shepherd, vice president of research at AMR Research and co-author of AMR’s 2004 ERP report.

Although there may be myriad ways that projects can experience problems, actual implementation usually succeeds, Shepherd says.

The Standish Group, which exists solely to track IT successes and failures, sets out very strict criteria for success. For its Chaos Report, The Standish Group surveyed 13,522 projects last year and showed that unqualified project successes are well below 50 percent, 34 percent to be exact. Out-and-out failures, defined as projects abandoned midstream, are at 15 percent. Falling in between the two are completed but “challenged” projects. The report says challenged projects represent 51 percent of all IT projects and are defined as projects with cost overruns, time overruns, and projects not delivered with the right functionality to support the business.

The level of success can be tied to the degree of user involvement, executive management support, and having an experienced project manager, in that order, the report says.

For IT project consultancy Sapient, the key ingredient to success or failure rests on the processes a company puts in place to manage risk. In other words, it’s essential to identify a point of failure before it brings down an entire project. “The larger the project, the greater the chance of failure, and therefore the more effort you want to put behind managing risk,” Sapient’s Gaucherin says.

Gaucherin adds that potential problems can be managed by “bubbling up risk,” a methodology for identifying problems before they get out of hand. To that end, projects are put on a value chart with plot points becoming project milestones plotted over a time line.

“As soon as we start veering off, we ask [ourselves] why,” Gaucherin says.

Probably the news with the most damaging implications for IT projects is not the number of those that were abandoned, rather it’s those that were completed but offer fewer features and functions than originally specified, says Karen Larkowski, executive vice president at The Standish Group. “Content deficiencies of more than 50 percent would most likely be considered a failure,” she says.

But AMR’s Shepherd has another view, which he says is more realistic. “Failure would be a situation where orders stopped being taken, or the books couldn’t be closed, or the project itself was simply abandoned,” Shepherd says. “That’s rare.”

(Return to special report)

Copyright © 2004 IDG Communications, Inc.

How to choose a low-code development platform