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