Baseline variance problem

Kevin,

It may the that this is due to the common issue of using planned dates in baselines.

Paul Harris explains it well here:

http://eastwoodharris.com/DL/TP/110616_P6_V7_What_Baseline_Bars_am_I_Displaying.pdf

But if you just want the quick fix, go to admin>admin preferences?earned value, and set the drop-down box at the bottom to "budgeted values with current dates"

Hi Kevin,

When loading a schedule as a baseline for another schedule, a common issue is the start & finish dates for
progressed activities are not converted correctly. This work instruction details how to correct the dates using global
changes without having to change system settings.

The differences in the dates between when converted is due to the system wide setting for earned value
calculations which is usually set to use budgeted values with planned dates. The effect of this is that baseline start
dates are set to the activity planned start dates, which can differ from the actual start dates (usually rescheduled to
after the update date). So for progressed activities in the schedule being converted to a baseline , the baseline start
date and the original schedule start date can be different.

There are two options to fix this issue if you want to have the actual dates used for the baseline start (and finish)
dates.
1. You get the system wide setting changed to use current dates in lieu of planned dates. Unlikely, since
baselines should reflect what was planned rather than actuals, and the setting affects all schedules in P6.
2. Take a copy of the schedule and change the planned dates before you convert it to a baseline

For Option 2 above you will have to follow the following sequence
1. Run a global change that changes the planned start dates to the original schedule’s actual start
dates for progressed activities
2. Run a global change that changes the planned finish dates to the original schedule’s actual finish
dates for progressed activities
3. Add the schedule as a baseline as per the normal process of “Maintain Baseline”

Please ley me know if you need more info and I will send to you a step by step intruction to solve this issue.

Regards,

Rodolfo Kurek

Rodolfo,

"There are two options to fix this issue if you want to have the actual dates used for the baseline start (and finish)
dates.
1. You get the system wide setting changed to use current dates in lieu of planned dates. Unlikely, since
baselines should reflect what was planned rather than actuals, and the setting affects all schedules in P6."

I disagree with this. If you are using a baseline with progress for earned value purposes, you are doing this deliberately. Therefore any actuals in the baseline should be reflected in your PV curve.

If you don't want to reflect actuals, you shouldn't be using a baseline with actuals in it.

The real reason the "planned dates" option is used so often in P6 is in my opinion purely because it is the default setting, and most P6 admins / planners don't understand it is the wrong setting to use in 99% of circumstances.

The solution#2 you propose using a global change to ammend the planned dates actually has precisely the same functional impact as changing the EV calculation settings from planned to current. It just takes more time, and introduces an additional opportunity for error each time a new baseline is taken. -Just change the settings. Easier, cleaner, simpler.

Despite the name, "planned" dates in P6 do NOT reflect what was planned for actual activities. They reflect the early dates which were calculated the last time the programme was scheduled before the activity was actualised. Since most planners will schedule their programme many times during an update cycles, these planned dates can very often actually be utterly meaningless.

Cheers,

G

Thanks Gary, I will check on that and change my way of operating.

This ia a standard working instruction from most of the big companies. Just to quickly fix this issue.

But I agree with you, the schedule must be as clean as possible to ensure that the software will work for us.

Thanks.

Rodolfo Kurek