Construction Claims
The SCL Protocol, in Practice · Part 5 of 24
The Baseline Programme: Where the Conversation Starts
The baseline is the agreed starting line against which every later delay is measured. If it isn't realistic, logic-driven and — ideally — accepted under the contract, it can't carry the weight of a delay analysis. A programme you emailed once is not automatically a baseline, and a baseline propped up by constraints is a date, not a plan.
The baseline is the agreed starting line against which every later delay is measured. If it isn’t realistic, logic-driven and — ideally — reviewed and accepted under the contract, it can’t carry the weight of a delay analysis. A programme you emailed once is not automatically a baseline, and a baseline propped up by constraints is a date, not a plan.
The construction-site version
Everyone’s arguing about who finished late — but nobody agreed where the race started. One party waves the tender programme; the other says it was never accepted and was unbuildable anyway. Before you can measure a single day of delay you need a starting point both sides recognise.
Skip that step and the delay analysis quietly turns into an argument about the baseline instead of the delay. You never actually get to the question that matters, because you can’t agree the ruler you’re measuring with.
The technical bit
A baseline programme is the Contractor’s planned intent for executing the works — activities, durations, logic and sequence — usually submitted under the contract and, in good practice, reviewed and accepted (or at least not objected to) by the Contract Administrator or Employer. The Protocol treats a properly prepared programme and good records as the foundation of everything (Core Principle 1). “Properly prepared” means realistic durations, complete logic (few or no open ends), a sequence that reflects how the job will actually be built, and constraints kept to a justified minimum.
The danger sign is a baseline whose completion date is forced by a mandatory-finish constraint, or held together with negative lags — that hides the real logic, so when delay hits, the programme can’t show cause and effect. Acceptance matters too: submission is not acceptance, and the contract usually defines what “accepted” means and what evidential weight the programme carries. Agree the baseline early and later disputes are about the delay; leave it vague and every analysis starts with a fight about the starting point. This is exactly what Baseline Integrity sets out to test before the dates are trusted.
”I submitted my programme, so that’s the baseline.”
Under most contracts a baseline needs review or acceptance, and its evidential weight depends on being realistic and logic-driven. A submitted-but-unaccepted, or constraint-propped, programme may carry little weight.
Audit constraints (mandatory start/finish, start-on, finish-on) and treat a completion date held by a constraint as a red flag. Count open ends and dangling logic; look for negative lags substituting for real relationships; check that durations are resourced and realistic rather than reverse-engineered to hit a date; and confirm the baseline is actually set as a baseline you can compare updates against — see baseline vs current programme.
Evidence check
The submitted baseline and any revisions; the contract’s programme clause; correspondence showing review, acceptance or objection; the method statement or basis behind durations and sequence; and the constraint log. Relevance always depends on the facts and the contract.
Rishi’s takeaway
- The baseline is the agreed starting line — without it, delay is unmeasurable and every analysis is contestable.
- Submission is not acceptance, and acceptance is not a guarantee of realism. Know which you have.
- A completion date forced by a constraint is a date, not a plan — and it won’t survive a delay analysis.
- Get the baseline realistic, logic-driven and reviewed early; it’s the cheapest insurance on the job.
If nobody agreed where the race started, arguing about who finished late gets interesting very quickly.
References. Society of Construction Law, Delay and Disruption Protocol, 2nd Edition, February 2017 — Core Principle 1 (programme and records), including the preparation, submission and acceptance of the baseline programme. What “acceptance” means, and the weight a programme carries, depend on the contract and the governing law. Educational commentary; not legal advice.
Common questions
What is a baseline programme?
The Contractor's planned intent for executing the works — activities, durations, logic and sequence — usually submitted under the contract and, in good practice, reviewed and accepted. It is the agreed starting line against which delay is measured.
Is a submitted programme automatically the baseline?
No. Submission is not acceptance. Under most contracts a baseline needs review or acceptance, and its evidential weight depends on being realistic and logic-driven; a submitted-but-unaccepted programme may carry little weight.
Why is a constraint-forced completion date a problem?
A completion date held by a mandatory-finish constraint is a date, not a plan. It hides the real logic, so when delay hits the programme can't show cause and effect — and it won't survive a delay analysis.
What makes a baseline reliable?
Realistic durations, complete logic with few or no open ends, a sequence reflecting how the job will actually be built, constraints kept to a justified minimum, and review or acceptance under the contract.
Can an accepted baseline still be challenged?
Yes. Acceptance is not a guarantee of realism; the baseline's realism can still be tested on the facts.
Related