The schedule basis document: what to include, and why it wins disputes

Every CPM schedule is a stack of decisions — durations chosen, logic preferred, constraints imposed, scope excluded. The schedule basis document is where those decisions get written down. Most projects never produce one, and most of those projects regret it at exactly the moment regret is most expensive.

What a schedule basis document is

The schedule basis document is the companion record to a baseline programme: a written account of how the schedule was built — the scope it models, the assumptions it rests on, the methodology behind its durations and logic, the constraints it carries and the things it deliberately leaves out. AACE International formalised the idea in its Recommended Practice 38R-06, but the underlying principle is older than the RP and simpler than its title: a schedule is a model, and a model whose inputs are undocumented cannot be checked, defended or sensibly revised.

What goes in it, in one breath: the scope snapshot the programme represents, the contractual dates and clauses it must serve, the planning methodology and software settings, the derivation of every significant duration, the sequencing rationale, the calendars and constraints with their justifications, the resource and productivity assumptions, the exclusions and assumptions register, the approach to risk and contingency, and a revision history saying who changed what and when. The rest of this article walks through each of those, then turns to the discipline of keeping the document alive — because a basis document frozen at award and never touched again is only marginally better than none.

The audience is anyone who needs to understand why the programme says what it says without access to the head it was built in: the planner who inherits the schedule, the client reviewer deciding whether to accept it, your own team three years in, and — in the worst case, which is the case worth planning for — a tribunal.

Three documents, three questions

The basis document sits in an ecosystem of three artefacts that get conflated constantly. The baseline is the model itself — the XER or MPP file, the thing the CPM engine calculates. The basis document explains how that model was built. The schedule narrative explains what happened to the project this period, against that model. We covered the narrative side in its own article; the short version of the distinction is lifespan. The narrative is rewritten every update cycle. The basis document is written once with the baseline and revised only when the basis genuinely changes — a re-baseline, a major methodology shift, a scope reset.

Why it wins disputes

Almost every forensic delay analysis, whatever the method, begins with an attack on the as-planned programme. Before anyone argues about what delayed the project, the opposing expert will argue that the baseline was never achievable in the first place: the durations were optimistic, the sequence was theoretical, the weather allowance was fiction, the procurement lead times were guesses. If that attack lands, every analysis built on the baseline inherits the damage.

A contemporaneous basis document is the strongest available answer. It shows that the durations had a derivation — benchmarks, quotes, production rates, and where it was judgement, declared judgement. It shows the sequence had a rationale and the exclusions were stated rather than discovered. The expert can still disagree with the assumptions, but disagreeing with a documented assumption made in good faith at the time is a far weaker position than pointing at an unexplained number and inviting the tribunal to assume the worst. Without the document, the planner reconstructs intent from memory, years later, under cross-examination — and "I believe we would have based that on experience" is not an answer that survives contact with a competent QC.

The dispute case gets the headlines, but the everyday wins arrive sooner. A new planner inherits a 4,000-line programme and is productive in days instead of months. Client review cycles get shorter, because the reviewer's questions — why is this duration 60 days, why is there a constraint here — are answered before they are asked; on NEC contracts, where programme acceptance turns on whether the programme is realistic and practicable, a basis statement is the closest thing to a pre-emptive defence the contractor can submit. Re-baselining through change control becomes tractable, because there is a recorded "before" to change from. And the quiet one: an undocumented schedule is a key-person risk. If the only complete account of the programme's logic lives in one planner's head, the project is one resignation away from owning a model nobody can explain.

What goes in it: a walkthrough

The element families below follow the shape of RP 38R-06 without reproducing it. Three groups: what the file does, what the world is assumed to do, and who keeps the whole thing honest.

The model: how the file was built

Project overview and scope basis. State what scope snapshot the schedule models — which drawings revision, which contract amendments, which pending changes are in and which are out, all at a named cut-off date. Schedules drift out of step with scope quietly; the basis document fixes the point of departure so the drift is measurable rather than deniable.

Contractual framework. The key dates and sectional completions, the milestones carrying damages, and the programme clauses the schedule must satisfy — submission cycles, acceptance criteria, float-sharing provisions. A reviewer should be able to trace every contractual date to an activity or milestone in the file.

Methodology and settings. The WBS and activity coding strategy, the level-of-detail policy (and where it intentionally varies — detailed near-term, summarised far-term is fine if declared), and the software settings that change calculated results: retained logic versus progress override, calendar definitions, the definition of critical used (total float threshold or longest path — they diverge on multi-calendar programmes), and a float ownership statement consistent with the contract. Two planners can open the same file with different scheduling options and get different dates; the basis document says which set of dates is the schedule. Our piece on float covers why the ownership statement matters more than most teams expect.

Duration basis. The heart of the document, and the section that decides whether the baseline survives the achievability attack. For each major area of work, record the estimating method: benchmarked against named comparable projects, calculated from production rates and quantities, taken from subcontractor quotations, or engineering judgement — and flag which is which. Judgement is legitimate; undeclared judgement dressed up as calculation is what cross-examination exists to find.

Logic basis. The sequencing strategy in prose — the build direction, the key interfaces and handovers, the access strategy — and, critically, which logic is mandatory (physics, safety, statute) and which is preferential (a choice that could be made differently under pressure). Preferential logic is exactly what gets resequenced during acceleration, so knowing which links are which is worth real money later.

Calendars and constraints register. Every calendar defined, with working patterns and holidays; every constraint listed, with its individual justification. A date constraint without a recorded reason is indistinguishable from a date someone wanted, and the DCMA 14-point check treats hard constraints with suspicion for precisely that reason.

The assumptions: what the world must do

Resources and productivity. The crew sizes, plant and production rates the durations assume, and the availability assumed — single shift or double, and any labour ceilings. When a duration is challenged, this is where its arithmetic lives.

Exclusions and assumptions register. The weather basis (which dataset, what allowance, distributed how), site access assumptions, approvals turnaround assumed from the client and statutory bodies, free-issue materials and their promised dates, and anything explicitly excluded. This register is the schedule's boundary fence: everything inside is the contractor's problem, everything outside is a change.

Risk and contingency approach. Where time risk allowances sit (inside durations, as discrete buffers, or as terminal float), what they cover, and who owns them. If the programme has been through quantitative risk analysis, say which model, which confidence level informed the committed dates, and where the QSRA assumptions are kept — our article on the risk-loaded schedule covers that discipline in full.

The governance: who keeps it honest

Revision history and ownership. Who wrote the document, who approved it, which baseline version it describes, and a log of every revision with reasons. A basis document that cannot say which file it explains has already failed.

Keeping it alive

A basis document is versioned with the baseline, not filed beside it. Every re-baseline gets a revised basis recording what changed and why; every major update worth the name notes whether any basis assumption has been overtaken — the weather allowance consumed, the access assumption broken, the approvals turnaround proving optimistic. The review takes an hour a period and is mostly the word "unchanged".

A stale basis document is almost as bad as none, and in one respect worse: it makes confident statements that the current file contradicts, and hands the other side a credibility argument gift-wrapped. If the document says ten hard constraints, justified, and the XER now carries thirty, the gap is the finding — whichever side finds it first.