One of the first principles of project controls is that the project budget has to be time-phased over the duration of the project. Here’s why: It’s not enough to simply know the total budget for a project – it’s critical to also know when that budget is planned to be spent. In other words, each quantity of material, labor hour or subcontractor service that’s planned for the project, is planned to occur at a particular time on the project. Some of these budget items happen over a time-span – like a service – and some happen at a point-in-time – like the delivery of some material. Together, all of these budget elements result in a budget timeline. That timeline is typically represented by a curve that plays-out over the life of the project. See the chart to the right.
There is more than one way to time-phase a budget of course. Nevertheless, what project controllers most often do to put their budget on a timeline, is establish a healthy connection between the project budget and project schedule. In theory, this should be a fairly straightforward exercise since both budget and schedule have a work breakdown structure (WBS) in common. As you’ve probably guessed however, theory is just theory and in reality it’s not that simple. Schedulers have a very distinct view of a project’s WBS as compared to estimators or cost engineers. Schedulers view the project from the perspective of activities, duration, milestones, dependencies and critical path. Their version of a WBS includes things like milestone tasks, progressing tasks and events. Things that have no relationship to budget whatsoever. Estimators see the WBS predominantly in terms of a hierarchy of cost areas for allocating budget items. Their world is largely wrapped-up in cost codes and the Cost Breakdown Structure (CBS) – how the CBS maps to the WBS is someone else’s concern.
Who is that someone else? It’s Project Controls who plays that role of connecting all the pieces together so that the efforts of the various different disciplines are translated into a common project language. They do this by mapping the CBS cost code hierarchy to the WBS and schedule so that the budget will play out over a timeline. The coding becomes the lynch-pin that pulls everyone together. This includes the procurement group, since everything that’s procured also has to be coded to the correct location on the work breakdown structure. The challenge that’s put to the project controls group is: how do you do that mapping? How do you know what codes go where on the WBS? There’s no simple answer to that since every project and organization are unique.
Nevertheless, below is a quick process of how we usually recommend you go about it. Bear in mind, that for the purposes of this quick article, I’m not going to discuss the methodology around a good cost code structure. This process I’m describing is only to give you some ideas as to how to map your well-thought-through coding to the WBS.
- Identify areas on the WBS that describe physical activities. These are the tasks or workpackages that will be budgeted – and will have service contracts associated with them
- identify items on the WBS that can be progressed. This can be activities, purchases, things to be constructed or commissioned
- Identify items on the WBS that do not require budget – such as scheduling tasks – and isolate those as not requiring any CBS mapping.
- Once all the budgetary items on the WBS have been identified, you’ll need to work with the project estimator to connect the dots between each item they’ve estimated and what WBS activity it belongs to. For each budget item, a valid cost code will need to exist on that WBS activity/task. This is where the majority of the effort occurs.
- To do any of this, the WBS task or workpackage will have to have a specific cost code assigned to it. This means that the task is an element of the project CBS hierarchy