Capital Budget
Here at PACCAR we are about to enter the "capital budget planning process" for 2005. I'm wondering how other companies handle the concept of estimating how much a proposed project might cost given the rapidly changing IT world we live in. Here, it seems as though we make our best guess, double the cost estimate and tack on twice the hours expected to complete the project. Management then counters by approving the project with 25% of the requested budget and a larger scope. (with no option for negotiating, by the way...)
Is there a more practical way of planning for next year's projects?
Software/Hardware used:
Software/Hardware used:
ASKED:
May 18, 2004 10:49 AM
UPDATED:
May 21, 2004 9:44 AM
Answer Wiki:
I use past experience to estiamte future capital needs. It seems to work well enough to keep me in the ballpark. As some costs go down (hardware), others increase so it evens out. To build the list of what I want my organization to accomplish, I poll them for ideas and needs and then filter out the ones that I know will not make the cut based on the current business climate.
To see all answers submitted to the Answer Wiki: View Answer History.
Since project costs can vary from year to year I usually request quotes from the vendors for the projects that I plan to do and up adjust by 10% to allow for cost changes. It sounds like you would have to add 25% to get by.
Some elements that may help you:
- always have a justification for your figure(s): any challenge of these can either confirm the correctness of your estimate or help in adjusting them to a more correct (and hence defendable) figure.
- keep the distinction between a plan (budget, resources) and what is ‘sold’: the plan is the most realistic estimate of the project leader/manager, the ‘sold’ plan is what has been decided/agreed by the client (3rd party) / sponsor. (internal). If there is a difference between the two, the role of the project leader is to warn for the risks (budget, time, resources) and if the sponsor or client still wants to continue, the risk is for him/her. As such you can start a project as demanded by the client/sponsor but with your ‘true’ figures as a project baseline.
- There are tools and methods for project estimation (especially IT projects). You can find information on this all over the internet (e.g. start searching for ‘function point’ or ‘COCOMO’ and you have already a long list of places to look). Anyhow, most of these things thrive on metrics, so if you don’t have any historical data on similar projects (similar may mean same business, same techniques, or other), you won’t get far.
- Without metrics, you can always try a combination of experience and the Delphi method where specialists of different background but knowledgeable on the subject of the project are brought together and provide estimates on the project. When these estimates differ too much, the participant discuss the reasons for their estimate and then estimate again. Normally, the estimates will start to converge and one can repeat the process until the different estimates are lose enough.
- In the company I work for, we have build a spreadsheet with estimates per role and phase for the projects we usually run as well as the assumptions that are underlying to the (average) figures in the spreadsheet. The project leader is free to increase or decrease the suggested estimates based on the project specifics and is encouraged to document his justification for these changes in the assumptions section.
Best regards
Dries GEERAERT
We tend to treat projects like customer quotes – during the budget process we solicit project requests/service level requirements from the business we service, we estimate costs by getting supplier quotes and work estimates from the team leaders, then those business folk who want the project/improved service do the sums from a business perspective (the ROI-type stuff) to show business case. Executive Management evaluate and approve capital projects based on these business justifications, and, I guess, what burns them the most from a business execution perspective.