Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Mike,
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.
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. Saving Changes...
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. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
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. Saving Changes...
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. Saving Changes...
Betsy GreenOnboarding Manager| TownNews.comMoline, Il, United States
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. Saving Changes...
Mahalmadane TouréEngineer| National Headquarters of Geology and Mines of Mali (Bamako)Mali
Project management is iterative so when more information is available throughout the project life cycle I think baseline may change to represent the reality. Saving Changes...
John TiesoAuthor, Lecturer in Business Management| The Catholic University of America, Busch School of Business & EconomicsArlington, Va, United States
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. Saving Changes...
Thilo WackHead of Existing Product and Test Lab| optimedTholey-Hasborn, Germany
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... Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Andrew and Aaron first comments are great. If you use base lines then take the Andrew´s first comment. If you do not use base lines take Aaron ´s first comments. In my actual work place we do not use baselines because it has no sense no matter the type of product we are creating. We use other method. In the actual world the use of base lines has no sense mainly if you are trying to use Agile at enterprise level or business unit level. Saving Changes...
Community Champion
