Your Schedule Didn't Slip — Your Baseline Disappeared

Month five. The sponsor asks: "So how far behind are we?" The PM answers: "About three weeks." The sponsor asks again: "Three weeks behind what? What was the original plan?"

The room goes quiet — because there are several things that could be called "the original plan." The kickoff plan. The plan after requirements were added. The plan redone after losing a key engineer. Somewhere along the way, the latest plan quietly became the original plan. Worse than being three weeks late is the fact that nobody can say three weeks late relative to what.

Measurement without a reference is not measurement

"Three weeks behind" is a measurement, and every measurement needs a reference point. "I've gained weight" means nothing without "since when." In projects, that reference point is called the baseline: a frozen snapshot of scope, schedule, and cost as approved at a point in time.

What happens on a project without one is always the same.

Each time the plan is revised, it overwrites the previous version. Delay is then only ever measured against "the most recently revised plan," so each slip looks small. Ten slips of three days is a month — but without a record, the accumulation is visible nowhere. This is how projects sink quietly: not through one big accident, but through the disappearance of the reference point.

Scope is even worse. As requirements trickle in, the absence of a baseline turns "what was the original scope?" into a debate. The PM usually loses that debate. The side without documentation always does.

A baseline is a discipline, not a document

The PMBOK prescribes two mechanisms.

First, freeze a snapshot at approval. The moment a plan is approved, store the entire WBS, schedule, and cost — and never edit it again. The never edit part is the point. A baseline isn't corrected; it's superseded (re-baselining), and superseding requires formal approval.

Second, manage every change as a delta against the baseline. When a change request arrives, assess its impact on schedule, cost, and scope relative to the baseline, and record the decision of whoever holds approval authority (the CCB, change control board). Let that record accumulate, and by month five you can answer the sponsor like this: "We are three weeks behind the approved baseline — two weeks attributable to approved CR-007 and CR-011, one week of pure slippage."

Same "three weeks," entirely different weight. The first answer sounds like an excuse; the second sounds like control. And it is: the second PM actually has the project under control.

Baseline, Forecast, Actual: three dates you must not confuse

The most common failure point in practice is confusing these three concepts.

Delay is Forecast minus Baseline. With only Actuals and Forecasts you can say "we're later than we expected," but never "we're later than we promised." And what the sponsor cares about is always the latter.

Before freezing a baseline, verify four preconditions: an approved WBS (passing Part 1's 100% Rule), a schedule computed from dependencies, documented key assumptions (staffing, external dependencies, exchange rates — whatever the plan stands on), and confirmed budget/resource figures. A snapshot frozen with any of these missing is not a reference — it's a liability.

The five steps of change control

For a baseline to stay alive, every change must flow through this path — and only this path.

1. Intake — receive the change request in a form (a verbal request is not intake)
2. Impact analysis — estimate the schedule/cost/scope delta against the baseline
3. Approve / reject — the CCB (or designated authority) decides, and the decision is recorded
4. Record the delta — register the approved change as a difference against the baseline (assign a CR number)
5. Update the forecast — reflect it in the forecast schedule and notify stakeholders

With this path in place, the sponsor report collapses into one sentence:

"The current forecast is 15 days behind baseline — 10 days from approved scope changes (CR-007, CR-011), 5 days of execution slippage, and here is the recovery plan for the slippage."

The moment you report the composition of the delay rather than its total, reporting turns from excuse into control.

When to re-baseline

Knowing when to let a baseline go matters as much as the discipline of keeping it.

• Keep it: changes explainable by individual CRs; cumulative delta still manageable
• Consider resetting: when accumulated approved changes have made the original reference meaningless (rule of thumb: delta exceeding 15–20% of the total), or when the business objective itself has changed
• Principles: re-baselining always requires sponsor approval, and prior baselines are preserved, never deleted. It is not laundering slippage through a reset — it is making a new promise, formally

Why everyone knows this and nobody does it

No PMP is unfamiliar with baselines. The reason they vanish in practice is simple: maintained by hand, the cost is too high. Keeping a baseline in Excel means copying files, date-stamping them, and diffing two spreadsheets at every change. In a busy week, this is the first work to be skipped.

One principle we set while building a PM tool: a baseline must be a first-class object in the system, not an auxiliary file. If snapshots freeze automatically and every change displays as a delta against the reference, the cost of the discipline approaches zero. Discipline enforced by structure outlasts discipline enforced by willpower.

There's also something you can do today. Make a copy of the current plan, date it, lock it read-only, and announce to the team: "From today, every delay and every change is stated relative to this file." That one sentence resurrects the reference point.

Slipping is not a sin. Not knowing what you slipped from is.

The PM's action block

Three things to do tomorrow

1. Copy the current plan, date-stamp it, lock it read-only, and announce it as "the reference from today"
2. Inventory all in-flight change requests and assign CR numbers — retroactively if needed
3. From the next report onward, use the format: "N days against baseline, of which N from approved changes + N from execution slippage"

Questions to ask in the next meeting

• "This delay — relative to what? When was that reference approved?"
• "Has this change's baseline impact been estimated? Does it have a CR number?"
• "What's our cumulative delta as a percentage? Is it time to discuss re-baselining?"

Good signs / bad signs

What a tool should solve

The reason baseline discipline collapses is maintenance cost. So in wbsgantt we made the baseline a first-class object rather than a file copy — frozen automatically at approval, drawn as a reference line beneath the current schedule on the Gantt, with every change recorded as a delta. When the cost of the discipline reaches zero, what remains is judgment.