Updating project status

One of the best ways to differentiate scheduling skills and knowledge is to ask project managers how they update status in their schedules.

There are fundamentally four ways people go about it.

• Option 1: They don’t, say no more
• Option 2: % complete, sort of like colouring in the bars of the baseline schedule. It gives a visual representation of where things are at compared to the status date.
• Option 3: Actual dates plus a re-forecast of remaining work. It captures history (useful for lessons learnt) and provides a reschedule of all future work relative to the status date. It relies on comparison to the baseline for reporting purposes.
• Option 4: An extension of Option 3 where actual and remaining resource effort are also captured.

Option 2 is the popular one because it is easy and provides a clear picture of where the project is at from a schedule perspective. The unfortunate thing is that once a schedule gets behind, it rapidly ceases to give meaningful data, the schedule being no longer valid. Also what use is there knowing that a task has gone from 75% complete one week to 80% complete the next? I’d rather know when the task will be completed.

Option 3 is far more useful but arguably the most difficult. It relies on not only determining what has been started and finished but when. For in progress tasks one also needs to capture a revised forecast completion date. One of the wonderful legacies of this approach is capturing the ‘as-built’ schedule which is extremely useful for future estimates and schedules as well as lessons learnt.

Option 4 requires a huge amount of effort to collect and enter data. Many organisations just don’t have the systems or discipline in place to collect task-based actual effort, nor the willingness to track to that level of detail.

So what about the tools? Professional scheduling tools such as Primavera and Open Plan are set up for Options 3 and 4 whereas mainstream tools such as MS Project try to cater to all options. MS Project requires discipline, by the user, to successfully cater to Options 3 and 4. Many who use MS Project simply do Option 2.

The key for organisations who use MS Project is to define a scheduling standard that mandates a technique, then ensure that all schedules are updated consistently using a common status date.

If organisations adopt Option 3, then users must be trained. Organisations that attempt Option 4 via MS Project server definitely need to do this, particularly if they have also implemented timesheeting.