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

Task Type Use Cases in an IT Environment

In training sessions, my students traditionally have a tough time grasping the concept of task types and how they may be applied in the real world.   I often get the question of “Which task type would you recommend for ‘XYZ’?”  To which the response is almost always, “It depends.”  In this post, I figured I’d spend a little time talking about my own personal practices, and see if that sheds some light on task type usage patterns.

Task Types

First off, what are the available task types?

  • Fixed Duration
  • Fixed Work
  • Fixed Units

These task types play the part of variables in the Duration X Units = Work equation that Microsoft Project uses as the basis for a fair number of scheduling calculations.  (Note that the Duration X Units = Work equation should probably be more accurately depicted as Duration X Units (X Person Hours Per Day) = Work.)

The general way to identify which task type you would like to use is to ask yourself the question, “Which of those three variables, Duration, Units, or Work, do I know at this point?  Which variable will not change?”  That is the variable that should be fixed.

Planning the Project

Great in theory, but how does that work in practice?  Let’s take an IT project as an example.  As a consultant, I am often called upon to decompose the project scope and to identify the tasks required to complete the scope.  Since work frequently on similar projects, i.e. Project Server deployments, I might start with a schedule template that already lists the tasks and dependencies.

So my first goal is to work through that schedule list and attach work estimates.  At this point, I am not attaching duration or calculating a real schedule.  All I am doing is working through the list, and adding an estimate of work to each task….80 hours here, 20 hours there, 4 hours there.  Now here’s the trick.  Unless I uncover something new during the planning/estimating process, those hours will not change.  They probably will change when I get into the actual execution of the project, but we haven’t gotten there yet.  Hence, I will set those tasks to Fixed Work.  I don’t want those estimates to change.

Once I’ve gone through a first cut of the schedule and attached hours to the tasks – and set the tasks to Fixed Work, then I’ll go through and play with either the units of allocation of a resource or more likely the duration of a task.  I run through the project and start assessing duration for each of the activities.  Since work is fixed, and I am editing duration, the units field will recalculate – which is what I want.  My duration estimates are usually based on client availability estimates, i.e. I will assume that requirements gathering may take longer or shorter depending on the number of people involved in defining requirements or the complexity of the project.

Again though, unless I uncover something new during this process, the work estimates do not change.

Tracking the Project

Once I’ve reviewed my estimates, added calendars and constraints, then smoothed the overallocations, I tend to flip all of my tasks from Fixed Work to Fixed Units.  “Why?” you ask.  Well, when you get into execution, that’s when I am pretty sure that my work estimates will change routinely.  Similarly, I am pretty sure that my units will stay pretty stable – or at least they will do so for future estimates.  Past estimates will be overridden by the actual hours entered in the system.

So every week, I fill in my timesheet, and my actual hours get transferred back to my plan.  If I book more hours than I expected, units are fixed, and the duration comes in.  If as happens more often, I book less hours than expected, units are still fixed, and the duration gets pushed out.  If, based on partial completion, I change my work estimate, again units are fixed, and the duration is recalculated.

Hence, generally, in an IT environment that tracks hours, I would recommend using Fixed Units task.

So there you have it…..a long winded explanation of why “It depends” is a valid answer.  My recommendation for this specific scenario would be Fixed Work during the estimating and Fixed Units during the execution of the project.

Task Type Use Cases in an IT Environment