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.
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?