Project Cost Management is, to far too many managers, a misunderstood and mysterious process. However, it is a major component of successful projects and one of the major triads of project management - the other two being scope and time management. What are the major parts of a good project budget and how does one go about creating (and later, adhering to) a project budget? My post here deals with technology related projects, but the principles can be applied to other kinds of projects as well.
First, as you probably guessed, is to understand not only what the project's goals are, but also the context - the company environment. If costs are allocated and charged a certain way, then it is important to follow that process. For example, if the corporate policy is to charge back software licenses to individual projects (or to pro-rate them) versus an enterprise license that allows unlimited installations/implementations, then that should be taken into account.
Secondly, what is the project's scope - for example, in a hosting (infrastructure) area that I worked in, any project entailed hardware, software and service costs - hardware was the servers and network costs charged to the businesses that used them (or were responsible for them) and software costs included development, testing and licenses for other software used to make the applications work (middleware, for example, and special security software as well). Services included monitoring software that was maintained and monitored by other vendors and groups, for which we paid a fee.
Another point is to distinguish between one-time and recurring fees. For example, procuring hardware (servers, Hardware Security Modules - HSMs, network gear etc) were usually a one-time fee. However, maintenance costs, licensing and service fees to keep that hardware running - these were recurring costs.
Then the software portion of the project budget was created - after discussions with solutions architects, development team leads and software architects, I arrived at an estimate of how long the software solution ("application", "program", "code" etc) would take, and the average hourly cost per resource (this is normally used corporation wide - if not, you can easily get estimates from various sources). For example, our hourly resource estimate was $125 (this is not what people get paid, but rather, an average of the cost per resource per hour that included major supporting components). Multiplied by the number of hours for the component, you get a software total, which is then added to any procured components.
Other components include services - Monitoring, moving, testing, assembly, security (physical/virtual) or anything else that is of a service related nature that won't be included in hardware or software.
My budget for the project, which were presented to the project sponsor (business managers) provided a total budget, which was then broken down by one-time and recurring costs, which were spread over hardware, software and services.
Once the budget was presented, the review began. Frequently as more details were presented, the budget was changed - we went from an initial ("Level 3") budget to a more detailed version ("Level 2") and finally to a lock down version ("Level 0") as the project was formally approved and implementation began.
What about variables? This usually present the greatest hurdles to successful project cost management, and entire books and journals are filled with details on how to deal with them. Basically, there is no one answer - the idea is to drill down as much as possible and get details on what and how some process gets done. Then a reserve - a rainy day fund, if you will - is added. Some project managers get too tempted here, to add a very large reserve so that they have enough of a buffer - but the project then starts to look absurdly expensive, and can quickly be rejected if the project sponsors start asking questions ("how come XYZ team implemented a similar project for 30% less?").
Risk Management is connected to cost management - a good grasp of a project's risks means a realistic and potentially successful project. However, from sudden increases in hardware costs to unforeseen failure in software processes, technology projects are littered with cost overruns. This is especially true for new and untried processes. Many development methodologies exist to lower these risks; however, they must adhere to, and align with, the corporate standards as applicable.
If after laboring through the above processes, you arrive at a budget, only to have the project sponsors declare it is too high, then there are ways to lower them - keep the alternatives handy and well researched before these budget meetings. For example, if new hardware for a project is too expensive, find out if existing hardware can be shared - for example, servers can use virtualization technology to host many applications. Network gear can be shared in certain situations as well. For applications that are not mission critical, backup hardware can be shared as well. Furthermore, backup resources in a different data center can be used to do load-balancing (what that means is that instead of sitting idle waiting to be activated in case of a disaster, they can service some of the "live" or active traffic for web applications through load balancers etc).
Software processes can be outsourced - if it isn't already. If it is, and you still find it high, ask for a waiver from the approved vendors for your firm, so you can ask for competitive bids outside of the normal vendor pool for your firm. If that is not possible or feasible, do a detailed analysis (with the software team leads and architects) at the work breakdown structure for the software - which processes are taking the most resources? can some of them be pared down? can any process be "lifted" (copied or re-used) from any other recent project? For example, many applications use the same reporting engine - are there similar reports for other applications out there, that, with a little tweaking, be used in your project? or can a user-defined reporting system be installed where the end user can drag and drop fields and create customized reports so that a fully pre-defined reporting menu is not necessary?
Services too must be looked at carefully for hidden savings. Sometimes you may find other departments in your firm using the same service - in which case you can ask the vendor for a discount, or if the other areas have unused licenses or user credits, ask if you can use them. The same goes for monitoring solutions, security systems, control and risk management and on and on.
Many of the budget processes outlined here follow the same theme: Get an idea of the costs involved in building your project and then drill down to each piece and identify and price them. Leave a buffer for unexpected items, with the caveat to resist the temptation to make the buffer too large. And once the project is over, go over the budget versus actuals and identify the lessons learnt, and then you will be on to your next project, a bit wiser.
