Lock the Baseline: A Field Checklist for Freezing Your Project Schedule
A schedule baseline is the version of your plan you agree to be measured against. Everything after it — slippage, recovery, claims, change orders — is read against that frozen line. Yet on many projects the "baseline" is just the last file someone saved before the kickoff meeting. In 2022, with materials lead times stretching, trades hard to book, and prices moving week to week, an unanchored schedule quietly becomes fiction. This is a checklist you can run before you commit, so the line you draw actually holds.
Before you freeze it
A baseline you can defend has a few non-negotiable properties. Walk the list below and don't sign off until each item is true. If you can't answer one of these, you are baselining a guess.
Scope is bounded. Every deliverable in the schedule traces to an approved scope document or work breakdown structure. If an activity has no parent deliverable, it shouldn't be in the baseline.
The logic is complete. Run a check for open ends: every task except the start and finish milestones should have a predecessor and a successor. Dangling activities float free and make your dates meaningless.
Durations are estimated, not wished. Each duration should come from a basis — historical productivity, a quote, or a named estimator — not from working backward off a target end date.
Constraints are minimal and justified. Hard constraints ("must finish on") override logic and hide problems. Replace them with real dependencies wherever you can, and document the few that remain.
The critical path is real. Trace the longest path end to end and ask whether it reflects how the work will actually be sequenced. A critical path running through a placeholder is a warning, not a plan.
Resources are loaded where it matters. For the trades and long-lead items that are scarce this year, assign resources so the schedule shows the contention. An unresourced bar assumes labour and materials appear on demand.
Contingency is named, not hidden. Hold schedule reserve as visible buffer activities owned by the project, not as padding smeared across every task where it can quietly evaporate.
The moment of freezing
Freezing is an act, not a state of mind. Save the approved schedule as a named baseline in your tool, record who approved it and on what date, and store a read-only copy outside the working file. From here on, the working schedule and the baseline are two different things — you update the working version, you compare it to the baseline, and you never edit the baseline to make a status report look better.
Set the baseline in the software, not just by re-saving the file.
Stamp it: name, date, approver, and the change-control number that authorized it.
Capture the assumptions log — lead times, crew sizes, and the price and supply assumptions you made in this market — beside the baseline.
Confirm everyone who reports against the schedule knows which version is now the line of record.
After it's locked
A frozen baseline is not a frozen plan. The world moves; the discipline is that the baseline only moves through change control. When a scope change, a delivery delay, or an approved acceleration shifts the work, re-baseline deliberately and keep the prior version. That history is what lets you show, months later, exactly when and why the project diverged — which is the difference between a defensible variance and an argument. Treat the baseline as evidence, not decoration, and the rest of your controls become trustworthy.
If you want a second set of eyes on a baseline before you commit to it — or help standing up schedule controls that hold up under scrutiny — XNM's program & project delivery advisory can help you draw a line you can defend.