This is the last of four articles I’ve written recently on the topic of on tracking a project. I have outlined a four-step tracking cycle: set the status date, enter actuals and revisions, reschedule incomplete work, and level the remaining schedule.
To explore the last step, let’s consider an example. The below schedule was baselined after initial resource leveling. It is 11 days long. Resource R is constrained to two units.
The project started as planned on October 4th. The first weekly status was October 8th. Only two days were spent on Task A. Task B was completed, but Task D was not started. Hence dependent Task F was not started. Incomplete work was rescheduled to start after the status date, resulting in a split of Task A and a Schedule No Earlier Than (SNET) constraint being placed on Task D and Task F.
Entering actuals and rescheduling incomplete work created resource overallocations in the remaining schedule. The underutilization of resource R in the first week caused the shifting of four days of work into the remaining schedule.
In the Leveling Options dialog, the schedule is leveled from the Status Date through the end of the schedule. You do not want to level the entire schedule since this potentially would overwrite portions of the actual schedule from the beginning of the project. Note that the “To:” date may need to be extended to cover the potential expansion of the schedule during leveling.
If we choose to clear the prior leveling in the remaining schedule (by checking the Clear leveling values before leveling box), the leveling yields a 14-day schedule. During the day-by-day leveling starting after October 8th, Task E is critical on October 15th and that is why it is scheduled before Task F.
If we choose to not clear the prior leveling within the remaining schedule (unchecking the box), we get a different 14-day leveling of the remaining schedule. With the prior leveling not cleared, Task F is critical on October 15th and is scheduled before Task E.
Just as one may want to explore different leveling options prior to creating the baseline schedule, one should explore different leveling options for the remaining schedule. Project shows you only one leveling solution at a time based on the options you select. The one you are looking at may not be the best. As discussed in my prior MPUG postings on the subject, there is a distribution of leveling solutions. In this example, there was no difference in the project duration of the leveling’s. That will not always be the case.
Trevor Rabey
You say, “You do not want to level the entire schedule since this potentially would overwrite portions of the actual schedule from the beginning of the project.”
Leveling cannot delay a task which is complete and is marked as 100% complete, and leveling will not delay any task which has an actual start date.
So provided all complete tasks are to the left of the status date, there is no need to specify the leveling start date as being from the status date.
Robin Nicklas
Trevor,
Your statements are correct. If a task has been recorded as 100% complete, it is not affected by leveling. If a task has an actual start date, it will not be delayed by leveling. In other words, actuals are not affected by leveling.
The point I would like to convey is that we should be leveling incomplete work that is in front of us, rather than behind us, relative to the status date. In the third article of this series, I recommend rescheduling incomplete work to occur after the status state. If that third step has been done correctly, then it shouldn’t matter if we level the entire project or just the remaining project in the fourth step.