What is a project baseline, and when should you re-baseline?

What a project baseline is

A baseline is a snapshot. At a chosen moment, usually when the plan is approved, you copy every task's start date, finish date, duration and budget into a set of fields that do not change. The live plan keeps moving as work happens; the baseline stays where it was.

There are three baselines, often combined:

• Scope baseline: the approved scope statement, WBS and WBS dictionary.
• Schedule baseline: the approved start and finish dates for every activity and milestone.
• Cost baseline: the approved budget, spread over time. Its cumulative curve is the familiar S-curve.

Together they form the performance measurement baseline used in earned value management. Planned value (PV) at any date comes straight from it.

Why a baseline matters

Without a baseline, you can only say where the project is now. You cannot say whether that is good or bad. A baseline turns "testing finishes on 14 July" into "testing finishes on 14 July, two weeks later than we committed". That second sentence is the one sponsors need.

A baseline also protects the team. When scope grows through approved changes, the baseline history shows exactly when and why the dates moved, which keeps the conversation factual.

How to set a baseline, step by step

1. Finish the logic. Every activity linked, no dangling ends, constraints only where they are real.
2. Check the schedule quality. A DCMA 14-point check catches missing links, excessive lags, hard constraints and high float before you lock them in.
3. Load the budget onto activities or work packages so the cost baseline has a time profile.
4. Review with the team and sponsor. People should commit to the dates, not just receive them.
5. Get formal approval and record who approved and when.
6. Save the baseline in your scheduling tool, and give it a clear name and date ("Baseline 1, approved 3 March").
7. Start reporting variance from the next data date.

Worked example: reading variance against the baseline

An IT rollout was baselined with a budget of $300,000 and a finish date of 30 June. At the end of April:

Milestone	Baseline finish	Forecast finish	Variance
Design approved	14 Feb	14 Feb (actual)	0 days
Build complete	2 May	9 May	5 working days late
User testing complete	6 June	13 June	5 working days late
Go-live	30 June	7 July	5 working days late

On cost, the baseline says $180,000 of work should be done by now (PV). The work actually done is worth $165,000 (EV), and $170,000 has been spent (AC). So:

• Schedule variance SV = EV minus PV = 165,000 minus 180,000 = minus $15,000.
• Cost variance CV = EV minus AC = 165,000 minus 170,000 = minus $5,000.
• SPI = 165,000 / 180,000 = 0.92; CPI = 165,000 / 170,000 = 0.97.

Every one of these numbers depends on the baseline. If the team had quietly re-baselined in April, all variances would read zero and the five-day slip would vanish from the report. That is exactly why re-baselining needs rules. You can test numbers like these in the earned value calculator.

When to re-baseline, and when not to

Situation	Re-baseline?	Why
Approved change request adds significant scope, time or budget	Yes	The old baseline no longer describes the agreed project
Sponsor approves a new end date after a formal review	Yes	The commitment itself has changed
The project is replanned after a long suspension	Yes	Old dates have no meaning
The project is late and nobody approved a change	No	The variance is the information; report it and recover or escalate
Small changes that fit within contingency	Usually no	Absorb them and track them in the change log
The next phase is planned in detail (rolling wave)	Often yes, for that phase	Planned detail replaces a placeholder, within the same total budget and dates

The rule of thumb: a re-baseline follows a decision, never a delay. Keep every earlier baseline, so you can show both the current commitment and the original one.

Baselines in agile and hybrid projects

Agile teams often say they do not baseline, but most still commit to something: a release date, a budget, or a set of features for a funding round. That commitment is a baseline, even if it is not called one.

In practice, hybrid projects baseline at the level where commitments are made. Milestones, release dates and the overall budget are baselined and tracked. Detailed sprint content is not, because it is expected to change. Burn-up charts then play the role that earned value plays in plan-driven work: they compare delivered scope against the committed scope over time.

The same rule applies: if the release date or budget changes, record the decision and save a new baseline, rather than editing the old commitment.

Common baseline mistakes

• Never setting one. Many plans have a live schedule and no baseline, so nobody can say how late the project is.
• Baselining too early, before the logic is complete. You then re-baseline in week two, and the baseline loses credibility.
• Overwriting the only baseline. Save a new one instead, and keep the history.
• Re-baselining to hide slippage. It removes the warning sign, not the problem.
• Schedule and cost baselines out of step. If dates move but the time-phased budget does not, planned value is wrong and every earned value index is misleading.

How to do this in Critova

Critova lets you save unlimited baselines per project, so each approved re-baseline is a new snapshot and the original stays available for comparison. The Gantt chart shows baseline bars under the current plan, milestone variance feeds the status report, and the DCMA 14-point check lists every failing activity before you lock a baseline in. Approved change requests record their budget and date impact, which gives each re-baseline a documented reason. See the scheduling features, and the earned value management guide for how the baseline drives PV.