Skip to content
Learn

What is a project baseline?

The current plan always looks intentional. A baseline is how you remember what you actually promised.

The problem baselines solve

A live schedule is edited constantly: tasks slip, get split, move owners. Each edit is reasonable, and after three months of reasonable edits the chart shows a plan that ends in November, looking exactly as deliberate as the one that ended in September. Nothing on the screen admits that anything drifted. That is the trap of only ever seeing the current plan: it silently becomes the story everyone remembers.

A baseline is a frozen snapshot of the schedule at the moment you committed to it, every task's start and finish, kept unchanged no matter what happens to the live plan. It costs one click and it changes the nature of every status conversation afterwards.

Variance: the honesty number

With a baseline set, every task has a variance: the difference between where it is now and where the baseline said it would be. "Backend, +6 days." "Design, on baseline." Summed and trended, variance answers the question status meetings usually dodge: are we drifting, how fast, and where?

  • A single task with big variance is a local problem: staff it, split it, unblock it.
  • Small variance appearing on many tasks every week is systemic: estimates are thin, someone is overloaded, or scope is leaking in through the side door.
  • Variance concentrated on the critical path is the one that moves your end date, cross-check with the critical path before reacting.

The discipline part

Baselines only work if re-baselining is rare and honest. Reset it at every slip and the variance is always zero, you have deleted your own instruments. The legitimate moments: an approved scope change, a genuine re-plan, a new phase. In each case the old baseline did its job (it recorded that the promise changed) and the new one starts the clock again, on purpose, in the open.

A bonus use: the undo of last resort

Because a baseline is a complete snapshot, a tool can also restore the plan from it, rolling every date back to the promise. That turns baselines into a safety net for experiments: try the aggressive what-if reshuffle, and if it turns out to be a mistake, come back whole.

Common questions

When should I set the baseline?

The moment the plan is agreed and before work starts, at kickoff, right after the team and stakeholders said "yes, this is the plan". Setting it earlier freezes a draft; setting it later erases the early drift you most want to see.

When is it OK to re-baseline?

When the PLAN legitimately changed: approved scope change, a re-plan after a major event, a new phase. It is not OK to re-baseline just because the variance got embarrassing, that is deleting the evidence. A useful habit: say out loud what changed and why before pressing the button.

What does variance actually tell me?

Direction and speed of drift. A task showing +4 days variance slipped four days against the promise. A project whose total variance grows a little every week has a systemic problem (estimates, staffing, scope leaking in), not a one-off accident. Without a baseline, this signal simply does not exist.

Baseline vs critical path, which do I watch?

Both, they answer different questions. The baseline answers "how far are we from what we promised?" (looking backward). The critical path answers "what decides the end date from here?" (looking forward). A healthy weekly review glances at both: variance for honesty, critical path for action.

Can I restore a plan from a baseline?

In GanttPulse, yes: a baseline is a full snapshot of the schedule, so besides measuring against it you can roll the plan back to it, useful after a what-if experiment goes wrong or a bulk change turns out to be a mistake.

Related: how to plan a project with a Gantt chart · seeing team overload before it happens

Baselines, variance KPIs and restore, built in

GanttPulse is free during the beta. Local-first, one-time license, no cloud account.

Join the free beta