Programme Health Check

When preparing or evaluating the robustness of a construction programme, there are a number of basic checks worth carrying out. This post briefly describes the more important ones.

a) Missing Original Scope

A common problem with programmes is that they are not comprehensive, i.e. do not include all the works required to complete a project. It is important to ensure that all important work-scope referred to in the contract, specification, drawings, BQ and method statements are accounted for within the programme. This includes any restrictions or constraints on how the works are to proceed.

As such, it’s a good idea to check the programme includes things like:- preliminary design and engineering tasks (including all important submissions and approvals), procurement, fabrication, delivery, installation, testing and commissioning, as well as statutory certification and handover.

b) Open-end Activities

Open-end activities are those that have no logical successor. Generally, it is a good idea for all activities to have at least one successor and one predecessor. If an activity has no successor, it in effect means there is no constraint on when it has to be finished, i.e. it can be completed on the very last day of the project without causing any delay.

c) Excessive Float

Activities, or groups of activities, that possess a lot of apparent programme float, are a tell-tale sign that the network lacks sufficient logic relationships.

d) Retained Logic v Progress Override Scheduling

An important choice when preparing a programme is which scheduling mode to use when updating the programme with progress, i.e. for monthly updates. Generally, I prefer progress override, but if chosen it is imperative that there are sufficient logic links between activities to account for possible out-of-sequence progress. One way this can be done is by adding extra finish-to-finish links (with appropriate lag) between activities already linked via a finish-to-start relationship.

e) Unnecessary Constraints

Constraints are often added to programmes to help fix the schedule within the appropriate timeframe. They are added to individual activities or milestones, e.g. ‘project start’ and ‘project completion’. As such they are very important in defining activity float and criticality within the programme.

However, if too many are used, they drastically reduce the programmes ability to reflect and effectively model ‘change’, whether it be progress related or revised work-scope. Generally, it is a good idea to minimize the number of activity constraints to the absolute minimum. Often this can be done by replacing constraints with logic links.

f) Wrongly applied Activity Calendars

Programmes often include several project calendars, e.g. 5-day or 7-day work week, which is then assigned to individual activities. This is very useful, but can cause some problems if used carelessly. As such it is worthwhile checking calendars are properly assigned.

g) Excessive lags between activities

Lag is the defined as the time added to the logic relationship between 2 activities. For example, a Finish-to-Start link with zero lag is where the successor activity can start immediately after the predecessor activity is complete. Another example is a Finish-to-Finish link with 7 days lag – meaning the 2 activities can overlap, but the successor is expected to be completed 7 days after the predecessor is complete.

Sometimes however, planners include relationship links with excessively long lags. These can lead to long gaps between activities that give the false impression that there is no work planned to occur during the gap. Such excessive lags should be avoided and can often be replaced by an activity string that can be properly monitored and updated, and better reflect the actual work content.

h) Questionable logic between activities

As a general rule, negative lags in relationships and Start-to-Finish links should be avoided if possible.

After amending the programme incorporating the above, the planner can then run some further general checks. The idea being to make sure that the programme reacts to changes as you would expect, thereby ensuring it is a robust and dynamic model of planned expectations:-

1) What-if analysis

This is a simple and effective way to check what the impact on the programme might be if some identified risk occurs. For example, if certain approvals are not received on-time or there is a lack of specialist workers, then these ‘what-if’ scenarios can be input into the schedule to measure the likely impact. The ‘impacted’ schedule can then be compared with the original, to check what changes and whether these changes are in-line with what was anticipated. Often, due to a lack of sufficient activity relationships, clear flaws in the underlying logic become immediately apparent, and can be readily fixed.

2) Recheck the critical path (and near critical paths)

As a last step, it is important to recheck the final critical path to ensure it is reasonable, makes sense and in-line with what the project team would expect. This can also be extended to include ‘near critical path’ activities, with the same aim in mind, and thus make sure the resulting programme is fit-for-purpose.