In that last post, I talked about what cost abstraction is and claimed that it’s been going on in project management since times immemorial. In this post, I’d like to take a look at why we practice cost abstraction, and what happens when we try to skip it.
First off, why do we practice abstraction in budgeting? As I see it, there are three main reasons to do so (and no, if you’re reading this soon after I posted it, that’s not a set up for a Rick Perry joke…although yes, it could be with very little effort.)
- Abstraction and top down cost decomposition establishes the granularity of control over the portfolio with which the organization will assert itself. The project manager generally has the authority to manage the project and to maintain acceptable variances within the specific limits set by the overall budget as perhaps enshrined within each of the cost codes. Exceed those limits, and the organization must implement a Management of Change process as set out in the cost management plan.
- Abstraction sets up a crude form of stochastic modeling. In this day and age, where many organizations have not matured to the level of performing true stochastic modeling to identify target cost ranges, the budget provides an upper limit on how much may be spent in a specific category – while still allowing the project manager the ability to manage controlled fluctuations in project cost. In essence, this allows us to manage financial change at the appropriate level.
- Abstraction allows for complexity. Where the overall organization may manage at the reduced complexity defined within a budget, the project manager may develop a much more complex cost model more appropriate to the needs of the project manager and the project controls team. It is this more complex cost model that allows the team to develop and deliver against an effective Performance Management Baseline (PMB).
So that’s the “why.” What happens if we ignore abstraction and attempt to implement our projects using only a top down budget?
Mechanically, things get difficult.
First off, managing the schedule gets problematic when we conflate the concept of “budget” and “estimate.”
- If we don’t allow the project manager to decompose each budgeted cost code any further in the schedule, then we are stuck managing performance at the level of the cost code. Each of those cost codes would then have to be integrated with the schedule. If the cost code is not so granular, then the lowest level intersection of the schedule and the cost code may be at too high of a level to support adequate performance monitoring. Variance may have to be tracked at the phase level of the project but not at the task level.
- The question of when a task gets closed out becomes muddied. Consider the following scenario, a specific cost code is budgeted at $20,000. Upon completion, we find that we spent $15,000 on the activity. In Microsoft Project, the solution to this is quite easy, we set the task at 100% complete and then set Actual Cost to $15,000. That will change our Cost field to $15,000. Now what do we do with the remaining $5,000 in the budget? Leave it for potential future risks that may dip into the same bucket? Close it out and roll it back into the overall project contingency? If we’re using our estimates to track budget, where do I track that $5,000?
Now I know what you’re thinking. We could have just saved a baseline in all of that and used the baseline to represent the budget….which leads us to my next point….
- A budget makes a poor excuse as the base for a performance management baseline. In the above example, I may have budgeted $20,000 and spent $15,000, but perhaps I estimated $14,000 – assuming that the $20,000 harbored sufficient contingency to cover any potential issues. If I take my budget as my performance management baseline, I would see my task as having a significant cost surplus. Hooray for me, it looks like the entire project will come in under budget. If I look at the estimate of $14,000 as my baseline, then I see that I actually came in marginally over expectations.
Given the granularity to which the budget is typically decomposed, that may not allow me as a project manager to identify enough control points within my project schedule to identify variances. The aggregation and the potential inclusion of contingency within the PMB negate my ability to effectively manage the project costs.
It’s that layer of abstraction between the top down and the bottom up that makes the entire system work.