Nowadays, projects are getting more complex, contracts are more stringent and programmes are becoming more sophisticated. Computer softwares provide a big aid for such complexity. Despite this type of aid, implemented programmes still contain some irregularities in terms of their logic and activities that shift or pull back the project completion to illogical dates. For this reason, it is crucial to be very careful and consistent when running the programme and review the scheduling log to guarantee realistic results.
The starting point of planning is the baseline programme. The term baseline is defined in Merriam Webster Dictionary as “information that is used as a starting point by which to compare other information”. The practitioners did not go far from this definition. The American Association of Cost Engineers (AACE), for example, defines the baseline as “A fixed project schedule that is the standard by which project performance is measured”.
The baseline programme is a contractual requirement under most standard forms of contracts. For instance, FIDIC forms of contract requires the Contractor to submit a detailed programme to the Engineer for latter’s consent (under Sub-clause 14.1 of the 4th Edition 1987 reprinted 1992) or review (under Sub-clause 8.3 of the 1st Edition 1999). Thereinafter, upon receipt of the Engineer’s consent or the elapsing of the 21 day review period without issuing comments to the extent that the programme does not company with the Contract, the programme is referred to as the baseline programme.
Even if not consented/ approved by the Engineer, the baseline programme is a very important document / tool for the contractor’s internal monitoring and control. The baseline programme should be carefully developed since it forms the base for assessing claims of extension of time resulting from delays along with assigning the responsible party for the delay. For this reason, total float shall be carefully evaluated once the baseline schedule is finalized, along with the project longest critical path to make sure that it has a continuous chain of activities from start to completion. It is also recommended to minimize the use of constraints in the programme since it causes the schedule activity to have a zero total float thus result in an erroneous longest path.
The baseline programme is also used for updating the status of the works, monitoring and controlling the works. In addition to these basic requirements of the use of the baseline programmes, the baseline programme is the starting tool of supporting a claim for extension of time. The purpose of this article is not tackle the techniques used in delay analysis which depend on the baseline programmes, but it is only limited to discuss some thorny issues that planners should take care of. It should be noted that the baseline represents the best estimate of time and sequence that are needed to complete the scope of the works, at the time of preparing it at tender or commencement stage.
What makes a baseline programme a bullet proof programme? There are many articles and books that deal with the completeness of the baseline programmes. These can be summarized as follows: Scope of Works; Level of Detail; Timeline and Phasing; Schedule Calendar; Schedule Logic; Constraint Use; Forecast Calculations; Activity Duration and Budget Constraint; Cashflow Projection; and Project Critical Path. These summarized listed items should be carefully reviewed by a specialized planner in order to assess the adequacy of the programme and the risks that might come out from such irregularities nested within. The risks could result in devastating outcome when submitting a claim for an extension of time.
The baseline programme is considered a bullet proof programme due to the following factors: Scope of Works; Level of Detail; Timeline and Phasing; Schedule Calendar; Schedule Logic; Constraint Use; Forecast Calculations; Activity Duration and Budget Constraint; Cashflow Projection; and Project Critical Path
In elaboration of the above, a baseline programme shall represent a well-defined scope of the project and account for every item included in the bill of quantities to prove delay and/or disruption especially in the mega/complex projects with thousands of activities. It is also essential to identify contractual milestones or sectional completion dates.
As for the programme’s number of activities and level of detail, there are different levels in which the baseline programme can be presented, usually increasing with the complexity of the project. If the baseline is addressed to the Employer / Engineer, it shall include all major milestones, major elements of design, engineering, procurement, construction, testing and commissioning. Whereas if it is developed for the contractor’s internal management, it shall be at a sensible size (micro level) that can be easily updated and controlled, displaying the activities to be accomplished and mapping out the detailed tasks needed to coordinate work.
Another important aspect of the activities is their durations, which shall be well reasonable. Durations are usually calculated based on the quantities to be executed and their relative productivity rates. There are many factors which should be considered during this process such as availability and quality of manpower, machinery resources, weather conditions, and site conditions as well as other constraints.
Care should also be taken to thoroughly check all programme calendars since an error in the calendar setup will cause errors in dates. This means that holidays, weekends, weather conditions shall be allowed for in the programme calendar with a consistent number of hours per working day. It is also important to note that calendars must continue for a significant period after expected project completion to accommodate any potential delays.
The timeline should be realistic for conducting the proposed activities. Phasing is very important and shall be defined at the early stage of baseline preparation since it outlines the execution process. How shall we proceed? Per zone? Per area? Per block? Horizontally/Vertically? Phasing shall be examined and assessed by the project manager and reflected in the schedule, it may be revised during execution as per site conditions.
Another important aspect is the logic, since it is the key that represents the linear sequence of steps that need to occur for a project to meet its desired outcomes. This means that every activity in the programme should be connected to at least one predecessor and one successor, in a way that defines the requirements for the finishing of that activity. High and negative lags between activities shall be avoided to make the baseline reliable and a solid base/benchmarks for any future claim.
When a programme is discovered to contain irregularities at a point where it is adopted as the baseline by the parties of the contract, some steps need to be considered: What is the Extent of Problem? What Stage is the Project at? Are there on-going or potential Delay Claims? What is the complexity of the project? How many Stakeholders are parties to the Schedule? Thereinafter, after identifying these steps the baseline could be (1) corrected; (2) recreated/revised or (3) balance of work programme is produced.
I now turn to the updated programmes. There are different opinions/schools when it comes to the updated programmes and the way they are made. However, all schools agree that the updated programmes should reflect what actually happen on site during the period preceding the update issuance (whether it is weekly, bi weekly, monthly, etc…) since rarely does the execution of a project proceed as initially planned.
The main issue stemming out from the updated programmes is the change in logic and sequence of the works in a way different than what was included in the baseline programme, thus the remaining work shall be reassessed in light of the actual information. Contractors argue that it is their own way of work and they are reacting to site requirements.
Engineers/Consultants argue that the Contractor should not amend the logic inherited in the baseline programme and should acquire Engineers’/Consultants’ approval prior executing these changes. These arguments happen in reality irrespective of what the contract says, and the dilemma continues.