The evidence nobody thought to keep.

The evidence nobody thought to keep.

Of everything a project produces, the programme update is the strangest document. It is treated as an administrative chore, produced by one person under time pressure at month end, circulated to people who look at the bar chart and nothing else, and then filed.

It is also the only document on the job that records what the project believed at a moment when it still had to guess.

Everything else in Phase B looks backwards. The baseline is an intention written before anything happened. The as-built is a reconstruction assembled once everything had. The update sits in the middle, made by people who knew what had gone wrong so far and did not yet know how it would end. That is what makes it worth more than either.

What only an update can tell you

Week 4 established that criticality belongs to a moment. Week 7 established that as-built logic is inferred rather than recorded. Put those together and there is one question neither the baseline nor the as-built can answer: which path was driving in March?

The March update answers it directly, because somebody calculated it in March. Without that file, the answer has to be reconstructed from an as-built whose logic is already an inference — an inference on top of an inference, and both of them made by a party with an interest in the outcome.

This is not a marginal improvement in evidence. It is the difference between a fact and an argument, repeated for every month of the job.

What the contract actually asks for

Most teams update monthly out of habit. That is a reasonable habit, but it isn't what the contract says, and the difference matters in the months when things move.

Under the 2017 Red Book the trigger for a revised programme is not a date in the calendar. It is a condition. A revision falls due once the existing programme no longer gives an accurate picture of where the works have got to, or has drifted out of line with what the contractor is obliged to be doing. Something significant goes wrong in the second week of the month, and the obligation arrives with it rather than waiting for month end.

Then the mechanism Contract Week 11 set out takes over. If the Engineer says nothing within the review period, no-objection is deemed and the revision becomes the Programme.

And there is a consequence that gets almost no attention: the employer's people are entitled to rely on the Programme in planning their own activities. Your update is not merely a record of what you thought. It is a statement the other side may act on, and later point to.

One more detail, easy to overlook and expensive later: the contract requires an electronic copy, not only paper. That obligation is the reason the native files should exist — and the reason it is worth asking, in month two, whether anybody is actually keeping them.

Four ways the series is destroyed

An update series is fragile in ways that don't look like damage while they are happening.

Re-baselining is the most damaging and the most defensible-sounding. The programme has drifted so far that it is useless for managing the work, so a new baseline is issued and everyone moves on. Operationally that is often the right call. Evidentially it draws a line: the history before it has been replaced by a document that shows the new plan as though it were always the plan.

Retrospective editing is quieter. Last month's actual start was wrong, so it gets corrected in this month's file. Nobody records that it was changed. Two years later the update series contains no contradictions at all, which is itself a slightly suspicious property for thirty months of construction.

Missing months follow a cruel pattern. Updates get skipped in the periods when everybody is too busy — which are the disrupted periods, which are the periods a claim will turn on.

PDF-only retention is the most common of the four. The picture survives and everything that makes it analysable does not: no logic, no float values, no calendars, no way to re-run anything.

The setting that changes last month's answer

There is a fifth failure, more technical than the four above and harder to spot, because it lives in a dialog box rather than in a decision.

Work on site rarely follows the logic exactly. Something starts before its predecessor finished, and the software has to be told what to do about it. Depending on the setting chosen, it will either honour the original logic and push the remaining work out, or accept what happened and let the work proceed. The two produce different forecast completion dates from identical progress.

Neither setting is wrong. What causes damage is changing it partway through a job, because the update series then contains two kinds of month and nothing records which is which. An analysis run across that boundary is comparing answers produced by different rules and reporting the difference as delay.

The instruction is the same as everywhere else in this phase: pick a convention, write it down, apply it every month, and note it if it ever changes. None of this is difficult while a job is running. All of it is impossible afterwards.

What the gaps do to your options

Phase C opens next week with a choice of methods, and this is the point at which that choice narrows.

Methods that analyse the job period by period run directly on the update series. No updates, no periods; the technique simply isn't available. Methods that model an event into the programme as it stood at the time need the file as it stood at the time, for the same reason.

What remains, if the series has holes, are the methods built from the as-built alone — and those carry every inference Week 7 described. The update series is therefore not a nice-to-have record. It is the thing that decides how good an answer you are allowed to give.

The one that was never issued

A final case, and it comes up more than it should.

Sometimes a revision was prepared, was never submitted, and sits on a server. It shows the job as the planner saw it, honestly, and it may be the best contemporaneous evidence available.

It is also not the Programme. It went through no review, attracted no deemed acceptance, and the other side never had the chance to object to it or rely on it. It can support a narrative. It cannot carry the contractual weight of a submitted revision, and presenting it as though it can is the kind of error that costs credibility on everything else in the file.

Practical insight

Go and find every programme file your job has issued, and list them by date with two columns: was it submitted, and do we still have the native file.

Most teams doing this discover three things within an hour. There are months with no revision at all. There is at least one point where the baseline changed and nobody wrote down why. And a proportion of what survives is PDF only, usually the older ones, usually from the period that matters.

Then fix the going-forward half, which is cheap: one folder, one file per submitted revision, native format, never edited after issue, named by status date. Nobody tidies it and nobody works in it.

The backward half is harder, and worth an afternoon anyway. Native files that still exist on a laptop or in an email attachment can be recovered now. In two years the laptop is gone and the mailbox has been archived by somebody applying a retention policy that has never heard of your claim.

Key takeaways

✔ The update is the only document recording what the project believed while the outcome was still unknown.

✔ Which path was driving in a given month is answerable from that month's update and, without it, only by inference.

✔ FIDIC ties revisions to a condition rather than a calendar: the picture going out of date is itself what makes one due.

✔ Each accepted revision becomes the Programme, and the employer's people are entitled to plan around the dates in it.

✔ The contract asks for an electronic copy, which is the contractual basis for keeping native files rather than printouts.

✔ Re-baselining, silent retrospective edits, skipped months and PDF-only retention each destroy the series in a way that cannot be repaired later.

✔ A revision that was prepared but never submitted is evidence of what you thought, not a contractual document, and it must not be presented as one.

What's coming next

Phase B ends here, and with it the evidence. You have a baseline and know what it is worth, a record of what happened, an as-built built from it, and a series of updates with whatever holes it has. Next week the track turns to methods — and opens with the question that decides everything that follows: not which technique is best, but which ones your records have left open to you.