What Is a Project Schedule Baseline? A Practical Guide to Variance

What is a project schedule baseline?

A schedule baseline is the formally approved version of the project schedule used to measure performance. It records the planned dates and schedule logic accepted at a point in time. The team then updates a separate current schedule with actual progress and revised forecasts, comparing the two to understand variance.

The baseline answers “What did we approve?” The current schedule answers “What do we now expect?” Never overwrite the first to make it agree with the second.

Baseline vs current schedule vs target date

Suppose launch was baselined for October 2. The current schedule now forecasts October 9, while the contract requires completion by October 5. Those are three different facts:

• baseline finish variance: 7 days late;
• forecast against required date: 4 days late;
• approved historical plan: still October 2.

Changing the baseline to October 9 would erase the evidence needed to explain what changed.

What should be in a schedule baseline?

At minimum, preserve:

• approved task and milestone start and finish dates;
• durations and dependency logic;
• working calendars and relevant constraints;
• project and major-phase finish dates;
• scope represented by the schedule;
• assumptions and exclusions;
• the approval date and approving authority.

For controlled projects, cost and resource baselines may be integrated with the schedule. This article focuses on time performance; a complete performance measurement baseline can contain more than dates.

When should you create the baseline?

Baseline after the schedule is credible enough to control—not the moment someone creates the first Gantt chart. Before approval, check that:

1. scope is represented by a complete work breakdown;
2. activities have clear finish conditions;
3. dependencies reflect real handoffs;
4. durations and calendars are realistic;
5. owners and resource assumptions are understood;
6. key risks and contingency are visible;
7. the critical path is continuous and explainable;
8. milestone dates align with commitments;
9. stakeholders know what is excluded;
10. the authorized owner approves the reference plan.

Use the 10-point schedule quality checklist before freezing the reference.

How do you measure schedule variance?

The simplest useful comparisons are date variances:

• Start variance: current or actual start minus baseline start.
• Finish variance: current forecast or actual finish minus baseline finish.
• Milestone variance: current milestone date minus baseline milestone date.

State the calendar basis. Five calendar days and five working days are not equivalent.

For example:

The increasing variance suggests the project is not merely carrying one early delay; additional slippage is accumulating. Investigate changed scope, underestimated duration, resource availability, defects, and broken dependencies.

Formal earned value management also uses schedule variance (SV = EV − PV) and schedule performance index (SPI = EV / PV). Those are value-based measures, not date differences. An SPI below 1.0 indicates less planned value has been earned than expected, but it does not directly say the forecast is seven days late. Use date and earned-value measures for their intended questions.

How often should the current schedule be updated?

Update it on a cadence that supports decisions. Weekly is common for medium projects; a cutover may need daily or intra-day control. At each status date:

1. record actual starts and finishes;
2. update remaining duration for active work;
3. revise future logic only when the execution plan genuinely changes;
4. recalculate forecast dates;
5. review critical and near-critical paths;
6. explain material variance and agree actions.

Avoid updating only percentage complete. A task can be “90% complete” for three weeks. Remaining duration and the forecast finish are more operationally useful.

When is rebaselining legitimate?

Rebaseline only after an authorized, material change makes the old reference unsuitable for future performance measurement. Examples include:

• approved scope added or removed;
• a formally accepted delivery strategy change;
• a contract modification;
• a major external event outside the planning basis;
• a recovery plan approved as the new control reference.

Poor performance alone is not a reason to erase the baseline. Preserve the original and each approved revision, record why the change was authorized, and disclose which baseline a report uses.

Common baseline mistakes

Treating a saved file as an approved baseline

A snapshot can preserve data, but governance makes it a baseline. Record who approved it, when, and against which scope.

Moving the baseline during every update

This guarantees zero variance and removes accountability. Update the forecast, not history.

Comparing only the final date

An unchanged finish can hide consumed float and slipping intermediate milestones. Review the critical and near-critical paths.

Confusing version history with a baseline overlay

Version history answers “what did the project look like then?” A baseline overlay keeps approved bars available beside current bars for continuous variance review. The artifacts can support one another but are not automatically equivalent.

How can you preserve a baseline in GanttFather?

GanttFather supports named version snapshots that can be previewed and restored. Save a clearly named version—for example, Approved schedule — 2026-09-01—and record the approving authority and scope in project context or governance notes.

As of August 7, 2026, GanttFather does not provide a dedicated baseline-bar overlay across every task. For formal variance reporting, export the approved schedule or retain a baseline table alongside the live forecast. The product’s reporting and health views can support current performance discussions, but a named version should not be presented as a richer stored-baseline feature than it is.

That distinction is useful for choosing software honestly. If your contract requires multiple baselines, earned-value controls, or audit-ready baseline change logs, validate those capabilities before committing to a tool.

Create a free GanttFather project and save the approved schedule before entering the first status update.

During each update, read the current chart using the Gantt review sequence, inspect changes in float and slack, and preserve the link between the approved schedule and the relevant project milestones.

Frequently asked questions

Is the baseline the original plan?

It is the approved control plan, which may not be the first draft. Keep earlier drafts if they matter, but do not call an unapproved sketch the performance baseline.

Can a project have more than one baseline?

Yes. Large or formally controlled projects may preserve the original plus authorized revisions. Reports must identify which version is current and should retain the history of changes.

What if the project has no baseline?

You can still maintain a current forecast, but you cannot reliably measure performance against an approved prior plan. Establish a reviewed reference as soon as the scope and schedule are credible.

Does Agile work need a baseline?

Not every team needs a detailed task baseline. A product team may baseline a release, funding horizon, or external commitment while allowing backlog content to adapt. Match the control to the consequence of missing the commitment.

---

Sources

1. U.S. Department of Energy, Project Management Lexicon of Terms
2. Project Management Institute, Practice Standard for Scheduling
3. U.S. Government Accountability Office, Schedule Assessment Guide