Why an Approved Baseline Can Still Be a Poor Control Baseline

“The baseline is approved” is said as if it settles the matter. It settles one matter — the contractual one — and leaves another one open. Contractual acceptance and control usefulness are different questions, and a baseline can pass the first while failing the second.

There are really three separate things being asked of a baseline, and they do not automatically come together.

Contractual acceptance. Has the programme been submitted and accepted under the contract? This is a governance step — important, and not to be undermined. But acceptance usually turns on procedural and scope compliance within a review period, and a programme can satisfy that and still be technically weak. Acceptance is a status, not a certificate of quality.

Technical quality. Is the programme sound as a network? Is the logic complete, are constraints minimal and justified, do the durations and sequence reflect how the job will be built, does the critical path make engineering sense? A baseline can be accepted and still be riddled with open ends, hard constraints driving the dates, and a critical path running through improbable activities. Acceptance does not test most of this, and it is entirely possible to have an approved programme that no competent planner would call sound.

Management usefulness. Even a technically sound, accepted baseline can be a poor control baseline. Can you actually measure progress against it in a way that means something? Is it coded so exposure can be sorted and rolled up? Is it at a level of detail that supports decisions rather than drowning them? A programme built to win acceptance is not always a programme built to run the job — and the two purposes pull in different directions.

The trap is treating acceptance as if it answered all three. Once a baseline is approved, it becomes the reference everything is measured against — variance, delay, entitlement, recovery. If that reference is weak, every measurement made against it inherits the weakness, and no amount of careful downstream analysis fixes a flawed starting point. I have reviewed delay analyses that were technically competent and still unpersuasive, because the baseline underneath them could not bear the weight.

So I keep the questions separate. I respect the contractual position — acceptance matters and I do not undermine it. But I assess the technical quality and the control usefulness on their own terms, and where an accepted baseline is weak as a control instrument, I say so plainly, early, and constructively — because it is far cheaper to strengthen the reference at the start than to discover, eighteen months in, that everything was measured against a programme that could not carry it.

The takeaway: an approved baseline is not automatically a good control baseline. Acceptance, technical quality and management usefulness are three questions, and the job is to answer all three — not to let a status stand in for the other two. The tests I apply are in the Baseline Review Checklist, Baseline Integrity and the Director’s Playbook.