How to Cheat at IT Project Management

9.5. Creating the Project Budget

With your WBS in hand, you can also develop a fairly detailed budget. The ideal situation is that the task owner will develop the task cost. For instance, a painter knows how long it will take to paint a room and he or she is also probably the best person to tell you how many gallons of paint it will take. The painter might also be well acquainted with the cost of paint and can give you a cost estimate that is fairly accurate.

There are some instances when someone in Finance or Accounting develops your project budget based on the data given. In those cases, you might be working with purchasers to purchase IT equipment or others outside your immediate IT project team. Some companies have Finance create the budget based on past experience and with limited input from the IT department. Clearly, there are pros and cons to each of these methods.

Also keep in mind there may be hidden expenses such as indirect costs or overhead that will be added to your project costs. Work with your Accounting department to determine what these additional costs might be and how you should account for them in your project budget.

It's a good idea to document assumptions you're making about costs for your project. If you assume that particular resources will be available or that a particular price range will be available for large purchases, you should note those assumptions. When the project sponsor reviews your budget, he or she can review the assumptions and clarify or challenge any assumptions that might be incorrect or unacceptable.

Ideally, you will create your own IT project budget based on the WBS. Once you have a list of all tasks to be completed, you can calculate the cost of each task. Some IT projects have to track time against the project as a fixed unit cost. For instance, software engineers may be billed to the project at one fixed rate and IT technicians at a different fixed rate. Other IT projects require specific cost data to be collected such as the wages and benefits cost of each individual software engineer as well as that of all other individuals working on the project. This is a much more detailed approach but yields a truer cost picture. In cases where the project is being billed or charged against some set resource (client, grant, investor funding, etc.), tracking costs with this level of precision may be very important. In other cases, labor is not even tracked as a cost because the company assumes it is paying wages and benefits as part of its overhead costs. So, in some projects, the only things that would count as costs are things that must be purchased such as servers, network cabling, test equipment, etc.

To create your IT project budget:

1. Create cost estimates for each work package (task) either by using calculations, historical data, or subject matter experts.

2. Roll up the cost of all tasks for the project. At the major task, deliverable, or phase point, add appropriate reserves.

3. Compare your calculated project budget with the project budget assigned or approved by the project sponsor.

4. Reconcile any budget differences through either increasing the budget or reducing the scope, increasing the time, or reducing the quality of the project (remember the four elements: scope = time x cost x quality? If the budget changes, something else also has to change).

To create your budget, go through each task in your WBS and add the cost of that task to your tally. Best practices suggest that you create a subtotal for each major deliverable and create a reserve amount at that level. For instance, you might decide that there's a low chance for budget overruns during the network design phase, so you give it a 5% reserve. However, you decide there's a high chance for budget overruns in the server testing phase (the phase where you purchase and test your servers), so you add a 20% reserve for that phase. During the installation phase, you are fairly confident that your costs are well known and you're comfortable with an additional 10% reserve for additional cabling or replacement parts. In your testing and monitoring phase, you may believe there is a low chance for budget overruns and you assign a 5% reserve to that phase. Thus, none of your estimates are padded and you've intelligently managed potential overruns by reviewing the likelihood of occurrence during each phase of the project. This is a cleaner, more effective way to manage your budget and it keeps everything aboveboard.

By going through your tasks and identifying budget items, you'll probably come up with a budget that is fairly accurate. However, sometimes in creating the tasks, task owners have omitted critical data such as the need for equipment or supplies. The reserve amount may account for that; you can also use the IT project budget checklist from the Syngress website to give you a running start.

9.5.1. Estimating Cash Flow

You may be asked to provide an estimate of cash flow during the project. Some companies require the IT project manager to provide this, others don't. Regardless, it's good to get in the habit of looking at cash flow since you may someday be called upon to develop a cash flow estimate. Companies often need this with large expenditures because they need to budget accordingly. If your project is short or fairly low-cost, this may not be needed. Figure 9.10 shows a sample cash flow diagram.

9.5.2. Implementing Cost Control

The degree to which you attempt to control costs is directly related to your flexibility matrix. Even if cost is the most flexible, you will still try to control your costs, but cost may increase to accommodate your least flexible parameters. For instance, if your schedule is least flexible then you may have to add people to critical tasks to stay on schedule. You may have budgeted for this because you were aware of the potential for this problem (we'll discuss risk management later), but this is one place where your costs can slip. If cost is more flexible than schedule, your reserves should reflect this (more reserve in cost than schedule) and you should make conscious, deliberate decisions to use your reserve to keep your schedule on track (rather than getting wrapped around the axle because your cost reserves are being used up).

That said, you'll need to work to contain and control your costs and that should start with a cost baseline. This is the total project cost broken down by phases, major deliverables, or tasks (as appropriate) with your clearly marked reserve amount or percentage. Next you should develop (if you haven't already) change control processes. Changes in the scope or nature of the project is the number one place costs creep (or stumble) into a project, so managing change is critical to managing costs.

As with scope management, you should have a clear process for managing changes to costs. A cost change control procedure need not be complicated or detailed, but it should require someone to note the original (baseline) cost, the new estimated cost, the reason for the change, and the people impacted by the change (if any). It should also have clear parameters for when a cost increase must be approved and by whom (cost reductions are both rare and welcomed, and they rarely need approval).

You can use the following list to help control your costs:

1. Control causes of change to ensure change is needed.

2. Control and document changes to cost baseline as they occur.

3. Control changes to the project and note their impact on project cost.

4. Monitor costs regularly and understand the impact of cost variances to the project.

5. Record cost changes in a timely manner to keep project cost data current.

6. Prevent unauthorized changes to the project or project cost baseline.

7. Communicate cost changes to appropriate stakeholders and get approval when needed.

The project budget should be developed and submitted for approval by the project sponsor along with the rest of the project plan. The budget is typically delineated in a spreadsheet and any notes or comments related to the budget can be included in the spreadsheet or as an additional document. It is typically a separate document (depicted in Figure 9.11) that is included with the project plan.