What a baseline actually is
A project baseline is the reference against which variance is measured. It is not a forecast, a target, or a commitment — it is a snapshot of the agreed plan at a specific point in time, captured in enough detail that later changes can be compared against it. Every project controls function depends on a baseline; without one, there is nothing to be varying from, and every reported number is either a current position or a forecast to completion without context.
In UK practice, three baselines are typically distinct but linked: the scope baseline (what is being delivered, usually captured in a Works Information, Employer's Requirements, or equivalent), the schedule baseline (when it is being delivered, captured in the baseline programme), and the cost baseline (what it will cost, captured in the baseline cost plan or contract price). Each has its own documentation, its own change-control process, and its own failure modes. A baseline is only useful if all three are consistent with each other — a schedule baseline that does not reflect the scope baseline is a source of false variances, as is a cost baseline that does not reflect the schedule.
The quality of a baseline is tested not at the point it is approved but at the point it is used. A baseline that approved easily may turn out to be brittle under the first serious change event; a baseline that was argued over and stress-tested at approval may absorb significant change and still produce meaningful variance reporting. This guide is about what makes the second kind of baseline and how to produce one on a real programme.
The scope baseline — where most problems start
Most baseline failures begin with the scope baseline. If the scope is not captured in enough detail at approval, every subsequent baseline deliverable — the schedule, the cost, the risk register — is built on uncertain ground. The symptom is scope drift, where the work being delivered quietly expands beyond what was approved without formal change control. The cause is usually a scope baseline that was a high-level description rather than a defined list of deliverables.
On an NEC4 contract, the scope baseline is the Works Information (now "Scope" in the NEC4 revision). On FIDIC, it is the Employer's Requirements and the Contractor's Proposals. On JCT design-and-build, it is the Employer's Requirements as developed through the contractor's design. Each of these documents has a defined contractual role, and the scope baseline should be the controlled version of that document at contract award. If the scope baseline references a document that was issued in draft and never controlled, the commercial position is weaker than the project team may realise.
The test for a good scope baseline is: can a third party, picking up the documents two years later, reconstruct what was agreed to be delivered? If the answer requires reading design drawings that are not formally referenced in the contract, or relying on email correspondence to establish intent, the baseline is exposed. A defensible scope baseline explicitly lists the controlled documents that form it, with their revision numbers and dates, and references them throughout the cost and schedule baseline so that the linkage is explicit.
Scope baseline failures on major UK projects have been the subject of several NAO and IPA lessons-learned reports — and on defence programmes the same pattern shows up in Major Projects Reports, where the requirement document approved at end-of-Concept turns out at the end of CADMID Assessment to have been a description rather than a specification. The repeated theme is that scope was described rather than defined — the project knew what it was building in general terms, but the specifics were expected to emerge during delivery. Specifics that emerge during delivery are not free; they are variations, and without a defined baseline to vary from, the commercial treatment of those variations is opaque. The discipline of capturing scope to a sufficient level of detail at baseline is unglamorous but is the single largest determinant of whether the controls function can produce meaningful variance reporting during delivery.
The schedule baseline and what makes it brittle
A schedule baseline has to be buildable. This is the starting test. A programme that requires more concurrent resources than the site can accommodate, compresses design review cycles beyond what the client's governance will actually support, or relies on supply chain lead times shorter than the market can deliver is not a baseline — it is a wish. The most common reason schedule baselines are brittle is that they were not stress-tested against resources, design cycles, or supply chain realities at approval.
The second source of brittleness is artificial constraints. A programme full of hard constraints — dates imposed by the scheduling tool rather than by genuine dependencies — will not respond realistically to change. When a variation lands, the impact analysis cannot propagate through the network because the constraints absorb the change artificially. On NEC4 contracts this is particularly damaging because compensation event assessments depend on the programme's ability to show genuine impact. A constraint-heavy baseline programme produces low or zero assessed impacts on events that in reality are significant, and the contractor has to argue the programme is wrong before they can argue the assessment is wrong.
Overoptimistic durations are the third source of brittleness. A baseline that assumes activities take the minimum plausible duration, with no time risk allowance and no weather or access contingency, has consumed its schedule resilience before work starts. The first modest delay blows through to the critical path, and every subsequent event produces knock-on effects disproportionate to their actual size. The NEC4 requirement for explicit time risk allowances is specifically designed to protect against this — TRAs distributed across the programme at points of genuine duration uncertainty produce a more robust baseline than a tight programme that claims no uncertainty.
Missing activities are the fourth and hardest to diagnose. A baseline programme that covers the main works comprehensively but omits commissioning detail, handover activities, regulatory approvals, or client review cycles will produce variance every month as those missing activities are added during delivery. The additions look like scope creep but are actually baseline omissions. The best defence is to baseline at a sufficient level of detail that the major delivery phases are all represented, even if the underlying activities are placeholder summary activities that get broken out closer to delivery.
A defensible schedule baseline has: resource-aware activity durations, minimal hard constraints, explicit TRAs at points of known uncertainty, full coverage of all delivery phases including commissioning and handover, and a planned completion date that is close to the contractual completion date — with visible protection in the form of TRAs rather than hidden buffer in activity durations. This is harder to produce than a tidy, constraint-driven baseline, and harder to approve because it makes the project's uncertainty visible. It is also the baseline that survives the project.
The cost baseline — the basis of estimate is the baseline
A cost baseline is only as credible as the basis of estimate that underpins it. The basis of estimate — the narrative document explaining how the cost was built up, what rates were used, what assumptions were made, and what was excluded — is the document that makes the cost baseline defensible. Without a documented basis of estimate, the cost figures are numbers on a page with no supporting reasoning, and when cost pressures emerge during delivery there is no reference point to explain what is changing.
The basis of estimate should cover three things. First, the quantities — where they came from, how they were measured, what the confidence in them is at the point of baseline (Class 3 estimate, Class 2, etc., per AACE 18R-97). Second, the rates — whether they are historical, market-tested, benchmarked, or budgeted, and what period they relate to. Third, the assumptions and exclusions — what is assumed about scope, what is assumed about execution, what is specifically not covered by the estimate. A baseline without an exclusions list is a hostage to future scope discussions.
The second discipline in a cost baseline is separating base cost from contingency. Base cost is the best deterministic estimate of cost to deliver the approved scope under expected conditions. Contingency is the additional provision for risk and uncertainty. The two should be reported as separate numbers, with the contingency supported by a QRA or equivalent analysis. Mixing them — burying contingency inside line-item rates — produces a baseline that the cost team cannot explain when challenged and that risk-based analyses will double-count.
The third discipline is consistency with the schedule baseline. Time-related costs in the cost baseline — preliminaries, site staff, plant, finance — must reflect the schedule baseline duration. If the schedule baseline shows 18 months to completion and the cost baseline has 15 months of preliminaries, one of them is wrong. This sounds obvious and is a surprisingly common error, particularly on projects where the cost plan was produced by a different team from the schedule and the two were reconciled only at high level.
A defensible cost baseline has: a documented basis of estimate with quantities, rates, and assumptions; separated base cost and contingency with risk-based supporting analysis; time-related costs consistent with the schedule baseline; and a clear date at which the estimate is current, with inflation assumptions from that date forward. These are unexciting practices. They are also what distinguishes a baseline that will hold up under two years of change control from one that will fracture at the first meaningful variation.
Rebaselining — legitimate versus cover-up
Rebaselining is the process of replacing the existing baseline with a new one. It is sometimes necessary and sometimes illegitimate, and the difference is about why it is being done. A legitimate rebaseline responds to a fundamental change in project scope, circumstances, or funding that has made the existing baseline no longer a useful reference. An illegitimate rebaseline conceals poor performance by resetting the comparison so that accumulated variance disappears.
The clearest case for legitimate rebaselining is a scope change of sufficient magnitude that incremental change control is impractical. If a programme has been approved to deliver 500 homes and is now being asked to deliver 750 homes plus a community facility, reporting variance against the original baseline would be meaningless — the variance is not a failure of delivery, it is the delivery of a different project. A formal rebaseline documenting the new scope, schedule, and cost is appropriate. Similarly, a funding envelope change imposed by the client, or a major external event (a regulatory change, a force majeure event lasting months), can justify rebaselining if the original baseline has genuinely been overtaken.
The illegitimate cases are where rebaselining becomes a tool for hiding accumulated overrun. A project that is six months late and 20% over budget rebaselines to the current forecast, and the performance reporting in the next month shows CPI and SPI at 1.0. The accumulated variance has not gone away — it has been absorbed into the new baseline. If the rebaselining is described as "alignment with current conditions" without acknowledging the underlying cause of the variance, the project has lost the ability to report honestly on its own performance history.
The test for legitimacy is what is disclosed alongside the rebaseline. A legitimate rebaseline is accompanied by a document explaining what changed, why the original baseline is no longer useful, and what the variance against the original baseline would be if retained. The old baseline is preserved as a reference; the new baseline becomes the working comparison for future reporting, but the history is not erased. An illegitimate rebaseline quietly replaces the comparison point without acknowledging the previous variance, and the steering group loses sight of how the project has actually performed.
Under NEC4, rebaselining has specific commercial implications. The Accepted Programme is the reference for compensation event assessments, and a rebaselined programme replacing the Accepted Programme affects how subsequent events are valued. Rebaselining should only be done through the formal programme submission and acceptance process under Clause 31, not as an informal controls-team exercise. Under FIDIC, the baseline is effectively the Contractor's submitted programme under Clause 8, and rebaselining requires the Engineer's consent. In both cases, informal rebaselining without contractual recognition creates weaknesses that will be exposed if the project goes to dispute.
Change control — the thing that keeps a baseline honest
A baseline without robust change control is not a baseline; it is a historical document. The purpose of setting a baseline is to compare the current position against it, and that comparison is only meaningful if changes to the baseline are documented, controlled, and attributed. On UK programmes, change control typically operates at two levels: contractual change control (compensation events on NEC, variations on FIDIC and JCT) and project change control (internal changes that do not trigger contractual mechanisms but do change scope, schedule, or cost).
The common failure is that contractual change control is well-run and project change control is informal. Variations under the contract are documented, assessed, and recorded against the baseline. Internal decisions to expand scope, adjust the schedule, or draw on contingency happen through emails and meetings without a formal change log. Six months in, the accumulated informal changes have materially shifted the project position but cannot be tracked because they were never recorded. The remedy is a single change log that captures both contractual and internal changes, with each change showing its impact on scope, schedule, and cost, and its status (proposed, approved, implemented).
The second common failure is change control that records change but does not update the baseline. The change log grows, the changes are approved, and the baseline programme and cost plan remain as originally approved. Reported variance becomes meaningless because it includes both genuine performance variance and approved but unincorporated changes. Changes that have been approved should update the live baseline (sometimes called the "approved current baseline" to distinguish it from the original baseline), with the original baseline retained as a reference for historical comparison.
The discipline of keeping both the original baseline and the approved current baseline visible is worth the effort. The original baseline tells the steering group what was approved at the outset and how the project has shifted against that. The approved current baseline tells the operational team what they are currently working to, incorporating all approved changes. Variance reporting should be explicit about which baseline each variance is measured against. Reporting that mixes original baseline variance and approved current baseline variance in a single number without disclosure is confusing at best and misleading at worst.
What to do on Monday morning
If you are setting a new baseline, start with the scope baseline. Confirm the controlled documents that define the scope, document the exclusions explicitly, and make sure the schedule and cost baselines reference the same set of documents. Do not approve a baseline where the scope, schedule, and cost reference different versions of the scope documents — this is the single most common source of downstream confusion.
Stress-test the schedule baseline before approval. Check resource profiles against site capacity. Check design cycles against the client's actual review governance. Check supply chain durations against market lead times. Remove hard constraints that cannot be justified by a specific external dependency. Add explicit TRAs at points of known duration uncertainty rather than hiding the uncertainty in activity durations. These adjustments usually extend the planned completion date, and the negotiation to accept that date rather than pretend to an earlier one is the main work of baseline approval.
Require a documented basis of estimate for the cost baseline. Separate base cost from contingency. Check that time-related costs are consistent with the schedule duration. Get the contingency number from a risk-based analysis — even a simple one — rather than a percentage uplift, and make the analysis visible to the approval body. A baseline where the contingency is "10% because that's what we always use" is not defensible when the first real risk materialises.
If you are inheriting a baseline, audit it against the tests above. A common finding is that two of the three baselines are solid and the third is weak — typically a solid cost and schedule baseline with a weak scope baseline, or a solid scope and cost with a fragile schedule. Document the weakness, flag it to the project sponsor, and propose a strengthening programme that can be executed without rebaselining. Full rebaselining on an inherited project should be a last resort because it obscures the performance history and opens new arguments about what the original commitments were.
Finally, treat change control as the priority discipline once the baseline is approved. A well-run change log that captures both contractual and internal changes, with each change's impact on scope, schedule, and cost documented, is what preserves the value of the baseline through delivery. A baseline without change control decays quickly. A baseline with proper change control remains a useful reference until project close, which is the whole point of setting one.