The baseline schedule is the starting point for delay analysis used within any extension of time claim, delay in start-up (DSU) or business interruption (BI) claim analysis. Put simply, it’s evidence of the expectations of the contractor and should be used to model the impact of any delay or insurable event on the regular progress of the works.
This is clearly of critical importance; choose the wrong baseline and your entire delay analysis will be fundamentally flawed, and to be frank, quite useless. But, it’s not always easy to identify the correct baseline to use.
Sometimes the Contract may not include a schedule at all, or it may include a version of the tender schedule or a high-level summary schedule or in rare cases, a detailed schedule. These schedules may show the intent at the date of contract formation, however they may not be the most relevant schedule that sets out the actual sequence or method in which the works were planned to be progressed post contract i.e. it may be outdated.
Typically, a schedule is prepared soon after commencement of the contract and this schedule will likely be a more detailed and realistic view of the likely duration and sequence of the work. This is because once the contract is awarded, only then does the contractor sit down and really detail out how he intends to undertake the work. This may or may not differ from the schedule included within the contract, or it simply may just provide further detail, but usefully this schedule will likely have been used as the basis of progress reporting during the project.
But beware, this schedule is also a view of how the works were planned to proceed at that point; it may be incorrect, whether by under estimating or over estimating activity durations, it may contain flawed or missing logic or be missing crucial activities. In addition, it may be of insufficient detail in certain areas so that you cannot model the impact of the events accurately. So in a nutshell, some changes may be required to this schedule to make it “useable” in any delay analysis.
If this is the case a reconstructed or reconstituted baseline may be required, where these flaws are ironed out and a realistic version of this schedule produced. But beware if this reconstructed schedule wanders too far into the land of theory, with one eye on the delay events that you are looking to prove then it may be too far from the original intention to be considered relevant.
But let’s be clear about one thing, the starting point for an analysis of the contractor’s progress with the works and any delay and disruption is the contractor’s as-planned schedule in existence immediately prior to the occurrence of the relevant event under consideration. As the project develops, the schedules typically become more detailed and reflective of that actual intent, so a later schedule may better reflect the progress and plan at a date before the event occurred and this may be used.
So I hear you ask which baseline do I use? Well the answer is simply all of them! Let me explain, in any robust delay analysis you are in essence describing what should have and what actually did happen during the currency of the project. So, if the planned intent changed during the course of the project then you need to explain it and account for it within your delay analysis.
Ok, once again, its all based on the facts of each project, but typically, on large complex projects we will start with the schedule agreed post contract as the baseline, explain how this differs (if indeed it does) from the schedule in the contract, but still depicts how the completion date will be met. Then we will introduce any significant changes in sequencing etc. detailed within the re-baselines issued as and when they occur on the project.
This way, as we progress through the project within our delay analysis our planned intent is modified to reflect the intent at the time prior to the event occurring. Simple!
