Take the Guesswork Out of Project Budgeting in 5 Steps

Page content

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.

Step 5: Match Corporate Resources to Specific Tasks

Finally, you should match skills, locations, and labor rates to your company’s Program Portfolio Management (PPM) solution. Skills and effort information should be shared with the PPM system for specific resource assignments, ROI business case analysis, and portfolio analysis. Doing so will give those holding the purse strings the ability to easily see how project decisions impact skills, effort, and, ultimately, the projects themselves. Typically, this information would need to be input manually, but there are now tools available that help automate the process, taking one more weight off of your shoulders.

The five steps outlined here take time and effort to complete, but you should ultimately see a great return on investment. When you’ve implemented this type of standard estimation, you’ll discover that your IT projects will start to routinely come in close to budget – and you’ll be able to put the days of wild guesses behind you.

About Douglas T. Putnam, Co-Chief Executive Officer

As a Managing Partner for QSM, Doug has 33 years of experience in the software measurement field and is considered a pioneer in the development of this industry. Doug has been instrumental in directing the development of the SLIM Suite of software estimation and measurement tools, and he has trained more than 1,000 software professionals in the use of the SLIM Suite. Doug’s responsibilities at QSM include managing the delivery of QSM software measurement services, defining requirements for the SLIM Product Suite, and overseeing the research activities derived from the QSM project history repository. Connect with Doug on LinkedIn.