3. Poorly Defined or Changing Specs
What can go wrong: Some experts say that, along with lack of early input from stakeholders, this is the font of all IT project failures. "The requirements aren't well spec'd up front, and the project begins anyway. You've got no charter, no consensus among stakeholders," Keil explains.
In 1983, Alan Davis - now CEO at Omni-Vista, a Colorado Springs consultancy - was employed at another consultancy. "A telecom company hired us to assess a project," he says. "On the first day, I asked the project manager for a copy of the requirements spec. His answer was: Which one? We have two. Marketing sold one to [the client], the development team is building the other one'."
What you can do about it: Once again, securing input from stakeholders is the key. "To define the problem, you've got to know who you're solving it for," Hoenig says. A long series of meetings and discussions up front will help build consensus on what an IT project can and cannot do.
Once the requirements are defined, project hygiene comes into play. Any schedule slips or requests for additional funds must be formally justified. "Senior management can help drive this stuff," says Matt Light, a research director at Gartner (US). "They can ensure there's organisational context, that project management is not going to happen in a slipshod manner."
(As for the project with two specs, Davis's team urged a full-disclosure sit-down between both companies' CEOs and the project manager. The consultancy begged for and received an extra year to complete the project.)
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.