Why baseline integrity matters
A baseline schedule is the single most important artefact in any project controls framework. It defines the agreed plan against which all progress, earned value, and schedule performance will be measured. In Primavera P6, baselining is a specific technical process, but its implications extend well beyond the software: the baseline schedule P6 stores becomes the contractual, commercial, and operational reference point for the entire project lifecycle.
Commercially, the baseline underpins every earned value calculation. Budgeted Cost of Work Scheduled (BCWS) derives directly from the time-phased resource and cost loading within the baseline. If the baseline is flawed -- activities missing logic, durations that cannot be substantiated, resources unloaded -- then Schedule Performance Index (SPI) and Cost Performance Index (CPI) become unreliable, and forecasts based on these metrics lose credibility with client PMOs.
Under NEC contracts, the Primavera P6 baseline takes on additional contractual weight. The accepted programme under Clause 31 governs float ownership discussions, compensation event assessments, and delay analysis. A poorly constructed baseline that gains acceptance locks in unrealistic logic and creates a reference point that works against the contractor in disputes. Conversely, a well-constructed baseline protects the contractor's commercial position and supports robust time impact analyses.
Pre-baseline checklist
Experienced planners never baseline a schedule that has not passed rigorous quality assurance. The consequences of premature baselining -- locking in errors that persist throughout the project -- far outweigh the time invested in thorough pre-baseline review.
Logic completeness. Every activity must have at least one predecessor and one successor, excepting the project start and finish milestones. Open-ended activities distort float calculations and conceal critical path issues. In P6, use the Schedule Log or filter on activities where predecessor or successor count equals zero. Logic density should typically fall between 1.2 and 2.0 for a well-developed construction schedule.
Constraint validation. Constraints override logic-driven dates and should be used sparingly. Mandatory constraints (Must Start On, Must Finish On) sever the network. Start No Earlier Than constraints are appropriate for genuine external dependencies -- planning permission dates, equipment deliveries, third-party interfaces -- but not to force a desired sequence. Filter the activity table for all constrained activities and verify each has documented justification.
Calendar assignment. Activities assigned to incorrect calendars silently distort the schedule. Verify that each activity references the appropriate calendar for its work pattern and that calendars reflect actual working arrangements, including bank holidays and site shutdowns.
Resource and cost loading. If earned value analysis is required, resources and costs must be loaded before baselining. The baseline captures resource assignments and cost distributions at the point of snapshot; adding them afterwards means the performance measurement baseline will not reflect the planned expenditure profile.
Critical path review. The critical path must be logical, continuous, and representative of the genuine longest path. Use P6's Longest Path filter to trace the critical path from data date to project completion. Near-critical paths (within five to ten working days) should also be reviewed as potential alternative critical paths.
DCMA 14-point assessment. Running a Defence Contract Management Agency-style health check before baselining provides a structured quality gate covering logic density, constraint usage, high float, negative float, missed tasks, and relationship types. Whilst not all thresholds suit every project type, the framework provides disciplined pre-baseline validation that many client PMOs now expect.
Step-by-step baseline creation in P6
Once the schedule has passed quality assurance, creating the baseline in Primavera P6 follows a defined process.
Step 1: Schedule the project. Run the scheduler (Tools > Schedule, or F9) to ensure all dates are current. Set the data date to the project start date for an initial baseline. Review the scheduling log for errors and resolve them before proceeding.
Step 2: Navigate to Maintain Baselines. Go to Project > Maintain Baselines. This opens the baseline management dialogue where existing baselines are listed and new ones can be created.
Step 3: Add a new baseline. Click "Add" to create a new baseline. P6 creates a complete copy of the current schedule data -- all activities, logic, resource assignments, cost loading, and WBS structure. For the initial performance measurement baseline, this will be assigned as the Project Baseline.
Step 4: Apply a clear naming convention. Include the project identifier, baseline purpose, revision number, and date -- for example, "PRJ-001 PMB Rev.0 2026-07-04". Avoid generic names like "Baseline 1" that become meaningless when multiple baselines accumulate. Define the convention in the project execution plan and apply it consistently across the portfolio.
Step 5: Assign the baseline. Via Project > Assign Baselines, assign the snapshot as the Project Baseline. This tells P6 which baseline to use for earned value variance calculations. A User Baseline can also be assigned for additional comparison purposes.
Step 6: Protect the baseline. In a multi-user P6 EPPM environment, restrict edit access through Oracle's security profiles. The baseline should remain unchanged unless formal re-baselining occurs through proper change control.
NEC3/NEC4 Clause 31 requirements for accepted programmes
Under NEC3 and NEC4 ECC, Clause 31 establishes the programme as a contractual instrument. The accepted programme effectively becomes the contractual baseline, and planners producing a Primavera P6 baseline that serves this purpose must understand the specific requirements.
Clause 31.2 specifies the contractor must show on each programme: the starting date, access dates, Key Dates, and the Completion Date; planned Completion; the order and timing of operations; the order and timing of the work of the Employer and Others; dates for meeting Conditions for Key Dates; provisions for float and time risk allowances; method statements for each operation; and other information the Scope (NEC4) or Works Information (NEC3) requires.
Float ownership is critical. Terminal float -- the difference between planned Completion and the contractual Completion Date -- belongs to the project, not exclusively to either party. This distinction matters profoundly when compensation events are assessed under Clause 63.5. The baseline schedule P6 stores must clearly distinguish between total float within the network and terminal float to the contractual Completion Date.
Each revised programme under Clause 32 must show actual progress on each operation and the effects of implemented compensation events. The baseline must therefore be structured for clear comparison between planned and actual progress. A schedule that passes a DCMA health check but omits NEC-required information -- method statements, float provisions, interface dates -- may still fail acceptance.
Common baseline mistakes
Premature baselining. Pressure to "lock down" the baseline leads planners to freeze schedules with placeholder durations, incomplete logic, or unverified resource loading. Every subsequent earned value report then reflects a flawed plan rather than genuine performance.
Missing logic. Schedules with open-ended activities or activities linked through date constraints rather than genuine logic produce baselines that cannot support meaningful critical path analysis. This becomes acutely problematic in delay analysis, where the forensic planner must demonstrate how a delay event affected the critical path.
Over-constrained schedules. Excessive mandatory constraints create rigid schedules where activities show zero float because a constraint prevents movement, not because they are genuinely critical. Over-constrained baselines are particularly damaging in delay analysis, where logic-driven criticality must be distinguishable from constraint-driven immobility.
Not removing progress before baselining. If the schedule contains actual dates and percent complete values from prior progress tracking, baselining captures partly completed work rather than the original plan. Before saving the baseline, clear all actual dates, reset percent complete to zero, and ensure remaining durations match original planned durations.
Inconsistent WBS alignment. A baseline WBS that does not align with cost accounts and earned value work packages creates reconciliation problems. The WBS must map to the cost breakdown structure, reporting requirements, and contractual payment milestones.
Monitoring baseline performance
Baseline Execution Index (BEI). BEI measures the ratio of tasks that should have been completed (per the baseline) to those actually completed. A BEI of 1.0 means activities are completing at the planned rate. It complements earned value indicators by focusing on task completion rather than cost-weighted performance, providing early visibility of schedule slippage.
Schedule variance. In earned value terms, SV = BCWP - BCWS. Negative SV indicates the project has earned less value than planned. However, monetary SV converges to zero as the project approaches completion regardless of timeliness, so time-based metrics should supplement it.
Finish variance. Calculated as baseline finish date minus current forecast finish date, finish variance quantifies slippage in working days. In P6, display it as a column in the activity table and monitor it on critical and near-critical activities for early warning of project-level delays.
Earned value metrics. With complete cost loading, P6 calculates BCWS, BCWP, ACWP, SPI, CPI, and EAC forecasts. Monthly reporting should include trend analysis of SPI and CPI with narrative explanation of significant movements. A declining SPI trend, even above 1.0, warrants investigation.
When and how to re-baseline
Re-baselining must be treated as a formal change control event. Resetting the baseline to conceal slippage destroys the integrity of the performance measurement system and can have serious contractual consequences.
Legitimate triggers. Re-baselining is justified following approved scope changes that materially alter the schedule, client-directed acceleration or deceleration, force majeure events, or contract variations that add or remove significant work packages. The decision must be documented, approved by the project controls lead and the client where contractually required.
Maintaining the audit trail. Never overwrite or delete the original baseline. Save the new baseline with a clear revision identifier (e.g., "PMB Rev.1") and retain Rev.0 for audit. P6 stores multiple baselines per project, providing the documentary evidence needed for dispute resolution and project close-out.
NEC contractual requirements. Under NEC contracts, re-baselining means submitting a revised programme for acceptance under Clause 32, showing implemented compensation events, actual progress, and the revised plan. The project manager's acceptance establishes the new contractual reference point.
Impact on earned value. Re-baselining resets the planned value curve. Performance from the re-baseline date forward references the new baseline, whilst prior performance remains against the original. This discontinuity must be communicated clearly in reports. Some organisations maintain parallel calculations against both baselines for transparency.
How a planning consultant adds value in baseline management
Baseline management is where specialist planning consultants deliver disproportionate return on investment. The consequences of poor practice -- unreliable earned value, compromised contractual positions, eroded stakeholder confidence -- far exceed the cost of getting it right from the outset.
An experienced P6 planning consultant brings structured quality assurance, challenging unrealistic durations and logic assumptions and ensuring the schedule meets both technical quality standards and contractual requirements before the baseline is frozen. Their independence from the delivery team means assessment is objective and credible.
On NEC contracts, a consultant with contract awareness ensures the accepted programme complies with Clause 31.2 requirements, structuring the schedule to clearly show float ownership, method statements, and interface dates. When compensation events arise, a well-structured baseline enables efficient time impact analysis that withstands scrutiny from adjudicators.
For multi-project organisations, consultants establish baseline management procedures -- standardised naming conventions, quality gates, change control, and reporting formats -- that are repeatable and auditable across the portfolio. They also provide training and mentoring, building internal capability so that the organisation sustains good practice independently.