A Crash Course in Planning and Programming
Planning and programming are closely related but different parts of project management. Planning is about deciding how a project will be delivered, while programming is about communicating that plan, usually through a schedule or Gantt chart.
The words planning and programming are often used interchangeably to describe two distinct functions of project management. Planning constitutes how the project will be executed (the plan), whilst programming concerns the communication of the plan.
Planning starts at the time of tender and continues through to completion. The plan constantly evolves as the project progresses, as should the programme.
The programme consists of a sequence of logic-linked activities in line with the project plan of varying duration from commencement to completion, typically in the form of a Bar (Gannt) Chart. A good plan is constantly updated to reflect change and progress. A planner manages this process and its communication through the programme. However, to successfully execute the plan, the project must “own” the programme.
“If you fail to plan, you are planning to fail!” - Benjamin Franklin
Common Issues
The baseline master programme or “contract” programme is a static document
Whether it be due to a delaying event, subsequent mitigation strategy, or work not captured in an earlier revision, for a programme to be a useful project management tool it must be updated to reflect any significant deviation from the originally intended plan. Otherwise, the programme will become irrelevant.
No matter how robust and detailed the original plan is, it will invariably change throughout the course of a project. An accompanying (basis of schedule) document which substantiates and justifies the changes must be submitted with the revised baseline, and its approval sought from the clients representative or otherwise.
The programme is solely used for the purpose of monthly reporting
It is often a requirement that projects status be reported against the baseline or “contract programme” to demonstrate progress. The planner or programme operative often only considers the works planned to have been undertaken in the previous nominal time frame (typically a month) between reporting periods. Activity commencement and completion dates or a perceived percentage complete of activities in progress are simply input, overriding the planned logic.
The activities after the data date of the update are rescheduled in accordance with the preceding activities’ anticipated completion based upon a software algorithm. This is “programming”, not planning.
Programme Updates
The planner or programme operative should instead update the programme contemporaneously by modifying the as-planned logic and activity durations to reflect what occurred more frequently than the nominal reporting period. Additional activities (or “fragnets”) should be added where necessary to rationalise a change to activity duration.
Similarly, future activity logic and durations should be reviewed and any changes noted in the basis of schedule document and be accompanied by substantiating records. This way, a “live” (as in it has a historical critical path) as-built programme is maintained and a more robust forecast is communicated.
Multiple programmes
A project should have a single master programme that incorporates the intent of the entire construction process from commencement to completion in an appropriate level of detail. Short-term (look-a-head), detailed programmes should be developed by the respective contributor. However, their content must relate directly to the master programme, which is managed solely by the planner or programme operative.
Managing and controlling multiple programmes is difficult and time consuming. Often contractors see it as prudent to have two master programmes: A “contract” programme for reporting and a “target” programme to actually work to. This approach is fraught with trouble since the project will have a different status for each programme for the same works in the same respective period. Therefore, making it difficult to prove causation in the event of delay and for the party privy only to the “contract” programme to understand their key interfaces and deliverables.
The baseline level of detail
All too often, baseline programmes contain either too much or too little detail. An overly complex baseline can be difficult 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-programmes or short-term programmes should be developed, which relate directly to the baseline or programme.
The tender programme is often used as the basis for the baseline programme. It should be a fully logic linked network of activities that captures the genuine critical path and general delivery methodology, including the project key interfaces, deliverables and constraints. One must consider the contractual obligations in relation to programme, for example, some of the Australian standard forms of contract deem that the tender programme is the baseline programme (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” programme (sometimes referred to as the “contract” or “construction” programme, contract dependent) within a relatively short timeframe. This updated programme 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 programme, the programme can and should be updated to reflect future changes to the project’s delivery.
Updating programmes
The accepted baseline programme should be updated with actual progress at intervals of no longer than one month (or more frequently on complex projects), depending on the contract requirements. The programme operative should input the actual progress on a copy of the accepted programme to create the periodically updated or “status” programme by adding additional activities (“fragnets”) and updating the activity logic and durations to create a “live”, as-built programme. The more often the programme is updated, the easier this process will be.
Any delays to the planned works should also be incorporated into the updated programme, including methodology changes and EOT events. Further revisions of the programme 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 programme should be accompanied by a BOS (basis of schedule) report that details any changes to the programme since the previous update (the accepted programme). The purpose of saving periodic updates of the programme is to provide good contemporaneous evidence of what happened on the project in case of a dispute.
Approval from the Superintendent or employer’s representative must be sought with every update to the baseline programme. Upon approval, the updated programme will become the new contractor’s programme.
The Superintendents view on progress should be reflected in the updated programmes and disagreement resolved through the contract dispute resolution procedures.
“the CA’s view on progress should be reflected in the Updated Programmes. The Contractor’s position on the areas of disagreement should be recorded and submitted with the Updated Programmes.”
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” programmes
It is systemic in construction project management that the programme is simply used as a means of communicating “progress”, not the essential forecasting tool that it is supposed to be. This is largely due to the way in which the programme is updated. This may be in part to a lack of time or skillset. Typically, a perceived level of progress is determined by the programme 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, this perception is often 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
Minutes of meetings
Material delivery dockets
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 delay allowance should be pre-determined and incorporated into the date for PC.
Typical AS4300-1995 clause 35.5 (amended):
(a) The Contractor acknowledges that the Approved Programme 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
Demonstrating Cause & Effect
To prove delay causation, it is much easier to use an approved Contractor’s programme. It is unlikely that the Superintendent will approve a contractor’s programme when the actual status of works is different to that indicated on the submitted programme.
If the Contractor’s programme isn’t approved formally or otherwise rejected it makes it very difficult to prove delay.
The accepted Contractor’s programme is an excellent tool for the analysis of EOT or likely delay events. However, it must be formally accepted!
By updating the Contractor’s programme to reflect the sequence and progress of the works on a regular basis, the Contractor has an as-built record of construction progress and a means to carry out a ‘time-impact’ analyses of a delaying event.
Consider the programmes importance in demonstrating the causal link between delaying events and a projects key completion deliverable.
At Accura Consulting, our team of experts work with clients to create a tailored solution to problems. If you have an issue and want expert support, get in touch.
Back to News and Insights
Related News and
Insights from Accura
