The Epistemological Year in Review: Top Ten Posts of 2011

Since it’s that time of the year, here’s a quick list of the top ten blog posts (on this blog) from 2011.

A quick note about the methodology (or lack thereof)….top posts were determined to be so based on the number of hits they received over the year. This probably skews the results to the older posts, but let’s face it, I don’t have the energy to try to calculate a list based on average hits / day to account for this issue (although I could probably gin up a custom formula in Project to do so….maybe next year).

Also, by “2011” I really mean the last 9 months, as this blog was officially launched in mid-March.

So here they are, listed in alphabetical order…

  1. 10 Things SharePoint Admins Should Know About Project Server
  2. Capturing the Project Narrative with Project Server
  3. Centralizing Project Detail Page Information: Centralized Links Lists
  4. Creating a Portfolio Timeline Report in Visio (Part I)
  5. Making a Read Only PDP with InfoPath Forms
  6. Project Server Database Restore (Part I)
  7. Project Server Database Restore (Part II)
  8. Reporting with Gantt View Task Rollups (Part I)
  9. The Bulk Import Tool, Unwrapped (Part I)
  10. Using External Content Types with Project Server

As always thanks to the readers for reading, my clients for challenging me, my colleagues and fellow MVPs for providing me with answers, and my family for, well, pretty much everything.

Have a great new year and catch y’all in 2012.

The Epistemological Year in Review: Top Ten Posts of 2011

Defining an Update Methodology (Part V)

This post wraps up the discussion on developing update methodologies.  The first three posts addressed some of the basic principles of updating schedules as well as some of the specific mechanical elements within the Microsoft Project desktop client.

The last post reviewed how those principles and mechanisms could be applied to an IT scenario.  In this post, I’ll talk about how construction projects may get updated.  The goal is hopefully to provide suggestions that may be applicable to your own environment.

Again, there will always be nuances, but the general process will likely be as follows:

  1. Set the status date.
  2. Add the Actual Start or Actual Finish
  3. Set the Remaining Duration for in progress tasks.
  4. Progress all completed tasks to the status date.
  5. Reschedule unstarted tasks to the status date (or estimated start date)

Let’s walk through that scenario in a simple schedule.


In the simplest case, we first update the Actual Start or Actual Finish for the tasks that have actually started or finished.  I update the following:

  • Actual Finish for the Project Started milestone.
  • Actual Start for Task 1.
  • Actual Start for Task 4.


Then I set the Remaining Duration field for each of the tasks.  Generally, I would enter a Remaining Duration that pushes the new Finish date out to the estimated finish date that my resources are reporting to me.


If I am using Project Server, I might add a custom field for Estimated Finish to the My Tasks sheet, then roll the Estimated Finish field into the Remaining Duration field using a macro as part of the update process.

Then I select the option to Update the Project from the Project tab.  In this case, I select the started tasks first and set the options to progress the tasks as follows:


I could also use the Mark as Scheduled option in the Task tab to accomplish the same thing.


Note how % Complete automatically updates…


From there, it’s a simple step to reschedule any unstarted tasks to after the status date – again using the Update Project button.

Facilitating the Process

One method to facilitate this process is to add a custom field and grouping that would group tasks by whether or not they are in progress or unstarted.  A formula to establish that in a spare text field might look as follows:

IIf([% Complete]<100,IIf([Actual Start]<>ProjDateValue(‘NA’),”In Progress”,IIf([Start]<[Date1],”Unstarted”,””)),””)

…where Date1 is configured to equal the Status Date.


Group by it, and you would get the following view.


Review the process above, and the view makes things simpler.  If I apply the view after I’ve entered all of the Actual Start and Finish dates, then I can simply select the In Progress tasks to progress to the status date and the Unstarted tasks to reschedule after the status date.

Better yet, as discussed above, I could develop some form of VBA automation to refer to that field and update my project with a single key stroke.

Comparing Construction and IT

So now we’ve looked at two different scenarios, what is the fundamental difference? In both examples, we follow the two commandments of schedule updates, i.e. no incomplete work before the status date and no completed work after the status date.

However, we make different assumptions about why the task took longer than expected, i.e. whether the estimate was incorrect or whether the team was pulled off of the task.  In the example above, we assume that the team has been working continuously since the Actual Start date for the task.  In IT, we assume that the work was interrupted.  Are either examples always true in any industry?  No, what we’re attempting to do is to define a process that captures the bulk of the project updates, but there will always be tasks that don’t match this particular model.

Once we remove that assumption that the work was interrupted, % Complete becomes essentially useless for data input.  In that case, once the resource identifies the Actual Start and the Remaining Duration, the scheduler calculates % Complete for the resource.

Defining an Update Methodology (Part V)

Defining an Update Methodology (Part IV)

Continuing in an ongoing discussion on defining an update methodology….in this episode, I’d like to talk about a couple of scenarios specific to IT.  Tomorrow, I’ll talk about construction.  The general concept is to introduce two diametrically opposite update methodologies to hopefully identify patterns that may be useful to your onw specific circumstances.

IT Scenarios

Typically, I see IT update scenarios come in two, or maybe three flavors:

  1. Percent Complete
  2. Timephased Actuals (no Project Server)
  3. Timephased Actuals (with Project Server)

Regardless of the specifics, the general process invariably is as follows:

  1. Set the status date.
  2. Import/Enter/Add the Actual Work or % Complete.
  3. Reschedule incomplete work after the status date.

…although with time entered via Project Server, I might flip items #1 and #2.

So let’s take the simplest example for illustration purposes.  In this case, we have a couple of tasks that should be in progress or completed.  The status date has been set for a week after project start.


I then update several of the tasks:

  • Project Started is 100% complete.
  • Task 1 is 25% complete.
  • Task 4 is 100% complete.
  • Task 5 is 50% complete.


As we can see, since I had the Project settings configured properly, the entire schedule updates automatically.  In all, I entered exactly 4 points of data.

Let’s fast forward another week.  The status date has been pushed out another week.  Let’s say at this point that Task 1 was completed, but Task 5 made no progress as the team was pulled off the project temporarily to perform break-fix work.  Similarly, Task 2 hasn’t been started.

I update Task 1.


I then use the Update Project button on the Project ribbon to reschedule incomplete tasks.


…which yields the following result…


…and means my schedule no longer violates the two commandments of project updates, i.e. there is no incomplete work prior to the status date, and there is no completed work after the status date.

Note however that the tasks appear to have been interrupted – which in fact was the case as the teams were pulled off the tasks and put on other work.

Adding Complexity

Now, how do we add complexity to this model?  Let’s say that we want to track Actual Start as well as % Complete.  In this case, we add the Actual Start field to the project, enter that data, then pretty much continue as discussed above with % Complete.


Easy enough.  Now how about Remaining Duration?  In this case, I might implement the following process:

  1. Set the status date.
  2. Import/Enter/Add the Actual Work or % Complete.
  3. Reschedule incomplete work after the status date.
  4. Update Remaining Duration.

Dealing with Interruptions

To focus on a specific scenario, what about if the team was pulled off of a task, and you’re not sure when they will be able to return to the task?  If we follow the process above, the task will resume again right after the status date.  That may or may not be the case.  Perhaps we might assume that Task 5 will resume a week later.

In that case, we would add the Resume field to the project, and update that to control when we believe the team will return to the scheduled task.


…and that’s essentially an oversimplified view of updating projects in an IT setting.  If you actually imported timesheets from Project Server (or manually entered them in the Resource Usage View), you wouldn’t really change up the process all that much.  In that case, simply import the data, reschedule incomplete work after the status date, then review the Remaining Duration and Resume fields to ensure that the project data appears correct.

Now, of course there are nuances and complexities that will be specific to your own scenario, but hopefully that captured the essential basics of updating an IT project.

Tomorrow, let’s look at the same principles applied to construction projects.

Defining an Update Methodology (Part IV)

Defining an Update Methodology (Part III)

This is the third post in a short series on determining an appropriate enterprise-wide project update methodology….or actually, just determining an appropriate project update methodology – as what I am writing about could be implemented on a single project just as well as across a large number of projects.

In the previous posts, I talked about reviewing some of the organizational factors that might influence how the update process is structured.  I then went into the Microsoft Project client to review some of the settings that control how updates are applied.

In this post, I’d like to continue looking at the mechanics that govern how updates get entered in the system.

On Setting the Status Date…

First off, the status date is a critical bit of the update methodology.  I am constantly amazed by end users who attempt to update their schedules without using the status date.  Personally, I don’t really understand how such a thing is possible.

Put simply, the status date is the last date upon which the the data input into the schedule model was complete.  If we update the schedule every Friday, and today is Wednesday, then the last status date would be the previous Friday.

The issue with the status date is that when it is used in a Project schedule that doesn’t display the time, simply entering a date will default the status date to 8AM of that date.  So if I enter Friday as 12/16/2011, then the system will assign a default of 12/16/2011 8:00AM, which in a traditional corporate calendar translates essentially into 12/15/2011 5:00 PM.  Depending on the specific update methodology, this may get confusing.

Take the following example….in a construction scenario, I am importing Actual Costs from an external application and applying them to the project, having them accrue as of the status date.  If I update my schedules monthly at the end of the month, and I set my status date for 12/31/2011, then the system will accrue all costs as of 12/30/2011 and not as of 12/31/2011.  In theory, no status will appear on that day.

For this reason, I’d recommend as best practice either specifying the status date as 5:00 PM on a specific date or simply set the status date for the day after the “real” status date.  In an IT project, where I update the schedule each Friday, I would simply set the status date to the Saturday following to make updates easier.  In a construction project where I update at month end, I would set the status date to the first of the month following.

Lastly, here’s a trick to get the status date to appear in your schedule…and a filter to show in progress tasks…

Identifying Tasks to Update

So now we’ve identified how to enter the status date properly, the next issue lies in identifying which tasks need to be updated.  In theory, depending on your schedule granularity, you probably will never have to update more than a couple of tasks each update cycle.  If you set up your schedule properly, with the appropriate dependencies, updating the in progress tasks each cycle will result in an up to date schedule model.

My recommendation is to simply develop a filter or a view that will identify any task that requires updating.  This process has been made a bit more complicated with the introduction of manual scheduling in Project 2010 which necessitated the conversion of the default Start field to a Text field.  In 2010, the way around this is to develop a filter on the Scheduled Start field.  (Click here for more on that…)

This is also complicated by the fact that the Status Date is not available as a task level field.  Hence, the first step is to make the status date available for use in a filter.  To  do this, we use a custom Date field, and set it equal to the Status Date.


Then we create a filter that looks something like this:


…and I think that’s that.  Now we have the stage set, let’s get back to some process discussion with my next post on the topic….

Defining an Update Methodology (Part III)

Defining an Update Methodology (Part II)

In that last post, I talked about some of the basic considerations in defining a schedule update methodology, and in ascertaining whether or not a process is fit for purpose.  In this post, I’d like to continue that discussion and then get a bit more tactical to look at how Microsoft Project may be configured to support your requirements.

First off, let’s look at the two commandments of scheduling….

The Two Commandments of Updating Schedules

…and I should mention that these are probably heavily inspired by some of the content found on fellow MVP Jim Aksel’s blog here.  There’s a lot of great content over there worth checking out.

After updating your schedule, you should always review it to confirm that the following commandments have been met:

  1. Thou shalt have no incomplete work prior to the status date.
  2. Thou shalt have no completed work after the status date.


Now the actual implementation of these two commandments may vary by organization, but as long as these conditions are met your schedule is probably pretty good – or at least better than the other PMs in your organization, which is really the quality standard we should all strive for.

Flipping the Right Switches

There’re a lot of checkboxes and radio boxes that control how data gets into the Project schedule, but I’ve almost always focused on the same basic ones.  The primary settings reside in the File > Options > Advanced tab.


Here, I would almost always recommend toggling the settings the way they’re displayed above.  I can’t recall if that is the default, but it really should be.  These settings affect tasks updated using the % Complete method.  For instance, if you configure your project as shown above, entering 25% on a behind schedule task will automatically push the remainder of the work after the status date…


Similarly, all completed work will be shoved to the left of the status date which makes logical sense.  You can’t exactly do work in the future can you?  Similarly, you can’t go into the past and do your work on schedule given that we’ve already missed that opportunity.

The secondary options in the above illustration, i.e. the options to move the start of remaining work and the end of completed parts forward to the status date are determined by how your organization wants to track work. 

For instance, the first unchecked option, “And move start of remaining parts back to status date” is basically governed by how optimistic your organization is.  If you’re an optimistic sort, you can check that.  Then, if any task progresses ahead of schedule, the finish date will move to the left.  In the real world, I rarely see this, as what typically happens if we’re ahead of schedule is that the team slows down….and even if the task finishes ahead of schedule, the successor team is probably not ready to start ahead of schedule….assuming of course that we don’t have dedicated resources.  If you do have dedicated resources, you might make different sets of assumptions around how you would like the update cycle to work.

Note that, as  I learned recently, all of those settings are negated if the Updating Task Status Updates Resource Status checkbox is unchecked.  I am not sure why the functional dependency is there, but if that box is unchecked, the schedule will not apply the options above.


I almost always define a default setting for these options and incorporate that into the installation package – something which can be done either with these instructions from Paul Mather, ensuring each template is configured with these settings, or if a macro is used to facilitate the update cycle, adding those settings to the macro to ensure they’re all set the way we need them to be.

Lastly, for good measure, the status date is correctly set in either of the two locations identified below.


The status date may also be set on the ribbon, but note in 2010, that this setting is a bit misleading.  There’s an issue where if the status date hasn’t been set, it appears to display today’s date.  That’s not really the case though, as in the above illustration, the status date is blank.

Next up…let’s talk more about setting the status date and on a couple other mechanical details before we get into specific scenarios.

Defining an Update Methodology (Part II)

Defining an Update Methodology (Part I)

Every organization has a different level of scheduling maturity, and it’s rare that this scheduling maturity is homogenous across the entire group of schedulers.  Some are invariably more advanced than others, which necessitates almost a sliding scale of process definition – a rigid, detailed definition for the more advanced schedulers, and a less defined process for the schedulers still learning the “dark arts” of project scheduling.

..or perhaps I have that flipped.  Maybe the more rigid processes should be for the less mature schedulers, and the less rigid process should be for the experienced ones.

Regardless of which side on that debate you take, I would say that inevitably in any exercise in EPM maturity bootstrapping, there will be a discussion about what the planned organizational update methodology will be.  That may be a broad discussion with the entire organization as an effort to define a standard or that may be a limited discussion with a specific group of schedulers who have proclaimed themselves ready for it after scheduling for some time.

Like many events in the EPM deployment lifecycle, it can be difficult to gauge when schedulers are ready for this discussion.  Try it too soon and you turn them off the engagement due to overly rigid processes.  Try it too late, and you end up with multiple, very specific views on how to update projects that need to be reconciled into a single consensus.  I personally prefer to wait until a couple people start asking me very specific questions around updating schedules.

…and sometimes, just sometimes, the update methodology is logically derived from stated organizational reporting requirements.  That always simplifies things.

So I figured I’d waste a couple of electrons and go ahead and post a recap of various update methodologies to give a range of options.  In this post and the next couple of posts, I’d like to address how to define an update methodology, and then throw out some examples from diametrically opposite fields, specifically IT and construction.  Hopefully, those examples may give you something to think about as you design your own update methodology.

For today’s post, I’ll focus on the basic principles of updating projects….

Focus On the Why and Then the How

The first question I always ask a scheduler when attempting to suss out an appropriate update methodology would be “What information do you really care about?”

Let’s face it, Microsoft Project, and any other desktop scheduling tool allows users to input a whole slew of data to update a project: Actual Start, Actual Finish, % Complete, Physical % Complete, % Work Complete, Actual Work, Actual Duration….not to mention timephased actual data imported from timesheets or LOB applications.

At the end of the day though, I would submit that there’s really only one point of data that is absolutely required at each status update cycle: “Are you done yet?”  That keeps things simple and binary.  Picture it, at your next status meeting, just ask every resource that one question about any ongoing tasks.

Of course, that question only works when your tasks are defined granularly enough.  Specifically, my recommendation is generally to cap your task durations at a maximum of one reporting period, whether that be a week or a month. When tasks begin to exceed a single reporting period, that one question of “Are you done yet?” begins to lose effectiveness.

But think of it, and not to quote fellow MVP Eric Uyttewaal too much, but there was a great section in his Forecast Scheduling book which talked about how project managers only care about the future.  Accountants care about the past.  Do I really care about all of the historical data in a project schedule?  Nine times out of ten, I would say, no, I don’t care about the actual duration.  All I want to know is if it’s done or not.  That gives me enough data to replan my remaining schedule.

That simplicity begins to break down when we start throwing effort and cost into the equation.  Once I begin tracking that, I do need to start collecting a whole lot more data points – although again, the data collected needs to be mapped to my specific needs.  Do I need to know when the work was performed?  Not really.  All I care about is how much of my budget has been consumed, so that I can define how much of my budget is left, and how much work there is remaining that needs to get performed within the constraints of that budget.

So even in a resource consumption scheduling model, I often don’t need a complex update system.  I just need whatever will tell me what’s left in the resource bucket, how much work is left, and how much time I have left to get that work done.

Let’s throw another layer of complexity onto our analysis.  What about if we’re performing these projects under the guidance of a PMO charged with “continual process improvement” or as I wrote a couple of weeks ago, managing outcome improvement?  Then again, we need to start tracking more data, as continual process improvement usually comes hand in hand with metrics on performance, and identification of methods of improving (i.e. shortening) the duration of similar tasks on similar projects.

So that’s the ‘why’…

…But Let’s Be Realistic…

The second question you should ask yourself when planning an update methodology is really “how much authority does the PM have to request/demand data from the resources?”

If you’re a lowly PM working in a research organization where you’re trying to collect task status from highly educated Ph.D’s, good luck collecting historical data, timephased actuals, or any of the other points of data that a PMO might desire.  Unless that practice is deeply embedded in the organizational culture, you’ll have a tough time getting the time of day from your resources.

Similarly, unless you have the organizational might backing you up, if you’re a construction scheduler working to support a construction PM, it may be tough for you to penetrate the complex network and relationships of contractors that are actually doing the work on your project – although there you’re assisted by the fact that you can always define your data requirements as contractual obligations.

Hence, you want to balance out how much data the organization is requiring with how much data you can actually get from your resources.  Ensure that you factor in the difference between the level of both your formal and your actual authority.

Oh Yeah, One More Thing

In writing this series of blog posts, I also realized that there’s probably one other key bit of environmental background that we need to consider when planning an update methodology.  Are the resources dedicated or not?  If the task is behind schedule, can we make the default assumption that it’s behind schedule because the resource was pulled into another endeavor (IT) or because the resources doing the work encountered a variable that slowed progress (Construction).  There’s never going to be a firm rule that applies to 100% of the cases, but you can generally identify a default behavior.

Next up…we continue to look at the basic concepts of updating a schedule and how those are configured in Microsoft Project.

Defining an Update Methodology (Part I)

Prepopulating EPT Custom Fields in Project Server 2010

I figured that I’ve been focusing on issues of process and strategy for a while, and it was probably time to get back into the mundane world of technical delivery for a post or two.  Variety, after all, is the spice of life (which leads me to suspect that this idiom probably doesn’t translate well into some languages and cultures that don’t really respect spice or culinary diversity, but that’s a digression for another topic.)

Back to the point of this posting though, this is a Project Server 2010 question that I’ve seen come up quite frequently both in client discussions and on the newsgroups: “How do I prepopulate specific fields within an Enterprise Project Type?”

The answer is that it’s actually quite simple to do so.  Essentially, all we have to do is to populate the fields in a Microsoft Project Professional template and save the template to Project Server.  Associate the template to your EPT, and voila, when you create the project, the custom fields are already populated…..sort of.

Kicking it off….step 1: open a MPP file and populate the fields.  Even if you’re not ready to include tasks in a standardized template, that doesn’t matter.  You can still create a template with no tasks.


Save the project file as a template.


Now, go into PWA and associate the template with an Enterprise Project Type.


….and that’s pretty much it…with one relatively minor caveat:  the fields will appear blank within the PDP until the project record is saved for the first time.

For this reason, I’d recommend keeping only the basic minimum required fields on the first PDP created with the project, and then add any prepopulated custom fields to a subsequent PDP.  Honestly, that’s probably a best practice anyway.  When you save the project after completing the first PDP, the fields will be populated by the time you navigate to the second PDP.

If you add the prepopulated custom fields to the first PDP, they will appear blank until the project is saved – which needless to say is confusing to the end user and would probably result in them just filling out the field anyway, thereby defeating the purpose of the exercise.

Prepopulating EPT Custom Fields in Project Server 2010

From Strategic Outcome Management to Management of Outcomes

Another post in my process of digesting the outcomes of the recent PMO Symposium held in early November in Orlando…  As a result of attending this conference, I’ve been spending some time of late thinking about the nature of “strategy” and how PMOs and EPM tool sets fit into that.

My first thought of course, was to dig up an old book that’s been sitting on my shelf, an oldie but a goodie that I’ve tried to work through in the past, but never successfully.  This time, it was a lot more relevant – and a bit easier to work through.  If you’re looking to skim a rock over the surface of strategic thinking, there are probably worse places to start than Strategy Safari by Mintzberg, Lampel, and Ahlstrand.

Of course, I am still somewhat confused as to what the term “strategy” actually means, but my general conclusion after reading that book is “it depends,” which needless to say, is an answer that has always resonated with me.  Essentially, strategy boils down to a vision of the future along with the associated steps that are identified to achieve this future.  Now what that particular vision consists of or how it is defined?  That is another question…and a topic for another couple of blog posts.

(An old mentor of mine, might claim then that the strategy is the crystallization of our values, which when applied to the present world, allow us to identify a desired future state – but I digress.)

The book posits a number of different schools of strategic though, ranging from the centrally directed Planning School to the more emergent practices of the Learning School – both approaches to strategic thinking that I have seen in the client organizations I have worked within. 

An EPM tool could potentially support each (or at least some) of those schools in different ways.  For instance in the Planning School, we could take a top down capital budgeting approach to portfolio management, while in the Learning School, we could leverage a tool to identify constraints and therefore identify where the organization is actually heading.

Regardless of which school we subscribe to, let’s say, hypothetically, that we can define this desired future.  Not only can we define this desired future, but as an organization we can come to some sort of consensus as to what this future looks like.  Once we’ve done that, it’s but a short step to defining a set of characteristics that define initiatives that will get us one step closer to that desired future.

Those characteristics might look something like this…


And maybe, just maybe, we can come to a common agreement as to the relative ranking of those priorities.  That ranking may look like this….


Now here I should throw out a caveat that there is no software package that will manage your project portfolio.  There are however software packages that help you identify your priorities and assist you in calculating what the optimum portfolio may be in specific circumstances.  This is an example of that.

So once we have our desired outcomes defined, and our projects mapped to those desired outcomes, how do we assess how well we achieve those outcomes?  To quote this post I wrote before, how do we move from ensuring that we’re building the right thing to ensuring that we’re building the thing right?

Enter benefits realization, one of the (many) missing links in project management, and probably one of the leading justifications for the implementation of a PMO – insofar as project managers have traditionally been unsuited to the challenge of returning to a project 6 months to a year after completion to assess whether or not the project achieved the predicted ROI.

We can estimate our benefits over time as part of the business case…


….and then come back later and assess how well we met our targets:


So here what we’ve done is move down several layers of the V Model I wrote about in this post.  We’ve moved from the level of tracking project alignment to desired strategic outcomes to the level of managing our project outcome.

From Strategic Outcome Management to Management of Outcomes

Two More Reasons to be In Phoenix in March

PC2012_Sig_160x98_SpeakerWell, I’m both excited and honored to be delivering two presentations at the upcoming 2012 Project Conference…

  • Unleashing the Value of Earned Value: Applying Schedule and Cost Controls to Measure Project Performance
  • Turning Project Data into Real World Reports: An Overview of Business Intelligence Options

If anyone has any suggestions for content they’d really like to see in either of these presentations, please go ahead and start throwing requests into the comments section for this post.  I’ll see what I can do.

Oh yeah, one more thing… Game on, Alex….  Smile

Two More Reasons to be In Phoenix in March

The Importance of Cost Abstraction (Part II)


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.)

  1. 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.
  2. 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.
  3. 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.

The Importance of Cost Abstraction (Part II)