Baselines: When to Set Them and When to Re-Baseline

A baseline is a frozen copy of the approved plan that you measure every update against. Without one, "we're five days behind" has no meaning, because there's nothing to be behind. This post covers when to set the baseline, what to store in it, when re-baselining is justified, and how to do it so you don't erase the history you'll need later.

What a baseline is for

The baseline answers one question: compared to what we agreed, where are we? Every variance number in an update, whether it's a milestone slip or a schedule performance index, is measured against it.

It also does a second job that matters more when things go wrong. The baseline is the as-planned schedule in most delay analyses. If you later need to show that an owner change pushed the elevator installation and therefore TCO, the baseline is where that argument starts. See As-Planned, As-Built, and Windows.

That means the baseline needs to be:

• Approved, or at least formally submitted, by the parties to the contract
• Complete enough to model the whole scope through closeout
• Logically sound: no open ends, few constraints, realistic durations
• Unchanged once set

When to set it

Set the baseline when the schedule has been accepted, not when you finish typing it. On most contracts that follows a submittal and review cycle: contractor submits a baseline within a specified number of days after notice to proceed, the owner reviews, comments come back, the contractor revises, and the accepted version becomes the baseline.

Two practical issues:

Work starts before the baseline is accepted. It almost always does. Mobilization, site work, and maybe footings are underway while the baseline is under review. The usual practice is to set the baseline with a data date at or near NTP, so it reflects the plan before progress, and then make the first update with actual progress against it. Some owners prefer a baseline with early progress already statused. Your spec should say which; if it doesn't, ask.

The baseline is never accepted. It happens. The owner keeps returning comments and months go by. Keep submitting, keep a record of each submission and response, and use the most recent submitted version as your working baseline internally. Document it.

For what reviewers look for in a baseline submittal, see What Owners Should Check in a Baseline Schedule Submittal.

What to store

A baseline copy should hold the full schedule as it existed when accepted:

• All activities with original durations
• All relationships, types, and lags
• Calendars
• Constraints
• Early and late dates, and float
• Resource and cost loading, if used
• Activity codes and WBS

In P6, you typically copy the project and assign the copy as a baseline. Microsoft Project stores baseline fields (Baseline Start, Baseline Finish, Baseline Duration, and so on) on the task itself, with up to eleven baseline sets. Both work, but note that a Project field-level baseline doesn't preserve the logic, just the dates. Keep the full file too.

How variance is measured

Once you have a baseline, each update compares current dates to it:

(Workday counts here assume a Monday-to-Friday calendar with no holidays in these windows, and that all of the dates fall on weekdays.)

Variance by itself doesn't tell you why. Reading Schedule Variance covers tracing slips back to causes.

When re-baselining is justified

Re-baselining means replacing the measuring stick. Do it rarely and for a real reason. Legitimate reasons:

• Major scope change. An owner adds a floor, deletes a wing, or changes the building's use. The original plan no longer describes the job.
• Approved time extension that changes the contract completion date. Many contracts handle this by revising the baseline to incorporate the approved change and new dates.
• Fundamental resequencing, such as a phasing plan change requested by the owner, where tracking against the old sequence produces meaningless variances.
• Long suspension. If the job stops for months, the original plan's dates may be irrelevant once work resumes.

Not legitimate:

• The project is late and the variances are embarrassing
• A new PM wants a fresh start
• The schedule was bad to begin with and nobody wants to admit it

Re-baselining to hide delay is the one that causes real trouble. It erases the evidence of what happened and when, and any careful reviewer will ask why the baseline changed.

Many contracts require owner approval to change the baseline. Contracts vary, so read yours, and talk to counsel if the change relates to a dispute.

How to re-baseline without losing the record

1. Keep the original baseline. Never overwrite it. Save the new one as a separate, clearly named version: "Baseline 2 – approved CO 14, data date June 1."
2. Start from the current update, not from scratch. The re-baseline should carry actual dates for completed work and model the remaining work with the new scope and logic.
3. Document what changed. List added and deleted activities, changed logic, changed durations, and the new contract dates. Tie each to a change order or approved request.
4. Get it accepted. Treat it like the original baseline: submit, review, approve.
5. Report against both. For a while, show variance to the original and to the new baseline. It helps everyone see the effect of the change itself versus performance since.

Alternatives to a full re-baseline

Sometimes you don't need to replace the baseline at all:

• Insert a fragnet. For a change order or delay event, add the new activities to the current schedule and show the impact. The original baseline stays intact for comparison. See Fragnets.
• Adjust milestone targets only. If the contract completion date moved but the work didn't change, track a revised target date alongside the baseline.
• Use a what-if copy to show the owner what a resequence would look like before committing to it. In schedule.construction, scenarios run on a copy and don't touch the live schedule or its baselines.

Baselines in earned value

If you're using earned value, the baseline is also the source of planned value. Re-baselining resets planned value, which resets schedule variance and SPI. That's another reason to keep the original, so you can still show cumulative performance. See Earned Value for Construction Schedulers.

Key takeaways

• The baseline is the agreed plan you measure every update against, and the as-planned schedule in delay analysis.
• Set it when the schedule is accepted, with a data date near NTP unless the spec says otherwise.
• Re-baseline for real scope or contract date changes, not to hide delay.
• Never overwrite the original. Save each baseline as its own named version with documentation.
• Consider a fragnet or revised milestone target before replacing the whole baseline.