Target Schedules? No. No. No. Adjust the Baseline

A contractual part of most if not all Projects is the submission of a Contract Programme - it is sometimes better to refer to it as the Schedule - which is subject to the scrutiny of the Employer/Engineer before they provide their affirmative approval.

This is commonly referred to as the Baseline Schedule (once approved).

Of course, the tendency is to oftentimes give only Code 2/B so that comments therein can be used as a reason for the Employer/Engineer to always question the intergrity of said Baseline whenever convenient for them to do so.

This happens a lot because Payment is mostly linked with recording progress against an approved Baseline hence, in its absence an unscrupulous Party can use this to NOT make payment.

An ex-colleague once said the Contract is there to ALLOW payment, not prevent it and this adage should be adopted when and wherever possible especially when one is in charge of said process which decides whether payment is valid/entitled or not.

Anyway, commonly, Code 2/B is accepted so as not to hinder payment, therefore wherever possible insist that Code 1/A be achieved first however much internal pushback is received.

What has this to do with Target Schedules?

So often on site, the Baseline is achieved and for many people "the box is ticked".

At best, the Baseline is a "best guess" at the time of its submission, however, as the Works ramp up, Parties involved tend to delve into the Schedule further and adopt various iterations of the same for their own purposes.

It even happens that when the Baseline is noticeably slipping, pressure is brought for the Contractor to provide a "Target" Schedule which will be used for monitoring and discussion at meetings.

This is to be avoided completely.

Once the Baseline has slipped, irrespective of who is at fault, the important item to consider is how the latest "best guess" will impact the end date or Milestones therein.

However inconvenient it is to show the Completion is now +10 days (note that the Engineer may well have to report to the Employer and will want to avoid showing delay at all "costs" - no pun intended - else they then have to explain what the heck is going on to delay the Works) hence, the Engineer/Employer's Representative asks that the Contractor repurpose a Schedule to show the progress but "squeeze" upcoming activities to ensure that they can report back "upstairs" that the Target Schedule is showing the Project to finish "on time".

In so doing, the Contractor believes they have "dodged a bullet" i.e., no hard questions will be asked, the Engineer KNOWS they have dodged a bullet and ultimately, the Project will still most likely be late and bitter recriminations as to who owes whom extensions of time begin.

It is so much better to stick with the Baseline - impacts and all - and deal with the consequence as and when they are apparent.

The Contractor (and Engineer/Employer) knows that LDs will be applicable if EoT is not substantiation - though entitlement known by Engineer/Employer should possibly be awarded even in the absence of substantiation being provided by the Contractor - so that penalty exists and should not be hidden for the convenience of the Party who will ultimately "avail" themselves of the same penalty as and when it is prudent to do so.

Having a late Completion Date standing out like a sore thumb leaves no Party anywhere to hide and ultimately can show how the Contractor, through mitigation, begins to pull back the late COmpletion Date as the Works progress further.

This is healthy for all Parties concerned and should lead to an open and frank approach as to how to complete the Works in as short a time as possible (presupposing this is the intention of the end-user as the Project proceeds).