Managing and Documenting Budget Overruns

Because you've likely gone through a fairly extensive cost-estimating phase in the development of your project plan, you would expect that you've identified costs and won't be hit with substantial surprises. But what if you are?

There are two distinct realms in which you may run into a budget overrun surprise:

■ Too much time worked on a task

■ Procured item more expensive than originally anticipated

Both of these can be accounted for somewhat in the planning process. Time Overruns

Earlier in this book, I had a section on time estimating. I indicated that you should have the person who's going to perform the task estimate the amount of time it will take. The theory behind this is that the person you've picked to perform the task is the most qualified one, and as a result, he or she should have an experiential background that dictates to them some idea of how long a given task should take. You then tack on some overhead for administrative and supervisory purposes, as well some quality-control overhead. This add-on figure could potentially be very large—perhaps double, or a little beyond double, what this person originally estimated in terms of cost. Thus, you have a substantial cushion built into the time estimate for a given task.

But what if you didn't go through this time-estimating process to begin with? Following are some things that could arise if you skipped time estimating or if you went through the estimating process but didn't think of everything.

Blue-sky time-estimating technique Maybe you used the "blue-sky" technique for estimating the amount of time a task would take to finish. Blue-sky means about the same thing as "guesstimate"—you simply grab a figure out of the air that seems to be close. Blue-sky is great for PMs who have done a task a thousand times and could do it in their sleep. But people who are new to the task may find that blue-sky underestimates the amount of time required for the task they ' re currently estimating.

No estimators Maybe you didn' t have anyone to estimate the task, perhaps because you knew you needed to use contractors for a given task but had not yet contracted anyone. Team member too slow Alternatively, you might' ve gone through a time-estimating procedure, but you have a person performing the task who simply isn' t working as fast as he could and therefore is going to incur some overtime in getting the task finished. Quality too much of a concern The person doing the work might be quite concerned about quality control and is taking extra time just to make sure "it' s done right." Quality is always a concern, of course, but when she did her time-estimating, you probably expected that she' d factor in the same level of quality as would be applied during the work. Building in a quality-control overhead factor might alleviate some of this. Technical bugaboos You run into technical hurdles you hadn 't anticipated, and the task or tasks that you ve outlined that center around this component are taking dramatically longer than anticipated, despite best- guess efforts on the part of team members. These kinds of obstacles can surface everywhere in the IT aspects of the project: from a developer who can ' t figure out how to get the color blue to correctly display on a special screen, to web coders who can ' t get a piece of JavaScript code to work correctly with a given system.

You can probably add more to this list, these are but a few. However, the point is that paying attention early on to time-estimating, making sure that your time estimates are accurate, will save you some of the problems alluded to above.

The integrated-systems problem? Well, back in Chapter 3, we talked about the "a miracle happens here" phenomenon, where IT managers convince themselves that two or more systems can talk to one another through some sort of convoluted process. Unless a given software system has built-in tools that allow it to easily talk to another system (and vice versa if required), integrated systems are a sure-fire way to deadlock and eventually kill a project, or to produce a deliverable that is very poor in quality. Consider XML and SOAP running on applications servers when business managers begin talking about integrated systems.

Was this article helpful?

0 0

Post a comment