Project Management Central

Please login or join to subscribe to this thread

Practice Areas: Agile, Business Analysis/Requirements Management, Scheduling
When should you update baselines and when should you not?

I've heard conflicting stories. Some people say you shouldn't update baselines, but I've also seen people say you should update baselines.

Which projections should not be changed and which ones are alright to update as the project progresses?

Thank you
Sort By:
Page: 1 2 next>

Baselines would be updated with any significant change - significant is understandably subjective, but one would have to use their best judgement.

For example, if my project gets bumped down the priority ladder, with revised durations, or if there is an excepted change request, I will re-baseline. That said, you don't necessarily have to update the original. I recommend saving under the other options, baseline1, baseline2, etc. This gives you the ability to then add multiple baselines to the reports to provide a visual effect of the impacts - positive or negative.

Hope that helps.

Do you need a baseline?

For the most part, I don't use them. What are some reasons to use them?

1) You need to track project variances (work, duration, cost, start & finish dates) or performance
2) You are using EVM
3) You want to verify and/or improve accuracy of estimates

There may be more reasons, but my point is that the baseline is a tool. Before you use a tool, you should know the reason you need it, that it can do what you need, and how to use it.

MS Project gives you the ability to save up to 11 baselines - Baseline, and Baselines 1-10. EVM only works with the unnumbered Baseline, so only update that one if you want to change your EVM baseline. If you need to use the remaining 10 and then start updating them, you've probably gone a little baseline crazy.

If you're just worried about dates, use an interim plan instead of a baseline.

The updating of the baselines in my concept is an instrument that must be updated every time we want to start a project, I consider that it is our starting point and what we are going to measure in the end the results.

EVM only works with the unnumbered Baseline, so only update that one if you want to change your EVM baseline
Good Point Aaron. And exactly, be smart about, why and what you expect to gain or use from it.

I can say I use a machete, but it is up to the individual to understand the how, when, and why.

in one line like Andrew has mentioned : only after an approved change request from change control board you would change schedule baseline.

for e.g.
If you are running behind schedule you would re-evaluate the project and submit to integrated change control board to allow more time and hence change in baselines to monitor as per new baseline.
If you get a change request from client and budget is approved by sponsor you would re-evaluate the project ad get it approved by integrated change control board and hence the requirement to monitor as per new baseline.

I will update the baseline if there has been a significant change to the scope of the project. I will not update the baseline if we've fallen behind schedule.

I do, however, compromise a bit when giving status reports. At the top of each status report, I give red/yellow/green indicators to show the overall health of the project and the health at the given stage. For example, on one project that I am working on, the nature of the project has changed so much that we aren't anywhere close to my originally planned deployment date. My overall project status is red. However, after we redefined the project and updated baselines, I'm now running on target to schedule for my current process phase. The health for that is green.
Project baseline is the 'approved project management plan.' Any update/changes to the baseline requires approval.
It depends what baseline you would like to make the changes. Is it the scope baseline? schedule baseline?cost baseline?
In my opinion, if these changes will adversely impact the project, timeline, cost, deliverables, results, etc. then, it is not advisable..
If these baseline changes are needed to achieve project success, risk assessment and strategies have to be conducted to manage these updates/changes subject to approval.

Project management is iterative so when more information is available throughout the project life cycle I think baseline may change to represent the reality.

Let me add to the other responses here.

Like Aaron, I do not like baselines, especially those likely to be changing rapidly or frequently. That does not mean, I fail to use them; only that I always keep the initial baseline, in order to evaluate results against initial estimates. I change a baseline only when the agreed on scope changes, either through modification or practical need, or when the timeline changes due to external factors. otherwise, I maintain the baseline, noting the informal changes, and reasons for the changes. That is, as Aaron points, out a critical in EVM.

Not much to add here. Maybe just this small piece of advice: The more updated baselines you have in your project the more tedious the tracking of the overall project across the changes you made (Andrews advice to save each version seperately helps in that regard). In the same line short term tracking for reporting gets easier as you can track against the most current baseline w/o manually taking into account the external factors that have already been accepted. So know your priorities...
Page: 1 2 next>  

Please login or join to reply

Content ID:

When an elephant is in trouble even a frog will kick him.