The schedule baseline is the plan every future update gets measured against. Each progress report, extension request and delay claim refers back to it. Yet on many projects the baseline gets accepted in a rush in the first month, nobody stores a clean copy, and by month six it's been quietly overwritten three times. When a dispute comes, nobody can say with confidence what the agreed plan was.
This guide covers how owners should set, accept, lock and, when necessary, replace a construction schedule baseline. It's about the process and governance around the baseline. For a checklist of what to look for inside the schedule itself, see our separate guide to reviewing a construction schedule.
Baseline, update and revision: three different things
These terms get used loosely, and the confusion causes real problems:
- Baseline. The accepted plan for the whole project, frozen at a point in time. It doesn't change when progress happens. It's the yardstick.
- Update. A copy of the schedule with actual progress recorded up to a data date and the remaining work re-forecast. Updates happen monthly or at whatever interval the contract sets. They show where the project is now.
- Revision. A change to the plan itself, such as new logic, new sequences or added scope. A revision may lead to a new baseline, but only through a deliberate, documented process.
The most common mistake is letting updates turn into revisions without anyone noticing. A contractor changes logic in the update to work around a problem. That may be a reasonable plan, but if it isn't flagged, the change wipes out the evidence of how the original plan was affected.
What a baseline submission should contain
A credible baseline is more than a Gantt chart PDF. At minimum, owners should ask for:
- The native schedule file, such as a Primavera P6 .xer or a Microsoft Project file, not just a printout. Without it, nobody can check the logic.
- A basis-of-schedule narrative explaining the construction approach, key sequences, assumptions about owner activities, crew sizes for critical work and any known risks.
- Calendars showing working days, holidays, winter assumptions and any work-hour restrictions.
- Contract milestones exactly as the contract defines them, including interim milestones such as building enclosure, permanent power or tenant turnover.
- Owner activities: design reviews, submittal approvals, owner-supplied equipment, permit dependencies and decisions the owner has to make.
- Procurement activities for long-lead items, from submittal through fabrication and delivery.
- Cost or resource loading, if the contract requires it. A cost-loaded baseline lets you check progress claims against the schedule and supports earned value reporting.
The baseline life cycle
A baseline goes through a predictable sequence. Owners who manage each step deliberately end up with a baseline that holds up under scrutiny.
1. Submission
The contract should set a firm deadline for the baseline, typically within the first few weeks after award. Until the baseline is accepted, there's no agreed yardstick. Every week of delay is a week where owner-side decisions and contractor progress can't be measured properly. Tie the first progress payment, or part of it, to submitting a compliant baseline if your contract allows.
2. Review
The review should check logic, durations, constraints, float, calendars and milestones against the contract. It should also check that owner activities are realistic. A baseline that gives the owner five days to review a full mechanical submittal package is setting up a future delay claim.
Put review comments in writing, organized so the contractor can respond to each one. Expect at least one round of resubmission. On programs we've supported, a strong first submission is the exception, not the rule.
3. Acceptance
Be careful with the word "approved." The Society of Construction Law's Delay and Disruption Protocol (2nd edition, 2017) describes the contractor's accepted plan as the Accepted Programme. It treats acceptance as confirmation that the plan looks reasonable, realistic and achievable, not as making the schedule a contract document. That distinction matters. Owners who "approve" a schedule may later be told they agreed to every assumption in it, including the five-day submittal review.
Acceptance wording should say what it is: the owner accepts the schedule as the baseline for measuring progress and evaluating delay, without accepting responsibility for the contractor's means, methods or durations. Have your lawyer review the wording against your contract.
4. Lock and archive
Once accepted, save the native file, the PDF and the narrative with a clear version name and date. Store them somewhere the contractor can't overwrite. In P6, keep the accepted baseline as a separate, read-only project. This sounds basic, but on disputed projects the first question is often "which file was the baseline?", and the answer is surprisingly hard to find.
5. Measure updates against it
Each update should report variance against the baseline: start and finish variance for key activities and milestones, plus changes in total float on the critical path. A baseline that nobody compares against is just a historical document.
View the data
| Activity | Baseline (days) | Current forecast (days) | Finish variance |
|---|---|---|---|
| Foundations | 10–25 | 10–29 | +4 days |
| Structure | 25–55 | 29–63 | +8 days |
| Envelope | 55–75 | 63–85 | +10 days |
| Interior fit-out | 55–80 | 63–90 | +10 days |
| Substantial perf. | 90–90 | 100–100 | +10 days |
When to re-baseline, and when not to
Re-baselining resets the yardstick. Done for the right reasons, it keeps the schedule useful. Done casually, it erases the record of what went wrong.
Good reasons to re-baseline:
- A major scope change that adds or removes significant work.
- An agreed extension of time large enough that measuring against the original dates is no longer meaningful.
- A fundamental change in construction approach agreed by both parties, such as switching from cast-in-place to precast.
- A project restart after a long suspension.
Poor reasons to re-baseline:
- The project is behind and the variance numbers look bad.
- A new project manager wants "a fresh start."
- The contractor has resequenced work without an agreed change.
When you do re-baseline, keep every previous baseline. Document why the new one was created, what it includes, and whether any time was granted as part of it. If the re-baseline settles a delay entitlement, say so in writing. If it doesn't, say that too, so nobody can later argue that accepting the new baseline waived a claim.
Baselines on phased and multi-site programs
Owners running a phased build or a rollout across many sites face an extra problem. Not every phase or site is designed, priced or permitted when the first contract is signed. A single baseline covering everything can be out of date within weeks.
The practical answer is a layered approach:
- A program-level master schedule that the owner controls, showing each phase or site as a summary with key milestones and the dependencies between them.
- Detailed baselines for each phase or site, accepted as each contract or work package is awarded.
- Clear links between the two, so a slip in one site's turnover date shows up in the program view straight away.
Each detailed baseline still goes through the full submit, review, accept and lock cycle. The master schedule gets its own version control, so the owner can show what the program plan was at any point. When a board asks why a rollout is three months behind, that history is what lets you give a straight answer.
Common baseline problems we see
- Accepted too late. Months pass before the baseline is accepted. By then, early delays have no agreed plan to be measured against.
- Accepted without the native file. The owner accepted a PDF and can't check the logic later.
- Owner durations nobody checked. The baseline shows owner reviews, decisions and supply dates that the owner's team never agreed to.
- Silent logic changes in updates. The contractor changes the plan in each update without flagging it, and the baseline comparison stops meaning anything.
- No record of acceptance. The baseline was discussed at a meeting and "everyone agreed," but nobody wrote it down.
What owners should do
- Write baseline requirements into the contract. Set the submission deadline, the required contents, the native file format, the review period and the consequences of late or non-compliant submission.
- Plan your own review capacity. Someone on the owner side needs the skills and time to review the baseline within the contract period. If that isn't in-house, line up an independent scheduler before award.
- Check owner activities with your own team. Confirm that design, IT, security, furniture and operations staff can meet the dates the baseline gives them.
- Use careful acceptance wording. Accept the schedule as a baseline for measurement, not as approval of the contractor's methods.
- Archive every accepted version. Keep the native file, PDF and narrative, each clearly named and stored outside the contractor's control.
- Require a change log in every update. Any change to logic, durations, constraints or calendars should be listed and explained.
The bottom line
The baseline is the owner's best protection in any schedule dispute, but only if it was properly reviewed, clearly accepted and safely stored. A few hours of discipline in the first month can save weeks of argument at the end of the project.
None of this takes a big team. It takes someone on the owner side who knows what a good baseline looks like, has the time to review it, and has the authority to say no to a weak one.
Need help reviewing or accepting a baseline on your next project? Book a 30-minute call with Benjamin R. Consulting.
Sources: Society of Construction Law, Delay and Disruption Protocol, 2nd edition (2017), Core Principle 1 and guidance on the Accepted Programme; Fenwick Elliott, The SCL Delay and Disruption Protocol: a second edition; AACE International, Recommended Practice 29R-03, Forensic Schedule Analysis (2011). This article is general information, not legal advice.