The way I simply look at baselines is that you are effectively drawing a line in the sand so for example if you are 6 months through a project then the past is the past (including logic/resource etc changes as these would represent true plans) and your new baseline reflects how you, the project managers and Owner agrees on how the job will be delivered at whatever stage you are going forward.

The receipt of updates is informative, it does not change contractual conditions, change orders and other documents can change contractual conditions. Among the other documents are Change Directives, a remedy to the Owner to direct changes in the lack of an agreement, another can be the acceptance, not the mere receipt, of a Revised Baseline. Just imagine if for every update the owner would be required to evaluate your updates as if representing change orders.

In essence you are right with regard to an adjusted baseline, it represents adjustment to schedule after the time the prior contractual baseline that shall conform to revised actual contract conditions.

I have seen jobs in which a revised baseline have never been submitted, others in which the revised baseline is never agreed. The most common reason for rejecting a revised baseline is disagreements to pending claims. The most common reason for not submitting a revised baseline is that the contractor in no way can any longer promise delivery on time as per actual contract conditions at the time of re-baseline, even if there are no pending claims.

What if the contractual conditions say you must finish next month but there is no real way you will be able to meet this time as there is a critical equipment that will be delivered in two months. In this case a common option for the Owner is to accept it will be delivered late and that you will have to pay liquidated damages, you got to be far to target in order to declare you in default. It is a catch 22 situation, the Owner cannot accept a re-baseline that changes contractual delivery time and you cannot promise you will be on time with a re-baseline schedule you cannot use to manage your job.

Asking for a revised baseline when you are late is asking for a recovery schedule that upon acceptance will become the new contractual baseline. The following link can be of some help.

http://www.warnercon.com/articles/Article%2012%20-%20Recovery%20Schedules.pdf

Lloyd,

Schedules are dynamic, updates must reflect changes in logic. One of the main reason to require updates to the baseline is because it no longer reflect plans. Blindly transferring actuals to a baseline when there have been changes in plan including corrections to the basic logic, corrections to out of sequence logic, addition of change order activities, among others, is in error.

As time pass and you continue this procedure to transfer actuals to the original obsolete logic, one on top of the other, the logic becomes farther and farther from reality. Remember the logic of any "updated baseline" as per this procedure will not be changed ever if you continue this logic.

Contractual baseline is a different thing than a reference job to be compared against another; what-if scenarios and compared projects that are not contractual baselines can be updated using such procedure, but applying this to contractual baselines is not valid. I always preferred the way P3 would handle baselines, contractual and non-contractual. Seems like the procedure to transfer actuals to P6 baselines avoiding detaching the file is creating confusion on when it is valid and when it is not. Is like people believe it is always valid.

As a matter of fact I am having difficulty to understand what the Owner pretends.

Best regards,

Rafael

Lloyd,

I understand from your statements that you need to update the original baseline by inputing the current actuals into it and save as a new baseline?

If so, then attached the original baseline as baseline to the current project, then make use of the update baseline in the maintain baseline window to modify the original baseline.

Hope this will help.

Lloyd,

Revised Baselines shall be based on actual performance, shall have the DD of the revision date.

If the Owner does not understand this an option can be to use the actualized schedule to produce a Collapsed As-Built but it can be a trap as Collapsed as-built does not solve pacing issues per-se, if implemented in its most basic form will give all pacing to the Owner. Of course you have the initial logic, this removes out most of the subjective issues of a collapsible as built, essentially leaving out of sequence issues that were not resolved in due time.

Make the fight for the Owner to accept the revised Baseline from the latest update, with a DD of the last  update. Latter you might be sorry if you fall in this trap.

Best regards,

Rafael