August 2021

Planning & Programming Pitfalls (Part 2) 

Article by Andrew McKenna, Director of Delay and Planning

Following on from part one of this three-part series, we consider three additional salient issues regarding common planning and programming issues: 

  • The project baseline and the level of detail;
  • Program updates and maintaining an as-built program;
  • Contemporaneous records and actualising: programs
  • Delay allowances and contingencies.

The baseline level of detail

All too often, baseline programs contain either too much or too little detail. An overly complex baseline can be challenging to manage and can quickly become irrelevant if it is not regularly updated. The level of detail must be proportional to the complexity of the project. However, sub-programs or short-term programs should be developed, which relate directly to the baseline or “master” program. 

The tender program is often used as the basis for the baseline program. It should be a fully logic linked network of activities that captures the true critical path and general delivery methodology, including the project key interfaces, deliverables and constraints. In addition, one must consider the contractual obligations concerning the program. For example, some of the Australian standard forms of contract deem that the tender program is the baseline program (AS2124) or is deemed a contract document, as is the case of AS4000

Upon contract award, the contractor is usually required to submit a baseline or “contractors” program within a relatively short time frame (sometimes referred to as the “contract” or “construction” program). This updated program should capture more detail in the initial phases of the project, say the first six months, depending on its complexity and duration. Notwithstanding the contractual obligations regarding the program, the program can and should be updated to reflect future changes to the project’s delivery. 

Updating programs

Depending on the contract requirements, the accepted baseline program should be updated with actual progress at intervals of no longer than one month (or more frequently on complex projects). The program operative should input the actual progress on a copy of the accepted program to create the periodically updated or “status” program by adding additional activities (“fragnets”) and updating the activity logic and durations to create a “live”, as-built program. The more often the program is updated, the easier this process will be. 

Any delays to the planned works should also be incorporated into the updated program, including methodology changes and EOT events. Further program revisions should be created to assess potential (“what-if”) scenarios and their potential time impact analysed.

The updates should be saved electronically and archived. Each revision of the updated program should be accompanied by a BOS (basis of schedule) report that details any changes to the program since the previous update (the accepted program). The purpose of saving periodic updates of the program is to provide good contemporaneous evidence of what happened on the project in case of a dispute.   

The contractor must seek approval from the Superintendent or employer’s representative with every update to the baseline program. Upon approval, the updated program will become the new contractor’s program. The Superintendents view on progress should be reflected in the updated programs and disagreement resolved through the contract dispute resolution procedures.

“. the CA’s view on progress should be reflected in the Updated 

 Programs. The contractor’s position on the areas of disagreement should be 

 recorded and submitted with the Updated Programs.” 1

The as-built method of status updating has many advantages. As well as serving as the best method of delay analysis, it gives a clear presentation of planned against actual performance (a factual account of what happened, when and why).

Supporting contemporaneous records and “actualising” programs 

It is systemic in construction project management that the program is only used to communicate “progress”, not the essential forecasting tool that it is supposed to be. This is primarily due to the way in which the program is updated. This may be in part to a lack of time or skillset. Typically, a perceived level of progress is determined by the program operative who is often divorced from the project. The operative may receive “status” information from the project team in relation to their perceived level of task completeness. However, more often than not, this perception is not reinforced with factual support and is incorrect. 

The status of the works should be reinforced with evidence of progress, such as:

  • Photographs; 
  • Measured quantities correlating with progress claims;
  • Marked up drawings;
  • Drawing issue registers;
  • Material delivery dockets.

The program operative should maintain an as-built program to maintain a historical critical path. “Actualising” activity start and finish dates or simply entering when the activity started and/or finished essentially removes historical logic, thus rendering the program useless in determining the historical critical path through the project. Similarly, relying on the software to determine the completion of an activity based on an interim perceived level of completeness often produces inaccurate forecasts. 

Delay Allowances & Contingency

A delay allowance should not be confused with “float” or contingency. A delay allowance represents a genuine assessment of potential delays and their probable impact to the progress of the works, whereas contingency constitutes a future event or circumstance which is possible but cannot be predicted with certainty.

Delay Allowances 

Typical delay allowance considerations might include (contract dependent):

  • Inclement weather;
  • Site IR disruption;
  • Latent conditions (defined Contractor risk events);
  • Resource availability and productivity;
  • Changes to construction methodology or complexity not identified at contract award. 

AS4300-1995 (un-amended) allows for an extension of time to be claimed for inclement weather. However, most standard forms are amended to the effect that a inclement weather delay allowance should be pre-determined and incorporated into the date for PC. 

Typical 35.5 (amended)

 (a) The Contractor acknowledges that the Approved Program allows for anticipated delays to the performance of the Works by reason of: 

(i) Inclement Weather and the effects of Inclement Weather; 

(ii) Weekends, public holidays, rostered days off and other foreseeable breaks in the continuity of the Works; and 

(iii) Subject to clause 35.5(d), any other delays that is reasonable having regard to the nature of the Works. 

The contractor is not entitled to any extension of time for Practical Completion of the Works if any delays to the progress of the Works for any of the anticipated delays noted in this clause 35.5(a), all of which are and will remain at the contractor’s risk.

Contingency 

Recovery plans and strategies should be developed early on for high-risk activities to mitigate potential delays should they arise. 

Such contingency strategies examples include: 

  • Using air freight, not sea for long-lead-time materials from overseas 
  • Working double shift work patterns 
  • Working out of regular hours 
  • Re-sequencing of works to overlap work fronts

1 SCL Delay and Disruption Protocol 2nd Edition: February 2017

Disclaimer: This paper does not in any way constitute any type of legal or professional advice whatsoever and in no way should be relied upon by any party whatsoever in any jurisdiction.

Show more news