Skip to content
PingCadence
Get started

Scheduling · Critical path · Baselines

When to re-baseline a project schedule (and how to do it without hiding the slip)

By PingCadence · · 6 min read

Short answer

Re-baseline only when the critical path slips and the impact is recorded and approved, or when the approved target itself changes (scope, contract or customer date). A late task that isn’t on the critical path doesn’t need a new baseline; that’s what slack is for. Before you re-baseline, save the old baseline, log the date, reason and approver, and keep reporting against the original too.

Unless the late work is on the critical path, there’s no need to re-baseline. A non-critical task can finish late and the program still lands on its date, because the task has slack to absorb it. Re-baselining is for when the critical path has slipped, the impact is recorded, and the expectations for the whole program have to change.

What re-baselining actually does

A baseline is the set of dates you agreed to. Slip is measured against it: current finish minus baseline finish. When you re-baseline, you copy today’s dates over the baseline, and every task’s slip drops to zero in one click. That’s the right result when the agreed target has really moved. It’s the wrong result when the project is simply late, because the report now says “on baseline” about work that is weeks behind what was promised.

So the question isn’t “are the dates wrong?” They usually are, somewhere. It’s “has the critical path moved, and did the person who owns the target agree to the new dates?”

Check the critical path first

Before anyone talks about a new baseline, find out whether the late task is on the critical path. In Microsoft Project, add the Total Slack and Critical columns to the Gantt Chart, or tick Critical Tasks on the Gantt Chart Format tab to colour them. If the task’s slip is smaller than its total slack, the end date doesn’t move. Track it, follow up, and leave the baseline alone.

If the slip eats all the slack and pushes a key milestone or the end date, you have a critical-path slip. Now the choice is recovery, a scope change, or a re-baseline with the program’s expectations reset.

Good reasons to re-baseline

  • A critical-path slip that can’t be recovered. The impact is recorded, the cause is understood, and the sponsor or change board approves new dates.
  • An approved scope change. Work was added or removed through change control, and the new dates were part of what got approved.
  • A new contract or customer date. The customer, contract amendment or program office moved the milestone you’re held to.
  • Rough estimates replaced by a detailed plan. Early phases were planned at a high level on purpose, and the detailed plan for the next phase is now done and approved (rolling-wave planning).

Bad reasons to re-baseline

  • A task off the critical path is late but still inside its slack.
  • The report is red and someone wants it green before a steering meeting.
  • A few tasks slipped and “the baseline isn’t realistic anymore”, but nobody approved new dates.
  • A new project manager inherits the schedule and wants a clean start.
  • The team re-estimated their own work and simply typed the new dates in.

One public example of where to draw the line: the State of Georgia’s IT project guidance says poor performance and poor planning are not reasons to re-baseline, and every re-baseline needs a change request that states its rationale and goes through the change control board.

Should you re-baseline? A three-question check, starting with the critical pathQuestion 1: does the slip hit the critical path, moving a key milestone or the end date? If no, do not re-baseline; the task has slack, so track it and follow up. If yes, question 2: are the new dates approved in writing by whoever owns the target? If no, get the approval first; until then it is slip. If yes, question 3: have you saved the current baseline as a copy? If no, save it first. If yes, re-baseline, log the date, reason and approver, and reset expectations for the program.1. Does the slip hit the critical path?Does it move a key milestoneor the end date?Don’t re-baseline. That’s whatslack is for: track it, follow upNoYes2. Are the new dates approvedby whoever owns the target?Get the approval first.Until then, it’s slipNoYes3. Have you saved a copyof the current baseline?Save it first(Baseline 1, or a dated column)NoRe-baseline, log the date, reason and approver, and reset expectations
Three questions before you overwrite a baseline. If the slip doesn’t touch the critical path, the answer is to track it, not to reset it.

Should a slip threshold trigger a re-baseline?

Some teams write rules like “re-baseline when the finish moves more than 10%”. There’s no common number that works everywhere. Thresholds should be different for critical-path and non-critical work, and how aggressive the schedule is should drive the percentage: a tight schedule with little slack needs a lower trigger than a relaxed one.

Use the threshold to force a decision, not an automatic reset. When slip crosses it, the sponsor chooses between recovery, a scope cut, or approving new dates.

How to re-baseline without losing the history

The steps are the same in any tool: copy, record, then overwrite.

  1. Copy the current baseline somewhere it won’t be overwritten.
  2. Record the change: date, reason, the change request or approval, who approved it, and the old and new finish of the key milestones.
  3. Set the new baseline for the whole project, or only for the tasks the change covers.
  4. Report against both for at least the next few reports, so nobody reads a reset as a recovery.

In Microsoft Project (desktop)

  1. Go to Project → Set Baseline → Set Baseline…
  2. Choose Set interim plan, set Copy to Baseline and Into to Baseline 1 (or the next unused number), choose Entire project, and click OK. Your old baseline is now preserved in Baseline 1.
  3. Open Set Baseline… again, choose Set baseline → Baseline, then Entire project or Selected tasks, and confirm the overwrite.
  4. To compare, add Baseline1 Finish next to Baseline Finish and Finish in the task sheet. Project keeps Baseline plus Baseline 1 to Baseline 10, so you have room for a re-baseline history, and the Set Baseline list shows the date each one was saved.

In Excel

Never overwrite the baseline column. Add a new one with the date in the header, for example Baseline finish (2026-03-02), and keep the old one beside it. With the original baseline finish in B, the current baseline finish in C and the forecast finish in D:

Slip formulas (calendar days)

Slip vs current baseline:   =D2-C2
Slip vs original baseline:  =D2-B2
Approved change:            =C2-B2

A real case: a failed test on the critical path

On a medical device program, extractables and leachables (E&L) testing sat on the critical path. A test failure pushed it out, and because it was critical-path work, the end date moved with it. That needed a re-baseline of a few weeks, and then close monitoring of the work from there on.

A worked example: approved change versus slip

Example data: the original baseline finishes on day 60. A critical-path change is approved and adds 21 days, so the new baseline finishes on day 81. A month later, owners report dates that put the forecast at day 92. The report should say 11 days late against the current baseline, and 32 days against the original, of which 21 were approved. Both numbers are true, and the second one stops anyone from thinking the project has only ever been 11 days late.

Example: total finish movement split into an approved change and slipExample data. The original baseline finishes on day 60. An approved scope change adds 21 days, so the new baseline finishes on day 81. The current forecast finishes on day 92. Against the new baseline the slip is 11 days; against the original it is 32 days, of which 21 were approved and 11 were not.Original baselineBaseline 1 (kept)Current baselineAfter approved changeForecastLatest dates from ownersDay 60Day 81Day 92+21 approved+11MovementReport both: 11 days late against the current baseline, 32 days against the original (21 approved).
Example only. Keeping the original baseline lets you split total movement into what was approved (green) and what is still slip (red).

What to tell stakeholders

Re-baselining is a stakeholder conversation, not a scheduling chore. Say plainly that the re-baseline is needed because of a critical update to the critical path, and that expectations for the overall program need to be adjusted. Then put the details in the next status report and keep them there until people stop asking.

Re-baseline note for a status report

This re-baseline is needed due to a critical update to the critical path: [what happened, one line].
Expectations for the overall program need to be adjusted.

Re-baselined on [date], approved by [name or board] ([change request]).
Key milestone: [milestone] moves from [old date] to [new date] (+[n] days approved).
Slip is now reported against the new baseline. Against the original: +[m] days, of which [n] approved.

The two mistakes that cause the most damage

  • Overwriting without a copy. Once the old baseline is gone, so is every slip measured against it, and you can’t show the history when someone asks how the program got here.
  • Re-baselining too often. If the baseline moves every time a date does, it stops being a commitment and becomes a copy of the forecast. Slip never shows up in a report again.

Keeping the baseline fixed while dates move

The easiest way to lose a baseline by accident is to type a new date over the planned one. PingCadence avoids that by design: when you import a Microsoft Project XML file it reads your saved baseline, and when an owner says a task isn’t on track, their new date comes back as a proposal for you to accept, edit or reject. Your baseline stays as you set it. See how it works.

The rule of thumb: stay flexible on non-critical-path items, but on critical-path items stay firm and follow up frequently, because re-baselining requires stakeholder management. For the formulas behind slip in calendar and working days, see Schedule slip in days: baseline vs current.

Menu names are from Project Standard and Professional on Windows. Microsoft documents baselines in Set and save a baseline and the extra baseline fields in Baseline1-10 Start fields. The State of Georgia guidance is Project Re-Baselining Guidelines (GM-22-001).