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

6 thoughts on “Rolling Up Physical Percent Complete

  1. Andrew, this is a great post! I work with clients all the time who use MSP and Cobra and this is always a gripe. Not that you can’t calculate EV in Cobra, but the lack of a visual in MSP of progress made always illicits a groan. Thank you and great job.

  2. Yeah, good job. I tell clients not to worry about it… because it is like a solution looking for a problem… Furthermore, SPI and CPI calculate as they should on summary rows, so it does no matter wha the physical % on summary rows computes to.

  3. Thanks for this great post Andrew. I just want to add another thing about this feature … something disappointing actually about 2010 version.
    In earlier versions (both 2003 and 2007) the ability to calculate P%C with different baseline cost values works fine. However in 2010, if you change Baseline for EV Calculation (File>Options>Advanced>EV Options for this project), it doesn’t perform calculations properly with selected Baseline(X) Costs (still it does with Baseline Cost only!).

  4. Arun Nair says:

    What do i do if i there’s a summary task such as concreting which has three subtasks.
    1.pouring concrete 1 day duration weightage 50 per cent.
    2. Allowing for cure 7 day duration. Weightage 25 per cent
    3 Removing the formwork 2 days . Weightage 25 per cent

    Physically my major task is concreting and by the end of 1st day i want to show that 50 per cent of task is completed.
    How can i overcome this issue in Msp.

  5. You would need to make the cost for the tasks commensurate with weighting, i.e. task 1 = $5000, 2 = $2500 and 3 = $2500. That would then roll up as needed per the calculations in this post.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s