Budgetary black holes

10 mistakes that can suck the funds out of your IT project budget -- and how to avoid them

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.

3. Lack of negotiation skills. Few project managers get formal education in how to negotiate the best prices for software or contract labor. "They are like lambs waiting to be fleeced," Kapur says.

Solution: Develop basic skills. At the Center for Project Management, Kapur asks project managers to give him an offer for a new and a used car. He checks to see if they use the Web to research accident histories and Kelley Blue Book values, as well as how many dealers they contact and how much they find out about financing terms. "I like to see the process they've gone through, and most have just not learned it," he says.

Negotiation skills are also communication skills. For instance, after you've made an offer, Kapur says, don't say a word. "Instead, [silently] count or recite the names of people you know," he says. "Most people can't handle that." Kapur also suggests that project managers spend a week in the procurement department to learn how negotiations are handled. For instance, purchasing software at the last minute can be three to five times more expensive than buying it in advance.

4. Not understanding project finance, which is different from project accounting. "People just don't understand what money meansÑlike if I add money to this project, another project can't be done," Kapur says.

Solution: A short course in financial concepts and terminology. Particularly for complex projects that last longer than six months, Kapur advises project managers to educate themselves and their teams on concepts such as internal rate of return and net present value. "We're not making people experts, but they should have enough knowledge to recognize both the problem and the solution," he says.

5. Implementing large, big-bang projects. Research shows that per-person productivity decreases as the project size goes up, says William Roetzheim, founder of Cost Xpert Group Inc. in Rancho San Diego, Calif. Additional communication overhead, more formal requirements, more detailed design and the increased number of meetings all add expense. With small projects, Roetzheim says, the time spent implementing the project is 60% of the total versus 8% to 10% on very large projects. "The rest of the time is spent on coordinating, communicating and additional testing," he says.

Solution: Break up projects into smaller, more manageable pieces. Studies have shown a correlation between high failure rates and large projects, Roetzheim says, but smaller projects are also more cost-effective.

6. Overtesting. We've all heard of analysis paralysis. Reilley suggests that there's also a phenomenon called testing paralysis. "Maybe it's because you've had a bad experience in the past with bugs popping up at the last moment, so you keep testing and testing," he says. Or developers could just be playing with fonts to impress users. The result: overshot deadlines and a waste of resources.

Solution: Accept it: There are going to be bugs. At some point, you have to say, "Enough is enough," Reilley says. Tell the users that there will be bugs and that the team will work them out. Shoot for 80% perfection, not 100%.

7. Duplicate or overlapping tasks. Particularly in large, dispersed companies with no central IT department, you might not know that you could borrow ideas or perhaps even a system from another group that already addressed the same challenge you're facing.

Solution: A searchable project library. Kapur suggests building a simple word-processor-based system that tracks all projects undertaken in the company, with standard naming conventions and keyword searches.

8. Poor estimating. If costs and schedules aren't well understood in the beginning of the project, when problems arise, it's often too late to reallocate IT resources effectively, Roetzheim says. The worst-case scenario is when a manager realizes halfway into a project that it's behind schedule, and he throws more developers or testers on the job, Rothman says. These latecomers don't understand the problems or how the application works, so they can't come up to speed quickly. "That's completely a waste of money," she says.

Solution: Cut your losses, and next time, use an estimating tool. The best thing to do when you realize that you didn't estimate resources properly, Rothman says, is to figure out the minimum requirements for finishing the current project and immediately begin planning another project in which you can use your money more effectively. Roetzheim also suggests estimating tools as a means to predict costs and schedules.

9. Lack of cost-to-date and estimate-to-complete data.Too often, team members are completely unaware of whether they're on track with the project budget. At Comdex one year, Kapur asked 160 people in one of his sessions to tell the people seated next to them what their project budgets were and the costs to date, rounded to the nearest thousand dollars. Only 7% were able to do it.

Solution: Develop and monitor cost vital-sign thresholds. Kapur uses a process where the sponsor and the project manager jointly define cost thresholds. He also recommends telling the sponsor that cost overruns will come out of his own budget or even his paycheck as a wake-up call to track costs.

10. The project should never have been authorized. Projects can get assigned that have little business justification or just don't pass the "smell test," as Ouellette's Fouquet puts it. How do you avoid setting something in motion that's destined to be a true money pit?

Solution: Forget the politics; stop the project. At the very least, says Reilley, "everyone should be able to answer, 'The purpose of the system is blank.' If you can't describe it in a few words, maybe your focus is too broad."

It's the project manager's obligation to validate a project's legitimacy, Fouquet says. "It's what distinguishes a professional project manager from a hack," he adds. For instance, if you realize halfway through the project that there's no business-side commitment to a training plan, stop the project, advises Bob Benson, a senior consultant at Cutter Consortium in Arlington, Mass. Adds Benson, "Project managers have to be willing to call it bad news when it's bad."

Brandel is a Computerworld contributing writer in Grand Rapids, Mich. Contact her at mary.brandel@comcast.net.


How often do your actual effort and cost data match the estimated effort and cost data?
How often do your actual effort and cost data match the estimated effort and cost data?

Do your project managers have the appropriate skills to develop accurate estimates?

Do your project managers have the appropriate skills to develop accurate estimates?

Base: 198 individuals representing 148 corporations

Source: Center for Project Management, 2003

Copyright © 2004 IDG Communications, Inc.

Shop Tech Products at Amazon