This post wraps up the discussion on developing update methodologies. The first three posts addressed some of the basic principles of updating schedules as well as some of the specific mechanical elements within the Microsoft Project desktop client.
The last post reviewed how those principles and mechanisms could be applied to an IT scenario. In this post, I’ll talk about how construction projects may get updated. The goal is hopefully to provide suggestions that may be applicable to your own environment.
Again, there will always be nuances, but the general process will likely be as follows:
- Set the status date.
- Add the Actual Start or Actual Finish
- Set the Remaining Duration for in progress tasks.
- Progress all completed tasks to the status date.
- Reschedule unstarted tasks to the status date (or estimated start date)
Let’s walk through that scenario in a simple schedule.
In the simplest case, we first update the Actual Start or Actual Finish for the tasks that have actually started or finished. I update the following:
- Actual Finish for the Project Started milestone.
- Actual Start for Task 1.
- Actual Start for Task 4.
Then I set the Remaining Duration field for each of the tasks. Generally, I would enter a Remaining Duration that pushes the new Finish date out to the estimated finish date that my resources are reporting to me.
If I am using Project Server, I might add a custom field for Estimated Finish to the My Tasks sheet, then roll the Estimated Finish field into the Remaining Duration field using a macro as part of the update process.
Then I select the option to Update the Project from the Project tab. In this case, I select the started tasks first and set the options to progress the tasks as follows:
I could also use the Mark as Scheduled option in the Task tab to accomplish the same thing.
Note how % Complete automatically updates…
From there, it’s a simple step to reschedule any unstarted tasks to after the status date – again using the Update Project button.
Facilitating the Process
One method to facilitate this process is to add a custom field and grouping that would group tasks by whether or not they are in progress or unstarted. A formula to establish that in a spare text field might look as follows:
IIf([% Complete]<100,IIf([Actual Start]<>ProjDateValue(‘NA’),”In Progress”,IIf([Start]<[Date1],”Unstarted”,””)),””)
…where Date1 is configured to equal the Status Date.
Group by it, and you would get the following view.
Review the process above, and the view makes things simpler. If I apply the view after I’ve entered all of the Actual Start and Finish dates, then I can simply select the In Progress tasks to progress to the status date and the Unstarted tasks to reschedule after the status date.
Better yet, as discussed above, I could develop some form of VBA automation to refer to that field and update my project with a single key stroke.
Comparing Construction and IT
So now we’ve looked at two different scenarios, what is the fundamental difference? In both examples, we follow the two commandments of schedule updates, i.e. no incomplete work before the status date and no completed work after the status date.
However, we make different assumptions about why the task took longer than expected, i.e. whether the estimate was incorrect or whether the team was pulled off of the task. In the example above, we assume that the team has been working continuously since the Actual Start date for the task. In IT, we assume that the work was interrupted. Are either examples always true in any industry? No, what we’re attempting to do is to define a process that captures the bulk of the project updates, but there will always be tasks that don’t match this particular model.
Once we remove that assumption that the work was interrupted, % Complete becomes essentially useless for data input. In that case, once the resource identifies the Actual Start and the Remaining Duration, the scheduler calculates % Complete for the resource.