Approving a Baseline Programme: What to Check Before You Sign It Off

A baseline programme becomes the measuring stick for every delay argument on your project. Most owners accept one that cannot measure anything.

The baseline programme is the version of the schedule both sides agree to measure against. Once accepted it decides who is late, which activities matter and what a change is worth. An owner who accepts a coloured bar chart because it looks organised has given up the ability to prove anything, because bars without logic cannot show what caused a delay.

Why these keep happening

These mistakes share one root: the programme is treated as a presentation rather than a model. A presentation shows intention. A model shows consequence, which is what you need when an activity finishes six weeks late and somebody has to explain why the completion date moved with it.

1. Accepting bars with no links between them

The document looks like a programme, so nobody asks whether the activities are logically connected.

• Avoid it by: Require a linked programme where each activity has predecessors and successors, and ask to see the critical path highlighted.
• Proof it is closed: A programme file that recalculates the completion date when a delay is entered into it.

What it costs you: When one activity slips, nothing moves automatically, so the effect on completion becomes a matter of opinion rather than calculation.

2. Activities so long that nothing can be measured

A single bar labelled finishes covering eight months is quick to draw and impossible to argue with.

• Avoid it by: Cap activity durations so that each one can be verified within a single reporting cycle, and break finishes down by floor or zone.
• Proof it is closed: No activity longer than one reporting period on the critical path.

What it costs you: Progress reporting becomes a percentage somebody invents, and the slippage hides until the last quarter.

3. Procurement left out of the programme

The contractor programmes construction work and treats ordering as an internal matter.

• Avoid it by: Require long lead items to appear as activities, with approval, fabrication, shipping and delivery shown separately.
• Proof it is closed: A procurement schedule inside the programme, linked to the activities that need each item.

What it costs you: A lift, a switchgear set or a facade system arrives late and stops a sequence that the programme said was safe.

4. Owner obligations missing from the model

The programme shows only what the contractor does, which feels natural because the contractor drew it.

• Avoid it by: Insist that every date depending on you appears in the programme, with the number of days you are allowed for each approval.
• Proof it is closed: A list of owner dependencies extracted from the programme and agreed as achievable.

What it costs you: Your own decisions, approvals and free issue items become invisible until they are used against you in a delay claim.

5. No float anywhere, or float hidden everywhere

A programme with zero float looks efficient, and a programme padded throughout looks comfortable.

• Avoid it by: Ask where float sits and how much there is, then agree in writing who is allowed to consume it.
• Proof it is closed: A float statement listing total float on the main paths at baseline acceptance.

What it costs you: With no float, every minor event becomes a claim. With hidden float, real slippage is absorbed silently until it is too large to recover.

6. Ignoring the calendar the programme actually uses

The working calendar sits in a settings menu that nobody opens.

• Avoid it by: Review the calendar, the assumed working week, holidays and any restrictions on hot weather working before acceptance.
• Proof it is closed: A written statement of the calendar assumptions attached to the baseline.

What it costs you: A programme built on an unrealistic working week or ignoring seasonal constraints on certain activities is already wrong on day one.

7. Accepting the programme after work has started

Nobody wants to hold up mobilisation over a document, so acceptance drifts.

• Avoid it by: Tie acceptance of the baseline to an early payment so that the document arrives while it still describes the future.
• Proof it is closed: A dated acceptance of the baseline issued before the second valuation.

What it costs you: The contractor issues a first programme reflecting progress already made, which quietly moves the yardstick in their favour.

A short check before you sign

• Does entering a delay into the file move the completion date automatically?
• Can every critical activity be verified within one reporting cycle?
• Are long lead items shown with approval, fabrication and delivery separated?
• Does the programme name every approval and decision that depends on you?
• Is total float stated, and is it clear who may use it?
• Do the calendar and working week assumptions match reality on this site?

If it has already happened

If work is already running against a programme you never properly accepted, do not argue about the past. Ask for a current updated programme with logic, procurement and owner obligations included, accept it as the measuring point from today, and record in writing that the earlier document was never agreed as a baseline. A programme accepted late is still far better than a project measured against nothing, and your legal position on any existing delay should be checked with a licensed adviser before you sign anything that could be read as a waiver.

Domira designs, builds and manages projects across Saudi Arabia for owners who are based abroad: land appraisal, feasibility, design, construction, handover and asset management under one accountable contract. Send us the plot or the brief and Domira will put the numbers in front of you before you commit.