Modifications to an Original Scope require a revised baseline incorporating such changes, as the additions / Ommisions are not reflected in the baseline program, and thus the original baseline does not incorporate these changes andtherefore; their dirct effect on the project in total cannot be shown (if any).

An updated baseline program without incorporating the additional works might show the effect of the new works on other activities (maybe), but still you need to revise the baseline, incorporate the additions / ommisions evaluate the effect on the project completion.

The next step would be is to insert actual dates on the revised baseline (update) the revised baseline inorder to show that un affected works has commenced as per the original plan (if this is the case).

If I were the Engineer or the Client; I would ask for both as it helps in pointing out any concurrent delays and thus the evaluation of cost incurred.


While it is in (my opinion)...that the logic will remain the same....as a logic is not dependant on scope rather than on relations, the sequence might change as it is a matter of preference, sequence changes all the time ...but it does not affect the logic, because in theory, there is only one logic, the correct logic, while sequence becomes a matter of preference that can change without intersecting with the logical relationships.

Exacctly...it even strengtherns your case or claim

Chan...Sorry Mate,I just didnt want to add to the confusion of whoever started this thread.

Hi Chan,

but the issue is regarding a revised baseline against a baseline....and not an update. No actual dates are involved in.

All programs, even the best program, will be a collection of assumptions, educated or a stab in the dark, from the durations used and logic links to approximate the reality that you are trying to model.

Those assumptions made must always be tested, and the best acid test by far will be the events that took place against what the program predicted.

Updates to me must never be just the mechanical filling in of percentages done and ASD/AFDs. Its also a forensic disection of what had gone by so far and the portion of baseline used to forecast that. You cannot be more right in the future if you do not wish to know how wrong you were in the past and why you were wrong in the past.

Since program consist of recurring sequences, lessons learned of the past can be reincorporated into similar recurring sequences or activities yet not done for better forecasts in the future. Or additional resources/manpower/sheer will power be brought to bear such that those durations on site will be achieved as intended in the program. And activities missed in program made that lead to real life delays be incorporated back into that program.

After all, even if baseline program is disregarded, surely the updated program is indeed the same baseline program in first place. Surely one will like to have the updated program more accurate in future even if one should want to disregard the baseline.

Also in an ’updated program’ , the delays are kind of ’incorporated’ into the program. At every week, things are back ’on schedule’.

Which made me exclaimed at site meetings where only updated programs were used as to "Why is this project 3 months late when every week we are back ’on schedule’ with the updated program each week!"

And if we are to say we are ’early’ , or we are ’late’ , or we are ’on program’, surely that must be in relation to what is planned int he first place, aka Baseline Program.

Only by knowing at any point in time, where we should be at (from Baseline), and where we are actually at(from updated program), can we then make more effective usage of resources in our control to bring the project to where we want it to be at.

I dont totally disagree with you guys, the point I was trying to make is that once the project is "live" the base line is purely historical. It was the route we intended to take and is used as you quite rightly say for comparison with the current plan.
Also as planners we should concentrate on looking ahead, if the project changes and it will/does our job is to re plan/schedule the project to the earliest completion and in that task the baseline is no longer relevant. (other than as a point of reference.

Think of the baseline as a paper print of the original contract programme and only change it when the contract completion date is changed by an extension of time. (But keep a copy of the original baseline!)

I believe that a project has one current plan and a series of baselines produced as and when extensions of time are awarded.

Hi Andrew,

At any point in the project , we should know ’where we should be at’ and ’where we are at’

’where we should be at’ will be indicated by the Baseline Program or modified Baseline (if major changes dictated by significant changes in work scope)

’where we are at’ will be indicated by updated program.

Surely you dont RUN YOUR PROJECT against a baseline?
The baseline reflects the plan at project commencement. You run a "LIVE" schedule which WILL allways be different to the baseline. A comparison between the baseline and your current plan will give you the ammunition for EoT’s assuming reason for variation is recoverable under whatever form of contract you are using.
Each time the scope of your project changes your current plan will change and give a revised completion date, that is how you substantiate your EoT, Yes?

To complete a project Successfully YOU DO NOT NEED A BASELINE!

To complete a project Successfully YOU NEED ACCURATE CURRENT INFORMATION !

Am I missing something? I think David has the right idea.
1. The original baseline is the original plan based on the original estimate, drawings spec etc. (the basis for the contract)
2. As Planners we maintain the current plan by adding actual data and reviewing logic to reflect ANY changes that may occur. This may include substantiation of EoT claims.
3. We can create additional baselines at any time, but untill an EoT is granted the original baseline must be the basis of any comparitive reporting.

As planners we should spend most of our time concentrating on what is to the right of the data date (time now) line.

Hi David,

I think that you use the original programme (as a formal document) in preparation of the revised programme, which can only be prepared after granting of EOT not before.

The best I can do (in the case of delay in approval of the EOT) is to have a proper and precise data for the changes (or even to prepare an internal schedule to reflect the changes).

So in case of delays from employer/engineer side then I shall claim for EOT (which can lead to further compensation) ASAP and later on incorporate the changes in the original programme (if approved).

Regards,
Karim

Hi Ulysses,

The best time to re-baseline is when everyone has agreed all the changes (as soon as possible) - although such changes may not yet have been formally written into the contract.

This situation is always arising, especially in Design work. The problem that we encounter is the fact that it can be very difficult to differentiate between a proper scope change and a natural evolution of the design itself. Not only that, but it can takes months for the client to agree on such changes. As a result, and in order to continue making progress, we often have to work on the amended design without a formal change having been fully agreed or incorporated into the contract. This is why we have to be very strict and keep records of all such communications.

Ultimately, we have to be extremely careful in order to avoid "scope-creep" - otherwise we find ourselves massively overspending and monitoring a project against a baseline that is so far out-of-date that it has little value. The ideal situation is to have everything agreed and incorporated into the contract BEFORE re-baselining - but practical implementation often does not allow you such luxury - so as long as there is some formal or written reference to the change, then it’s best to re-baseline as soon as possible.

Cheers.

James.