- Got Your Money on Your Mind?
- Got Your Mind on Your Money?
- IT and Project Cost Control
- Cost and the Project Manager
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Got Your Mind on Your Money?
As the project moves toward completion, there will likely be a need to revise the project's price. If the project started with a ROM estimate, the original estimate could be wildly wrong. The customer who reads the ROM estimate should know that the final cost is likely to be much different from that estimate. No doubt the customer will be anxious to hear your more accurate definitive estimate.
Of course, from ROM to definitive, estimates can be just plain wrong. It's not fun to have to approach your sponsor, stakeholders, or customer with hat in hand and beg, plead, scrounge for more cash because your project estimate was way, way off. Poor planning is the major cause of poor estimates. Rushed estimates, bloated estimates, or estimates that are "low-balled" just to get the project moving are bound for budget reviews, unpleasant conversations, and project reassessments.
Sometimes, thankfully, it's not the project manager's fault when the estimate must change: The cost of materials has changed, the anticipated time to complete the project work was wrong, or the bases for decisions were faulty. In these instances, the project manager still has to communicate the variances, which isn't fun, but it's easier than taking the blame when that blame is all yours.
Poor estimates can also be the fault of the customer, stakeholders, or even the project sponsor. When the stakeholder is responsible, the increase in cost is usually tied to a change request. Contrary to public opinion, change requests are not good things. Ideally, when the customer and the project sponsor sign off on the scope statement, no changes should ever be made to that scope. Of course, errors and omissions, technological enhancements, and value-added changes all affect the scope's resistance to change.
If the customer demands new deliverables in the project scope, however, a price tag is usually associated with those demands. The monies needed to implement the change have to come from somewhere—and not your wallet. Even changes that replace current scope components may have a price; time and monies may already have been invested in these deliverables. In my opinion, change after the scope statement is a bad, bad thing.
We'll talk more about change management in a future article. For now, know this: When the project scope changes, the budget usually has to change as well. Changes generally cost something, and that means a budget increase.