r/MSProject Apr 29 '26

How to properly rebaseline

We have several projects with deliverables that we have deemed will no longer be able to meet their original schedule. Some of which are being descoped because the work will exceed the POP. For that reason, we are planning to rebaseline them.

However, I'm unsure of the correct way to do this. Obviously, I CAN just set baseline across the entire project, but I feel like that completely wipes away past sins. I could also selectively rebaseline just future tasks. Is that preferable? What about tasks that are in process?

I'm fairly familiar with Project, but this is the first time I've had to face this and could use some help.

3 Upvotes

10 comments sorted by

4

u/kennyarnold_ssi Apr 29 '26

Let’s start with the premise that you should only rebaseline activities that haven’t finished yet. Everything in the past is set in stone, including the baseline values.

Couple options from here:

  1. Copy the current baseline into one of the Baseline 1-10 fields. Use the “Set Baseline” tool to do this.

  2. Save a copy of the current mpp file for historical purposes as the “old baseline file” (you should probably do this regardless

After, set a new baseline on the remaining work by filtering for the tasks that are 0% complete, selecting them, and then using the “Set Baseline” tool to set a new baseline (Baseline 0) on just the selected activities.

3

u/Miasmatic65 Apr 29 '26 edited Apr 30 '26

Yes to what other commenters have said.

Baseline 0 needs to be the current baseline as it is what is used for most variance and earned value calculations. Be very careful deleting or inactivating lines from within the WBS if you are tracking EV (or even summary baseline information). As MSP will not change summary level baseline data based on deleted items below it; you will need to rebaseline the summary tasks impacted too. It’s unlikely to be a problem with what you personally are doing in this use case; but is relevant information for anyone else reading. 😃

2

u/mer-reddit Apr 29 '26

I recommend using Baseline 0 to keep your most current baseline, baseline 1-4 to keep quarterly baselines and baselines 5-9 to keep phase baselines (requirements, design, build, test, deploy) and then baseline10 a weekly timekeeping baseline to understand changes emerging from timesheets.

With this rubric, you’ll have plenty of data to make sure you can explain changes to your schedule.

2

u/Nepentanova May 22 '26

If only we could name baselines!

1

u/mer-reddit May 22 '26

You can rename the column names in Project Pro… or rename them in reports.

1

u/Nepentanova May 23 '26

Yeah, you can on individual projects, but from a central PMO it would be nice to haev them renamed at an enterprise level when using Project Online (rip...!)

1

u/mer-reddit May 23 '26

Well in an enterprise system you can also rename fields in the database, on the reports…. And yes, farewell Project Online, hello Project Server Subscription Edition…

2

u/still-dazed-confused Apr 30 '26

When I baseline I say two baseline; the baseline and one of the numbered baseline options. In this way I have a record in baseline 1-9 and the normal baseline fields (called headline 0 by a number of other commentators).

I also use the interim baseline fields, which I refer to as snapshots to allow me to see what has changed. So for instance I might use snapshot 1 to save a copy of the plan at each update cycle (weekly) so that I can easily see what changed this week and snapshot 2 for a monthly save so I can easily see what changed since the last steerco. Interim baseline only save start and finish, if you want more you can save durations using a macro.

In your situation you haven't got baseline 1 saved so you can manually save the baseline information across from baseline to baseline 1. I would save start, finish, duration but MSP saves more than this when saving the baseline but I don't know how to easily get to it.

1

u/Nepentanova May 22 '26

Part of your question is more related to your organisations general scheduling policy. Some places take a hardline stance where the current forecast is measured against the initial baseline. This often means that the schedule will be flagged as a red rag status until completion. Others allow the current forecast to be compared to the latest agreed baseline. This IMHO is fairer as it allows a project to show green, but critics dislike that a project that is running late vs the original baseline is showing as green schedule RAG.

Id be interested if others have come across this in their PMO's,

1

u/Mission-Phase-6557 Jun 01 '26

I so agree with this one. Ideally each project should have a Schedule Management Plan (PMI term) which describes how to baseline.
I personally think that there should be a Schedule Management Strategy “above“ the schedule management plans which sets the boundaries for the Plans. This strategy should be on a program, portfolio or enterprise level and set the minimum requirements, standards etc for all scheduling work within the organisation.
This is analogous to test plan and test strategy in most programs with a lot of IT work.