BEWARE THE DARK ARTS!

DELAY ANALYSIS AND THE PROBLEMS

WITH RELIANCE ON TECHNOLOGY
A paper presented to the Society of
Construction Law International Conference
held in London, 6th-7th October 2008

David Barry
January 2009
D95

www.scl.org.uk

BEWARE THE DARK ARTS!

DELAY ANALYSIS AND THE PROBLEMS
WITH RELIANCE ON TECHNOLOGY
David Barry

Beware the dark arts was the sage advice of Albus Dumbledore to the young
Harry Potter. Besides budding wizards, construction clients (at the project or
dispute resolution stages), contractors and lawyers would be equally well
served by this advice when it comes to the difficult subject of delay analysis.
Project scheduling (programming) in general, and delay analysis in particular,
suffers from its own particular technical jargon, with terms such as critical
path, free float, logic links and concurrent delay being cited with free
abandon. Moreover, delay analysis, like Lord Voldamort, comes in many
guises and it seems there is a spell for every circumstance. What would you
like conjured err proven, sir? Let me just mix up some fragnets,
lags, eye of newt and hey presto!
Let us also not forget the delay analysts best friend, the computer. One
speculates at times about who is controlling who. Is it any wonder that
scepticism about delay analysis is rife? The irony is that it all stems from a
most practical industry, construction.
This paper seeks to assist the sceptics, by providing some general clarity as to
what each of the commonly used delay analysis techniques are, what they do,
what they do not do, and when they may appropriately be applied; it also
discusses the relationship between scheduling and technology.

Delay analysis methods

There are five commonly used delay analysis techniques: 1
o
Impacted as-planned method;
o
Time impact analysis method;
o
Collapsed as-built or but-for analysis method;
o
Snapshot/windows/time slice analysis method;
o
As-planned versus as-built windows analysis method.
1

A word of warning about titles there are no set, or agreed, labels for the various delay
analysis methods employed today. One might find that certain analysts use the term
time impact analysis when in fact they are using the method I refer to as time slice
analysis. Indeed in recent important judgments about delay (particularly Mirant & City
Inn) the titles used by the programming expert witnesses and referred to by the judges
are at odds with the descriptions I set out in this section. I suggest that one should never
presume to understand the analysis technique employed by an analyst simply on the basis
of what label he gives his analysis, rather one should investigate the technique to
establish a clear understanding of the methodology employed.

Each method is discussed below in terms of technique and application.

However, it is first important to provide some definitions.

Prospective v retrospective
Delay analysis techniques are either prospective or retrospective.
Prospective analyses refer to the future, and seek to determine the likely
impact of actual progress or a particular event(s) on project completion.
Retrospective analyses refer to the historic, and usually seek to determine the
actual impact of events upon progress and completion.

Dynamic v static
Dynamic analyses involve schedule calculations, through simulation using
computers and scheduling software. Static analyses rely on the components
and common sense of the schedule while avoiding significant computer
calculations.

Baseline schedule
This is the schedule which best represents how the contractor intends to satisfy
its responsibility to complete the works within the contract period. This
schedule can sometimes be engrossed into the contract; more often, it is
required to be produced and agreed shortly after the contract is awarded (such
as a Clause 14 programme under most civil engineering forms of contract). In
the absence of a clear contractual baseline schedule, it tends to be the schedule
prevailing at the time the contract is awarded or work commences on site.
Determining the baseline schedule is a matter of reasonable and objective
analysis, with the contract documents being the first point of call.

Networked schedule
A networked schedule is one that has been produced in scheduling software,
such as Primavera or Microsoft Project. It will contain activities (representing
the work content) and logic links (representing the relationships between
activities). The combination of software, activities and logic links will allow
the schedule to be updated with progress data, and will enable the effects of
change to be simulated.
Turning now to the most common methods of delay analysis:

1.

The impacted as-planned analysis method

The overall thrust of this method is to establish the hypothetical impact of

delay events on the baseline schedule. It is a prospective analysis method. It
is also a dynamic method, and therefore requires a networked schedule. The
delay events that the analyst wishes to model are introduced into the baseline
schedule, and linked in an appropriate manner. 2 Having incorporated the
2

For example, if during excavations access to the site was denied for a week, then the
delay event could be introduced by imposing on the excavation activities a no-work
calendar constraint for that week. Alternatively, a new one week long activity entitled

delay events, the schedule is then modelled/recalculated. Any resultant impact

upon completion is determined to be the critical delay impact of the introduced
delay event(s).
There are really only three significant tasks required of the analyst in carrying
out this technique. Firstly, he must establish that the baseline schedule was
achievable, otherwise the hypothetical delay he calculates may not be correct
for the simple reason that some or all of the delay he has calculated may have
been inevitable notwithstanding the delay event. Secondly, the analyst will
need to ensure that the schedule is suitable for dynamic simulation. Most
project schedules are not. It is usually the case that the analyst will have to
make adjustments to the schedules logic, particularly in replacing applied
constraints, 3 so that the activities can react appropriately during the
recalculation process. Thirdly, the analyst must establish the nature, extent
and relationships of the delay event(s) to be introduced, so that it can be
appropriately linked in the schedule.
The impacted as-planned analysis method enjoys the benefit of simplicity, and
will therefore be inexpensive to prepare. Its disadvantages, however, are
substantial particularly when used in post contract disputes.
Obviously this technique does not establish whether delay to completion was
actually incurred as a consequence of the modelled delay events. My
experience is that most decision makers (be they judge, arbitrator or
adjudicator) are primarily interested in this key causation factor. Moreover,
this technique does not even establish if delay was likely to occur as a
consequence of the introduced delay events, because it ignores the effect of
actual progress on the works, or schedule for the works, up to the time of the
event. The timing of the delay event is just not considered: it is possible that
at the point in time when the delay event occurred it was unlikely to have any
impact upon project completion due to progress or events elsewhere.
Moreover, it is widely recognised that the impacted as-planned analysis
method lacks balance and fairness because it typically includes only one
partys delay events, while at the same time assuming perfection from the
other party.
My view is that this method should only be employed when the contract
specifically requires its use, or perhaps where the delay events being modelled
are all incurred right at the outset of the project.
One interesting question, however, is whether this method might be used to
model the effects of unforeseen conditions which are later discovered. The
principle being that these delay events did actually exist at the outset, and the
works related thereto were inevitable, just nobody knew about them.

access denied could be inserted between the work start milestone and commence
excavation activity.
A constraint relates to an absolute condition that can be assigned in schedule software to
an activity, for example Activity A may not commence before 1 October 2008. Such
constraints have the potential to skew the results of any change simulation exercise.

2.

The time impact analysis method

I have devoted more of this paper to the time impact analysis method than the
other methods because it is the method recommended by the SCL Delay and
Disruption Protocol,4 and it is presently used extensively. Like the impacted
as-planned method (discussed above) this is both a prospective and
dynamic method. However, time impact analysis overcomes some of the
key disadvantages of the impacted as-planned method, insofar as it takes
account of the effect of progress and the timing of delay events on the works.
The time impact analysis method therefore requires good as-built data with
which to update the schedule. If detailed and regular progress data is not
available then it is unlikely that this method can be used.
The time impact analysis technique is precisely the same as the impacted asplanned method (discussed above) but with the following highly significant
variant. For each introduced delay event the networked baseline schedule is
first updated with progress to a point in time just before the delay event arose
(for example, the day upon which a specific variation instruction was issued).
If the updated schedule identifies a delay to completion this is registered (say,
five days). The delay event is then introduced into the schedule to establish
the likely impact upon completion, given the status of the works at the time
the delay event arose using exactly the same technique as described under
the impacted as-planned method above. The schedule is recalculated, and the
new calculated delay to completion is registered (say, 15 days). It follows, in
the example, that the incremental likely delay to completion due to the delay
event is ten days. This is an iterative process repeated for each and every
selected delay event. 5
In principle this is an appropriate method for use during a project, and it
usually sits in harmony with most standard delay/extension of time contract
clauses (in their contemporaneous project context). In this connection, the
difficulty is not the principle behind the method but its reliability, more of
which later.
The application of this method in post-contract dispute resolution is deeply
questionable, however. Proponents of the SCL Protocol will not appreciate
this view, as the Protocol states that:
[Time Impact Analysis] is the preferred technique to resolve complex
disputes related to delay and compensation for that delay. 6
The Protocol recommends that this methodology be used wherever the
circumstances permit 7

4
5
6
7

The Society of Construction Law Delay and Disruption Protocol, October 2002,
available from www.eotprotocol.com.
Where there are a great number of delay events to be introduced, analysts will tend to
impact the monthly schedules with the events that arise in that month, rather than create
numerous eve schedules.
SCL Protocol, see note 4, paragraph 4.8.
SCL Protocol, see note 4, paragraph 3.2.11.

 in deciding entitlement to EOT, the adjudicator, judge or arbitrator

should so far as is practicable put him/herself in the position of the CA
[Contract Administrator] at the time the Employer Risk Event
occurred. 8
In the post-contract dispute, it is perhaps incongruous to establish the likely
impact of something that has already occurred. The delay events complained
of have happened in the past. The impact of these delays should be a matter of
fact, and provided the information is available, capable of analysis and
determination. I once heard a leading arbitrator QC put it more eloquently;
Why look in the crystal ball when you can read the book?
Time impact analysis can be used to demonstrate why a significant switch in
emphasis or strategy occurred at a particular point in time: as a consequence
of the likely impact of Delay Event X, we re-sequenced. However, assuming
the analysis was not carried out contemporaneously, it seems to me that the
true justification for such a switch will either be a matter of fact or impression.
Time impact analysis may be used to back up such evidence, but perhaps
should not be used as primary proof.
It has been my experience that arguments in favour of the use of prospective
time impact analysis in post-contract delay analysis tend to rely on the usual,
and indeed sensible, contract provisions that require contemporaneous notice,
particulars and/or assessment of the entitlement to an extension of time. It can
be argued that such a justification for a prospective approach usually takes
these contract provisions out of context. Experienced project managers and
planners are well aware that these provisions are there to facilitate
contemporaneous project and contract management, and to provide a balanced
and fair approach to resolving what can be complex programming matters in a
timely manner, which will facilitate the future planning of the works. These
provisions are drafted in the knowledge that one has to operate in imperfect
circumstances during the course of the project and rely where necessary upon
estimates. These provisions recognise, indeed are motivated by, the situation
that the full matrix of facts relevant to delay and progress will not be available
until after the event.
If either party has not operated these provisions, for whatever reason, during
the currency of the works, then it follows that the full matrix of facts will be
available by which to assess delay and extension of time entitlement. The
assessor is then in the fortunate position that he can proceed not on the
imperfect world of estimates, but on the basis of fact (including taking account
of whether mitigation measures were actually employed). In such a manner, a
fair and balanced assessment can be achieved.
The aspect of the SCL Protocols recommendation of time impact analysis that
bothers me most is the relationship between the following statements (all of
which I individually agree with):
Entitlement to an EOT does not automatically lead to entitlement to
compensation and compensation for prolongation should not be
8

SCL Protocol, see note 4, paragraph 4.19.

paid for anything other than work actually done, time actually taken up
or loss and/or expense actually suffered. 9
the amount of EOT [determined by Time Impact Analysis] may not
precisely reflect the actual delay suffered by the Contractor. 10
Time impact analysis is generally the most time-consuming and
costly when performed forensically. 11
What one can take from this is that the best one can do from a time impact
analysis is secure an extension of time, and presumably relief from liquidated
and ascertained damages (LADs): forget, however, about recovering loss and
expense associated with delay. Having spent a fortune on the initial analysis,
the poor old contractor has to go back to the delay analysis drawing board
(certainly if he hopes to recover damages, which he usually does!). Perhaps
the SCL Protocol drafting committee might have considered suggesting that a
less expensive and more useful (in recovery terms) delay analysis be carried
out first. This could then be followed up with a time impact analysis if there
was a legal basis for getting relief from LADs beyond the excusable actual
delay suffered (for which an extension of time has already been established by
the preceding retrospective analysis).
In my view, the unfortunate ringing endorsement of time impact analysis in
the SCL Protocol does not serve the industry at large but rather the delay
analysts required to satisfy the recommendation. However, I recognise there
may be circumstances where an after-the-fact analysis of likely delay
assessed by time impact analysis is required, and certainly I applaud its use
contemporaneously.
Experience tells me that time impact analysis is difficult to produce reliably.
To do that the following criteria need to be satisfied:

9
10
11
12

The baseline schedule (which is hosting the analysis) must be

shown to be achievable before embarking on the analysis;

The logic in the schedule must be capable of correctly simulating

the likely effect of the delay event. The significant potential for
skewed results arising from inappropriate programming logic must
be removed;

The progress/as-built data incorporated into the schedule must be

detailed and accurate;

The remaining planned sequence of the schedule for each time

slice 12 prior to impacting the delay event must reflect the
contractors known future intentions;

The delay events to be introduced should be based only upon

information known at the date of the time slice;

SCL Protocol, see note 4, Core Principles 14 and 16, page 8.

SCL Protocol, see note 4, paragraph 4.8.
SCL Protocol, see note 4, paragraph 4.16
That is, the point in time of each iterative analysis; usually the day on which the
particular delay event arose.

All known delay events as of the data date of the time slice
(irrespective of whether they are the liability of the employer or the
contractor) should be taken into account, both in terms of progress
updating and future forecasting.

One final comment regarding time impact analysis relates to the sequence in
which numerous delay events are introduced. The key factor is usually the
date upon which the delay event manifested itself. This can be very subjective
of course: was it the date the signed variation order was issued, the date the
contractor first became aware a change would be forthcoming, or the date
when the designer first realised the need for change, etc? Time impact
analysis methodology says that the delay events should be inserted strictly in
chronological sequence. At first blush, sensible! However, consider the
following example:
o

On day 3, the contractor starts excavating the foundations of a

building;

On day 5, a variation is issued to the flagpole atop the building

(which is scheduled to be installed 18 months hence) the likely
resulting delay is 50 days;

From days 10-40 the contractor suffers 25 days of culpable delay to

the building during the excavation works;

On days 50-70 weather (neutral event) resulted in a suspension to

the works;

Assume the rest of the project went according to plan, and the flag
pole arrived as expected 50 days late.

A mechanistic delay analysis methodology will ensure that both the

contractors culpable delay and the neutral weather delay are concealed by
something which may be happening far in the future, despite the fact that the
two earlier delays will actually be critical. I believe this is generally
inappropriate.

3.

The collapsed as-built or but-for analysis method

Unlike the previously discussed impact methods, the but-for analysis

method is retrospective.
This method should have the benefit of working from the full factual matrix.
The host schedule for the analysis should be a detailed and accurate as-built
schedule. The but-for method is however dynamic (see definitions above)
and therefore requires a networked schedule. As one would expect an as-built
schedule has no programming logic (ie linked activity relationships). While
the as-built schedule may have been produced during the project by
progressively updating the baseline schedule (which would contain the
original links), the influence of these links will have been entirely overwritten
in the updating process.
The key difficulty in this method of analysis is in developing retrospectively
the logical relationships between as-built activities. Rarely is this a simple
7

exercise: indeed on a complex project, such as a building involving extensive

fit-out, it is near impossible.
Assuming, however, that the logic between as-built activities can be developed
appropriately, the next task is for the analyst to identify the incidence of delay
within the activities on the as-built schedule. For example, one might identify
that remedial works were required as a consequence of a defective roof
installation, which served to extend the overall roof installation activity by
three months. The analyst, usually with some schedule fettling work, then
ensures that the delay aspect of the relevant activity can be removed, in order
to simulate what the as-built schedule would have looked like if the delay
event had not in fact occurred. Using the example above, if the completion
date of the whole project improved by a single month due to the removal of
the three month delay to the roofing works, then the conclusion is that the
incremental critical impact of that delay event is one month.
While this method is comfortably based upon the facts, it should be kept in
mind that the conclusion reached is a hypothesis and not a fact. A practical,
common sense and intensive review of the hypothetical conclusion must be
undertaken. Perhaps the sequencing of the works would have been entirely
different had the event not occurred, and therefore simply extracting a discrete
delay event does not represent fairly the but-for hypothesis.
The collapsed as-built method very much favours a defensive view point,
largely because most schedules involve a significant number of activities and
sequences which culminate in completion. The collapsing of one particular
path or sequence, in my experience, will rarely lead to any significant
improvement in the completion date. The next available near-critical path will
simply pop up and prevent any substantial collapsing. This method is
therefore often used, perhaps unfairly, to demonstrate to a contractor that it
would have been substantially late in any event.
This method can only be used satisfactorily in very discrete circumstances,
such as where the key delay being addressed is very close to the end of the
project, or where the project is wholly linear in nature (eg a simple tunnelling
project).

4.

Snapshot analysis method

This method is sometimes referred to as the time slice method or the windows
method. This is also a retrospective and dynamic analysis method. It
requires both a networked baseline or host schedule, and good as-built data to
allow progressive updating.
Simply put, the baseline schedule is updated at regular intervals, usually
monthly. Each update provides a snapshot of status at that point in time, and
from which one can discern two important pieces of evidence. Firstly, the
sequence of activities which represents the critical path to completion at that
date, and secondly, the extent of actual delay incurred to completion as at that
date.

To take an example, assume a snapshot schedule update of 1 June 2008

shows that there is no delay to completion, and the critical path runs through
the faade installation. Then a snapshot schedule update of 1 July 2008
shows that there is a ten day delay to completion and the critical path
continues to run through the faade installation. The analyst will conclude at
this point that ten days of critical delay were incurred in this period and these
delays relate to the critical faade installation activities. Thereafter a forensic
trawl through the critical path faade records for the period should usually
reveal the causes of the ten day delay. If the critical path changes between
updates, one usually tries to establish (through more interim snapshots or
objective pro-rating) where the switch occurred.
This method can be very effective and reliable, provided that the snapshot
schedules accurately and reasonably reflect the status of the works on the
respective dates. There are three criteria that influence the analysis
reliability. Firstly, the baseline or host schedule must be detailed and
networked (see the explanation above). The logic relationships within the
schedule electronic file must facilitate reasonable and practical conclusions:
the potential for skewed results is substantial, and must be eliminated.
Secondly, the historic element of each snapshot schedule must be developed
from accurate and detailed as-built data. Frankly, if regular detailed progress
data is not available then it is highly unlikely that this method of analysis can
be used. Inaccurate as-built data can substantially affect the results reached,
particularly the critical path route conclusions.
Finally, the future element of each snapshot schedule should accurately and
reasonably represent the status of the works on the analysis date. Too often
this aspect is ignored and the analyst will rely entirely upon the original
schedules sequencing and logic. If so, this type of method can easily be
undermined.

5.

As-planned versus as-built windows analysis method

This method is retrospective and static. Windows are used to break the
project into manageable sections or periods. The focus of the as-planned
versus as-built windows method is to establish the incidence, extent and
causes of actual delay to completion. It operates on the principle that actual
delay to completion must by definition be found on the actual critical path of
the project. The as-planned versus as-built windows method therefore seeks to
first locate and identify the projects actual critical path, and only then the
causes of delay.
Before seeking to determine the actual critical path, the analyst needs to gain
an excellent and detailed understanding of the project scope, the plan
(schedule, method statements, resources etc), the actual as-built progress data
and the contemporaneous records of the project, including photographs,
correspondence, reports, minutes etc. Having achieved this understanding, the
following progressive sequences of analysis/review are applied:

Apply common sense in reviewing the as-built progress in the

context of the plan and factual matrix;

Apply practical planning and project management experience in

reviewing the as-built progress in the context of the plan and
factual matrix;

Apply discrete schedule calculations using planning software

where it is necessary to distinguish the relative criticality of
competing paths. This should be used sparingly and with great
care.

It is my experience that the actual critical path can be discerned on most

construction projects through the progressive application of the above
principles. There is no magic or dark art to this method, and if successful the
conclusions should be capable of being effectively presented and understood,
even in the difficult environment of a trial. Sometimes it will be impossible to
separate a couple or more of near competing paths, other than through
artificially precise schedule calculations. This should be avoided; instead a
range of opinion or conclusions should be produced.
Having established the actual critical path from start through completion, it
can be compared to the corresponding planned activities, and from this the
incidence and extent of delay can be adduced. For example, if it is determined
that the critical path ran through piling into the generator slab construction, a
simple comparison of the planned and actual data might reveal that piling
started five days late on 1 June 2008 and the generator slab started 20 days late
on 1 September 2008. Therefore it can be concluded that 15 days of critical
delay were incurred in this window/time period, and the delays are to be found
in the piling activities (as this has previously been determined to be on the
actual critical path). From that point a careful forensic analysis of the piling
records and related data will usually reveal the cause of the delay.

Choosing a methodology
There are effectively four main criteria for selecting which delay analysis
methodology to use. These are:
o

What does the contract require?

Which approach is appropriate, correct, sustainable?

Does a lack of information preclude the use of any of the

approaches?

Do time/cost constraints eliminate certain options?

This paper may lend some assistance in answering the second and third
questions.
Effect and cause not cause and effect! One principle that I firmly support
is that when analysing delay to a project, one should establish the effect first
(ie the incidence and extent of delay) and only then move to establish the
cause of that delay. In such a manner both accuracy and objectivity are
10

ensured. My experience is that an approach which starts with the question

what was the impact of this delay? (ie what was the effect of this cause) can
be self-serving (whether by design or accident) and is prone to result in an
incorrect conclusion.
In post-contract disputes I usually recommend a retrospective approach that is
focussed on establishing actual delay. Theoretical delay is far less compelling,
and of course, importantly, does not assist with the recovery of loss and
expense associated with prolongation.

Technology and scheduling

Let us consider the modern schedule/programme on a substantial construction
project. It will usually include several hundreds of work activities; indeed
many project schedules will contain thousands of activities. Moreover, one
can usually expect, as a rule of thumb, that at least three times as many logic
relationships will be required to connect these activities. 13 In addition, there
may be many different and discrete rules that need to be applied to specific
activities or groups of activities, such as calendar rules 14 and constraints. One
might also find that the schedules are resource 15 and/or cost-loaded, which add
to the schedules complexity. The typical major project construction schedule
might therefore contain between 1,000 and 10,000 components.
Without computer hardware and scheduling software, it would be near
impossible to construct and publish a substantial project schedule wherein the
timing context and relative criticality of all construction activities could be
detailed and accurately established. Moreover, while one could chart-out a
substantial schedule by hand, it would be extraordinarily difficult to keep it
current and updated throughout the project.
So how is it, one might ask, that construction projects got completed in the
days before the computer arrived on our desktops? Well, the answer is to be
found in the woods and not the trees. Smart and experienced construction
professionals were and continue to be adept at understanding what is
approximately critical on a project, and did not concern themselves with
calculating float down to the nearest single day. It mattered little to them
whether a particular group of low priority activities had 150 or 175 days of
float. Indeed, the best people in our industry are very capable of walking onto
a construction site and judging within a short period of time what are this
weeks, or months, critical activities. The best forensic planners are usually
13
14
15

This is often referred to as logic, ie the rules which govern one activitys relationship to
another (eg Activity 2 construct wall cannot commence until Activity 1 construct
foundation is complete).
For example, electrical installation activities may be scheduled on the basis of a five day
week, whereas brickwork activities may be scheduled on the basis of a six day week.
Indeed, well developed schedules (through the resource loading application) will
establish the durations of key work by calculating the time required on the basis of a set
quantity of labour and/or equipment resources. For example, if a project has a
requirement for 10,000m2 of brickwork, and the contractor has available to him only two
bricklayers who can each complete 75m2 per day, then through the resource loading
application the software will determine that 67 work days will be required to complete
this work.

11

capable of researching the history of a well-documented project and discerning

what the actual critical path was throughout the project, and while they would
be greatly assisted by a CPM schedule, it is not an absolute necessity. Do not
believe for a minute what many forensic planners would suggest, that the
absence of a CPM schedule means one is ham-strung from determining the
critical path!
So do we really need sophisticated computer generated schedules? Yes.
Creating a detailed construction schedule forces us to plan and think-out the
works in advance and in detail. The old carpenters adage of measure twice,
cut once is particularly relevant to the construction industry, and it is always
beneficial to contractually insist upon detailed planning. Maintaining the
schedule forces us to re-plan and optimise our resources (including time and
money) in the face of progress and change. A CPM schedule allows us to
quantify time on a priority basis (ie float), and this can provide very valuable
insight to a stretched and stressed management team. The CPM schedule
allows us to record on screen and paper what otherwise might exist only
within the head of a valuable and experienced colleague (watch out for that
bus!). It also provides a focus and medium for coordinating the input of all
key parties, and allows us to accurately integrate the client, designers and
interested third parties into the projects strategy and tactics. Finally, the
baseline schedule and its subsequent updates will usually provide the parties
with an excellent basis from which to consider extensions of time and time
related loss and expense issues.
So, in my view, CPM scheduling is a modern and valuable tool, and when
used and applied correctly it can be very powerful. It is much better to have it
than not. However, the use of technology in delay analysis brings with it a
number of problems; so to the extent that it features in a dispute you are
involved in, I recommend the exercise of extreme caution.
Construction schedules can be very complex, involving many thousands of
components, as discussed above. Most of those components are not on display
in the powerful and effective graphics that are routinely produced today, and
are really only capable of being investigated by skilled planning personnel. It
is very easy to incorporate a significant flaw into the schedule either by
accident or design, and it can be very difficult to locate this flaw. Moreover,
just one rogue component in a schedule of say 10,000 components may result
in a misleading conclusion.
Most major construction contracts require that regular updates be produced.
Technology allows us to update schedules in a vastly more efficient manner
than was available before the computing age. However, an accurate updating
exercise is still very time consuming, largely because inputting progress tends
to overwrite some of the schedules logic, and therefore significant new logic
can be required. Moreover, things change and plans need to be adjusted as the
project progresses. Most schedules are susceptible to the domino effect, and
therefore it is not always simple to incorporate a change in strategy or tactics.
It is not unusual to discover that even good faith schedule updates
misrepresent the true mathematical contemporaneous status of the project.
12

Sadly, many CPM schedules (both baselines and updates) are produced for
tick-the-box purposes. The contract requires it, so a glamorous schedule is
produced by the contractor and then ignored. It is not unusual to find that the
contractor publishes one suite of schedules for the clients benefit while
working to his own internal schedules. Moreover, it is often the case that the
project is really run on the basis of two or four weeks look ahead schedules,
and upon investigation it is revealed that these bear little relationship to the
overall project schedule. While technology has made it efficient to produce
and publish schedules, it is wrong to presume that the published schedules are
rigorous and accurate. Check the context, check the content.
As discussed above, some of the delay analysis techniques require significant
adjustment to the logic within the project schedules, as well as the introduction
of new activities to represent delay events. Whenever this is required,
supreme caution is needed to ensure an objective and accurate result is
returned. While the marriage of computing and construction planning has
provided the modern project manager, planner and delay analyst with a most
powerful tool from which to launch dynamic delay analyses, great caution is
needed for therein lie the dark arts!

David Barry BSc, MA, MRICS, is a project and construction management

professional and former principal of Precept Programme Management which
was acquired by Navigant Consulting in 2006.

David Barry and the Society of Construction Law 2009.

The views expressed by the author in this paper are his alone, and do not necessarily
represent the views of the Society of Construction Law or the editors. Neither the
author, the Society, nor the editors can accept any liability in respect of any use to
which this paper or any information or views expressed in it may be put, whether
arising through negligence or otherwise.

13

The object of the Society

is to promote the study and understanding of
construction law amongst all those involved
in the construction industry
MEMBERSHIP/ADMINISTRATION ENQUIRIES
Jackie Morris
67 Newbury Street
Wantage, Oxon OX12 8DJ
Tel: 01235 770606
Fax: 01235 770580
E-mail: [email protected]
Website: www.scl.org.uk

14