Schedule Baseline: What It Is and When to Freeze It
Without a baseline, "are we behind?" has no answer — there's nothing to compare against. With a poorly managed baseline — one that shifts every time something goes wrong — the answer is always "no," and it's also a lie. This is about doing it right.
What it actually is
The schedule baseline is the version of the plan that's formally approved and stored separately, against which real progress is measured for the rest of the project's life. It isn't "the plan" — the plan stays alive and keeps changing. The baseline is the snapshot of that plan at the moment the sponsor said "go."
In practice, for each task it stores three things: planned start date, planned finish date, and budgeted work/cost. From there, any actual date recorded gets compared against that reference and produces a variance in days. The sum of all those variances is what the committee calls "the delay."
Baseline vs. current plan. A good Gantt shows both bars at once: the baseline as a shadow bar behind, and the current plan in front. The distance between them — +8d, +3wk — is the accumulated drift. If you never see that shadow, or it's always glued to the current bar, there's no baseline — there's a plan that keeps rewriting itself.
Why there's no earned value without a baseline
Earned value rests on three figures. Two of them are born from the baseline:
- PV (planned value) — how much work you should have done today per the baseline. Without frozen dates and budget, PV doesn't exist.
- BAC (budget at completion) — the sum of the baseline cost of every work package. It's the denominator behind half of EVM.
That's why the order matters: freeze the baseline first, and only then do CPI and SPI mean anything. An SPI calculated against a plan that moved last week will always land close to 1 — because you're comparing the plan against itself.
When to freeze it
Not too early, not too late. The right window is when these four conditions are met:
- Scope is approved. If the "what" is still under discussion, any schedule is provisional.
- The WBS is decomposed into estimable work packages (rarely more than two weeks each).
- Dependencies are defined. You know which task drives which, and with what lag.
- Key resources are confirmed. Not nominally — by name and real availability.
This usually coincides with the end of the planning phase and the sign-off of the expanded charter or project management plan. Freezing it earlier is fixing a fiction; freezing it three months after kickoff means giving up on measuring the start — usually where the time nobody gets back is lost.
When NOT to touch it
The default rule is: the baseline doesn't move. A delay isn't fixed by re-baselining — it's fixed with a recovery plan or a scope decision. Moving the baseline to turn the status color back to green is the schedule equivalent of the boiling-frog pattern: it hides the debt until it explodes.
Situations that don't justify a re-baseline:
- The team is moving slower than estimated. That's exactly what the baseline is meant to capture.
- A known risk materialized. That's what the reserve was for.
- The committee is uncomfortable with the variance. The problem is the variance, not its measurement.
When to genuinely re-baseline
Re-baselining is legitimate when the reference has stopped describing the project actually being executed. Clear cases:
| Trigger | Why |
|---|---|
| Approved scope change | Work enters or leaves via formal change control. The baseline absorbs that delta and is re-approved. |
| Authorized major reschedule | The sponsor accepts a new, documented finish date (not a silent slip). |
| Suspension and reactivation | The project sat idle for weeks due to an external cause; measuring against dates that ran in a vacuum adds nothing. |
| Structural error in the original plan | A misplaced dependency or a forgotten phase — not a bad estimate. It's corrected and re-approved. |
In every case: with formal approval, with a date, and keeping the previous baseline. A healthy project has one or two baselines over its whole life. Five is a red flag in itself.
Always keep the original baseline. Even if you re-baseline, that first snapshot is the most honest data you'll ever have about how this project was really planned — and about how your organization plans. That comparison, repeated across several projects, is worth more to a PMO than any single report.
Where it shows up day to day
Once frozen, the baseline appears in three places in day-to-day tracking:
- In the Gantt — a shadow bar behind each task and a variance label (
+Nd) on the ones that have drifted. - In the report's milestones — baseline date, current estimated date, and variance in days, for the next 3–5.
- In EVM — it feeds PV and, through it, SPI and closeout forecasts.
If keeping those three views in sync by hand feels like extra work, that's because it is. The discipline of freezing and not touching the baseline belongs to the team; propagating it to every indicator should belong to the tool.
PMOvio freezes the baseline in one click
Shadow bar in the Gantt, per-task variance, milestones with day-level drift, and the PV behind earned value — all from the same baseline. 15 days free, no card required.
Plan my project →