The Importance of Cost Abstraction (Part I)


Since time immemorial, projects have been estimated with a combination of top down and bottom up practices.  That’s just how things are and have always been.  And when people try to circumvent those processes, bad things are likely to occur.

Specifically, what am I yammering about here?  Well let’s take a look at the project budgeting cycle.  Essentially, the way it typically works in a portfolio driven organization is that a budget for the project is developed as part of the approval cycle.  That budget may be decomposed into a level of granularity that is appropriate to the organization – generally driven by the level of expertise available or the level of volatility in project scope.  (And voila!  The organization has an illusion of control.)

Generally speaking though, that budget is tied to concepts, i.e. specific materials, labor types, or cost allocation codes that will be required to complete the project, but not yet tied to specific tasks with dates and calendars and such.  In other words, we have a flat estimate of the project costs with costs broken down into a specific granularity, but we have not yet tied that estimate to a timephased spending plan.

Now that we have a budget with specific funds allocated to each of the specific elements, we hand the project over to our scheduler.  The scheduler will develop the tasks of the schedule from the ground up, allocating specific cost elements such as construction contracts, specific components, or resources to the tasks.

Those tasks then roll up to a higher level, the level at which they may be mapped to the budget, i.e. a layer of abstraction that marries the top down budget to the bottom up estimate.

That layer of abstraction may occur in the Project client with Budget resources….


…or at the server level with a product such as our Project Essentials which allows you to define budget templates and then to map the bottom up estimates from the project plan to the predefined organizational template.


Great.  So that’s how things should work based on commonly accepted project management practices.  As I alluded to above, what happens if that mapping doesn’t happen as part of the project planning process?  

That will be the topic of my next post….

The Importance of Cost Abstraction (Part I)

One thought on “The Importance of Cost Abstraction (Part I)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s