Schedule Assurance
How to Review a Primavera P6 Baseline
The baseline you accept is the one you'll be measured against — and the one every future delay claim is argued from. Here's how to review one before you sign it off.
Accepting a baseline is one of the most consequential things a controls function does, and one of the most rushed. Get it wrong and every downstream number inherits the error.
Start with scope, not dates
Before touching logic, confirm the programme actually contains the full scope of works. Missing scope is the most common and most damaging defect — and the hardest to argue about later.
Test the logic
Every activity should have a predecessor and a successor. Relationships should be predominantly finish-to-start, with leads and lags justified. The real test: push a key activity out and see whether completion moves sensibly. If nothing moves, the logic isn’t doing its job.
Interrogate the critical path
The critical path should run through genuinely constraining work, and should be reconciled against the longest path. If it threads through trivial activities, constraints or logic are distorting it.
Constraints, durations, acceptance
Most hard constraints should not be there; each one needs justification. Durations should trace to a resourcing basis, not round numbers. And acceptance should be recorded as “a sound measure of record” with any qualifications noted — not as agreement on the dates themselves.