Project Baselines: Setting, Tracking, and Knowing When to Rebaseline

"Are we on track" is not a question a schedule can answer by itself. A schedule is a living document; it updates every time a task moves, a dependency shifts, or a duration gets revised. Without something frozen to compare it against, "on track" collapses into whatever the PM currently believes, which is a different thing entirely from a measurable fact.

That frozen comparison point is the project baseline: a snapshot of the approved plan, dates, work, and cost, captured at a specific moment and left untouched while the live schedule keeps moving underneath it. Every honest answer to "are we on track" is a comparison between the two.

TL;DR. A project baseline is a frozen copy of the approved plan, task dates, work, and cost, taken at a specific point in time. The live schedule is compared against it to produce variance: how far actual dates, cost, and progress have drifted from what was approved. Set the baseline only once the schedule is validated, not before. Rebaseline when a change goes through the same approval governance the original plan did; don't rebaseline quietly to make a slipping schedule look clean, because that erases the variance signal a baseline exists to produce in the first place.

What a Project Baseline Actually Captures

A baseline is not a copy of the schedule's current state; it's a copy of the schedule's approved state, taken once and then deliberately left alone. Three data points per task make up the useful core of a baseline: baseline start and finish dates, baseline work (effort or duration), and baseline cost. Together, those three let every later comparison answer three separate questions: is this task running on the calendar dates it was supposed to, is it taking the amount of effort it was supposed to, and is it costing what it was supposed to.

The distinction that trips up teams new to baselining: the baseline doesn't update when the schedule changes. If a task's baseline finish date was March 14 and the task actually finishes March 22, the baseline still says March 14 forever, and the 8-day gap is the variance the baseline exists to expose. A PM who edits the baseline to match reality every time something slips hasn't created a baseline; they've created a second live schedule with no comparison value at all.

How to Set a Baseline That's Worth Comparing Against

Setting a baseline is a one-click action in most modern PM tools. Setting one worth trusting for the rest of the project takes more discipline than the click implies. The U.S. Government Accountability Office's Schedule Assessment Guide, one of the most widely cited references on schedule baseline practices in large-program management, ties a credible baseline directly to a validated, dependency-checked schedule rather than treating baselining as a purely administrative step.

1. Validate the schedule before you freeze it. A baseline captures whatever state the schedule is in at the moment it's set, including every dangling dependency, missing predecessor, and constraint conflict nobody caught. Run the free Schedule Health Check against the .mpp or MSPDI export first; baselining a broken schedule produces a baseline that's arithmetically clean and practically meaningless, because every variance calculated against it inherits the underlying error.
2. Confirm the plan is actually approved, not just drafted. A baseline set on a plan that hasn't been through whatever approval process the organization uses, sponsor sign-off, change control board, phase-gate review, isn't a baseline in the governance sense; it's a placeholder that will need replacing the moment the real approval happens.
3. Capture the baseline once, deliberately, not by accident. Most PM tools distinguish "Set Baseline" from ordinary saving. Confirm the action is intentional, not a default that fires every time someone saves the file, which quietly overwrites the comparison point the whole team is relying on.
4. Record why the baseline was set, not just when. A baseline tied to "kickoff approval, March 3" or "Phase 2 scope addition, approved by steering committee June 14" is auditable months later. A baseline with no context attached becomes a mystery snapshot nobody can explain when a compliance review asks about it.
5. Communicate the baseline date to everyone reporting against it. Status reports, dashboards, and variance calculations all need to reference the same baseline. A team where half the PMs are comparing against the original baseline and half against an informal replan produces status numbers that don't agree with each other for reasons nobody can explain in the room.

What Is Baseline Variance, and How Do You Read It?

Baseline variance is the measured gap between what the baseline said and what actually happened, and it comes in two flavors that get read differently. Schedule variance compares actual (or currently forecast) dates against baseline dates: a task with a baseline finish of April 10 that's now forecast to finish April 17 carries 7 days of negative schedule variance. Cost variance compares actual spend against baseline cost, the same comparison earned value management formalizes into CPI and SPI once you're tracking variance in dollar terms rather than just calendar days.

Reading variance well means distinguishing a single noisy data point from a trend. One task running 3 days late against baseline, on a project with 200 tasks, is normal schedule noise; almost every real schedule has some tasks running ahead and some running behind their baseline at any given moment. What deserves attention is a pattern: a specific workstream consistently running late against baseline across multiple tasks, or variance that's been widening for three consecutive status periods instead of holding steady. That pattern is the actual early-warning signal a baseline is built to surface, well before the project as a whole visibly misses its end date.

The diagram above shows why variance needs context, not just magnitude, to interpret correctly. Task D's 11-day slip is the largest number on the chart, but the detail that matters is that it has exhausted its float; the next day of slip on that task pushes the critical path and the project end date with it. A task with 11 days of variance and 20 days of float remaining is a lower-priority watch item than a task with 3 days of variance and zero float left.

Schedule Variance vs Cost Variance: Two Different Baselines

Schedule variance and cost variance measure different failure modes, and a project can post a clean number on one while failing badly on the other. A task running exactly on its baseline dates can still be running over baseline cost if it's consuming more resource-hours than planned to hit that date, overtime, a second contractor pulled in to catch up, expedited shipping on materials. Conversely, a task can finish under baseline cost while running badly behind baseline schedule, if it was simply under-resourced relative to the plan and nobody spent the extra money to keep pace.

Treating these as one combined "how's it going" number hides which lever actually needs pulling. A sponsor who hears "we're a little over" without knowing whether that's a schedule problem or a cost problem can't make an informed trade-off decision. Reporting the two separately, even when they tell a consistent story, keeps the conversation anchored to the specific baseline each number is actually measuring against.

When Rebaselining Is Honest Replanning

Rebaselining, replacing the current baseline with a new snapshot, is legitimate the moment a formally approved change genuinely invalidates the old comparison point. A sponsor approves a scope addition in month 6 that adds three months of real work; comparing the rest of the project against a baseline that predates that approval produces variance numbers that are technically accurate and practically useless, because they're measuring against a plan the organization no longer intends to deliver.

The governance test is simple: did this change go through the same approval process the original baseline went through? A formally approved scope change, a signed change order, a steering committee decision to extend the timeline, all clear that bar. When they do, rebaseline deliberately: preserve the old baseline as an archived record (most tools support multiple named baseline slots for exactly this reason), document why the new baseline was set, and communicate the change to everyone reporting against the old one.

When Rebaselining Is Hiding a Slip

The same mechanical action, resetting the baseline, is dishonest the moment it happens without approval, purely to make a slipping schedule's variance numbers look clean again. A PM whose project is running two weeks behind and who quietly re-baselines to the current dates hasn't fixed anything; they've deleted the evidence that anything went wrong, and the next status report shows a project magically back "on track" with no explanation for how.

This is the uncomfortable version of the judgment call every PM eventually faces, and it's worth naming directly because the pressure to do it is real: a project two weeks behind looks bad in a status meeting, and quietly resetting the baseline makes that discomfort disappear on the page without making it disappear in reality. The organizations that catch this pattern require baseline changes to go through the same visible approval the original baseline required, no exceptions for "just tightening things up." The ones that don't catch it end up with a portfolio full of baselines nobody trusts, because everyone's learned that a clean-looking status report might just mean the baseline moved, not that the work did.

How Many Baselines Should You Keep?

Most projects need somewhere between one and four meaningful baselines over their life: the original approved plan, and one for each subsequent formally approved change to scope, schedule, or budget. That's a governance answer, not a technical limit; most PM tools support far more baseline slots than any project should actually use.

The classification test for whether a given baseline snapshot is worth keeping is the same test used when migrating baseline history off a legacy tool: is this baseline referenced in any change control record, contract, or audit document? Is it the basis for a current variance calculation? Was it set at a formal approval event? A baseline that gets a yes to any of those is worth keeping as a named, documented snapshot. A baseline that was set as an informal "let me see where we'd land if" save, then forgotten, doesn't need to survive as clutter in the project file.

Building a Baseline Discipline That Survives Contact With Reality

1. Validate before you baseline, every time. A dirty schedule produces a baseline that inherits every hidden problem and reports it back with false precision for the rest of the project.
2. Set the baseline at a named approval event, not a Friday afternoon. Tie every baseline to a specific, documented decision so a later audit or steering committee question has a clear answer.
3. Report variance against the baseline consistently, every reporting period, on the same cadence. Skipping a period to avoid reporting a bad number is a softer version of the same dishonesty as a quiet rebaseline.
4. Require visible approval for any rebaseline, the same governance the original baseline went through. No informal resets, no exceptions for "just cleaning up."
5. Keep the old baseline when you set a new one. Archive it rather than overwrite it; the comparison between old baseline, new baseline, and actual is often more informative than either baseline alone.

Every formula built on top of a baseline, variance, earned value's CPI and SPI, forecast completion dates, inherits whatever discipline, or lack of it, went into setting and maintaining the baseline itself. Get that discipline right and the baseline becomes the most reliable number in the project. Get it wrong and every report built on top of it is precise, documented, and quietly fictional.

Validate your schedule before you baseline it Run the free Schedule Health Check against your .mpp or MSPDI export to catch dangling tasks, broken dependencies, and constraint conflicts before you freeze a baseline on top of them. No signup required. → Open the Schedule Health Check