Project baseline and schedule variance: a practical guide

A schedule changes every week: tasks finish early or late, dependencies push dates forward, new information arrives. Without a fixed reference, the Gantt chart only shows where the project is today, not how far it has drifted from what was agreed. The baseline is that reference: a snapshot of the approved plan that every later version is compared with.

This guide explains what a baseline contains, when to save it, how to read the variances it produces and, above all, when a new baseline is legitimate and when it only hides a delay.

What a project baseline is#

A baseline is a frozen copy of the schedule at the moment it was approved. Baseline is one of the standard terms of project management, listed in PMI’s lexicon of project management terms^[1]. In practice, for each task it records:

• the planned start and planned finish;
• the planned duration in working days;
• for summary tasks, the same values calculated on the tasks below them.

Many tools can also store planned work and planned cost, and methods such as earned value management build on a cost baseline. That is a different topic: this guide covers the schedule baseline, which is the one every project needs.

The current plan and the baseline then live side by side. The current plan keeps moving as you update progress; the baseline stays where it was, so the distance between the two is the drift of the project.

When to save the baseline#

The right moment is after the plan has been approved and before work starts. Saving it earlier fixes a draft that will still change for reasons that are not delays; saving it later means the first variances are already absorbed into the reference.

Before saving, check that:

• every task has a realistic duration (the guide on estimating task durations helps here);
• dependencies are complete, so dates are calculated and not typed in by hand;
• the critical path makes sense and the finish date is the one you are committing to;
• milestones match the dates agreed with the client or management;
• the people who must approve the plan have actually approved it.

If you forget, a tool that saves the baseline automatically at the first progress update is a useful safety net: it captures the plan as it was the moment tracking began.

Start, finish and duration variance#

Three variances describe how each task has moved. All are expressed in working days, so a weekend between two dates does not count as delay.

A positive value means later or longer; a negative value means earlier or shorter. The three variances answer different questions. A task can start two days late because its predecessor slipped, with a duration exactly as estimated: the problem is upstream. Another can start on time and finish late because the work was underestimated: the problem is in the task itself. Finish variance is the one that ultimately matters for deadlines, but the other two tell you where to act.

Reading variance: a worked example#

Take the first phase of a project. The baseline was approved with three tasks in sequence: Requirements (5 days), Design (5 days) and Build (10 days), from Monday 2 to Friday 27 November, 20 working days in total.

Three weeks later, the current plan looks like this. Requirements took two extra days; Design started two days late but kept its duration; for Build, a second developer was added and the estimate dropped from 10 to 9 days.

How to read it:

1. Start from the summary. Phase 1 ends 1 working day late (Friday 27 becomes Monday 30). That is the number to report.
2. Go down to find the cause. The delay was born in Requirements (duration +2) and passed to Design as a start variance of +2, without any fault of Design itself.
3. Look for compensations. Build recovers one day (duration −1), which is why the phase is late by 1 day and not 2. The summary looks almost healthy, but it hides a 2-day overrun and a recovery that cost an extra person.
4. Check the critical path. If Phase 1 is followed by critical tasks, the +1 moves the project finish; if there is enough float, it is absorbed. The critical path guide explains how to tell.

A good weekly routine is to filter the tasks with a finish variance greater than zero, sort them by size and start with those on the critical path.

When to re-baseline, and when not to#

A baseline is useful only if it stays stable. Replacing it every time the plan moves resets every variance to zero and makes the drift invisible. It is legitimate to save a new baseline when the commitment itself changes:

• an approved change of scope adds or removes work;
• the deadline has been formally moved, for example after a recovery plan has been agreed (see how to recover a delayed project);
• the project has been put on hold and restarts with a new start date;
• the original plan contained a substantial error, acknowledged by whoever approved it.

It is not legitimate to re-baseline because tasks are late, because the report looks bad before a steering meeting, or by routine every week. In those cases the variance is exactly the information stakeholders need.

Working with multiple baselines#

Keeping several baselines preserves the history of the commitments: the original plan, the plan after the first approved change, the plan after the new deadline. Each new baseline should have a reason and a date, ideally recorded in the project notes.

The current comparison is normally made against the latest baseline, because that is the commitment in force. The older ones answer a different question: how much the project has moved since the beginning, across all the approved changes. Together they distinguish delays from decisions.

Common mistakes#

• Never saving a baseline. Without it, nobody can say how late the project is, only where it is today.
• Saving it too early. A baseline taken on a draft records changes in the plan as if they were delays.
• Re-baselining every week. The variance always reads zero and the delays disappear from the reports, not from the project.
• Reading only the summary. Offsetting variances below it can hide overruns and recoveries that deserve attention.
• Counting calendar days. A slippage from Friday to Monday is one working day, not three.
• Typing dates by hand. Fixed dates do not move with their predecessors, so the variances stop reflecting the real chain of delays.

How to do it in Planitude#

In Planitude the baseline is saved automatically at the first progress update, so tracking never starts without a reference. You can also save one at any time with Save baseline, or ask the AI assistant to do it. Every baseline is kept, and the comparison uses the latest one.

The baseline appears as a grey bar under each task in the Gantt chart, and the slippage is shown in working days (for example +3d), summary tasks included. The tracking features flag overdue tasks, tasks behind plan and tasks moved since your last visit, and links turn red when a delay exceeds the slack and spreads to the tasks that follow.

Across projects, the portfolio view shows the variance from the baseline and an automatic status for each project: on track, at risk or late. If you are coming from Microsoft Project, you can import the plan and keep working on it.

Frequently asked questions#