Baselines: the discipline that decides whether you can prove anything

A baseline is the contract's memory. Keep it properly and every delay conversation starts from an agreed record of what was promised. Lose it — or quietly rewrite it — and every variance discussion becomes archaeology: digging through emails and old PDFs to reconstruct what the plan used to say.

Why the baseline is the whole game

Delay is a comparison. You cannot be late in the abstract; you can only be late against something. The baseline is that something — the approved statement of intent against which every subsequent fact is measured. Which means the entire edifice of progress reporting, earned value, extension of time entitlement and forensic delay analysis rests on a single question: does an agreed, intact, dated baseline exist?

In our experience the answer is "sort of" depressingly often. There is a baseline, but three versions of it circulate. Or it was approved, but the approved PDF doesn't match the XER anyone can find. Or it exists, pristine — and the live programme has been re-baselined four times since, informally, so nothing measured against it means anything. Each of these is survivable on a project that goes well. None of them is survivable in a dispute.

What a proper baseline actually is

Not just the first programme submitted. A baseline worth the name has four properties:

• Approved. Formally accepted under the contract mechanism, with the acceptance recorded and the exact electronic file — the XER or MPP, not a PDF of it — identified and archived. The PDF shows what the dates were; only the native file shows the logic that produced them.
• Logic-complete. A connected network that can actually calculate: no significant open ends, leads, lag abuse or constraint scaffolding. A baseline that fails the 14-point check badly is a weak foundation for any later argument — including yours.
• Achievable. Durations and sequence a competent contractor could deliver. A baseline built to win the tender rather than to build the job will be attacked on exactly that ground later — "the as-planned was never achievable" is the first arrow in every defending expert's quiver.
• Resourced as required. If the contract demands resource or cost loading, loaded; if not, at minimum sanity-checked against the resources actually planned. Unresourced durations are assertions, not estimates.

It should also come with a schedule basis document: a short narrative recording the assumptions the programme was built on — calendars and working patterns, access and possession dates, procurement lead times, weather allowances, the intended critical path. Ten pages written in week one are worth a hundred pages of expert reconstruction in year three, because they prove what was intended, not merely what was drawn.

Re-baselining: the legitimate version and the quiet one

Baselines are allowed to change. A major scope variation, an agreed acceleration, a compensation event that restructures the works — at some point measuring against the original intent stops being informative, and the contract's change mechanism exists for exactly this. The legitimate version has three features: it is formal (instructed or agreed under the contract), it is rare (a handful of times across a multi-year project, not quarterly), and it is non-destructive — the superseded baseline is archived, the changes from it are documented, and the audit trail from BL0 to BL1 is reconstructable.

Then there is the version teams actually do. The update is looking ugly, the variance column is embarrassing, and somewhere around Thursday afternoon the "baseline" quietly becomes last month's forecast. Reported variance returns to nearly zero. Everyone relaxes. Next month, the same again. This is the rolling baseline, and it is one of the five scheduling sins for good reason: it is not measurement against intent, it is measurement against last month's failure — a ratchet that converts accumulated delay into permanent amnesia.

Update discipline: the unglamorous part that wins later

A baseline only proves anything in combination with honest periodic updates. The mechanics are not difficult; they are merely relentless:

• Move the data date every period. An "updated" programme with a stale data date is a forecast issued from the past, and every date in it is quietly wrong.
• All actuals behind the data date, all forecast ahead of it. Actual dates recorded in the future, or remaining work scheduled in the past, are exactly what the DCMA invalid-dates check exists to catch — and each one is a small documented untruth in your own record.
• Status from records, not optimism. Actual starts and finishes from site diaries and inspection records, not from what the subcontractor reckons in the corridor.
• Keep a narrative log of changes. Every period: what logic changed, what durations changed, why. P6 will not remember your reasons for you, and "why did the critical path move in update 7?" is a question someone will eventually ask under oath-adjacent conditions.
• Archive the native file every period. The XER, immutable, named consistently, somewhere it cannot be overwritten. Storage is free; reconstruction is not.

Why forensic analysts treat good updates as gold

When a dispute arrives, the analyst's first request is always the same: the approved baseline and every periodic update, native format, in sequence. The reason is that the most credible delay analysis methods — the observational ones, including windows analysis — work by reading what the programme actually recorded at the time, window by window. They live or die on update quality. Contemporaneous updates are persuasive precisely because they were created before anyone knew what they would need to prove: a programme statused honestly in month 9 is testimony from a witness with no motive.

The alternative is reconstruction — building a retrospective as-planned versus as-built from diaries and photographs — which is slower, costlier, and permanently vulnerable to the charge that it was assembled with hindsight by a party who knew the answer it wanted. Every period you skip an update, or roll the baseline, you push your future self one step further down that road.

The fan of truth: variance as evidence, not embarrassment

Plotted over time, an honestly maintained programme produces a characteristic picture: the baseline holds still, the periodic forecasts drift away from it, and the gap between them widens — a fan opening period by period. Planning teams instinctively hate this picture because it looks like failure. Forensic analysts love it, because it is the opposite of failure: it is a dated, machine-readable record of when the delay arrived, how fast it grew, and what the team believed at each moment. The fan is the evidence.

The same picture works prospectively as an assurance tool. Trending successive revisions — completion forecast, critical path composition, median float, quality score — tells you things no single snapshot can: whether slippage is accelerating, whether the critical path is stable or churning, whether the programme's structural quality is decaying under update pressure. A schedule whose 14-point score deteriorates update after update is a leading indicator of a project heading somewhere expensive. Multi-revision trending is precisely what our Time Machine feature was built to automate, because doing it by hand across a dozen XERs is nobody's idea of a productive afternoon.