THE APPROVED REVISED PROGRAM - CLAUSE 14.2 SUPERSEDE THE PREVIOUS ONE, AND SO ANY CLAIM SHOULD BE BASED ON IT.
ELSE, WHAT IS THE BENEFIT OF IT?

James, you tend to read things into what I say that I did not say. I did not say that the Baseline should not exist or that it should not be good. It should be done as early as possible and should be the absolute best that you can come up with at the time. It must be a complete, accurate representation of what is intended at the time it is made. Its existence, and how good it is will determine how easy and quickly it can be revised. You have to have a plan to change a plan. But it has a use-by date.

The construction industry is plagued by very poor planning to start with, and then by a reluctance to devote the necessary effort to frequently review and update.

I did not say leave Sydney with no plan and just point in the general direction of South and hope for the best.

In the allied invasion of Normandy there was a very good plan to start with but 5 days after it started things had not all gone according to plan. But the guys on the ground focussed on and planned for the best way to tackle the next stage based on what had been encountered and what remained to be done. They left the discussion of how and where and why the original plan had succeeded or failed to the historians.

At Stalingrad the German army was stuck with senior management which insisted on sticking to the original plan long after it was obvious that a new plan was needed.

If your baseline is usually obsolete/useless by the time the first progress assessment is made then I sympathise with you. You have started the project with a useless baseline and done so so often that you now expect it. I don’t say that this is not the state of the industry, I have certainly worked on projects where the plan was more of a marketing tool than a management mechanism, but it should not be.

A lousy baseline is probably the product of a lack of resources having been put into its production and/or Lack of buy-in to the strategy by those in charge of the day to day activities. As you’re on PP then you know how to plan, so the last possibility (bad planner) won’t apply ;)

To follow up your sailing analogy, a properly constructed and sufficiently detailed baseline plan is not only the route to the end, it is also the map. When the unexpected happens (as it always will) the baseline should be able to accommodate that and continue to show you the path to the end. That path will vary depending on day to day reality as you say, but the baseline will have predicted certain possible occurances (through multiple scenarios) and made certain allowances for the truly unforeseen, usually in the form of float. If reality overtakes these allowances, then a recovery plan becomes necessary.

You might set out from Sydney towards Hobart without a course marked on your chart (although I’d advise against it) you would be nuts to go without the chart and only a compass bearing to your destination. Knowing that you are off your planned course does not (always) necessitate returning to the start, I don’t understand why you said that.

My job is to write baselines and report against them during project execution. If they became irrelevant every reporting cycle I would not expect to have my job for very long. But I do.

That is called : Concurrent Delays

Ah, I understand what you mean wrt new events. so we were talking somewhat at cross purposes, my point was about judging progress of planned activities during the execution.

Now I understand what you mean about contractors thinking they can claim delay against baseline for items that would only have been critical should the baseline have been followed but in the event were rendered subcritical due to other driving delays.

Then (coz I’m interested and you’re in forensics),

say (in your example), the contractor is 4 weeks behind baseline at some point but the client issues his drawings 5 weeks late, thus pushing the contractor a further week behind. Accelleration is not possible (or doesn’t achieve anything) so the project completes 5 weeks behind baseline. You would consider the contractor responsible for 4 weeks and the client for one?

Most of my contracting work has been in SE Asia, where they tend to take a "last man standing" approach, whether legally correct or not (and "legally" in most countries in SE Asia will tend to be somewhat flexible anyway). There’s also the "he who holds the cash wins the argument" approach, which I particularly enjoy ;)

Not responding to the OP, but to this discussion about the different programmes on a project.

OK, imo the definitions of the different plans arebasically in line with what Andrew says.

What I don’t understand is how you can judge delay against a programme that is updated regularly (The Updated Construction Programme)? the delay becomes a part of the programme and so no judgement is possible, surely.

or, to put it another way; let’s say I am a contractor and I update my plan to show that I will finish a month after the baseline (or tender programme etc) says I will. Next month I update again showing no further delay. Am I no longer in delay? The third month I show a further 2 week slippage. Am I now 6 weeks in delay (which I would be, judged against Baseline) or only 2 weeks (judged against the last issue of the Updated Construction Schedule). When we all end up in court because the job was turned over 2 months after the originally agreed date (in the baseline) will I be able to get out my last issued Updated construction schedule and claim to be "on time" or will the client whip out the baseline and say I am late?

I’m missing something because it seems that you’re judging reality against itself by comparing progress with an updated schedule that that progress has been entered into.

Now (as I’m thinking about this I perhaps see what Andrew means)

If I am a month late (behind baseline) so I adjust the programme for the rest of the project and this is accepted by all parties while maintaining contracted milestones then I agree, progress moving forward needs to be judged against that. Stages for this are, in my experience, as follows

1. Eat the open float in the schedule
2. Eat the hidden float in the activities
3. Eat yourself Accellerate
4. Delay contract milestones

In any of these could be a change in project strategy, which would be an effective abandonment of the plan.

Item 1 is fairly common and in my mind does not constitute abandonment of the plan. Item 2 is equally common but more dangerous. Hidden float is by definition non-transparent and the tempation is to adjust durations to fit the desired outcome, rendering tehm impractical. Neither of these really constitute what I would call a "recovery plan" though, unless a strategic change has been made. float reduction on the project (arguments about who owns that float notwithstanding) does not constitute delay.

Accelleration, on the other hand, normally requires some sort of additional resource input and thus requires either the client to issue an instruction or the contractor to accept culpability for the acceleration costs (although I believe an instruction should still be issued). Once no more accelleration is possible, contract milestones slip and then an EOT is required, again this can be to the client or contractor’s account

If, however, this is occuring every reporting cycle then there is a fundamental problem with the plan. Once you reach the point that you are unable to judge progress of your critical paths in detail, and your bulk (or long float) items at least at a strategic "hours earned" level then I would say the plan has been abandoned.

It’s most likely we’re all saying the same thing, just using different terms. I am so sensitive on the issue because I was in the situation a few years ago as a project coordinator (thankfully not teh PM or Planner) where a major (nominated) supplier updated his programme each month and simply reset his baseline to match whatever had happened to his finish milestones, without giving thought to highlighting slippages, explaining them or offerring solutions to recover them. At the end of the job, he felt able to claim that he had finished "100% on time" as his baseline matched his progressed plan. Well, of course it did, he updated it every month! Fortunately (in some ways) he sent this letter direct to our client who proceeded to go absolutely mental but at least began to understand what we had been dealing with.

I think i am just misunderstood because I did’nt say that the baseline is not the approved programme. Of course whenever we are saying a baseline then it must be the approve programme. The thread author is asking about clause 14.2 so, it means that if the actual progress doesnt conform to clause 14.1 then you must revise the programme showing the modifications (as per clause 14.2) subject to clause 43. Let say that the revised programme submitted is again approved, will it not be considered a baseline?

It seems that we have different perseptions with regards to the terms that we are being applied here. All are just opinions my friends, don’t make things complicated. The longer explanation therehas the bigger the misinterpretation was. Lets go back to the basic and don’t be too smart.

Can somebody define the following please?

1. Baseline programme
2. Approved programme
3. Tender programme
4. Contract programme
5. Construction programme

Providing your definition for the items above will answer everybody’s questions.

Hi,Philip

as mentioned in claue 14.1 oof the general condition of contract, the contractor has to submit ,within 28 days from the letter of acceptance date ,detailed working program to show how the contractor is planning to complete the diferent construction activities for the complete scope of works within the original contract period.

So ,it is a construction program for the construction stage not program for tender as you stated.

and i can not agree that Most of the time the program is also unworkable , if the program will be prepared professionally and it should be ,then the program will be workable and will be the best leader for all parties contractor, engineer and the client.

Hi Khalil,

1) Revised programme means that u will crash/fastrack the activities on site in order to stick to the original completion date (as defined in your org baseline).

2) The org programme must be used in granting an EoT as it shows which side hold the responsibility that caused the delay(s).

Best Regards,
Karim