Today, most organizations approach budgeting in an overly simplistic manner: a manager makes a call for project estimates and receives responses based on expert opinions, task-based spreadsheets, anticipated budget restrictions, available resources, and – let’s face it – wild guesses. Most often, the estimates are nothing more than a collection of hours, with no differentiation by job role or schedule. This inefficient process can result in 40 percent of projects missing their marks, simply because they weren’t budgeted accurately.
Let’s take the guesswork out of the equation. Follow a few simple steps to ensure that your projects remain on point – and on budget.
Step 1: Collect Data
First, collect existing project estimates or create new estimates containing the following information:
- Project start and end dates
- Effort and cost required to design, develop and test applications
- Size or functionality of the system being developed. This can be measured in requirements, epics, stories, use cases, function points, configurations and RICE (Reports, Interfaces, Conversions, Enhancements) objects, source lines of code, and so forth.
If your organization has a standard estimation process in place, collecting this data may be fairly straightforward. Without a standard estimation process, collecting data requires a treasure hunt through spreadsheets and artifacts. Ideally, data should be stored in a spreadsheet or other format that is both easy to access and share. Once collected data is deemed complete, you can document your data collection and interpretation process so that it can be replicated in the future. Voila! You’ve created a standard collection process for your organization.
Step 2: Assess Project Feasibility
Many IT projects fail because of unrealistic schedule expectations, but performing a basic feasibility study on projects as they are budgeted can sidestep this problem. The goal is not to establish a perfect estimate; there’s really no such thing (although many project managers and stakeholders would love such an occurrence). Rather, the goal in a feasibility study is to identify project estimates that are grossly unrealistic or overly conservative before those estimates are locked into place.
Project feasibility is assessed by once again examining data. This time, you should:
- Create historical trend lines for schedule, effort, and staffing versus the size of functionality produced. These trend lines illustrate average expected capability, as well as typical variability.
- Plot initial budget requests against the trend lines. These plot points should indicate if projects are outside of the norm and variation, meaning they are too risky or not valuable enough to take on.
By plotting projects against trend lines, you should be able to visually ascertain which project budgets are too risky or conservative, and which are feasible – and then make necessary adjustments in Step 3.
Step 3: Build the "As Planned" Budget
Building an “as planned" budget involves generating a staff, skill, and cash flow plan for each of the projects included in your organization’s budget submission process. The goal is to develop a comprehensive view of the number of people involved in each project and the number of hours needed to fill each role and skill category at various points. By doing this, you’ll be able to synchronize peak demand points with labor capacity and ensure that each project will have the necessary support at the appropriate times.
You may need different templates to accommodate differences in methodology or project types. For example, a project that involves agile development will require different skill categories and labor rates than a project that is focused on building out infrastructure. Regardless, you’ll need to identify skill categories and attribute costs to each.
Simultaneously, you will want to ascertain how and when resources can be rolled on and off projects over time. Combining this with the labor cost analysis will result in a complete picture that details the demand for various projects and resource types, a monthly spending profile by skill, and cumulative costs associated with various projects.
Thus, an “as planned" budget is born. Now it’s time to refine.
Step 4: Refine the Budget
An "as planned" project budget is one part of a whole; it can't exceed constraints imposed by your organization’s overall budgets on peak monthly spending rate, staff capacity, or other categories. Therefore, refining the budget requires looking at where it fits in the larger plan. After examining the larger context and studying the projections for risk factors not previously identified, you may discover that your budgets still need to be refined. To accomplish this, you may want to consider delaying project start dates or reducing the number of full-time staff on a project that has not fully ramped up yet.