Concurrency in the Modern Construction Environment
Andrew Farrer provides some thoughts and examples on the practical application of concurrency within a construction environment.
Typically within every construction and engineering contract lies an obligation for the contractor to provide regular (usually monthly) progress reports. At the outset, the contract administrator will typically list out the do’s and don’ts of such a report, and the report’s hot topics will be discussed between the project team and the contractor.
Frequently one of the contractual requirements is for a form of progressed programme (or ‘time schedule’) to be prepared by the contractor. To that end the contractor’s planner will walk the site observing progress and apply his or her view of that progress as a percentage against the scheduled activities.
So far, so good.
However, more often than not, the programme issued by the contractor in its monthly progress report has a jagged progress dropline.
The horizontal green bars in the programme represent the schedule’s activities. The vertical red line represents the progress date line. A straight progress date line from top to bottom indicates that all activities are on programme. A jagged progress date line (such as above) indicates that individual activities are not progressing in accordance with the planned programme. Any activity or part-activity to the left of the red date line is complete; anything to the right is incomplete.
Whilst such graphics may assist in ascertaining delay to discreet activities, it provides little assistance for assessing overall project delay (or recovery). There is no indication of the current anticipated completion date. This can only be achieved by rescheduling the activities to reflect their current progress and re-applying their as-planned durations, sequencing and logic.
Programming software has this rescheduling function, which effectively straightens the progress line. By rescheduling based on the progress achieved, the full functionality of the programming software is able to recalculate the anticipated completion date. Rescheduling programmes is a cornerstone of software led critical path delay analysis.
And therein lies the problem.
Where, in its monthly report, the contractor submits a computer-based assessment of delay to the completion date, a strong statement is made of (i) the measure of delay; (ii) when that delay accrued; and often (iii) those activities that have contributed to that delay. However, this is often not supported in the contractor’s submission by reference to contemporaneous delay-related evidence (correspondence, reports, site diary records, notices etc), which leaves the contract administrator with only his or her professional judgment to assess the true time-status of the project and to the cause(s) of any project critical delay.
The fifth edition of Delay and Disruption in Construction Contracts agrees, pointing out that jagged line progress monitoring…
“… fails to illustrate the effect on completion of the contractor’s progress and, whilst it may seem incredible, some contract administrators accept such progress monitoring reports as contractually compliant updates”
and also that it …
“… serves no useful purpose within an effective time model …”
This balance of knowledge – and thus power – will remain tipped in the contractor’s favour until clients, and contract administrators, start demanding rescheduled progress programmes.
By Sam Playford