Baseline vsre-baseline
The baseline is the plan you promised, frozen.
The baseline is the original approved plan for cost and schedule, held fixed so that every later variance has something honest to be measured against. You manage the work to a current plan that changes every update. You never move the baseline to make a variance disappear. When a re-baseline is genuinely needed, it is rare, formally approved, and it keeps the original on the record.
The baseline is the yardstick, not the plan you work to
A project baseline is the approved original plan, fixed at the moment it is accepted: what will be built, by when, for how much, and in what sequence. In earned value practice this time-phased plan is the performance measurement baseline. Planned value is read from it, and schedule and cost variance are the distance between it and what has actually happened.
The current plan is a different thing. It is the working schedule and budget, updated every period with actual progress, resequenced logic, and revised durations. It is supposed to change; that is what managing the work looks like. The baseline is supposed not to. Two documents, two jobs: manage to the current plan, measure against the baseline.
The moment the two become the same file, the job has no baseline. It has a plan that always agrees with itself, and a variance that can never be larger than the last time someone saved over it.
Legitimate re-baseline vs goalpost-moving
Both replace the target the job is measured against. The difference is what triggers it, who approves it, and whether the original survives to tell the story.
| Legitimate re-baseline | Goalpost-moving | |
|---|---|---|
| Trigger | A major approved scope change, an owner-caused delay, or force majeure that makes the original plan unmeasurable | A slip the team would rather not report, usually surfacing at a monthly review |
| What moves | The current plan, and a new baseline version is cut with a formal approval, a date, and a written reason | The target curve, quietly, so that planned value lands wherever earned value already is |
| What is preserved | The original baseline, intact, alongside every later version, so any period can still be measured against it | Nothing. The old plan is overwritten and the history of the slip goes with it |
| Effect on the variance record | The variance is carried forward and explained; CPI and SPI stay comparable across the life of the job | The variance disappears from the metric. SPI reads near 1.0 while the finish keeps slipping |
A worked example
At the data date the original baseline says the job should be 60 percent complete. That is the planned value. The work actually earned is 48 percent. The job is 12 points behind the plan it was approved on, and the schedule performance index, earned over planned, is 0.80. Every planned week is buying about four days of progress.
Now re-baseline quietly. Reset the target so that planned value at today equals 48 percent, exactly where the earned line already sits. Planned and earned are now the same number, so SPI snaps to 1.00 and the 12-point slip vanishes from the metric. Nothing about the job changed. The crews are the same, the remaining work is the same, the real finish is just as far away. Only the yardstick moved.
The original baseline, if anyone kept it, still shows the true gap, and it is growing. Do a second re-baseline at the next review and a chronically late job reads SPI near 1.0 the whole way while it keeps slipping, right up until the finish date arrives and the work does not. That is the cost of moving the baseline: not a wrong number, but a metric that has stopped measuring anything.
The reset, drawn
The dashed line is the original baseline climbing from zero to 100 percent at the planned finish. The amber line is the work actually earned, reaching 48 percent today where the baseline says 60. The shaded wedge between them is the slip. Then the re-baseline: the violet target steps straight down onto the earned point, the gap reads zero, and the new target carries on at a shallower slope, a later finish quietly baked in as if it had been the plan all along.
When a re-baseline is legitimate
Sometimes the original plan genuinely stops being a fair yardstick. A major change in scope is approved and the job being measured is no longer the job that was planned. The owner causes a delay that is formally recognized. A force majeure event takes months out of the calendar that no plan could have carried. In those cases measuring against the original would punish the team for a plan that no longer describes the work, and a re-baseline is the honest move.
Even then, the way it is done is what separates it from goalpost-moving. It is rare, not routine. It is approved by whoever has the authority to accept a new finish date and cost, not by the person whose variance it erases. The trigger is written down. And the original baseline is preserved, versioned and dated next to the new one, so that any period can still be read against the plan the job was actually approved on.
A useful test: could you show the owner both baselines side by side and explain, in one sentence, why the new one exists? If the honest sentence is "because we were behind," it is not a re-baseline. It is a report edit.
The same job, milestone by milestone. Each planned date is the original baseline; each actual date is when the milestone really landed. Foundations finished 17 days late, topping out 35, dried in 49: the slip is widening, and it is only visible because the planned dates were never moved to meet the actuals.
Milestone Tracking
Four ways the baseline gets buried
Resetting planned value to meet earned value makes SPI read 1.0 and tells the owner nothing has happened. The finish date did not move back. Only the yardstick did, and the next review will need another reset.
A schedule file that is saved over each month has no baseline at all, just a current plan that always agrees with itself. Once the original is gone, no one can say how late the job really is.
A legitimate re-baseline is a governance event: someone with the authority to accept a new finish date and cost signs it, and the reason is written down. A re-baseline no one approved is a report edit.
The current plan should change every update, that is what managing the work looks like. The baseline should not. Treating every schedule update as a new baseline is goalpost-moving on a weekly cadence.
A schedule that overwrites itself vs a preserved original
Baseline integrity is not a reporting preference. It is the difference between a variance you can act on and a variance no one can prove ever existed. That comes down to whether the original plan survives each update.
- ·The schedule file is updated in place and the original plan is gone
- ·Planned value drifts toward earned value with every save
- ·SPI and CPI read near 1.0 on a job that is visibly late
- ·The true finish date only surfaces when the calendar runs out
- ·POD reads the schedule and cost data your job produces
- ·The current plan is measured against the preserved original baseline
- ·A re-baseline that would bury a variance is visible, not silent
- ·Every period can still be read against the plan the job was approved on
POD reads the schedule and cost data your job produces and keeps the current plan measured against the preserved original baseline, so a re-baseline that would bury a variance is visible. The metrics themselves live in earned value management and the estimate at completion; the one legitimate reason a baseline moves is usually a change order. This page is about keeping the yardstick honest so those three mean something.
The project controls library
The pillar guide: where baseline integrity sits among cost, schedule, and earned value control.
Planned value, earned value, CPI and SPI. The metrics that only mean something against a preserved baseline.
The forecast a re-baseline quietly distorts, because a reset CPI feeds a reset EAC.
An approved change is one of the few legitimate reasons the baseline is allowed to move.
Revenue recognition depends on a percent complete that a re-baseline can overstate.
The over and under billing report that inherits whatever the baseline says about progress.
Baseline questions
What is a project baseline in construction?▾
A project baseline is the approved original plan for the work: the scope, the schedule, and the budget, fixed at the point the plan is accepted. In earned value practice it is called the performance measurement baseline, and it is the time-phased plan that planned value is read from. Its purpose is to be the fixed reference that every later measurement of cost and schedule performance is compared against.
What is re-baselining a construction schedule?▾
Re-baselining means replacing the approved baseline with a new plan and measuring future performance against the new plan instead of the original. Done properly it is a formal, approved, and documented event that keeps the original on file. Done informally it means resetting the target so that the current position looks on plan, which removes the variance from the metrics without changing anything about the job.
When is it legitimate to re-baseline a project?▾
A re-baseline is legitimate when the original plan can no longer be measured against in good faith: a major approved change in scope, an owner-caused delay that has been formally recognized, or a force majeure event. Even then it should be rare, approved by whoever has the authority to accept a new finish date and cost, written up with the reason, and versioned so the original baseline is preserved alongside it.
What is the difference between the baseline and the current schedule?▾
The current schedule is the working plan. It is updated every period with actual progress, resequenced logic, and revised durations, and it is the plan the crews are managed to. The baseline is the original approved plan, held fixed. You manage to the current schedule and measure against the baseline. When the two are the same file, there is no baseline, only a plan that always agrees with itself.
Why does re-baselining hide schedule and cost variance?▾
Schedule and cost variance are the difference between what the baseline said should have happened by now and what actually has. If the baseline is moved to match the actual, that difference becomes zero by construction: SPI and CPI reset to 1.0 without a single day recovered or a dollar saved. Repeat it at each review and a chronically late, over-budget job reports on plan the whole way, while the true finish date and cost keep moving away from the original promise.
How does POD help keep the baseline honest?▾
POD reads the schedule and cost data your job produces and keeps the current plan measured against the preserved original baseline, so a re-baseline that would bury a variance is visible instead of silent. The original plan stays on record next to each later version, which means planned value, earned value, and the schedule and cost indices are always available against the plan the job was actually approved on.
POD measures the current plan against the original
Begin with the free schedule baseline log, then let POD read the schedule and cost data already moving through your jobs, so a variance stays visible against the plan the job was approved on.