Schedule Variance Baseline: Reading Drift Patterns

"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. A schedule variance baseline reading is what turns "on track" from an opinion into a number: freeze the plan at week 0, compare it against the same tasks' actuals at week 6, and the gap tells you something specific, if you read the shape of it rather than just its size.

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. Two projects can post the identical negative variance number and be failing for entirely different reasons: one from a bad original estimate, one from a resource getting pulled mid-task, one from scope nobody put through change control. The worked example below shows how to tell which is which from the same week-0-to-week-6 data.

TL;DR. A schedule variance baseline reading compares a frozen baseline (dates and work approved at week 0) against the same tasks' actuals later, producing schedule variance (a date gap) and SPI (earned value ÷ planned value). The number alone doesn't diagnose the cause. Estimating error shows up early and holds steady in proportion to work done; resource starvation shows a sharp elbow at the week a resource was reassigned; quiet scope creep shows hours burned above baseline while the original scope's earned value still looks roughly on pace. Read the shape of the drift, not just its magnitude, before deciding what to fix.

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.

Reading a Schedule Variance Baseline: A Worked Example

Here is a schedule variance baseline reading run on one real-shaped plan: four tasks, baselined at week 0, checked again at week 6. The portfolio-level number is the same kind of number every status report shows. What it hides, until you break it apart, is that three of the four tasks are drifting for three unrelated reasons.

Task	Baseline work (hrs)	Earned value at week 6 (hrs)	What actually happened
Design spec	40	40	Finished on its baseline date, no drift
Vendor integration build	80	40	Contractor reassigned to a production incident twice; work stalled, didn't slow down gradually
Data migration scripts	60	42	70% "done" by the PM's own estimate, but the remaining 30% turned out to need a rewrite nobody scoped at week 0
UAT environment prep	40	54	Three extra environments added by a stakeholder in week 4, never logged as a change

Baseline planned value through week 6 across all four tasks is 220 hours. Earned value, the baseline-weighted work actually completed, is 176 hours. That gives an SPI of 176 ÷ 220 = 0.8: the project has completed 80% of the work it should have finished by this point, or roughly 44 hours of schedule variance in hours-behind terms. A sponsor reading only that 0.8 sees a project running behind. They don't see that the four tasks behind that single number needed four different conversations.

What Your Baseline Drift Pattern Actually Means

The portfolio SPI of 0.8 above is one number covering three distinct failure modes, and treating them as the same problem produces the wrong fix.

Estimating error (the data migration scripts task). The task's variance didn't appear suddenly; the effort was undercounted from week 0, and the gap between planned and actual widens in roughly the same proportion as work progresses. The signature is a variance that was baked in at baselining, not one that developed later. The fix is a better estimate on the next similar task, not a resourcing conversation on this one.

Resource starvation (the vendor integration build task). The task tracked close to baseline until a specific week, then stalled hard when the contractor got pulled onto a production incident. The signature is a sharp elbow tied to a datable event, not a gradual drift. The fix is a resourcing decision: get the contractor back, or accept the task's new finish date and replan around it.

Quiet scope creep (the UAT environment prep task). This is the one status reports miss most often, because the earned-value math on the original baseline scope can look almost fine even as the task burns more hours than baselined. The tell is in the ratio: hours consumed exceed baseline hours, but nobody logged a change request for the three extra environments that caused it. The fix isn't a schedule fix at all; it's enforcing that new scope goes through the same approval the original baseline did, per the earned value discussion below.

Reading the shape, not just the size, of each task's drift is what separates a status report that assigns the right owner to the right fix from one that just reports a single number and lets everyone guess.

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. The rest of the blog's Schedule Analysis series covers the surrounding practice, from critical path math to resource leveling, that a trustworthy baseline reading depends on.

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