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.


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.


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:


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:


…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