9.10 Where Does the Money Go?

< Day Day Up >

If cost overruns are typical, why is that so? You may select your favorite from the following list of potential explanations:

If the initial budget was off target, you cannot win for losing.
Even if you do a credible job of reforecasting the budget after a rigorous requirement development process and publicize the need for additional funding, the project number may remain locked in at the lower, inaccurate amount.
Delays due to poor planning, performance, participation, and as the insurers say, "acts of God or terrorism," all cost money.
IT projects have a way of being more labor intensive than originally thought. As the project begins to lag, it is common practice to throw more resources at the sticking points. That costs money.
Requirements can change once the beneficiary gets involved. These changes are probably going to inflate actual cost beyond the original budget. We built out a new corporate campus and ran over budget on the network side by a significant sum. The main reason was that the customer wanted more LAN and telephone connections in conference rooms and other common areas than was originally planned. This required the purchase of additional telecom switch cards for dozens of floors. You can call this poor requirements gathering, or you can call it giving in to the customer (i.e., "scope creep"). The reality is that internally this additional cost will be recouped by the monthly service charge billed to the beneficiaries for those extra ports. Those funny money credits go to the service organization, however, while the overrun stays on the project books forever.
There is a scenario I like to call "oh, you want it to work?" Sometimes, if you do not ask the right way, or the right person, you will fail to get the right answer. You may find yourself sitting in a meeting one day with technical staff or a vendor and have to bite your tongue when they tell you with a straight face that the "real cost" has just doubled because you never told them that conditions C, D, and E were in scope. Your distemper, of course, emanates from the fact that you thought that clearly stipulated conditions A and B quite naturally implied that C, D, and E would be required as well, and thus would have been covered by the original cost estimate.
You do not watch carefully and get ripped off. Once a project code is published, all kinds of people may bill against it, some of who have no business doing so. Vendors cannot always be assumed to be on the up and up, either, although many such instances of internal or external fraud wind up being characterized as misunderstandings. Although it may be difficult to swallow, people are out there who, unfortunately, will take the opportunity of project chaos to literally steal equipment, for example.

< Day Day Up >