What a baseline is, and whose it is
A project baseline is the reference against which variance is measured. It is a snapshot of the agreed plan at a stated date, held in enough detail that later changes can be compared with it. It is not a forecast, a target or a commitment. Without one there is nothing to measure variance against, and every reported number is either a current position or a forecast with no context.
Most UK projects carry three linked baselines: scope (what is being delivered), schedule (when) and cost (how much). A baseline set is only useful if the three agree. A schedule that does not reflect the scope, or a cost plan whose time-related items do not match the schedule duration, generates false variance every month.
The word 'baseline' also covers three different things with different owners, set out in the table above. The contractor's Accepted Programme is a contract document. The client's performance baseline is a management tool. The funder's baseline is an approval. Each has its own rebaselining route, and a change to one does not change the others. Much of the confusion in baseline disputes comes from someone rebaselining the one they own and reporting it as if it were another.
A baseline is tested when it is used, not when it is approved. One that was approved easily can fail under the first serious change. One that was argued over and stress-tested at approval can absorb a lot of change and still give meaningful variance reporting.
The scope baseline
Variance reporting is only as good as the scope it measures against, so start there. If the scope is held as a high-level description rather than a defined list of deliverables, the schedule, cost and risk register built on it inherit the uncertainty. The usual symptom is scope drift: work expands without formal change control, and later additions have no baseline to be priced against.
This guide is written against NEC4 Engineering and Construction Contract (2017, with the January 2019 and October 2020 amendments; check for any later amendment before relying on clause numbers). NEC3 called the scope document the Works Information. NEC4 calls it the Scope, and the Scope is the controlled document that defines what the Contractor must provide. Other forms have their own equivalents (the employer's requirements and contractor's proposals on a design-and-build form, for example). Whatever the form, the baseline should be the controlled version of those documents at contract award. If it refers to something issued in draft and never controlled, the commercial position is weaker than the project team realises.
The test is simple. Could a third party, picking up the documents two years later, reconstruct what was agreed? If the answer depends on drawings not referenced in the contract, or on emails to establish intent, the baseline is exposed. A defensible scope baseline lists the controlled documents with revision numbers and dates, and the cost and schedule baselines cite that same list.
The schedule baseline and what makes it brittle
Four defects make a schedule baseline brittle: it cannot be built as drawn, it is held up by artificial constraints, its durations are optimistic, and it omits activities.
Buildability comes first. A programme that needs more concurrent resource than the site can take, compresses design review below what the client's governance will support, or assumes lead times shorter than the market delivers is a wish. Stress-test resource profiles, review cycles and procurement durations before approval.
Artificial constraints are the second defect. Hard dates imposed in the scheduling tool, rather than by a real dependency, stop a delay propagating through the network. On an NEC4 contract this matters directly. Compensation events are assessed using the Accepted Programme, so a constraint-heavy programme can show little or no impact for an event that is significant in practice. The Contractor then has to argue the programme is wrong before arguing the assessment is wrong.
Optimistic durations are the third. If every activity takes its minimum plausible time and nothing is allowed for weather, access or review, the resilience has gone before work starts. NEC4 clause 31.2 requires the programme to show float and time risk allowances. Those allowances belong to the Contractor and the clause does not say how big they should be. A QSRA is the usual way to size them, and the next section covers that. Also settle early how the gap between planned Completion (the date the programme shows) and the Completion Date (the contractual date) is treated. That gap is terminal float. Under clause 63.5 a compensation event moves the Completion Date by the delay to planned Completion, so the gap is kept for the Contractor unless a Z clause changes that. Check the contract before the first delay.
Missing activities are the fourth and the hardest to see. If commissioning, handover, regulatory approvals or client reviews are absent, they arrive during delivery and look like scope creep. They are baseline omissions. Represent every delivery phase at baseline, even if some are placeholder summary activities to be broken down nearer the work.
DCMA 14-point checks give an objective test for the constraint and logic defects. They are a US Department of Defense origin schedule-health check, widely used in UK practice but not mandated by National Highways, Network Rail or HS2. Run them on the native programme file and treat the thresholds as screening, not pass or fail. Missing predecessors or successors: no more than 5% of tasks. Leads: none. Lags: no more than 5%. Finish-to-start relationships: at least 90%. Hard constraints (Must Start On, Must Finish On, Start No Later Than, Finish No Later Than): no more than 5%. Start No Earlier Than and Finish No Earlier Than are soft constraints, but still need a reason. Durations over 44 working days: no more than 5%. Total float over 44 working days: no more than 5%. Negative float: none. Invalid dates: none.
The cost baseline
A cost baseline is as credible as its basis of estimate: the narrative that says how the number was built, which rates were used, what was assumed and what was left out. Without it, the figures are numbers on a page, and when pressure arrives there is nothing to explain what changed.
The basis of estimate should cover three things. Quantities: where they came from, how they were measured, and the estimate class. Estimate class, under AACE International Recommended Practice 17R-97 Cost Estimate Classification System, describes the maturity of project definition and the expected accuracy range of the estimate, from Class 5 (concept screening, least defined, widest range) to Class 1 (most defined). It does not describe confidence in the quantities. For the process industries the equivalent is 18R-97, and for building and general construction it is 56R-08. Use the one that matches the asset, or 17R-97 if none fits, and state which. Rates: whether historical, market-tested, benchmarked or budgeted, and for what period. Assumptions and exclusions: a baseline without an exclusions list is a hostage to later scope discussions. Government projects can also draw on the IPA Cost Estimating Guidance (2021), the extant document, now owned by NISTA (formerly the IPA).
Separate base cost from risk allowance. Base cost is the best deterministic estimate to deliver the approved scope under expected conditions. The risk allowance covers identified risk and estimating uncertainty. Report them as separate numbers. Contingency buried in line-item rates cannot be explained under challenge and gets double-counted by any risk model run on top. Management reserve is a third item: held by the sponsor or client above the project, outside the performance measurement baseline, and released by decision. In earned value terms the performance measurement baseline holds the control accounts, summary-level planning packages and undistributed budget, and management reserve sits outside it.
Keep time-related costs consistent with the schedule. If the programme shows 18 months and the cost plan carries 15 months of preliminaries, one is wrong. At an illustrative £0.2m a month for preliminaries, that is £3.6m against £3.0m, a £0.6m gap that will surface as an overrun with no performance cause.
Target cost options change what the cost baseline means. Under NEC4 Options C and D the total of the Prices is the target and the cost baseline, and Defined Cost plus Fee is what is measured against it, and the pain/gain share gives both parties a financial interest in its integrity. Under Options A and B the price is built up from the Activity Schedule or Bill of Quantities and Price for Work Done to Date is assessed from it. Option E is cost reimbursable, so there is no fixed price to hold. Check which option applies before deciding what the cost baseline should be.
Putting risk into the baseline
A baseline with no stated allowance for risk is a best-case plan. Three decisions need to be explicit.
The first is the time allowance. A QSRA run on the baseline programme shows the confidence level of the planned Completion date and the time needed to reach a higher one. That is a defensible basis for sizing time risk allowances, and it removes the temptation to hide padding in activity durations.
The second is the cost allowance. A QCRA, or an integrated cost and schedule analysis, gives a risk allowance at a named confidence level. The level is a decision for whoever approves the baseline, so state it. The HM Treasury Green Book (2026 edition, section on optimism bias and risk) requires risk and optimism-bias adjustment in appraisal, but it does not mandate P80. P50 and P80 mean different things to an approver: P80 is a cost that has an 80% modelled chance of not being exceeded, which leaves a 1-in-5 chance that it is.
The third is the refresh. A rebaseline that does not re-run the risk model carries the old allowance onto a new plan. Re-run the QSRA or QCRA on the revised programme and cost, and show what has moved.
On a QSRA we start from the programme as submitted, test its logic and constraints first, and only then model uncertainty. A risk model on a programme with broken logic reports a precise answer to the wrong question.
Rebaselining: legitimate or cover-up
Rebaselining replaces the reference with a new one. It is sometimes necessary and sometimes illegitimate. The difference lies in why it is done and what is disclosed with it.
A legitimate rebaseline responds to a change in scope, circumstances or funding large enough that the existing baseline is no longer a useful reference. If a programme approved for 500 homes is instructed to deliver 750 plus a community facility, variance against the original is the delivery of a different project, not a delivery failure. Funding changes imposed by the client, or an event that the contract treats as a compensation event or a Client's liability, can also justify one.
An illegitimate rebaseline hides accumulated overrun. A project six months late and 20% over budget rebaselines to its forecast, and the next report shows CPI and SPI at 1.0. The variance has not gone. It has been absorbed into the comparison point.
The test is what is disclosed alongside. A legitimate rebaseline comes with a note on what changed, why the old baseline no longer serves, and what the variance against the original would be. The original is kept and the history is not erased. An illegitimate one replaces the comparison point without acknowledging the earlier variance, and the board loses sight of real performance.
Under NEC4 the contractual route is specific. The Accepted Programme changes only when a revised programme is submitted under clause 32 and accepted by the Project Manager. The Contractor submits revised programmes at the intervals in the Contract Data, when instructed, and when the Contractor chooses, so this is a routine contractual obligation rather than a discretionary controls exercise. Clause 31 covers the first programme only. Because compensation events are assessed using the Accepted Programme, what the Project Manager accepts affects how later events are valued. A controls team that rebaselines its own copy informally has not changed the contract position, and the gap will show in a dispute.
The client's performance baseline changes by a different route, through the sponsor's or board's change control. The same disclosure test applies there.
Change control and worked example
A baseline without change control is a historical document. Contractual changes (compensation events under NEC4) are usually documented. Internal decisions to expand scope or draw on contingency often happen by email. Keep one change log covering both, showing each change's effect on scope, schedule and cost and its status (proposed, approved, implemented). The second failure is a log that records approved changes but leaves the baseline unchanged, so reported variance mixes performance with approved change.
Hold two views. The original baseline shows what was first approved and how the project has moved. The approved current baseline, which on an NEC4 contract is the Accepted Programme plus approved changes to the cost plan, shows what teams are working to. Say which each variance is measured against.
Illustrative example. Original baseline: £40.0m. An approved scope change adds £4.0m, so the approved current baseline is £44.0m. At month 12, core work shows planned value £18.0m, earned value £16.0m and actual cost £17.6m. The change work shows planned value £2.0m, earned value £1.6m and actual cost £1.6m.
Measured against the approved current baseline: planned value £20.0m, earned value £17.6m, actual cost £19.2m. CPI is 17.6 / 19.2 = 0.92 and SPI is 17.6 / 20.0 = 0.88. Estimate at completion is 44.0 / 0.9167 = £48.0m. Against the original £40.0m that is an £8.0m overrun, of which £4.0m is approved change and £4.0m is performance.
Mixing the views gives the wrong answer. If actual cost includes the change work but the baseline does not, CPI reads 16.0 / 19.2 = 0.83, which overstates the cost problem. Core work alone gives 16.0 / 17.6 = 0.91. A cover-up rebaseline to £48.0m would show CPI back at 1.0 and the £4.0m performance overrun would no longer appear in the report.
Baseline audit checklist
Use this when setting a baseline or inheriting one. Record each answer as yes, no or not evidenced.
1. Scope: are the controlled documents listed with revision and date, with exclusions stated, and do the cost and schedule cite the same list?
2. Ownership: is it clear whether the baseline is the contractual programme, the client performance baseline or the funder approval, and how each is rebaselined?
3. Buildability: have resources, design review cycles and lead times been checked against site capacity, governance and the market?
4. Constraints and logic: do the DCMA checks for hard constraints, missing logic, lags, high duration and negative float sit within threshold, with a reason for each exception?
5. Time allowance: are float and time risk allowances visible, sized by a QSRA, with planned Completion and Completion Date both stated?
6. Basis of estimate: does it state quantities, rates, assumptions, exclusions, estimate class under the applicable AACE practice and the estimate date?
7. Cost layers: are base cost, risk allowance and management reserve shown separately, with the confidence level of the allowance stated?
8. Consistency: do time-related costs match the schedule duration?
9. Change control: is there one log for contractual and internal change, and does an approved change update the current baseline?
10. History: is the original baseline retained, and is every variance labelled with the baseline it is measured against?
If the scope baseline is weak and cost and schedule are sound, or the reverse, document the weakness, tell the sponsor, and agree a strengthening plan that avoids a full rebaseline. A full rebaseline on an inherited project obscures history and reopens the argument about the original commitments.