We know the theory – a baseline is a line that is used for measurement. In the PPM world, it frequently refers to a snapshot of the schedule at a point in time that is used to compare how you’re actually doing against the original plan.
Often comparisons of your current plan with the baseline are used to generate a RAG traffic light in Project Centre views and reports how well (or otherwise) you are doing. In the schedule below things were going according to schedule until tasks 31 – 34 where a 1-week delay was introduced. Task 39 is now also taking much longer than planned meaning the whole project is now showing RED.
However, while projects exist to effect change, they are not immune to it themselves. For example, imagine a project delivery schedule that spans 4 months and that at the end of the 2nd week, sign-off on the Brief will be given. However, due to end of financial year spending constraints, the sign-off is delayed and not granted until 4 weeks later than what is planned and recorded in the original baseline. With a 1 month delay on a 4 month project, the comparison of current to baseline for the project schedule will likely now report a RED traffic light (depending on the triggers) and will likely continue to report RED for the life of the project as it is unlikely that the PM will be able to make up this lost time.
Many would conclude that the red traffic light becomes somewhat meaningless as it does not reflect on the current state of the project. So we normally submit a change request for a delivery extension and often re-save the baseline for the project. This results in a new snapshot to compare against and – at least initially – a GREEN traffic light. However, by doing this we have also lost the original snapshot which can be very useful when performing a post-implementation review.
Another response to this situation would be to retain the original baseline and then save a new baseline (Project keeps up to 10 baselines). However, the downside with this approach is that all reports and automated traffic light calculations need to take potentially 10 baselines into account. While this is all doable, it can be messy!
Also, the out-of-the-box fields used in project tracking use Baseline 0 as the comparison point. So if a user looks at standard fields such as Start, Finish and Cost Variance, they will all display a value that results from a comparison with baseline 0. In other words, we have two conclusions – the out-of-the-box tracking fields (which use baseline 0) are saying we are “way over schedule” but the custom fields that factor in the other baselines may return an “on track” result.
The approach I favour takes a minute to explain but I believe makes the most sense. In the scenario above when the PM has completed the first cut of the schedule and it is ready for the initial baseline – two baselines are saved Baseline 1 & Baseline 0. After the change request for the one month delay has been approved, Baseline 2 is saved and then, importantly, Baseline 0 is overwritten. If a subsequent change request is approved that has an impact on the schedule then Baseline 3 would be saved and then Baseline 0 overwritten again. The key here is that at the time of saving each new baseline, baseline 0 is also overwritten/updated.
The advantages of this approach are:
- All the out-of-the-box tracking fields are now aligned with the internal reporting fields and provide value by assisting the user in identifying why their project is reporting as it is.
- At any time a user can compare multiple baselines on screen and see how their schedule changed over time.
- Baseline 0 always represents the latest baseline so any calculations, traffic lights or reports that are based on the latest baseline, can look to the Baseline 0 fields.
The above can be used in conjunction with Project Online security model to restrict the ability to save baselines to authorised groups if required.
I hope this makes sense to you and can add value to your organisation. Let me know if you have any feedback or experiences.