What is a project baseline?

A project baseline is a snapshot of your plan, taken and approved at a fixed moment — usually kickoff — and then frozen. It records what you said you would deliver, by when, and for how much. Once it is saved, you do not edit it. You compare reality against it. The baseline is the answer to a question every status meeting asks but most cannot really answer: on track compared to what?

Without a baseline, "we're on track" is an opinion. The end date drifts a few days, then a week, then a fortnight, and because each move felt small and reasonable at the time, nobody can say how far the project has actually wandered from its original promise. The baseline is the line in the sand that makes drift measurable. It is, frankly, the difference between managing a project and just watching one happen.

Scope, schedule, cost — and why we focus on the schedule

A full baseline has three parts, often called the performance measurement baseline:

• Scope baseline — what is being delivered: the agreed list of deliverables and the work behind them, usually captured in a work breakdown structure.
• Schedule baseline — when each piece is planned to start and finish, including the dependencies and milestones.
• Cost baseline — the approved budget, often spread across the timeline so you can see planned spend per month.

The three are linked — change the scope and the schedule and cost move with it — but for most teams the schedule baseline is the one you live and die by, and it is the one a Gantt chart is built to show. The rest of this guide leans on it. The principles apply equally to cost; the picture is just clearer in time.

Baseline, current plan, and actuals — three different things

This is the distinction that trips people up, so it is worth nailing down. At any moment a live project holds three pictures of itself:

Picture	What it is	Does it change?
Baseline	The approved plan, frozen at kickoff.	No — that is the whole point.
Current plan	Your best estimate of the future right now, including replanned dates.	Yes — it updates as you learn.
Actuals	What has genuinely happened: real start and finish dates, real spend.	It only grows — the past is fixed.

Think of a road trip. The baseline is the route and arrival time you committed to before leaving. The actuals are the roads you have actually driven and the time it took. The current plan is your live estimate of when you will now arrive given the traffic so far. All three coexist. Confusing the current plan with the baseline — quietly editing the "plan" until it matches reality — is how a late project convinces itself it was never late.

Planned versus actual, and what variance tells you

Once you have a baseline and you are recording actuals, you can compute variance — the gap between what you planned and what happened. For a schedule:

• Schedule variance is how far ahead or behind a task or the whole project is against the baseline. "Design finished four days later than baseline" is a variance of +4 days.
• Trend matters more than any single number. One task slipping two days is noise. Five consecutive tasks each slipping a little is a pattern that is about to eat your end date.

The value of variance is that it is specific and early. It turns "things feel slow" into "we are nine days behind on the critical path, and it started with the vendor delay in week two." That is something you can act on — by recovering time elsewhere, cutting scope, or telling stakeholders honestly. For the recovery side of that, see handling schedule slippage.

When and how to set one

You set a baseline once the plan is genuinely agreed and approved — not the first rough draft, but the version stakeholders have signed off and committed resources to. Set it too early and you are baselining a guess; set it too late and there is nothing left to measure. The sweet spot is the moment the plan stops being negotiable and becomes a commitment.

The mechanics are mundane, which is the point: you press "save baseline" (or copy the planned dates into a locked column, or export a dated copy of the file) and then you do not touch it. In a Gantt tool this is usually a single action that stamps every task's current start and finish as its baseline start and finish. From then on, the tool can draw the two side by side. If your tool has no baseline feature, exporting a dated PDF or duplicating the file at kickoff is a perfectly honest manual substitute — the discipline matters more than the button.

Showing a baseline on a Gantt chart

The clearest way to display a baseline is as a second, thinner bar sitting directly beneath each live task bar. The live bar shows the current plan or actuals; the baseline bar shows what you originally promised. When the two line up, you are on plan. When the live bar pokes out to the right of its baseline shadow, that task is running late — and you can see by exactly how much, in calendar terms, without reading a single number.

Re-baselining: legitimate reset or hiding the body?

Here is where honesty matters most. Re-baselining means throwing away the old approved plan and setting a new one. Done for the right reason, it is good practice. Done for the wrong reason, it is the single most effective way to erase evidence that a project went off the rails.

Re-baselining is legitimate when the project has genuinely changed in a way the original plan could not have anticipated, and the change has been formally approved:

• Scope was added or cut through a proper change request.
• The budget or deadline was officially moved by the people who own them.
• A major external shock — a key supplier collapsing, a regulation changing — reset the playing field.

Re-baselining is dishonest when it is really just slippage with a fresh coat of paint:

• You are behind, so you re-baseline to today's dates and declare yourself "on track" again — variance reset to zero, problem hidden.
• It happens quietly, without anyone signing off, often right before a status report.
• It becomes a habit — re-baselining every month means you have no baseline at all, just a rolling alibi.

The tell is simple: a legitimate re-baseline is triggered by an approved change to the project; a dishonest one is triggered by the project being late. If you re-baseline, keep the old baseline visible alongside the new one. A project that has re-baselined twice and still shows all three lines is being honest about its history. A project showing only the latest, freshly-aligned baseline is, more often than not, hiding something.

The bottom line

A baseline costs almost nothing to set and pays for itself the first time someone asks whether you are behind. Freeze the approved plan at kickoff, record what actually happens, and let the gap between the two tell you the truth. Treat re-baselining as a serious, approved event rather than a monthly tidy-up, and the baseline stays what it is meant to be: a fixed point you can trust in a project that is otherwise always moving.

Frequently asked questions

How often should I update the baseline?

Almost never. The baseline is meant to be frozen — that is its entire value. You only set a new one (re-baseline) when scope, budget, or the deadline has formally and significantly changed through an approved decision, not because the project is running late.

What is the difference between the baseline and the current plan?

The baseline is the approved plan frozen at kickoff and it does not change. The current plan is your live, best-estimate forecast of the future, which you update as you learn. You compare the current plan and the actuals against the unchanging baseline to see how far you have drifted.

Can I set a baseline in a free Gantt tool?

Yes. Some tools have a dedicated baseline feature that stamps and displays the original dates automatically. If yours does not, you can baseline manually by saving a dated copy of the plan at kickoff and comparing against it — the discipline of freezing the approved version is what matters.

What is schedule variance?

Schedule variance is the gap between when a task (or the whole project) was planned to happen in the baseline and when it actually happened. A finish four days later than baseline is a variance of four days. The trend across many tasks tells you more than any single one.