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."
View article on one page