A picture of a programme.

Four things that don't line up

The reasons are mundane and they compound.

Detail. A link from a three-week summary bar to a two-day activity carries no useful logic. Aggregating the detailed programme up to match the coarse one throws away exactly the sequence you needed; expanding the coarse one down is inventing activities the contractor never committed to.

Data dates. Each party updates on its own cycle. Three updates taken on three different dates, drawn on one page, describe no single moment — which is the distinction Reporting Week 16 drew between a data date and a cut-off, appearing here three times at once.

Calendars. Five-day, six-day, shift work, different public holidays for a foreign contractor. The same duration produces different finish dates, so a duration copied between programmes is not the same duration.

Coding. Without a common area or system code there is no way to filter across the three, which means the integrated view can only ever be read as a whole.

Why the drawing survives

It survives because it answers the question it gets asked in the room.

At a monthly meeting somebody wants to see the packages against each other, and the picture does that adequately. It shows intent, it shows where the handovers are meant to be, and it fits on a page.

The failure appears the first time somebody asks a consequential question. A delivery has slipped by three weeks — what does that do to commissioning? The picture can't answer it. Somebody works it out by hand, in a spreadsheet, from the three programmes, and produces a number that is an opinion.

Which is Schedule Week 17's subject arriving from a new direction. A model with no logic is not a poor model. It is a diagram, and the diagram has been presented for a year as though it forecasts.

Integrate at the interface, not the activity

The version that works gives up on merging the programmes and connects them instead.

Take the boundary register from week 10 and turn each interface into a pair of milestones: one party finishes something, the other starts something, and the handover is the link between them. Do that for every boundary and the result is a network of perhaps sixty or eighty milestones covering the whole project.

That model calculates. It is small enough to maintain, it contains no activity anybody has to agree to, and it answers the consequential question directly: move a milestone and the effect on every downstream package is computed rather than estimated.

What it doesn't do is show the work. That is correct and it is the point — the work is in each contractor's own programme, which is where it belongs and where it is being managed.

What each party has to supply

Three requirements, and they belong in the contract rather than in a request.

The agreed interface milestones must appear in each party's own programme, with the agreed identifiers, so the dates can be extracted rather than transcribed. This is the one that has to be imposed at award; asking for it afterwards means asking a contractor to restructure a programme they have already been working to.

Each submission must be current to a stated data date, and the integration model has one data date of its own that every contribution is aligned to. Where a party is a fortnight behind, that is visible rather than absorbed.

And the calendar for each party must be declared, so that dates rather than durations move between the models. A finish date carries its calendar with it. A duration doesn't.

The milestone that binds

There is a contractual form of the thing this model is made of, and at least one of the standard forms carries it. It is worth knowing about, because it is the difference between a network of agreed intentions and a network of obligations.

The mechanism attaches a date not to a party finishing its own works but to the works reaching a stated condition — an area cleared, a slab available and free of obstruction, a service live. The contractor undertakes to bring the work to that condition by that date. It isn't completion and it isn't a section of the works. It is a state somebody else needs in order to start, which is precisely what the milestones above are.

What turns it from a target into an obligation is what follows a miss. Where the condition is not met by the date, and the employer incurs extra cost as a result — doing the work itself, or paying another contractor to — that cost is recoverable from the party that missed it, assessed by the contract administrator within a stated period. And that recovery is the employer's only remedy for it, which is what makes it usable rather than punitive. The exposure is bounded, so it can be argued about without becoming a claim for everything downstream.

The alternative, where there's no such provision, is the employer suing for breach in the ordinary way. That is difficult, and it is difficult for a reason worth understanding: a missed handover state looks a great deal like a partial completion, and a contract that already carries damages for late completion is a poor place to argue about a completion nobody defined.

Which also answers the position week 5 left open — the employer holding time granted under one contract and nothing to recover it with under another. This is what the recovery route looks like when somebody wrote it in before the packages were let.

Two things follow for the model. The list of milestones built above is the list that should have gone into the contracts, so producing it is worth doing even where it is already too late to impose. And where these dates do exist, the model stops being only a forecasting tool: it becomes the record of whether an obligation was met, which is a different document kept to a different standard of evidence.

Where they don't exist, and on most jobs assembled from packages let at different times they will not, the model is still worth building. The honest description of it is then that it computes consequences nobody owes anybody. That is a long way from nothing. It is just not a remedy.

Who owns the model

Not any of the contractors, since it contains their commitments to each other and each would prefer a version of it.

It sits where the interface register sits, for the same reason last week gave: project controls holds every party's programme at once and is the only function that can see all sixty milestones simultaneously.

And it carries the same limit. Owning the model is not authority to change anybody's dates. It is the ability to say, on the day a milestone moves, exactly which other parties are affected and by how much — which is the input every conversation about recovery needs and rarely has.

System design

Four records, and the first one has to be a contract requirement rather than a request.

Record	Produced by	Required quality	Verified against	Feeds
Interface milestone list	Project controls	Agreed identifiers, present in every party’s own programme	The boundary register	The integration model
Integration model	Project controls	Milestones and logic only — no activity anybody must agree	Each party’s submission	Forecast · recovery discussions
Model data date	Project controls	One date, with every contribution aligned to it	Each party’s data date	Whether the forecast means anything
Declared calendar per party	Each contractor	Working days and holidays, stated at award	Their own submission	Dates moving between models

Agreed identifiers are what turn the model from transcription into extraction. Without them somebody retypes sixty dates every month, which is both a job nobody has time for and a source of errors that surface as programme disputes.

Practical insight

Count the activities in the largest and smallest programmes you hold. If the ratio is more than about ten to one, stop trying to merge them; you are not going to succeed and the attempt is consuming your month.

Instead, list every point where one party has to finish something before another can start. The list you end up with is your integration model, and on a job with a handful of packages it runs to a few dozen lines rather than a few thousand.

Build it as milestones with logic between them and nothing else. It will take you a week. Then the next time somebody asks what a three-week slip does to commissioning, you will press a button rather than open a spreadsheet, and the answer will be the same one tomorrow.

Key takeaways

• Programmes at four thousand, four hundred and eighty activities can't be meaningfully merged.
• Three updates on three data dates, drawn on one page, describe no single moment.
• Different calendars mean a duration copied between programmes is not the same duration. Move dates instead.
• Without common coding the integrated view can only be read as a whole.
• The hand-drawn version answers the meeting-room question and can't answer a consequential one.
• Integrate at the interface: each boundary becomes a pair of milestones and a link.
• Sixty to eighty milestones calculate, maintain and forecast. They deliberately don't show the work.
• Interface milestones with agreed identifiers have to be imposed at award, not requested afterwards.
• At least one standard form already does this: a date by which the work must reach a stated condition, so that somebody else can start.
• Its value is the bounded remedy behind it — the extra cost the employer incurs having others do the work, and nothing beyond that.

Records born here. The interface milestone list with agreed identifiers · the integration model and its own data date · each party’s declared calendar.

What is coming next

A milestone model shows which parties are affected when a date moves. It doesn't say whose delay it was, and on a multi-package job that question has an uncomfortable answer.

Next week: access, sequencing, and the delay that belongs to no one.