This is the third post in a short series on determining an appropriate enterprise-wide project update methodology….or actually, just determining an appropriate project update methodology – as what I am writing about could be implemented on a single project just as well as across a large number of projects.
In the previous posts, I talked about reviewing some of the organizational factors that might influence how the update process is structured. I then went into the Microsoft Project client to review some of the settings that control how updates are applied.
In this post, I’d like to continue looking at the mechanics that govern how updates get entered in the system.
On Setting the Status Date…
First off, the status date is a critical bit of the update methodology. I am constantly amazed by end users who attempt to update their schedules without using the status date. Personally, I don’t really understand how such a thing is possible.
Put simply, the status date is the last date upon which the the data input into the schedule model was complete. If we update the schedule every Friday, and today is Wednesday, then the last status date would be the previous Friday.
The issue with the status date is that when it is used in a Project schedule that doesn’t display the time, simply entering a date will default the status date to 8AM of that date. So if I enter Friday as 12/16/2011, then the system will assign a default of 12/16/2011 8:00AM, which in a traditional corporate calendar translates essentially into 12/15/2011 5:00 PM. Depending on the specific update methodology, this may get confusing.
Take the following example….in a construction scenario, I am importing Actual Costs from an external application and applying them to the project, having them accrue as of the status date. If I update my schedules monthly at the end of the month, and I set my status date for 12/31/2011, then the system will accrue all costs as of 12/30/2011 and not as of 12/31/2011. In theory, no status will appear on that day.
For this reason, I’d recommend as best practice either specifying the status date as 5:00 PM on a specific date or simply set the status date for the day after the “real” status date. In an IT project, where I update the schedule each Friday, I would simply set the status date to the Saturday following to make updates easier. In a construction project where I update at month end, I would set the status date to the first of the month following.
Lastly, here’s a trick to get the status date to appear in your schedule…and a filter to show in progress tasks…
Identifying Tasks to Update
So now we’ve identified how to enter the status date properly, the next issue lies in identifying which tasks need to be updated. In theory, depending on your schedule granularity, you probably will never have to update more than a couple of tasks each update cycle. If you set up your schedule properly, with the appropriate dependencies, updating the in progress tasks each cycle will result in an up to date schedule model.
My recommendation is to simply develop a filter or a view that will identify any task that requires updating. This process has been made a bit more complicated with the introduction of manual scheduling in Project 2010 which necessitated the conversion of the default Start field to a Text field. In 2010, the way around this is to develop a filter on the Scheduled Start field. (Click here for more on that…)
This is also complicated by the fact that the Status Date is not available as a task level field. Hence, the first step is to make the status date available for use in a filter. To do this, we use a custom Date field, and set it equal to the Status Date.
Then we create a filter that looks something like this:
…and I think that’s that. Now we have the stage set, let’s get back to some process discussion with my next post on the topic….