A colleague posed a problem recently. He recorded earned value after tracking work done in the first status period of his project. When recording work done in the second status period, he returned to the first only to find the earned value had changed. What could have caused this?
One possible reason is neglecting to reschedule work that should have been completed prior to the status date. Remaining work must be rescheduled to start after the status date. If we don’t reschedule incomplete work, then actual work will be posted as if it occurred in the past, before the prior status date. This will alter the earned value of the prior period.
Here is a simple example. Consider one task that is six days long, with one resource assigned at $100/hr. The current date is April 19th, which is prior to the April 20th project start date. The schedule is baselined.
The status date at the end of the first week is April 24th. The task started late and only three days of work were completed. There is no cost variance. As much was earned as was paid (assuming the resource was paid hourly for every hour worked). There is a schedule variance since we earned three days of work, but planned to do five.
In this first pass, we neglect to reschedule incomplete work from the first week. Instead, we move on to status at the end of the second week, which is May 1st. The task is complete. The % Work Complete field is set to 100%. The Actual Duration is computed to be six days and the finish date is computed as April 28th. There is no schedule variance (the task is complete), and there is no cost variance. We earned the six days that we spent.
Going back to the first status date, the earned value is different from what we saw above. Without rescheduling the incomplete work, it appears that work was done on April 24th. MS Project thinks we earned four of six days of work (0.6 x $4800) in the first period, instead of three of six days of work (0.5 x $4800) shown above.
To correct this, we must first verify that the “Split in-progress tasks” box is checked in the File > Options > Schedule dialog box.
Then, we return to the first status date of April 24th, enter the task tracking information, and use the Update Project dialog to split the remaining work and reschedule it after the status date. Earned value is now computed correctly.
In the second status period, the task completed within six days of work. Note that the task finishes one day later than above, since no work was done on April 24th. The earned value at the end of the project remains the same.
When we return to the first status date, April 24th, the earned value is correct.
As a twist to the example above, let’s consider what happens if no work was completed on the task prior to the first status date (April 24th). The reschedule incomplete work option of the Update Project dialog will constrain the start of the entire task to after the status date. Below, we see that a Start No Earlier Than (SNET) date constraint has been applied to the task. While it is advisable to limit use of date constraints, the application of a SNET constraint in this case is benign. It does not impact the remaining schedule.
There are several steps in a tracking cycle, such as to set the status date, enter actuals, reschedule incomplete work, and level the remaining schedule. Rescheduling incomplete work is a vital step that ensures we do not overwrite history as we track project progress and that our earned value assessments remain accurate.
Have you used this method to reschedule incomplete work? I would love to hear from you in the comments below.