When re-baselining is legitimate, and when it is laundering

The triggers that justify it

Four situations put a re-baseline on solid ground, and they share one property: in each of them, the thing being measured has genuinely changed, so the datum must change with it or the variance numbers become noise.

• An approved scope change with a contract variation behind it. New scope was never in the old baseline, so measuring its progress against that baseline is meaningless. The re-baseline should incorporate the variation and nothing else; scope change is the classic cover for smuggling in unrelated duration relief, so the discipline is to change only what the variation changed.
• A formally approved recovery or acceleration programme. Once the client or the board has approved a new plan of attack, performance should be managed against that plan. The key word is approved: a recovery schedule the delivery team drew up for itself and started reporting against is a self-issued pardon.
• A directed re-sequencing. When the principal instructs a change to the order of the work, access dates, or delivery strategy, the old logic no longer describes the job anyone is being asked to do.
• A phase gate the contract anticipated. Many contracts expect the programme to be re-planned at defined stages: end of design, contract award of a major package, start of commissioning. Reprogramming at a gate the contract wrote in advance is administration, and nobody serious will read it as anything else.

The trigger that never justifies it

Then there is the fifth trigger, the one that arrives dressed as one of the four: performance so far behind plan that the variance reporting has become embarrassing. BEI has been under 0.8 for six months, the missed-task list runs to three pages, and every review meeting opens with the same red wall. A re-baseline resets all of it to green overnight. Missed tasks: zero. Milestone variance: zero. BEI: recalculating from a fresh start.

That is measurement laundering. The project has not improved; the instrument has been rezeroed with the needle buried. Nothing about the crews, the productivity, the procurement, or the logic changed on re-baseline day, so the pace that produced the red wall is still the operative pace, and the new baseline will accumulate the same variance at the same rate. All the exercise bought was a quarter or two of manufactured calm, paid for with the historical record.

Experienced reviewers can smell it, usually within minutes. The tells are consistent: a re-baseline with no contract variation attached, remaining durations cut without any change in method or resource, and metrics that were deeply red the month before the reset. The practitioner's counterargument deserves a hearing here. Sometimes the original baseline really was fantasy, approved under commercial pressure, and managing against it produces variance numbers so large they stop informing anyone. That is a real situation. The answer to it is still a formally approved recovery programme with the original datum retained alongside, because a bad baseline quietly replaced is two records destroyed instead of one repaired.

The governance that makes it safe

Four mechanics separate a defensible re-baseline from a quiet one, and they cost almost nothing when done at the time:

• The old baseline is archived, never overwritten. Saving the new plan over the old baseline slot deletes evidence. Every superseded baseline stays retrievable, in the tool and in the file archive, for the life of the project and the claims period after it.
• Approval in writing from whoever consumes the reports. The party who reads the variance numbers is the party the datum belongs to. If the client, the PMO, or the board is measuring against it, their written approval is the authority to move it, and an email chain is a perfectly good instrument.
• Two-datum reporting. After the re-baseline, variance against the original contract baseline continues to be reported alongside variance against the new datum. The original answers "how are we doing against what was promised", the current answers "how are we doing against the approved plan", and both questions stay live for the whole project. A re-baseline that comes with a request to stop reporting against the original is announcing its own motive.
• A re-baseline note. One page, written the week it happens: what changed between old and new, why, under what authority, and which metrics reset as a result. Three years later, in a dispute, this note is worth more than any amount of reconstructed recollection.

Use the baseline slots deliberately

Both major tools support this discipline natively. P6 allows multiple baselines per project with assignable roles; Microsoft Project carries Baseline through Baseline 10. Capacity is rarely the problem. The slots get used ad hoc, and a year in nobody can say what Baseline 3 was for. Assign the slots meanings and hold them: one slot for the contract original, which is never touched again; one for the current approved baseline, which moves only through the governance above; and one or two working slots for what-if snapshots, clearly labelled as such so they are never mistaken for a datum. A schedule whose baselines carry names and dates in their titles is auditable at a glance. A schedule with six anonymous baselines is a deposition waiting to happen.

Reviewing someone else's re-baseline

When a re-baseline lands on your desk for acceptance, the review is a diff, not a read-through. Put the old baseline and the proposed one side by side and answer three questions from the comparison itself.

First, what moved? Every date shift should trace to the stated trigger. A scope variation in the fit-out has no business moving dates in civils, and when it does, something else came along for the ride. Second, was scope added or logic rewritten? Added tasks should reconcile against the variation register line by line. Logic edits are the subtler risk: a handful of removed links or relaxed lags can buy weeks without touching a single duration, and only a relationship-level comparison will surface them. Third, do the duration cuts have a stated basis? Any remaining duration shorter than the old baseline needs a reason in method, resource, or scope. "To achieve the completion date" is an objective, and objectives do not compress work. If the answers to the three questions are clean, accept it. If the diff shows a broad shortening of future work with no mechanism behind it, you are looking at the fifth trigger wearing a variation number.

The serial re-baseliner

One last pattern, visible only across time. A programme that re-baselines every quarter has no datum at all; it has a moving average of its own optimism. Each reset is individually argued, sometimes even individually approved, and collectively they mean no variance number on the project reaches back further than ninety days. Ask one question of any programme you inherit: how many times has this been re-baselined, and can I see each superseded baseline? The count and the archive tell you more about the project's reporting culture than any current metric, and if the archive cannot be produced, treat every green number in the pack accordingly.