Help! My baseline bars are in the wrong place!
| In Blog - EN|
When I started working with Primavera P6, I had a colleague who showed me how you can use ‘global change’ to make sure that your baseline bars are showing the right information. It was fairly simple: you just amended the planned dates to the dates you want in the baseline, and it’s done. Hu? Primavera is not capable of managing baselines? Of course, something else is going on. Like so often, Primavera turns out to be so powerful and versatile that one really needs to understand what’s under the hood to properly operate the system.
In Figure 1 you can see what I am talking about.
Fig. 1 – Baseline bars show wrong dates[/caption]
Planned dates
The global change as described in the introduction proves that even though we thought that Primavera is flawed, we knew what we needed to do to fix it. We knew that a baseline uses the ‘planned dates’ from the baselined project. And you can manually overwrite those planned dates to represent the dates you want.
So Baselines show planned dates. But why are they not what we expect? We have to differentiate between activities that are not started and activities that are in progress or completed.
Activities that are not started
For activities that are not started, planned dates match the early dates. Planned start mirrors early start and planned finish mirrors early finish. If those early dates change, planned dates change as well. This doesn’t apply when resource levelling is used. Also, the planned dates can be overwritten manually.
Figure 2 shows how this looks.
Fig. 2 – Baseline for activities that are not started[/caption]
Activities that are in progress or completed
If the user assigns an actual start to an activity, planned start will be frozen to match that actual start. Planned finish will however not mirror actual finish (for completed activities). Instead, planned finish will be calculated as actual start plus original duration.
This is not what Figure 1 is showing. That is because the activity was set to be ‘started’ when it was planned to start on 01-Jan. That’s why its first actual start was 01-Jan. The planned start was fixed to this date and when actual start was changed to 03-Jan, planned start didn’t change. This means that planned start dates are fixed and will not be recalculated if other information changes (they are frozen).
Now, Figure 3 shows the situation of Figure 1 with the planned start date manually overwritten to be 03-Jan. Planned finish is now calculated as actual start date plus original duration. Again, this date can manually overwritten.
Fig. 3 – Planned finish is actual start plus original duration
Earned Value Settings
As said, one might try to change the planned dates with global changes. But this cannot be the intentional use of Primavera? Indeed, by choosing the right settings, Primavera’s behavior will be closer to the desired and expected behavior. What has been described above, was the result of applying the ‘Planned values with Planned Dates’ setting. Unfortunately, this is the standard setting in Primavera! Changing this setting to one of the other 2 options will release you from stress and anger.
Figure 4 shows where you can change this setting through the web browser (for EPPM) and Figure 5 shows the same for (some other releases of) Primavera Pro.
Fig. 4 – Earned value settings through web browser[/caption]
Fig. 5 – Earned value settings through client for some releases
Conclusion
I cannot stress enough how important profound knowledge of the inner workings of Primavera is to enable you to work efficiently with Primavera. This blogpost showed you the relevance of planned dates and original durations in relation to baselines. Also make sure to apply the correct settings for Earned Value calculations.