P6 Baselines: Assign and Maintain
Last reviewed 16 September 20268 min read
Project vs user baseline β one is the contract's yardstick, the other three are yours to compare against
π© In one line: A P6 baseline is a frozen copy of the project stored inside it; the Project Baseline is one per project, shared by every user, points at the accepted baseline from the register and drives earned value; the User Baselines (primary, secondary, tertiary) are per user, point at anything you want to compare against β last month's update, the tender programme, a recovery plan β and never at anything contractual.
π€ Who this is for: J/M. Prerequisites: baseline-approval-and-control, importing-and-exporting-xer.
First, let's be honest about why this page exists
The contract page settled what a baseline is and how it is accepted. This page is the button-level version: how the accepted programme becomes a baseline object inside P6, how to point the right columns at it, and how to avoid the three operations that destroy it β Restore, Update Baseline and Replace on import.
The commonest damage is not deliberate. A colleague assigns their own comparison as the Project Baseline, the EV columns quietly switch to measuring against last month, and the S-curve in the report is wrong for two cycles before anyone asks why BEI jumped to 1.00.
π¨ The standard β what "good" looks like
| Source | What it asks for (paraphrased) | Consequence in P6 |
|---|---|---|
| GAO Schedule Assessment Guide, BP 10 | Maintain a baseline schedule; document each revision and its approval | One Project Baseline = the register's current accepted revision |
| DCMA 14-Point, Metrics 13 and 14 | CPLI and BEI measured against the approved baseline | The variance columns and BEI count read the Project Baseline |
| AACE RP 38R-06 | Schedule basis identifies the baseline and its revision | Baseline name carries revision and data date |
| PMI Practice Standard for Scheduling, 2nd ed. | Baseline as the approved version for comparison; changes controlled | User baselines for analysis, Project Baseline for control |
| FIDIC 1999 Cl 8.3 / 2017 Cl 8.3; NEC Cl 31.3, 32.2 | Accepted programme (NEC) / programme submitted and not rejected (FIDIC) | The accepted one becomes BLn in the register and the Project Baseline in P6 |
| Convention (baseline-approval-and-control) | Named BL0-Accepted-DD 01Jan25-Rev1; register for life of job; accepted XER archived read-only; never Restore except into a sandbox | This page's procedure |
π’ Rule: Project Baseline = the current accepted revision in the register, named to match, changed only when the register changes; User Baselines = anything else; and a baseline is never Restored, Updated or overwritten in the live project.
How it actually works
1. The four slots
| Slot | Scope | Set at | What reads it | Convention |
|---|---|---|---|---|
| Project Baseline | One per project, all users | Project β Assign Baselines β Project Baseline | Variance β BL Project columns; BL Project bars; earned value (when Project Details β Settings β "Baseline for earned value calculations" = Project baseline) | Current accepted revision from the register |
| Primary User Baseline (BL1) | Per user | Project β Assign Baselines β Primary | Variance β BL1 columns; BL1 bars | Previous accepted update (slippage-and-trend-analysis) |
| Secondary (BL2) | Per user | Same | BL2 columns / bars | Tender programme, or the previous baseline revision |
| Tertiary (BL3) | Per user | Same | BL3 columns / bars | Recovery plan target, or any what-if |
Baselines also sit inside the project as objects: Project β Maintain Baselines lists every baseline saved, regardless of whether it is assigned to a slot. Admin β Admin Preferences β Data Limits sets the maximum number per project β raise it early; five to ten is comfortable on a three-year job.
2. Creating the baseline from the accepted file
| Step | Action | Note |
|---|---|---|
| 1 | Written acceptance received naming revision and data date | Register row opened |
| 2 | Accepted XER archived read-only | The file, not the database object, is the record |
| 3 | Project β Maintain Baselines β Add β "Convert another project to a new baseline of the current project", pointing at the imported accepted file | Preferred: the baseline is exactly the accepted file. "Save a copy of the current project" is acceptable only if the live project is byte-identical to what was accepted |
| 4 | Name: BL0-Accepted-DD 15Jan25-Rev0; Baseline Type: Initial Planning / Customer Sign-Off (or whatever the admin's list uses); Last Update Date noted | Name matches the register and the archive file |
| 5 | Project β Assign Baselines β Project Baseline = BL0-Accepted-DD 15Jan25-Rev0 | Everyone now measures against it |
| 6 | Project Details β Settings β Baseline for earned value = Project baseline | Otherwise EV follows each user's primary |
| 7 | Layout bars: Project Baseline bar on; BL1 bar for the previous update | Six layouts (p6-layouts-and-filters) updated |
| 8 | SBM tool-settings section: baseline name, slot assignments | Screenshot |
3. Monthly
- After each accepted update, Maintain Baselines β Add β Save a copy of the current project, named "Upd08-Accepted-DD 01Sep25". Assign as Primary User Baseline next month. This is how the previous-update comparison exists without a second project.
- Project Baseline untouched.
4. Baseline revision (an EOT, agreed acceleration, re-scope)
Same eight steps for BL1-Accepted-DD 01Dec25-Rev0. Project Baseline reassigned to BL1. BL0 stays in Maintain Baselines β never deleted β and can sit in a user slot for the transition-month comparison (splitting-in-progress-activities). Register and SBM updated together.
5. The three operations that destroy a baseline
| Operation | Where | What it does | Rule |
|---|---|---|---|
| Restore | Maintain Baselines β Restore | Turns the baseline back into a standalone project and removes it from the baseline list | Only in a sandbox database, on a copy, when you need to export or inspect it. Never in the live project |
| Update | Maintain Baselines β Update | Copies selected current-project data into the baseline (dates, logic, resources, by filter) | Never on an accepted baseline. It rewrites the yardstick to match the work |
| Replace Existing Project on import | Import β Import To | Deletes the project and every baseline inside it, then recreates from the file | Never on a production project |
Delete is a fourth: Maintain Baselines β Delete removes the object. Only ever for a stray what-if copy, never for anything that appears in the register.
6. Getting a baseline out of P6
The XER export does not carry baselines. To send one: send the archived accepted XER (the register points at it); or Copy the baseline (Maintain Baselines β Copy) into a sandbox, Restore it there, export; or use XML export, which can include assigned baselines. Whichever, the transmittal says which.
7. Reading the columns
| Column | Meaning |
|---|---|
| BL Project Start / Finish | Dates in the Project Baseline |
| Variance β BL Project Finish Date | Current finish β Project Baseline finish; positive = later (check against your copy) |
| BL1 Start / Finish; Variance β BL1 Finish Date | Same against the Primary User Baseline |
| BL Project Duration | Baseline OD |
| Planned Value Cost / Labor Units | From the baseline for EV |
Activities added after the baseline show blank BL dates; P6 can substitute planned dates for missing baselines (Project Details β Settings β "Earned value calculation β use planned dates when baseline missing" β verify label), which should be off in a submission so added scope is visible as added.
π₯ Where people go wrong
- Project Baseline pointed at last month. Every variance column and the EV curve now measure a month, not the contract. Project Baseline = register; last month goes in BL1.
- "Save a copy of the current project" after the live project has already been edited. The baseline is not the accepted file. Convert the imported accepted XER instead.
- Restore to "have a look." The baseline leaves the list and becomes a project; a week later someone schedules it. Copy β sandbox β Restore there.
- Update Baseline to add the variation. The yardstick now contains the change and the variance disappears. Variations are visible precisely because they have no baseline dates.
- Data limit at the default. Third baseline refuses to save mid-update. Raise the limit at set-up.
- Baseline name that says nothing. "Baseline 3 (copy)" cannot be matched to a register row or a letter. Revision and data date in the name, every time.
βοΈ When you're challenged
"Your S-curve moved but nobody changed the baseline." Someone reassigned the Project Baseline to Upd 07 for a comparison. Assign Baselines shows it; I've set it back to BL1-Accepted-DD 01Dec25 and the curve matches the register again. Comparisons go in the user slots β that's what they're for.
"Send the baseline inside the XER." XER doesn't write baselines. The accepted baseline file is in the register as BL1, issued 4 December; I'll re-attach it, or send XML with the baseline embedded if that suits your import better.
"Just update the baseline with the new dates so the report is green." Update Baseline rewrites the accepted programme to match what happened, and the variance vanishes with it. The report is measuring correctly; the slippage is real. If the client wants a new baseline it's a written acceptance and a register row.
π Related pages
- Baseline Approval and Control β the acceptance, the register, the naming
- Revised Baseline vs Recovery Schedule β why the recovery is BL3, never Project
- Slippage and Trend Analysis β the BL1 comparison every month
- CPLI and BEI β what reads the Project Baseline
- Importing and Exporting XER β why the baseline is a separate file
- Splitting In-Progress Activities β the transition-month use of BL2
- Earned Value Basics: SPI and CPI β the EV baseline setting
βοΈ Worked example
Baseline state on a Doha office tower at Update 11 (DD 1 December), the month a 25-day EOT triggered BL1:
| Maintain Baselines | Type | Assigned slot | Purpose |
|---|---|---|---|
| BL0-Accepted-DD 15Jan25-Rev0 | Customer Sign-Off | Secondary (BL2), this month only | Transition comparison |
| BL1-Accepted-DD 01Dec25-Rev0 | Customer Sign-Off | Project Baseline | Register current; EV; DCMA 13/14 |
| Upd10-Accepted-DD 01Nov25 | Monthly Update | Primary (BL1) | Slippage vs previous update |
| Recovery-R2-Target-DD 01Dec25 | What-If | Tertiary (BL3) | Target date shown alongside forecast |
| Upd01 β¦ Upd09 | Monthly Update | None | Kept; register history |
Data limit set to 20 in month one. Project Details β Settings β EV baseline = Project baseline. Register row 2 reads: BL1, acceptance letter E-1044 dated 18 Nov, data date 1 Dec, archived file DOH-OT_BL1_DD01Dec25_v20.xer, SBM Rev 1.
π References
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practice 10
- DCMA 14-Point Schedule Assessment, Metrics 13, 14
- AACE International RP 38R-06, Documenting the Schedule Basis
- PMI Practice Standard for Scheduling, 2nd ed.
- FIDIC Conditions of Contract for Construction, 1999 and 2017, Cl 8.3; NEC3/NEC4 ECC Cl 31.3, 32.2 (check the edition in your contract)
- Oracle Primavera P6 Professional User Guide β Maintain Baselines; Assign Baselines; Project Settings (earned value baseline); Admin Preferences β Data Limits (field labels as in P6 Professional v20; earlier versions differ)
From the field
Notes, corrections and additions from people who've done this on a real job. Everything is checked before it appears here.
Loading notesβ¦
Checked before it appears. No client, project or employer names. Your name is shown; your email never is. Terms.