Why is a baseline schedule frozen?

So that slippage has something fixed to be measured against. If the schedule is simply updated over and over with no preserved original, a delay quietly becomes the new plan and no one can say how far the project has drifted from what was agreed. Freezing the baseline at contract award, after the owner and contractor accept it, creates a stable reference: every later update is compared back to it, and the gap is the schedule variance. The baseline is not meant to be edited as the job changes; that is what the current, in-progress update is for. Keeping the two separate is what makes delay provable rather than a matter of opinion.

What is the data date in a schedule update?

The data date is the as-of line that divides actual from forecast in a schedule update. Everything to the left of it represents work that has already happened, with real start and finish dates; everything to the right is the remaining plan, recalculated forward from that point. When a scheduler runs an update, they set the data date to the status date, mark what is complete and in progress, and let the Critical Path Method recompute the forecast for the rest. Reading an update without noticing its data date is a common mistake, because the same schedule looks very different depending on how much of it is actual versus projected.

When should a project re-baseline?

Only when the original baseline no longer represents a plan the team can meaningfully work to or measure against, and with the owner's agreement. Legitimate triggers include a major scope change, an executed change order that adds significant time, or an agreed recovery plan after a serious delay. Re-baselining resets the reference the project is measured against, so doing it casually, or to paper over the contractor's own slippage, destroys the ability to see accumulated delay and is often contested. The disciplined approach is to preserve the original baseline, document why a re-baseline is justified, and get it accepted, so the schedule history stays intact and the reason for the reset is on the record.

Construction Glossary · Scheduling

The BaselineSchedule

You cannot measure drift without a fixed point. The baseline is the plan frozen at day one, the line every later update is compared back to.

Definition

A baseline schedule is the approved, frozen version of the project schedule that actual progress is measured against. Once accepted it is locked, so later slippage shows up as variance from the plan instead of disappearing into a constantly moving schedule. The data date is the as-of line in each update: work to its left is actual, work to its right is forecast. Comparing the current update at its data date against the baseline is how delay and recovery are measured.

Measured against a fixed line

The baseline is frozen. The current update, statused at its data date, forecasts a finish 12 days later. Because the baseline did not move, that 12 days is visible as variance instead of vanishing into a redrawn plan.

Left of the data date is actual; right is forecast. The gap to the baseline finish is the variance.

Three schedules, three jobs

The baseline is the reference, the current update is the live plan, and a re-baseline resets the reference, deliberately and on the record.

	Baseline	Current update	Re-baseline
Role	Frozen reference	Live forecast	A new, accepted reference
Changes?	No, locked	Every status period	Only with owner agreement
Measures	Nothing — it is the ruler	Variance vs baseline	Resets the ruler

The float those updates report is defined in total & free float; measuring a slip formally is time impact analysis.

How POD reads the baseline

POD reads the schedule you import from Primavera P6 or Microsoft Project, including each activity’s planned dates and the progress statused against them, so planned-versus-actual is visible next to the field record that explains it. The frozen-baseline discipline itself, keeping the original plan untouched as the live schedule moves, lives in your scheduling tool; POD reads the plan and the progress it holds rather than maintaining a second, frozen copy of the schedule dates to diff the live schedule against. POD does not recompute the schedule or decide when a re-baseline is justified.

Baseline vs re-baseline guide

Frequently asked questions

The plan is read short-interval

Crews do not work to a baseline directly. They work to the look-ahead pulled from it, where the next few weeks are broken into real tasks.

Look-Ahead Schedule Back to the Glossary