Everybody performed.

The date that was never a promise

The April handover came from the integration model. Last week built that model and was clear about what it is: a network of milestones held by project controls, maintained monthly, and useful precisely because it calculates.

What it isn't is a contract document. The civil contractor never signed up to April. Their contract has a completion date for their own works, and it is in May, and they hit it.

So the sequence everybody has been working to for a year rests on a date with no obligation behind it. Every party could see the date. Every party planned around the date. Nobody was bound by the date, and the one party who could have been bound by it was never asked.

Access is a supply with an unusual supplier

It helps to treat access the way Reporting Week 6 treats material: something the work needs, that arrives from somewhere, with a lead time and a source.

Every other supply comes from somebody with an obligation to deliver it. Material comes from a supplier under a purchase order. Drawings come from engineering under the contract. Labour comes from your own organisation.

Access, on a multi-package job, comes from another contractor who has no obligation to you at all. It is the only input to your work that is produced by a party you can't instruct, can't chase and can't claim against — and the only route to it, as week 5 established, runs through the employer.

Which means the readiness test from Reporting Week 9 behaves differently here. Drawing, material, plant, labour and permit all have somebody to chase. Access has a party who is entitled to ignore you.

Space as a resource nobody allocates

The second version of the problem isn't sequential at all.

Two packages need the same area in the same week. Both scopes are clear, so this isn't the gap from week 10 — both parties know exactly what they are building and both are entitled to be there.

Under one contract this is resource levelling and the contractor resolves it, because both crews work for them. Across contracts there is no mechanism at all. Neither party can be told to wait by the other, and neither has any reason to volunteer.

It is resolved in practice by whoever is more senior, more aggressive, or further along — which is to say it is resolved, and the cost of resolving it lands on whoever gave way.

Turning a sequence into an obligation

The fix isn't a better programme. It is putting the programme's critical assumptions into the contracts, and it has to happen at award.

Take the interface milestones from the integration model — the handovers, the dates one party needs an area released to another — and write them into each package contract as dates that party is obliged to meet or entitled to receive. Not the whole model. The twenty or thirty handovers the sequence actually depends on.

What that does is convert a shared expectation into an obligation with a mechanism behind it. The civil contractor with an April access date in their contract who finishes in May has breached something, and the ordinary machinery applies. The same contractor with only a May completion date has not.

The wording carries as much of this as the date does, and week 12 has the shape to copy. A bare date leaves the employer arguing breach in the ordinary way when it is missed, which is harder than it sounds: a missed handover looks a great deal like a partial completion, and a contract already carrying damages for late completion is a poor place to argue about a completion nobody defined.

A date tied to a stated condition, with the employer's recovery limited to the extra cost of having the work done by somebody else, avoids that. It is easier to enforce, and — the part that matters to a week arguing this has to be priced rather than imposed — it is easier for a contractor to accept, because the exposure it is being asked to take on has a ceiling it can see.

It also changes the price, and it should. A handover obligation is a real risk transfer and a contractor is entitled to price it. That is the trade, and it is a considerably better trade than discovering the gap in April.

What to do on a job already let

Most projects are past the point where that is available, and the honest answer is that the exposure can't be closed retrospectively.

What can be done is to know where it sits. Go through the integration model and mark every handover that isn't backed by a date in somebody's contract. Each one is a point where the programme depends on goodwill.

That list is worth more than it looks. It tells the employer where their integration risk actually is, in specific dates rather than in principle. It tells you which handovers to watch weekly rather than monthly. And when one of them slips, the conversation starts from a position that was documented in advance rather than reconstructed afterwards.

System design

Two columns on one list do most of the work here: the date the programme assumes, and the date somebody is actually obliged to meet.

Record	Produced by	Required quality	Verified against	Feeds
Handover list	Project controls	Programme date and contractual date side by side	Each package contract	Which handovers are backed
Unbacked handovers	Project controls	Marked explicitly, not implied by absence	The integration model	Employer’s risk position · watch list
Access obligation	Contracts, at award	A date the party must meet or is entitled to receive	The contract itself	Entitlement when it slips
Shared-area conflicts	Construction	Where two packages need the same space in the same week	The look-ahead	Sequencing decisions · cost

The second row has to be explicit. A handover with no contractual date behind it looks identical on a programme to one that is fully backed, and the difference only becomes visible on the day it slips — which is the day it is worth nothing.

Practical insight

Take the next three handovers your own work depends on and, for each, find the date in the other party's contract.

Not the date in the programme — the date in their contract. You may have to ask your commercial team, and on some projects you will be told it isn't available to you, which is itself informative.

Where their contractual date is later than the date your sequence assumes, you have found a delay that is going to happen and that nobody will have caused. Raise it now, in writing, while it is a programme risk with time to plan around. In April it is an argument about who pays, and you will lose it, because everybody will have performed.

Key takeaways

• A party can meet every contractual date and still be the reason another party lost three weeks.
• The integration model calculates and isn't a contract document. Nobody is bound by a date in it.
• Access is a supply whose supplier has no obligation to you and can't be chased or claimed against.
• Of the six readiness tests, access is the one with a party entitled to ignore you.
• Two packages needing the same area is a resource conflict with no allocation mechanism across contracts.
• Under one contract that is levelling. Across contracts it is settled by seniority and paid for by whoever gave way.
• Write the twenty or thirty critical handovers into the package contracts as obligations, at award. It changes the price, correctly.
• On a job already let, mark every handover not backed by a contractual date. That list is the integration risk in specific dates.
• Write the date with a condition attached and a bounded recovery behind it. A bare date leaves the employer suing for breach, and a contractor with no ceiling to price.

Records born here. The handover list with each party’s contractual date beside the programme date · the unbacked handovers, marked · the shared-area conflicts and who gave way.

What is coming next

Access comes from another contractor. The other thing that stops work comes from further away still, and its date is set by a factory nobody on the project has visited.

Next week: procurement on the critical path, and what happens when the driving path runs through an order.