Traditionally,
a project model is built up by:
- breaking down the entire project into a series of individual
tasks
- setting expected durations for each task
- adding logical constraints between the tasks to give planned
schedule of work.
This process will tell you the earliest date at which each task
is expected to start based on the durations of all tasks that
precede it in the model.
Planners usually also use the system to generate the latest
date at which a task can be allowed to start, or more particularly
finish, and this is usually added to the bar chart display as a
period or float. When monitoring the progress of the project the
reports calculate the actual slippage between the dates when tasks
were planned to start and when they actually started.
This analysis does not give an ideal approach however. If (as is
usually the case) progress is measured against the earliest start
of each task, then progress values are unlikely to show any
measure of being ahead of schedule - particularly for non-critical
tasks which are quite reasonably postponed until a resource is
available.
Since the majority of tasks are non-critical, a progress report
could well show large sections of the project apparently running
late, when in fact the tasks along the critical path are on
schedule and the project stands every chance of being finished on
time.
An alternative is to measure progress against the task late
start/finish dates. This will give the opposite result - the
project will start with large sections of the project being shown
ahead of schedule - all very comforting. Ultimately any section
may end up running late, but by the time this happens the
consequences could be serious as this situation will, by
definition, delay the project completion.
There are a number of options to overcome this.
- By limiting the reporting to ONLY critical tasks the above
problems will not arise - the calculations showing tasks ahead
or behind schedule will be a true representation of the current
status.
- The preferred option by Kvaerner was to develop a method of
introducing a mid-point schedule against which tasks could be
progressed. This gave a general `average' schedule against which
the progress reports could give a sensible summary of true
status. Whilst this is not a fully rigorous approach, it
provides a quick and easily understood approach and proves to be
most effective in use.
A facility was developed using
Hornet
Windmill's reporting facilities that would generate the
required mid-point schedule. The report scans the project tasks
calculating the midpoint between the early and late start dates for
each task, and lists these dates in a file on the disk. This file is
then imported back into the system against the current archive or
baseline dates, this is readily achieved using the database import
facilities. The progress reports can then be produced using this
baseline for all progress calculations.
The reporting instructions that calculate the mid-point schedule
included options to allow the user to specify the percentage delay
that he wished to apply; a scale from 0 (early dates), through 50
(the mid point) to 100 (late dates) could be selected. All tasks
in the project that had already been recorded as having been
completed are processed with a zero correction factor, thus
allowing the manager to create a new target baseline schedule at
key stages in the project should this prove necessary.
These options extended the usefulness of the reporting technique
considerably.
