Why Baseline Acceptance Should Go Beyond Document Reviews
What has been accepted when every discipline has accepted its own document?
The familiar pattern for Baseline evaluation is for each technical discipline to review its respective area and provide a sign-off: Planning, Cost, Construction and Risk reviews culminating in a series of green lights for Baseline acceptance. Yet we also know that significant flaws can survive this process and follow the Baseline into live construction, somehow missed during assessment.
This article explores why that happens. Each Baseline document represents a different projection of the same underlying project position. Testing those documents individually is necessary, but so is testing the relationships between them. Specific checks for misalignments, contradictions and omissions can transform the value of the Baseline when it really matters: during Change, Claims and routine performance management, supporting better decisions, better Earned Value analysis and ultimately better project outcomes.
Separate reviews establish separate positions
The programme sets out what is intended to happen and when. The cost baseline records what has been allowed and at what cost. Scope and design define the work required, while the construction methodology explains how the work is intended to be delivered.
Risk evidence qualifies that proposed delivery position. Assumptions and exclusions establish conditions and boundaries on which it depends.
A planner can examine logic, calendars and durations. A cost manager can test quantities, rates and the build-up of the estimate. Those reviews establish valuable grounds for confidence in the individual positions.
They do not necessarily establish that the positions agree.
Suppose the programme represents 1,000 units of work while the cost baseline prices 1,400. The programme may calculate its durations correctly for 1,000 units. The estimate may correctly calculate the cost of 1,400. Their internal correctness leaves the quantity difference unexplained.
There may be a legitimate explanation. There may also be omitted work. Acceptance needs to distinguish between those possibilities.
A separate example concerns delivery method. The programme assumes two workfaces operating concurrently, while the construction methodology provides for only one. Both documents may pass their individual reviews, but the feasibility of the planned sequence remains unresolved.
A collection of acceptable documents does not necessarily constitute an acceptable baseline.
The differences become part of the assurance task
Reconciliation establishes whether the positions are compatible. Reviewers need to identify the work being compared and understand its scope boundary, measurement basis and applicable revision.
Agreement does not always require identical figures. Purchased quantities may include waste or spares that installed quantities exclude. Commercial and delivery structures may group the same work differently. Reconciliation explains legitimate differences and establishes whether each representation is appropriate.
Other differences expose a contradiction. If procurement shows delivery of a long-lead item after the programme requires its installation, an explanation alone is insufficient. One or both positions must change.
The task is to establish a defensible relationship between the positions, rather than simply make their figures match.
Where the repository's answer ends
A controlled repository establishes what evidence exists, which revision applies and what review record accompanies it. These controls are necessary to ensure that reviewers examine the intended submission.
They do not establish whether its contents agree.
The repository can hold an approved programme and procurement schedule without demonstrating that the delivery dates support construction. It can preserve an exclusions register without establishing whether the supposedly excluded work remains within the programme or cost baseline.
Repository completeness and baseline integrity are different tests.
Examining those material relationships changes what is being assured. The reviewer is no longer assessing a collection of documents independently, but how they function together as a system representing one intended project.
The baseline establishes a network of connected positions. A completion date depends on a sequence. That sequence depends on access, resources and deliverables. The cost position may depend on the same quantities, methods and assumptions.
The relevant connections are those whose failure would materially alter the position being accepted. A shared package code may help locate related information, but compatibility must still be examined.
What the examination needs to establish
Reconciliation alone cannot establish a defensible baseline.
Two documents can agree because both omit the same scope. They can use the same unsupported productivity assumption. They can contain consistent figures whose source cannot be recovered.
A defensible baseline therefore needs to demonstrate four properties.
Complete.
The baseline represents the intended scope and lifecycle, including material interfaces and completion requirements. The appropriate depth of detail will depend on project maturity, but later-stage obligations cannot disappear simply because the immediate planning focus lies elsewhere.
Credible.
The individual positions have a defensible basis. Quantities, durations, rates, methods and treatments are supported by evidence and appropriate professional scrutiny. Agreement between documents cannot make an unsound assumption credible.
Reconciled.
Material relationships have been examined, legitimate differences explained and contradictions resolved. Evidence is reconcilable when it is sufficiently defined to compare. It is reconciled when that comparison establishes compatibility. An unresolved contradiction remains a limitation even when it is clearly recorded.
Traceable.
A reviewer can follow a material position to its supporting evidence and recover the relevant revisions, assumptions and reconciliation decisions. An explanation accepted during a workshop must remain accessible when others revisit the baseline.
These properties support one another without being interchangeable. Traceability can expose an unsupported assumption but cannot validate it. Reconciliation can establish agreement without proving completeness.
Baseline assurance therefore examines whether the intended project is represented completely, whether its principal positions are credible, whether their material relationships have been reconciled, and whether the supporting evidence is traceable.
Acceptance should make the baseline a defensive tool, not a liability
At acceptance, the review must establish which scope, quantities, methods, assumptions and provisions form the agreed project position.
That matters because the accepted baseline will subsequently be relied upon. Progress will be measured against it. Forecasts will use it as their starting point. Change will be assessed against what was previously included. Delay, disruption and contractual claims may require stakeholders to establish what had originally been planned, allowed for or assumed.
A well-assured baseline is therefore a defensive tool for project stakeholders. It provides an evidenced position against which subsequent events can be understood and decisions can be made.
A poorly assured baseline can do the opposite. An unexplained quantity difference, incompatible delivery assumption or unresolved scope boundary does not disappear when the documents containing it are accepted. Acceptance can instead embed that ambiguity into the project's control position, leaving stakeholders to resolve it later when time, cost or contractual consequences have already arisen.
The Baseline Book provides the opportunity to make the accepted position explicit. It need not reproduce every source, but it should establish the evidence relied upon, the material relationships examined and the basis on which significant differences were accepted or resolved.
Where a material relationship remains unresolved, the acceptance decision must address the resulting limitation. Approval of the documents containing a contradiction cannot resolve the contradiction itself.
The objective is not simply to demonstrate that the required documents have been reviewed. It is to establish a baseline position that project stakeholders can confidently rely upon when the project inevitably moves away from the assumptions on which that baseline was built.
That is the difference between accepting a repository of documents and accepting a baseline as a system.