The programme pinned to the cabin wall is dated March. It is now the middle of June, the groundworks sequence changed twice in April, and the only person who knows what the current logic looks like is a planner who is on another job three counties away. A programme of works is the document that sets out what gets built, in what order, by when, and with what resource sitting behind each activity. Kept current, it is the most useful page on the project. Three months stale, it is decoration.
Most contractors do not have a programme problem. They have a programme maintenance problem, and the two get treated as the same thing in almost every conversation about planning software.
Programme of works, schedule or plan of works: is there a difference?
In UK usage, programme is the standard word. Schedule means the same thing and tends to arrive with American software or American clients. Both describe a dated sequence of activities with durations and logic links, and usually resource against them.
Plan of works is where it gets confusing. People use it loosely to mean the same document, but the RIBA Plan of Work is something else entirely: a framework of eight stages numbered 0 to 7, running from strategic definition through to the building in use. It tells you what phase a project is in. It will not tell you whether the steel arrives before the slab is poured.
Worth being precise about, because a client asking for your plan of works may want either.
What a construction programme has to contain
That depends entirely on the contract. NEC4 is by some distance the most prescriptive of the standard forms, and clause 31.2 sets out what a programme submitted for acceptance has to show. In broad terms:
- The starting date, planned Completion and the Completion Date, plus any Key Dates
- The order and timing of the operations the contractor plans to carry out
- The order and timing of work by the client and by others
- The dates by which the contractor needs access, acceptances, and anything the client is providing
- Provisions for float and time risk allowances, shown separately
- Health and safety requirements and procedures set out in the Scope
- The form the programme has to take, which NEC4 lets the Scope specify
JCT takes a lighter touch. Its standard forms require the contractor to provide a master programme and to keep it updated, but the master programme is expressly not a contract document and does not impose obligations beyond the ones already in the contract. Two very different philosophies, and they produce very different arguments eighteen months later.
Under NEC4, the programme is a payment mechanism
This is the part contractors underestimate. If no programme is identified in the Contract Data and the contractor has not submitted a first programme for acceptance, NEC4 allows one quarter of the Price for Work Done to Date to be retained in the assessment of the amount due, until that programme arrives showing the information the contract requires.
A quarter of the money, withheld on the certificate, on a job where the planner has not got round to it.
The project manager then has two weeks to accept the programme or give reasons for not accepting it, and NEC4 states the grounds: the contractor’s plans are not practicable, the programme does not show the information the contract requires, it does not represent the contractor’s plans realistically, or it does not comply with the Scope. Clause 32 requires revised programmes at the intervals stated in the Contract Data, and after every compensation event. Miss those revisions and the Accepted Programme, which is the benchmark every compensation event gets assessed against, drifts away from what is happening on the ground.
The programmes running on a typical job
Contractors talk about the programme as though there is one. On any job of size there are usually five, with different authors and different purposes.
| Programme | Who produces it | What it is for | How often it changes |
|---|---|---|---|
| Tender programme | Estimator or bid team | Proving the bid is deliverable and pricing the preliminaries against a duration | Once, then frozen at submission |
| Contract or baseline programme | Main contractor’s planner | The agreed benchmark for measuring progress, delay and entitlement | Only by formal revision |
| Construction or working programme | Project and site team | Running the job, sequencing trades, calling off plant and labour | Continuously |
| Short-term lookahead | Site manager | The next two to six weeks in detail, at the level a subcontractor can act on | Weekly |
| As-built programme | Commercial team | Reconstructing what happened, for the final account or an extension of time | Built after the fact |
The gap between rows two and three is where most commercial pain originates. The baseline says one thing, the site is running to another, and nobody has formally reconciled the two since the contract was signed.
Why programmes go stale
It is rarely negligence. A variation lands on a Tuesday. The site manager absorbs it, shifts the sequence, tells the ceiling contractor on the phone and moves on to the next thing, because the alternative is opening the planning software and re-logicking four hundred activities. The planner has four other jobs. The revision waits for a quiet week that does not come.
Repeat that for eleven weeks and you have a baseline nobody trusts and a working sequence nobody has written down. Then the client asks for an extension of time.
At that point the commercial team goes looking for evidence of what happened, and finds the site diary, a WhatsApp group, a folder of delivery tickets and a plant hire schedule. Reconstructing a delay narrative from that is possible. It is expensive, it takes weeks, and the resulting analysis is far easier for the other side to pick apart than a maintained programme with contemporaneous progress records behind it would have been.
Can software keep a programme current?
Partly, and it is worth being clear about which part.
What the tooling can do is reconciliation. Progress records already exist on most sites in some form: diary entries, delivery notes, plant returns, dated photographs, subcontractor applications. Reading those against the planned activities and flagging where the two have diverged is exactly the kind of tedious, repetitive comparison that machines handle well and humans skip. The output is a list of activities where the record and the programme disagree, which a planner can then work through in an afternoon instead of a fortnight.
What it cannot do is decide the logic. Whether the mezzanine steel can follow the slab or has to precede it is an engineering and sequencing judgement, and it belongs to someone who has stood on the floor. Any tool that offers to re-sequence your job for you is selling you a guess dressed as an answer.
There is a dependency worth naming here. 4D planning is only as good as the programme underneath it. Link a stale programme to a model and you get a convincing animation of a sequence nobody is following.
Common questions
Is the programme a contract document?
Under NEC4, the Accepted Programme has real contractual weight and compensation events are assessed against it. Under JCT, the master programme is required but expressly is not a contract document. Check which you signed.
How often should the programme be updated?
Monthly is the common answer, and NEC4 jobs usually state a shorter interval in the Contract Data. The more useful discipline is to revise it when something changes the logic, not only when the date comes round. A monthly cycle that captures four weeks of accumulated change in one go tends to produce a revision nobody can explain.
Who owns the programme?
The contractor. It is the contractor’s plan for carrying out the works, and a client who dictates sequence is usually taking on risk they have not priced. Clients are entitled to see it, comment on it, and under NEC4 to accept or reject it on stated grounds.
Does a stale programme weaken a delay claim?
Yes. Substantially.
What is a time risk allowance?
Contingency the contractor holds against its own risks, shown separately from float so that everyone can see it exists and who it belongs to.
Can you run a job on a lookahead alone?
Plenty of firms try, and on short fit-out packages it sometimes works. On anything with a Completion Date and liquidated damages attached, a six-week window gives you no way of proving that a delay in week three of a fifty-week job caused the overrun in week forty-eight, which is the question the whole argument turns on.
Where this leaves you
Everyone has a programme. The useful question is whether the version on the cabin wall and the version in the planning software still say the same thing this week, and whether you could prove what changed between them if you had to.
We work with contractors on the maintenance problem rather than the drawing problem: getting site records, commercial data and the programme into one place so that revisions take hours instead of weeks. More on that on our operational efficiency page for construction and fit-out firms, or book a discovery call and bring your current baseline.