Budgetary Black Holes

Computerworld - IT projects are notorious for being over budget. In fact, Gopal Kapur, president of the Center for Project Management in San Ramon, Calif., estimates that 77% of projects blow their budgets, with an average cost overrun of 169%. As for the remaining 23%, Kapur doesn't have a lot of faith in those project managers. "They just lie about it," he says.

Perhaps if project managers knew where the biggest money wasters were, these statistics would improve. With that in mind, we spoke with experienced project managers and other experts to find out where the black holes of project management are and how to avoid them.

1. Scope creep. It can begin early, at the requirements definition stage. "People say, 'We're spending the time and money anyway, let's add this and this,' " says Mark Reilley, director of IT at the Corporation for Public Broadcasting in Washington. "This expands the scope way beyond what you can accomplish or really need."

Even well-planned projects expand up to 2% on their own each month throughout a project's duration, says Capers Jones, founder and chief scientist of Software Productivity Research LLC, a consultancy in Marlboro, Mass. One reason is "technical gold-plating," explains Gregory Fouquet, a consultant at Ouellette & Associates, a consulting firm in Bedford, N.H. "It's where well-intentioned programmers add features and functionality that haven't been specified but are neat or slick," he says. "It eats away at productivity and introduces difficulties in testing."

Solution: Keep to core functionality by defining requirements as "must haves," "should haves" and "nice to haves." To keep developers in check, Fouquet advises rigorously specifying must-have requirements and tracking them through the development process. "This is trickier for project managers who come from the business side and don't understand technical complexities," he says. For these managers, enlist the help of a good, credible IT person. Reilley also suggests lowering user expectations by releasing something small in scope that you can add to later. "Usually Version 1 is the prototype, and when users see it, it's good enough," he says.

2. Building a too-sophisticated GUI too early in the project. Most graphical user interfaces change dramatically from the requirements definition stage to the final release, says Johanna Rothman, president of Rothman Consulting Group Inc. in Arlington, Mass. And yet developers are always tempted to perfect the GUI in electronic form at early stages in the project.

Solution: Start with low-tech GUI prototypes. Rothman suggests representing the user interface with either a paper prototype, using colored pens and yellow stickies, or through a drawing program or software such as Photoshop. "If you start off with an electronic representation of the GUI, it's incredibly expensive," she says. Don't do it until you've frozen the final plan.