Rolling Up Physical Percent Complete

A couple of weeks ago, I kicked off a bit of an exercise in personal improvement by revisiting my own understanding of how Microsoft Project calculates Actual Cost and Earned Value measurements.  This post represents a continuation of that effort, as I explore how Physical % Complete rolls up from child to summary tasks.  I’ll admit up front, until I began writing this post, I didn’t realize that Physical % Complete actually rolls up natively within Microsoft Project.

Physical % Complete

First off, let’s take a step back and talk about just what exactly Physical % Complete is.

Physical % Complete is a measure of how “done” a task actually is.  Generally speaking, it’s the most appropriate measure of how done the task is – especially when compared to other typical measures like % Complete or % Work Complete – which track how much duration and work we’ve consumed respectively.

Physical % Complete is intended as a physical measure.  For instance, when building a 10 mile pipeline, after building 5 miles, I would call the task “50% complete” in Physical & Complete.  In software, I would identify rules of credit to define when I am allowed to change Physical % Complete.  For instance, an architectural review may net me 25%, architect approval 50%, customer sign off 100%.  The goal is to make sure everyone understands when and how the credit is applied.

% Complete only tracks how much time I spent to get to that level of doneness.  If I spent 70% of my planned duration building that pipeline, I would be 70% complete within the % Complete field.

Generally, when using these fields, we want to employ the concept of triangulation, i.e. each one of those variables is not important on its own – but powerful in combination.  In the above example, the two points of data for that pipeline project would imply I burned 70% of my duration to complete 50% of my work.

The Mechanics of Rolling Up Physical % Complete

The first thing I might point out is that I was always under the impression that it didn’t and that each child task was independent in how the value was calculated.

In this project, in fact, it doesn’t roll up.

image

A funny thing happens though when we add the Earned Value Calculation Method field into the mix and toggle it to Physical % Complete on baselined tasks.

image

Physical % Complete does roll up….but only when all tasks have been flagged to use the Physical % Complete method – and have also been baselined.

Here’s what happens if we leave one task flagged to use % Complete:

image

None of the relevant subtasks roll up to a common parent task any more. 

The next step is to figure out just what calculations are occurring.  As far as I can tell, we have a simplified form of Earned Value working here.  Going back to the original example:

image

…we can replicate the calculations by multiplying the Physical % Complete X the baselined cost of the task.

  Baseline Cost Physical % Complete Earned Value Calculation
Project Summary Task $13,200 6%   $750/$13,200
Summary1 $2,000 38%   $750/$2000
Task 1 $1,000 50% $500  
Task 2 $1,000 25% $250  

Great.  So now we figured this out.  What do we do with it?  Honestly, I am not entirely sure.  But at least it’s out there, and I can refer to it as I come back to coach my client through the various EVMS calculations.

There’re also a couple other salient points as I see it:

  • Physical % Complete may not be edited in summary tasks.  If we wish to manipulate Physical % Complete on summary tasks, we would need to ensure that all subtasks have cost assigned and are kept updated.
  • In environments where we do not plan on tracking cost at the lowest level, we are effectively required to use % Complete as an Earned Value calculation method.

Both good things to note….

Rolling Up Physical Percent Complete