Chapter 15 Protocols and Methods of Analysis

301

The Protocol recommends that, in deciding entitlement to EOT, the adjudicator, judge or arbitrator should as far as is practicable put him/herself in the
position of the CA at the time the Employer Risk Event occurred. He/she
should use the Updated Schedule to establish the status of the works at that
time. He/she should then determine what (if any) EOT entitlement could or
should have been recognised by the CA at the time.
This application seems to suggest that the blindsight approach should be adopted
and that the analyst should only take into account, when modelling the delaying
event, what was known at the time. For instance, where a work activity is extended
due to an increase in quantity, a reasonable assumption, at the time, would be that
the activity duration should be extended in proportion to the original scope of
work. Contemporaneous records may provide evidence of what, at the time, the
management team thought the effects of the delaying event might be. This
approach has led to criticism when dealing with delays retrospectively why look
into the crystal ball, when you can read the book.5 When dealing with delays
retrospectively, the analyst will have data and evidence of the actual duration and
sequences that resulted from the delaying event. Using this information, the hindsight approach will lead to a more realistic and accurate response of the schedule
and reduces the speculative and subjective assumptions.
The data required when undertaking a basic time impact analysis are:

The networked as-planned schedule;

The details of the delaying events (listed and categorised as previously
described);
The progress records; and
The as-built details for the project.

1. Collect all the relevant data including

The as-planned network (repaired as necessary),

The list of delays, and

The as-built and progress data.

2. Identify the first delaying event and the date it happened.
3. Identify the progress records for the date, or just prior to the date, that the
delaying event occurred. If actual progress records for the date do not exist
for the date in question, they must be synthesised by interpolation between
5

Attributed to Aneurin Bevan (18971960) but used more recently in Beware the Dark Arts, p. 5.

Section IV

Progress records and as-built data whether collected from diaries, weekly reports
or progress meeting minutes should be cross-checked and verified against other
records such as photographs, quality records, time sheets and so on to verify their
accuracy. The method depends on updating the schedule to the point just prior
tothe delaying event occurring. Most probably, progress and as-built data for a
particular date, if it is not on the date of a specific progress report, will not be
available; therefore, it will be necessary to interpolate the specific data between
the records for two known dates.
The stages in undertaking time impact analysis are:

302

A Handbook for Construction Planning and Scheduling

4.

5.

6.

Section IV

7.

known progress dates. To be completely accurate, the progress records should

be that of the actual date of the delaying event. Inspection of the progress
records will determine how significant a time difference is. Onshort duration
and fast-moving projects, the significance is liable to be greater.
Using the progress data, update and reanalyse the network and recalculate
the critical path. This represents an updated network taking account of
the progress of the project (and any variances in progress, faster or slower
than planned) at the delay event date. At this stage, the network logic
around the progress date should be examined to ensure it is still robust;
out-of-sequence progress may result in illogical sequences and dangles
(see Chapter 13 and 17).
The updated network will show whether, as a result of progress thus far, the
project is likely to be completed ahead, on or behind schedule. If the update
indicates that the project is likely to finish ahead of schedule, the contractor
has, by his efforts, created additional float in the project (terminal float).
If the update indicates that the project is likely to finish behind schedule,
absent of any unidentified delaying events, the contractor has created a likely
culpable delay to the project for which it may wish to take action to reduce.
A record of the static or changed forecast completion date is made. At this
stage and all subsequent intermediate stages, it is good practice to save and
rename a copy of the updated network and use the copied version for the next
stage of the analysis.
Using the updated network, model the first delaying event. The method of
modelling will be dependent on the type of delay. In some cases, it might be
necessary to use more than one of the methods. For instance, an additional
activity may also require a date constraint. When the delay has been modelled, the network is reanalysed. If the delaying event was on or near the critical path, then the end date of the schedule (calculated by the previous progress
update) will be extended. The difference between the previous finish date and
the new date is the delay attributed to the delaying event, the cause and
effect link having been established.
If the prior progress update was ahead of schedule and the delaying event
now modelled on or near the critical path, the effect of the delay will be to
consume part or all of the newly generated terminal float thus reducing or
negating the potential delay to the project (subject to the contract conditions
regarding the ownership of float).
A record of the new forecast completion date is made and the impacted
network saved and renamed for use in the next stage of the analysis.
The procedure for modelling subsequent delaying events follows the sequence
described in stages 25.
Following modelling of the last delaying event, recording the resulted and
copying and renaming the network, the impacted network should be progress
updated to the actual end of the project. This could be a number of updates
representing the, say, monthly progress reports or a single update at the end
of the project, when all activities should be complete. Continuing progress
updates to the actual completion date will confirm if any further time was
gained or lost during the period. The final updated schedule will represent,
and should coincide with, the as-built schedule for the project.

Chapter 15 Protocols and Methods of Analysis

303

The starting point for the analysis is the networked (linked) as-planned programme as shown previously in Figure15.2.
The first delaying event is identified and the date that it took place. Progress at
that date is identified. In this case, the design approval took longer than
expected so progress is measured up to the end of week 2 as shown in
Figure15.3a. The dropline shows that activity 8, Clear site and RL excavation, is 1 week behind schedule.
When the schedule is reanalysed (the critical path recalculated), the position or
status of the project at the time of the delaying event is established. The slow
progress of activity 8 results in the critical path being extended, and the milestone 17 Handover Key Date 1 is delayed until 2 July, 1 week later than the
original as-planned date of 25 June, as shown in Figure15.3b. This is considered to be the effect (or likely effect) on completion due to the thus far slow
progress of clearing the site and reduced level excavation; this would usually be
considered to be a culpable delay on behalf of the contractor.
The first delaying event is then modelled in the progress updated schedule.
Aspreviously, the design approval took 4 weeks as shown in Figure15.3c.
When the schedule is reanalysed, the critical path is further extended and the
handover date is delayed until 9 July, 1 week more than the previous date of
2 July and 2 weeks later than the original as-planned date of 25 June(see
Figure15.3d). The additional 1 week is said to be the effect (or likely effect) on
completion of the delay to the drawing approval period beyond the delay
already apparent due to the slow progress of activity 8.
Progress just prior to the second delaying event is input to the delay schedule,
and the schedule reanalysed. Figure15.3e shows the effect of progress and the
likely effect on the completion of the project. The analysis shows that a further
week has been lost; the additional lost week appears to be due to the extended
period taken to manufacture and deliver the steelwork (activity 6). Usually, this
would be considered a culpable delay, the responsibility of the contractor.
The next delaying event, the stoppage of the steelwork erection whilst the
wind-bracing calculations are checked, is modelled on the previously impacted
schedule as shown in Figure15.3f.
When the schedule is reanalysed, the critical path is not extended any further,
and the delay to completion remains at 3 weeks, as shown in Figure 15.3g.
Thereis no effect (or likely effect) on the completion date as a result of the
steelwork erection.
Progress just prior to the third delaying event is input to the delay schedule and
the schedule reanalysed. Figure 15.3h shows the effect of progress and the
likely effect on the completion of the project; there is no effect (or likely effect)
on the completion date.
The third delaying event, the additional racking, is then modelled on the schedule previously impacted by the second delaying event as shown in Figure15.3i.
When the schedule is reanalysed, the critical path is not extended any further
and the handover date remains at 16 July(see Figure15.3j). There is no effect
(or likely effect) on the completion date as a result of the installation of the
additional racking.

Section IV

The time impact analysis method is illustrated in the following example:

Figure 15.3 The time impact analysis method.

Section IV

Section IV

Figure 15.3 (Continued)

Figure 15.3 (Continued)

Section IV

Section IV

Figure 15.3 (Continued)

Figure 15.3 (Continued)

Section IV

Section IV

Figure 15.3 (Continued)

Figure 15.3 (Continued)

Section IV

Section IV

Figure 15.3 (Continued)