In today's economy, there perhaps is more pressure than ever to deliver IT projects on time, on budget and with the required capabilities. However, the Boston-based Standish Group's "CHAOS Summary 2009" report concludes that just 32% of IT projects meet those three criteria for success, while 24% of IT projects are cancelled or are never used.

Paul Davis, an IT security consultant who was known as a "project firefighter" during a 14-year tenure at EDS earlier in his career, asserts that IT projects typically fail because the project team either doesn't understand the full scope of the project or doesn't understand the objectives of the project.

"IT projects aren't put in just for fun -- there's a business objective behind them," says Davis, who is COO of Tampa, Fla.-based Decurity LLC. "So if a project starts dragging out, or if there's a lot of changes in the organization's leadership or if the architect of the vision disappears, a lot of times especially in big projects they lose focus on what they're supposed to be doing."

According to Davis, another common reason why IT projects fail is that the project team hasn't conducted "the appropriate due diligence" to fully understand what time and resources will be needed to complete the project.

"They've sort of lost their depth perception on what's actually required to do the project," Davis says.

According to Eileen Sweeney, president, manufacturing group, for Falls Church, Va.-based Computer Sciences Corp. (CSC), a lack of buy-in from non-IT executives can derail a project.

"So the business may feel that it is an IT-driven project that the CIO is just kind of ramming down everyone's throats," Sweeney explains. "If the executives don't really sponsor the change that is happening, you get a lack of participation and a lack of ownership and buy-in from the business units. It causes a lot of friction. And then I think the CIO is sitting in a very vulnerable position, trying to drive change without having the right executive alignment and sponsorship, because the IT programs aren't just IT programs -- they're business change programs."

If your project is in danger of derailing -- or even if it isn't -- consider these suggestions for preventing future calamities.

  • Break it up. Davis recommends staying away from what he calls the "Big Bang Theory of Project Management," and instead advises breaking projects into manageable pieces. Chris Colen, vice president of program management and solution architecture for CSC's Global Business Solutions, agrees, adding that it's important in each phase to show the business value that's being delivered. "You do it in pieces so that you're delivering capability, you're demonstrating competency and you're generating energy around the program," Colen says. "...As opposed to waiting for some big bang to occur, and the technologists sort of go in their hole for a while and everybody sort of loses interest."
  • Celebrate wins. Monitor the progress of the project -- but don't manage it "down to the minutiae" -- and celebrate whenever the project team hits a milestone, Davis suggests. In his experience, such celebrations "built the team, it took their minds off what we were doing and they had a chance to get a break from the stress," he says.
  • Understand the risks. According to CSC's Colen, the projects risks need to be evaluated from a number of different perspectives, starting with the technology risk. "Are you the first one to ever use this technology? Are you on the leading, bleeding edge?" Colen says. "I prefer to tell our customers that it's nice to be the first one, but it's kind of nice to be a little bit behind the wave too."

    Also consider the business risk ("What's the impact of failure on the business?") and what Colen calls the environmental risk. "I'm talking about the impact on the organization -- the environment that the technology is going to be deployed in," Colen says. " Are you making a dramatic step changes in the technology footprint? I've had customers who have gone from green screen to leading, bleeding edge supply chain implementations, and people really didn't think about the impact on the human resource -- someone who is really steeped in 1970s, 1980s technology -- and bringing them into sort of the fourth-generation evolution on some of these products." Included in Colen's definition of environmental risk is the geographic footprint of the deployment. "The complexity is exponentially harder if you're deploying to multiple locations, multiple regions of the world."

  • Put the technology through its paces. If an IT implementation fails to meet the functionality requirements that were needed or promised, Sweeney asserts that more time should have been spent evaluating the technology. Too often, she notes, IT leaders "become enamored with the technology and say, 'Oh, let's start playing." Instead, the IT department and subject-matter experts need to "put the business processes through the technology to see if it meets those business practices ahead of time," Sweeney explains. " There has to be a good pairing of the technology solution to what your business processes need to be."
  • Stick to the plan. In Davis' experience, failing to "lock down the specifications of the project" has led to the demise of many IT projects. "People keep adding on pieces, adding on pieces, adding on pieces," he explains. "I've gotten to the point where any new requests for new functions and features are going to go into the next release." Ultimately, IT leaders need to make it clear that "this is what we're going to deliver this time, these are the specifications, this is the functionality, these are the interfaces," Davis says, "and then stick with that, and let the people either succeed or fail at that." When organizations become enamored with new technology and are tempted to pile on more features to the original project plan, Colen recommends viewing those changes as "enhancements" that can be made after implementation. Colen has found that a few months after the IT project goes live and has been stabilized, those enhancements don't seem as important as they did when they were first proposed.
  • Know when to speak up. When a project has derailed, it's easier to take a step back, revalidate the project's objectives, assess what has gone right and wrong (and why) and then "recast the project" than it is to scrap the project and start again from scratch, according to Colen. But when a project is completely off track, IT leaders need to muster up the courage to engage the emergency brake. "It takes guts to stand and up and say, 'We have to stop this project, we have to figure out what we're doing wrong,'" Colen says. "But what I've found is you end up moving faster and achieving your outcomes much quicker that way, as opposed to trying to engineer a turn of a program while it's underway."

Interested in information related to this topic? Subscribe to our Information Technology eNewsletter.

See Also