Primavera P6 Baseline management.

What a baseline actually is

A baseline in Primavera P6 is a saved snapshot of the entire project at a point in time. It captures activities, durations, start/finish dates, relationships, calendars, resource assignments and costs — everything that defines the plan.

Once captured, the baseline never changes unless you deliberately update or replace it. The current schedule keeps evolving with progress and re-planning. Reporting is always about the delta: current vs baseline.

The three baseline types in P6

• Project Baseline — the single default baseline for the project, visible to every user. Typically the approved original plan.
• User Baseline (Primary) — a per-user selection from the baseline pool. Lets one planner compare against a different snapshot than another user.
• User Baseline (Secondary/Tertiary) — additional per-user comparisons for side-by-side analysis of two historical points.

P6 supports up to 50 baselines per project, so you have room to retain the original baseline, each formally-approved revised baseline, and interim internal snapshots taken at monthly cutoffs.

Capturing a baseline: the discipline

1. Freeze the current schedule — no last-minute activity edits
2. Run F9 (schedule) so all dates are consistent
3. Project menu → Maintain Baselines → Add → Save a copy of the current project as a baseline
4. Name it clearly — e.g. BL0 — Contract Award 2026-09
5. Set it as the Project Baseline (Assign) so all reports pick it up
6. Document the baseline in a formal record (baseline register, memo to the Engineer)

Baseline comparison views

Once the baseline is assigned, P6 lets you display baseline dates alongside current dates on the Gantt (Bars → Baseline). Standard columns for reporting include:

• BL Project Start / Finish — the baselined dates
• Start / Finish — current dates
• Variance — BL Project Finish Date — how many days ahead or behind (negative = slippage)
• Variance — BL Project Duration — duration slippage

Layouts that show these columns alongside activity name, WBS and total float become your weekly review sheet.

Baseline and EVM

Baseline data is what feeds Earned Value Management. Planned values (PV / BCWS) come from the baseline; earned values (EV / BCWP) come from progress against baseline scope. Without a properly captured cost-loaded baseline, EVM outputs are just derived numbers with no defensible plan behind them.

Re-baselining: when to, when not to

Every re-baseline breaks the historical continuity of variance reporting. Old baseline comparisons become meaningless; EVM curves get a break-point. Re-baseline only in formal circumstances:

• A major variation instruction has fundamentally reset the plan
• An approved Extension of Time has changed the completion date
• A formal re-planning exercise has been jointly agreed by Contractor and Employer

Even then, never delete the original baseline. Keep it as BL0 forever. Add revised baselines as BL1, BL2, etc.

Baseline and delay analysis

Every delay-analysis method depends on baseline discipline. Time Impact Analysis inserts a delay event into the schedule as of a specific data date and compares against the baseline in force at that point. Windows Analysis works over successive windows, each with its own baseline reference. Collapsed As-Built removes delay events from the as-built to reveal what would have happened without them — against the baseline.

Deeper: Primavera P6 delay analysis.

Common baseline mistakes

• No baseline captured before work starts — the classic. All reporting becomes contested.
• Baseline never formally accepted by the Engineer — the numbers exist but have no contractual weight.
• Silent re-baselines — overwriting BL0 instead of adding BL1. The original plan disappears from history.
• Baseline captured after progress started — contamination; can't distinguish plan from progress.
• Baseline uses different WBS than current — WBS changes post-baseline break rollup comparability.

FAQ