In the first two articles of this series, a four-step tracking cycle was defined. It includes setting the status date, entering actuals, rescheduling incomplete work, and resource leveling the remaining schedule. This article addresses the third step in the cycle: rescheduling incomplete work.
Do Not Rewrite Project History
The status date defines the time through which project progress has been recorded. Work that was done in the past, prior to the status date, should be recorded in the past. This includes work that was scheduled in the future, but was started early and done in the past. Work that should have been done in the past, but was not, must be rescheduled to be done in the future, after the status date. This ensures that the work is recorded according to when it was performed, not when it should have been performed.
A Simple Example
In the following example, Task A started on 27th of September was marked as 50% Complete as of the October 1st Status Date. The task’s Status is Late, since the cumulative percent duration complete is less than what was planned through the Status Date. In the subsequent status update, on October 8th, the task is marked as 100% complete. However, it appears as if the remaining two days of work were done during the week of September 27th instead of during the week of October 4th.
Figure 1: Task A is only 50% complete when it should be 100% complete as of the Status Date.
Figure 2: The remaining work on Task A completed during the second week is erroneously shown as completed during the first week.
We should have rescheduled the incomplete portion of Task A to be completed during the following week, after the October 1st Status Date. To do this, we must check the Split in-progress tasks box in the Schedule Options dialog. This allows us to show that work on the task was interrupted. Then, we use the Update Project dialog to reschedule the incomplete work to start after the current status date (October 1).
Figure 3: Check the Split in-progress tasks box in the Schedule section of the Project Options dialog.
Figure 4: Reschedule incomplete work to start after the Status Date using the Update Project dialog.
The result shows the remaining two days of work split and rescheduled to resume on October 4th. Note that Project considers the task Status to be On Schedule. The remaining work has been rescheduled into the future and is no longer considered late.
Figure 5: Remaining work rescheduled into the second week, to start after the Status Date.
When the task is marked as 100% complete on October 8th, we see that two days of work were completed in the first week and the remaining two days in the second week.
Figure 6: Work correctly recorded as to when it was performed.
How Do You Find Incomplete Work That Needs to be Rescheduled?
If you use the standard Incomplete Tasks filter, which shows tasks that are not 100% complete, it shows incomplete work in the past and in the future. If you use the standard Late Tasks filter, it shows tasks with a Status of Late, which means that the Cumulative Percent Complete field is not 100% complete by the Status Date.
Figure 7: Task tracking prior to rescheduling incomplete work in the first week.
Figure 8: Task tracking after rescheduling incomplete work and marking task 100% complete in the second week.
Filtering for tasks that are not 100% complete and whose Finish dates are less than or equal to the Status Date works, as well. Selecting the Reschedule option across the entire project in the Update Project dialog finds the late tasks for us.
Does it Matter?
Some might argue that rescheduling incomplete work does not matter. If a task is completed prior to the Status Date, it is 100% done, regardless of when the work was completed. To see how earned value calculations are affected by not rescheduling incomplete work, see my prior article on the topic.
John Owen
Thanks Robin. You have concisely called out the reason that many schedulers assume Project isn’t a serious project management tool. Tools like Deltek Open Plan and Oracle Primavera automatically reschedule incomplete work from the status date. Project does not. This can lead to incorrect forecasts for future work as Project allows incomplete work to be scheduled in the past. This ‘third’ step (rescheduling incomplete work to the status date) is essential to use Project correctly and achieve reliable forecasts.
Tammo
I’d like to make a comment regarding Split Tasks. The suggestion to Split In-progress tasks (check the box in Options) determines whether “retained logic” or “progress override” is used. It is not really required to be checked to reschedule unfinished work; it depends on what effect/result you want to achieve. If the box is checked, Project will insist that the remaining work, i.e. remaining duration, of the in-progress task is scheduled after its predecessor(s) finishes (retained logic). If the box is unchecked, Project will allow you to enter whatever remaining duration you want and schedules that after the data/status date (progress override).
Personally, I do not like retained logic. If I’m reporting status, I want to establish the finish date/remaining duration relative to the status date without having to revise the logic to get what I want. I call that re-planning history and it serves no purpose. As I’ m reporting progress, I’m obviously reporting what is the current state of affairs. I’d like to believe that I am smarter than the computer and have more current info than I had at the original plan. If at that time I decide I still need to wait for any predecessors to finish, I’ll add sufficient remaining duration to get that.