Baseline Approval and Control
Last reviewed 9 September 20262,014 words9 min read
Getting it accepted, keeping it meaningful
🟩 In one line: A baseline is only worth having if it was accepted under the contract, frozen in P6 as a named baseline, and changed only through a documented revision — otherwise every progress comparison is against a moving target and every delay analysis starts with an argument about which programme counts.
👤 Who this is for: Mid-level planners submitting a baseline; juniors who assign baselines in P6 and wonder why bars compare to the wrong one; seniors defending which programme is "the" baseline in a dispute. You should know schedule-levels-1-to-5 and p6-constraint-types.
First, let's be honest about why this page exists
Two failures, both common. First: the baseline is submitted, the Engineer comments, the contractor resubmits, the Engineer goes quiet, and six months later nobody can say which revision was accepted. Second: the baseline is accepted, then quietly edited — a constraint here, a duration there — until the file called "Baseline" bears no relation to what was signed.
Both mean the same thing: when the delay analysis comes, there is no agreed starting point. The fix is procedural, not clever.
🟨 The standard — what "good" looks like
| Source | What it says (paraphrased) |
|---|---|
| FIDIC 1999 Cl 8.3 | Contractor submits programme within 28 days of Commencement; Engineer has 21 days to give notice of non-compliance; Contractor proceeds in accordance with the programme |
| FIDIC 2017 Cl 8.3 (check the edition in your contract) | Similar timing; if the Engineer gives no Notice within 21 days the Engineer is treated as having given a Notice of No-objection |
| NEC3 / NEC4 Cl 31.3 | PM accepts or rejects within two weeks, giving reasons from the listed grounds (not practicable, doesn't show required information, doesn't represent Contractor's plans, not compliant with Works Information / Scope) |
| NEC4 Cl 31.3 (check against your copy) | Adds a deemed-acceptance route: if the PM doesn't respond, Contractor notifies, and after a further period the programme is treated as accepted |
| NEC3 Cl 50.3 / NEC4 Cl 50.5 (check the edition in your contract) | Retention of a portion of payment if no programme has been submitted showing the required information — a real commercial lever |
| SCL Protocol 2nd ed., Core Principle 1 | Programme accepted at the outset and updated properly; the accepted programme is the reference for delay analysis |
| PMI Practice Standard for Scheduling | Baseline is the approved version of the schedule model, changed only through formal change control |
| AACE RP 29R-03 | Baseline validation is the first step of forensic analysis; an unaccepted or altered baseline weakens every method |
🟢 Rule to remember: one accepted revision, one written acceptance, one P6 baseline named after it, and a log of every change since. Anything less and you don't have a baseline; you have a drawing.
How it actually works
The approval cycle.
| Step | Contractor | Engineer / PM | Record |
|---|---|---|---|
| 1 | Submit Baseline Rev 0 — XER, PDF, narrative, SBM — within contract period (FIDIC 28 days) | — | Transmittal with date |
| 2 | — | Review; comment sheet within 21 days (FIDIC) / 2 weeks (NEC) | Comment sheet |
| 3 | Respond to every comment; resubmit as Rev 1 with a comment-closure table | — | Closure table |
| 4 | — | Accept / no-objection, or further comments | Written acceptance letter naming the revision and data date |
| 5 | Freeze the file; create P6 baseline; issue "Accepted Baseline" transmittal | — | Baseline register entry |
Typical Gulf reality: two to three cycles, 60–120 days. Work proceeds against Rev 0 meanwhile — state that in every progress report so nobody later argues the project had no programme.
What acceptance means and doesn't.
| Acceptance means | Acceptance does not mean |
|---|---|
| This is the reference for progress and delay | The Engineer guarantees it's achievable |
| The stated basis (SBM) is acknowledged | Contractor is relieved of completing on time |
| Changes now go through revision control | Engineer accepted every constraint blindly — they can still be challenged |
P6 mechanics.
| Action | Menu path | Notes |
|---|---|---|
| Create baseline from the accepted project | Project > Maintain Baselines > Add > Save a copy of the current project as a new baseline | Do this on the frozen, accepted file — not the live one after two weeks of updates |
| Name it | e.g. BL0-Accepted-DD 01Jan25-Rev1 | Revision, acceptance status and data date in the name |
| Set baseline type | Maintain Baselines > Baseline Type: e.g. "Contract Baseline" | Types are defined in Admin > Admin Categories |
| Assign as project baseline | Project > Assign Baselines > Project Baseline | This is what Earned Value and variance columns use |
| Assign user baselines | Same dialog > Primary / Secondary / Tertiary | What the bars show; these are per-user — the trap on shared databases |
| Lock it | Do not open the baseline project for editing; restore only for audit | Baselines can be restored to editable projects via Maintain Baselines > Restore — a control risk |
| Archive | Export the accepted XER and PDF to a read-only folder | The P6 baseline is convenient; the archived XER is the evidence |
Revision control after acceptance. A baseline changes for three reasons only:
| Trigger | Document | Result |
|---|---|---|
| Approved EOT / variation changing completion or logic | Revised Baseline Rev n, with revision note | New accepted baseline; old one archived and retained |
| Agreed change of method or sequence | Revised Baseline with SBM revision | As above |
| Recovery instructed or offered | Recovery schedule — not a baseline | Separate document (revised-baseline-vs-recovery-schedule) |
Monthly updates never touch the baseline. The live project changes; the baseline sits still.
Baseline register — one table, kept for the life of the job:
| Rev | Data date | Submitted | Accepted | Acceptance ref | P6 baseline name | Reason for revision |
|---|---|---|---|---|---|---|
| 0 | 01-Jan-25 | 20-Jan-25 | — | — | — | Initial |
| 1 | 01-Jan-25 | 10-Mar-25 | 02-Apr-25 | ENG/L/0412 | BL0-Accepted-Rev1 | Comments closed |
| 2 | 01-Sep-25 | 15-Sep-25 | 20-Oct-25 | ENG/L/0980 | BL2-EOT01-Rev2 | EOT 01, 42 days |
📜 Who owns what
| Question | Usual position |
|---|---|
| Can the Engineer refuse to accept indefinitely? | FIDIC: silence after 21 days works in the Contractor's favour (2017 explicit). NEC: listed grounds only; NEC4 deemed acceptance. Either way, chase in writing and keep the correspondence |
| Does acceptance shift risk to the Employer? | No. Standard forms say the Contractor remains responsible for the programme and completion |
| Can the baseline be changed without agreement? | Not credibly. A unilateral change is just a new submission awaiting acceptance |
| Which programme governs a TIA? | The last accepted update before the event — the baseline is only the reference for the first period |
🟥 Where people go wrong
- Updating the file before it's accepted, then baselining the updated version. The P6 baseline now has actuals in it and different dates from the accepted PDF. Baseline from the frozen archive copy, never from the live project.
- Assigning a user baseline and thinking everyone sees it. Primary/secondary/tertiary are per user login. The client's reviewer sees whatever they assigned, often the wrong one. Set the Project Baseline (used for EV) and tell reviewers which name to assign.
- Letting comment cycles drift for six months. Every month without acceptance is a month where the "programme" is arguable. Chase in writing at 21 days; quote the clause; invoke deemed acceptance where the form allows it.
- Accepting comments that change the plan without updating the SBM. Rev 1 removed a constraint and re-sequenced Zone B at the Engineer's request. The SBM still describes Rev 0. Now the accepted basis contradicts the accepted programme.
- Calling a recovery schedule a revised baseline. The client accepts it as "the programme", the original completion date disappears, and the EOT entitlement goes with it. Keep them separate and label them (revised-baseline-vs-recovery-schedule).
- Restoring the baseline to fix something. Maintain Baselines > Restore turns it into an editable project. Someone edits it, re-baselines it, and the accepted programme has silently changed. Restore only to a sandbox, for audit.
- Not archiving the XER. The P6 database is migrated, the baseline project is dropped, and the only record of the accepted programme is a PDF. Export and lock the file the day it's accepted.
⚖️ When you're challenged
"The Engineer never formally accepted your baseline, so there is no baseline." "Rev 1 was submitted on 10 March and the Engineer's 21 days under Clause 8.3 passed without notice of non-compliance. Under the 2017 form that's a Notice of No-objection. We've reported against Rev 1 for nine months without objection."
"Your baseline in P6 doesn't match the PDF we accepted." "It should match exactly — let me check which baseline you've assigned. The accepted one is named BL0-Accepted-Rev1, data date 1 January. If you've got BL0 Rev 0 assigned, that's the pre-comment version."
"Why can't you just update the baseline to the current programme?" "Because then there's nothing to measure against. The baseline is the promise; the update is the reality. If the contract changes through an EOT, we revise the baseline formally. Otherwise it stays put."
"We want the recovery schedule adopted as the new baseline." "Happy to submit it for acceptance as a revised baseline — but only alongside the EOT determination, so the completion date it shows is the contractual one. Otherwise we're baselining a mitigation plan and losing the entitlement."
📄 Related pages
- Schedule Basis Memorandum — accepted alongside the programme
- Schedule Narrative — the third document in the submission
- P6 Baselines: Assign and Maintain — the P6 dialog in full
- Revised Baseline vs Recovery Schedule — the two documents people confuse
- Schedule review comment sheet — closing the Engineer's comments
- What the contract says about the programme — Cl 8.3 and Cl 31 side by side
- Time Impact Analysis — why the baseline is not the TIA base
✏️ Worked example
An industrial facility in Jubail. Timeline of the baseline, from the register:
| Date | Event | Days elapsed |
|---|---|---|
| 05-Feb-25 | Commencement | 0 |
| 03-Mar-25 | Baseline Rev 0 submitted (day 26 of 28) | 26 |
| 24-Mar-25 | Engineer comments: 34 items (12 constraints to remove, 3 open ends, calendar queries) | 47 |
| 14-Apr-25 | Rev 1 resubmitted, all 34 closed | 68 |
| 05-May-25 | 21 days pass; no notice | 89 |
| 06-May-25 | Contractor letter: Rev 1 deemed no-objection under Cl 8.3; P6 baseline created and archived | 90 |
| 19-May-25 | Engineer letter "accepting Rev 1 subject to monthly updates" | 103 |
Fourteen months later an EOT dispute turned on whether Rev 0 or Rev 1 was the baseline. Rev 0 showed a 4-day float on the affected path; Rev 1 (after constraint removal) showed 19 days. The register, the 06-May letter and the archived XER settled it in an afternoon: Rev 1. The contractor's TIA proceeded from the last accepted update, as it should — but the Employer's counter-argument had been built on Rev 0 and had to be withdrawn.
📖 References
- FIDIC 1999 Cl 8.3; FIDIC 2017 Cl 8.3 (check the edition in your contract)
- NEC3 ECC Cl 31.3, 32, 50.3; NEC4 ECC Cl 31.3, 32, 50.5 (check the edition in your contract)
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 1
- PMI, Practice Standard for Scheduling, 3rd ed. — baseline and change control
- AACE RP 29R-03, Forensic Schedule Analysis — baseline validation
- Oracle, P6 Professional User Guide — Maintaining and Assigning Baselines
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about baseline approval and control. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience