In budgeting cost of the overall project, what should the PM remember? What are the do's & don't s when dealing with the budget of the project?
closed as not constructive by jmort253 Sep 7 '12 at 0:49
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
Make sure the budget covers 100% of the scope and includes risk contingency and management contingencies.
Do: An estimated budget and a target budget are two different things. When estimating, you should conduct it in a non deterministic way; that is, you need to estimate the probabilistic distribution of the budget--or time--the pessimistic, optimistic, and most likely values. A "realistic" budget is any value under that curve, even at the 1 percentile, just not very likely.
The target estimate is the single-point value you choose under that probabilistic distribution, against which you will establish your performance measurement baseline. Start around to 50th to 60th percentile and go fatter if you have a lot of uncertainty or go leaner if the project is run-of-the-mill in nature.
Establish your budget against a baselined product/deliverable-oriented WBS so that it is crystal clear that your target budget is associated with that WBS and nothing more. Any new introduction of scope will constitute a change.
Don't: think you are going to hit your target with a zero variance. If you have a zero variance, either you were extremely lucky and that performance will never ever happen again in your lifetime or you cooked the books. And I'd put my money on the latter.
And as Mark indicated, fund your reserves. Where your target falls under the probabilistic curve will give you a clue as to how healthy your reserves need to be.
Be realistic. Don't be tempted to trim costs to make them meet some arbitrary target figure or to help with the benefits case: you cannot guarantee to negotiate discounts or avoid elements of expenditure. But equally, don't pad out the costs with artificially inflated numbers to make yourself look good when you come in under budget. Better to have a solid baseline with a declared contingency for risk.
And once the budget has been set and agreed, monitor the spend, report on it, and if necessary, make a case for changes, allowing plenty time to get through whatever governance processes are in place.
Finally, keep a small reserve to pay for a party when the project delivers!
Get your budget formally approved and signed-off, and define the budget change management process (know where to go and how when you need additional budget).
Make sure your budget includes money/time for project startup (esp. if your programmers haven't worked together before and your company doesn't have standard dev. environment, coding conventions etc) and for meetings. (You may have a lot of them with the customer even if your team doesn't have long meetings.)
Understand the difference between 'estimate' and 'budget'.
An estimate is cost of what you think it will take to provide the project the the client. this includes direct costs, indirect costs, profit, etc.
A budget is what you work toward internally, and is a more defined cost plan than the estimate.