Available to download here: Baseline Master Programme – A Contractor’s Nightmare

The purpose of this article is to highlight the importance of having a robust baseline/master programme upon which project activities are planned and controlled.

Many contractors fail to appreciate the importance of a baseline/master programme. Very often they produce a bar chart that fails to capture the full scope of works, has no logic and is simply not practicable or achievable.

This can be for several reasons.

  • Lack of design information/development
  • Their paranoia that too much detail could be used against them in a claim
  • Failure to review/revise the programme upon Contract Award and issue of construction drawings. Instead adopting the Tender Programme which was prepared under tight deadlines and less information.
  • Lack of respect for the programme itself. i.e. not understanding why it is so important and not just a paper exercise for the Client.

If the Employer approves or accepts a baseline/master programme then it will become the basis for the Project Monitoring during regular progress meetings between the Client and Contractor. An inaccurate poorly considered programme will not be beneficial to the Contractor if and when matters vary from their intended course albeit for Employer and Contractor failings.

If the baseline/master programme does not react dynamically when producing weekly / monthly updates, the programme will provide an incorrect critical path and more so damage the contractor’s ability in demonstrating delays to the works and thus potentially any justified entitlement to Extension of Time claims.

It is advisable to break down the preparation of the programme in stages.

    • Overall Strategic approach including key design and procurement issues
    • Develop Programme for Construction
    • Develop Programme for Design and Procurement. This should include the periods for review for any submission, approvals and consents specified in the employer’s requirements.
    • Merge and address clashes
    • Coordinate with key resource drivers
    • Include key subcontractor programmes eg steelwork, timber frame etc
    • Finalise the programme and issue for approval
    • Agree with stakeholders [if applicable]

Baseline/ Master Programme Review

It is important the baseline/master programme, is reviewed to ensure the programme is practical and achievable. At Edge, we “Plan to succeed and plan to protect. That simply means not putting together a programme we know is going to fail. We will ensure it is achievable and highlight risk areas that need careful attention. A plan to protect is simply ensuring that any third party obligations and actions are included in the programme and structured in such a way as to protect the parties involved should they fail to be achieved.

The programme has to be structured in such a way that it can be dynamic when progressed. This requires sound logic to have been assigned.

The Review should include:

  • Critical Path
  • Float
  • Logic

Then we would recommend that a similar exercise is carried out with the Employer’s Team, to ensure their ownership, particularly focusing on any tasks where they have a liability.

Critical Path

To ensure that the baseline/master programme show’s a true critical path, all activities must be linked with the correct logic to show the planned sequence of works to be carried out to complete the project at that point in time.

Within the baseline/master programme, there should only be one activity without a predecessor, which will be the project start milestone and one without a successor, which shall be the finish milestone. The exception is where Sectional Completions exist. These should be completing tasks to ensure the critical path running to the Sectional Completion can also be identified. If tasks between various sections are dependant on each other then this will help highlight the approach.

If the baseline/master programme has activities without a successor or predecessor, these activities become open-ended, and as a consequence when they are impacted by any delays, subsequent construction activities will not be affected. Accordingly, any potential effect on the project completion date is not identified, and any subsequent entitlement may be lost due to failure to notify.

Logic – In and Out

All activities must have logic; however, it is paramount that the logic is assigned correctly.

Every activity must start from a predecessor and must finish with a successor link, which closes out the logic link between activities. This is known as ‘in and out’ logic.

Every activity must start and subsequently must finish. When assigning only a start-to-start logic to an activity, the finish has no logical successor and therefore the project critical path will be faulty and if delays occur then the overall duration will not extend. The result is a failure to show any effect of a potential relevant event on the programme.


Float is often misunderstood. Just because a task has Project Float does not mean there are no consequences if the task is delayed. The task may be procured or resourced to occur at a certain time and changing the time of the tasks can have consequences.

There is much debate as to whether Float should be included in the baseline/master programme. Many programmes include the critical path but turn off the float display.
This is understandable when dealing with ill-informed parties as they can tend to misuse the information.

However, in our experience, we find that these days more people are informed and many Clients view the programme networks properly. The reality is in the event of a delay and or dispute then the float will need to be considered if an Extension of Time is to be properly and fairly considered.

The essence of the float within a programme is given by the logic that is assigned to the activities of the project; based on which the programme will calculate how much total float each activity can be assigned.

An activity with high total float usually indicates missing relationships, inaccurate relationships or missing detail from the schedule in the form of additional activities, which need to be addressed and corrected to have a proper, workable baseline/master programme.

NEC terminal float

There are different types of float, and terminal float refers to a situation where a Contractor’s planned date for completion is earlier than the date by which they are obliged to complete under the contract. It does this under the NEC 3 ECC form by providing at Clause 63.3 that delay to the Completion Date is assessed as the length of time that, due to the compensation event, planned Completion is later than planned Completion as shown on the Accepted Programme.

Similar wording is found under the NEC 4 ECC form of contract at Clause 63.5, which provides that delay to the Completion Date is assessed as the length of time that, due to the compensation event, planned Completion is later than planned Completion as shown on the Accepted Programme at the dividing date.

In circumstances where planned Completion is shown as occurring earlier than the Completion Date on the Accepted Programme, there would be a period of so-called terminal float. That float is then owned by the Contractor as under NEC delay is assessed by reference to the planned Completion, not the Completion Date.

Resource Logic

Logic between tasks, like to show the intended sequence for work gangs or other resource limitation, e.g. procurement may be constrained to several packages being tendered per month.

Sometimes it is appropriate to include resource logic. This can be addressed differently from a Clients perspective if a critical delay occurs, as the Client may determine that it is the Contractor’s choice to have a low resource. When Edge act for a Client we typically try to identify this separately with the condition that delays for such tasks will not be accepted as critical delays.

Having said that sometimes resource logic can be a genuine requirement, due to site or market constraints and therefore it can be truly critical.

Baseline/Master Programme Acceptance

Under JCT the baseline/master programme is a Contract requirement and not a Contract document. For this reason, formal approval is not received from the Contract Administrator.

It is common practice that the baseline programme becomes the document that is used to produce the Monthly Report.


Under NEC the baseline/master programme is referred to as the Accepted Programme and is a Contract requirement. For approval or rejection is required. Furthermore, the Programme is updated every month and issued for acceptance as part of the Monthly Report.

Available to download here: Baseline Master Programme – A Contractor’s Nightmare

November 2021