Delay Analysis - Correcting for Programme Errors

Greig Consulting, Norway and the UAE
W: GreigConsulting.Com, E: David@Greig.Com, T: 00 47 45418061,
Delay Analysis – Correcting Programme Errors
A Paper by David Greig1
of Greig Consulting
Should a programme containing errors be corrected prior to undertaking
delay analysis?
How and when should any corrections be made? Or perhaps, not at all!
These are some of the questions the delay analyst might face when
considering a contractor's programme which contains errors.
Overview
Any meaningful delay analysis has to be based on a sound and suitable programme, usually
prepared by the main contractorand submitted to the project contract administrator. However,
programmes frequently contain programming errors, some of which ought to be identified and
corrected prior to any analysis commencing. This article considers the typical programming
errors made and considers when and how they should be corrected.
Introduction
In the time before computers became everyday utensils programmes were usually static and
commonly used as monitoring tools only. Dynamic programmes only became possible with
the advent of the computer and planning software.
Most complex projects are required to have what amounts to a management programme that
allows monitoring and that it is dynamic enough to reflect progress and that impacts or
changes can be reflected in forecasts and appropriate adjustments made. Being dynamic
alone does not necessarily make a programmesuitable as a compensationprogramme, which
is what is needed for effective delay analysis. It therefore frequently becomes necessary to
bridge this gap which leads us to examine programmes in detail.
Contractor’s claims for extension of time usually include a delay analysis exercise that
presents an assessment of time entitlement resulting from certain owner risk events. Such
analysis’s commonly rely on the contractor’s baseline or revised programme. A programme
may have sufficed progress monitoring and updating throughout the project life though may,
nonetheless, contain errors which may not have been apparent when the programme was
prepared or accepted by the contract administrator though may inhibit meaningful delay
analysis due to such errors.
Programmeerrors are either conceptual in that the contractor’s planning is in someway flawed
or structural in that it incorporates incorrect programming practises.
Contractors may seek to correct the programme to form a compensation programme so that
it better depicts its contracted obligations and intentions to provide a suitable base for delay
1
Contributor - Martian Seaman ofDal Sterling LLC.

analysis. Conversely, contract administrators may seek to ensure any corrections made do
not especially favour the contractor or that no corrections are made at all.
This article describes some common programming errors and considers what and how
programme corrections may be made to ensure the programme is suitably fit for purpose as
an analytical tool. Also, as there are no notable authorities specifying how and when
programme corrections are to be incorporated some guidance and reasoning is suggested.
Types of Programme Errors
There are fundamentally two types of programming errors;
 Conceptual (or planning) errors are those which directly concern how the project was
planned and reflected in the programme. Incorrect planning, such as failing to include for
all required works, is a conceptual error. The programme itself may be correctly
constructed though reflecting an incorrect concept. Such errors may be inherent in the
baseline programme and be carried through to subsequent revised programmes and
remain unnoticed by the contracts administrator when giving consent or granting
approval.
 Structural (or scheduling) errors arisefrom the way the data is entered into the programme
(by the planning software), though the contractor’s planning intentions may be sound.
Examples include missing inter-activity linkage and an inappropriately applied activity
constraint. These may not inhibit programme construction though could prevent correct
updating and inhibit effective delay analysis.
Identification of conceptual errors requires a good degree of project knowledge and an
understanding of the contractor’s intent as well as to how the programme is structurally
constructed. Correcting many conceptual errors may change the programme out of all
recognition, which presents a challenge when presenting the corrected programme as a
suitable basis for analysis and may attract criticism of programme manipulation.
Conversely, structural errors can be identified by direct examination2
of the programme alone
and can be done mostly independent of any project knowledge. Correcting structural errors is
more straight forward and easier for the parties to accept since they originate more from poor
programming than from poor planning.
A way to avoid distortions whilst programme updating, especially when progress achieved
differs significantly from plan, one ought to adopt the simple rule of “ruthless logic”. That is to
review all logic links when creating a programme to ensure that whatever happens, the link in
question is absolutely necessary, and eliminate any which are not. The problem for
programme correction is that once a programme is created, it is for the delay analyst to
ascertain what causedit to elongate, which may be problematic if many links are inappropriate.
Whilst the programme corrections may suffice in many situations it can often be better to
explain the illogicality, and so apportion liability, though not necessarilychange the programme
itself.
Programmes can usually be made more realistic, though to do this extensively can be
exhaustive. Effective delay analysis requires a suitable programme as a tool, though not all
errors need be corrected. Given that the time needed is high, uncertainty and the need to
retain baseline characteristics programme corrections ought to be limited to corrections to
structural matters and any obvious isolated conceptual errors (misconceived planning) that
2
Detailed examination will require an electronic copyof the programme.

significantly distort forecasts and results and can be addressed. Also, every contractor has its
own way of constructing its programme, which depends in turn on its methods of working and
priorities that a reviewer might not necessarily share. It is therefore likely not cost effective or
necessary to correct all errors.
In any event, all significant programme errors ought to be identified, examined and reasoning
behind their correction or non-correction explained.
Contract requirements
The precise requirements for programme composition differ from contract to contract. Once
prepared the same programme can mean different things to different parties or stakeholders.
Five possible roles programmes provide was proposed by Vivian Ramsey3
, in that they serve
as;
1. Monitoring role:
a. milestone programme
b. progress programme
c. prediction programme
2. Dynamic role:
a. management programme
b. compensation programme
Contractor’s programmes commonly used as the basis for delay analysis fall under
‘management programme’ (2.a). though should also suffice as ‘milestone, progress or
programme’ (1.a. to 1.c) as well.
This paper is primarily concerned with the attaining a compensation programme (2.b.) which
usually originates from a management programme (2.a.). The suggested basic requirements
of a management and compensation programme are;
1. that it depicts the scope of work required;
2. that it depicts the contractor’s intent;
3. that it satisfies contract intermediary and completion requirements;
4. that activities depict discrete components of work;
5. that it is current to the identified status date;
6. that activity constraints are employed where appropriate;
7. that it contains sufficient inter-activity linkage and that such linkages reflect reasoned
construction sequences, and;
8. that it is dynamic4
enabling it to be progressed and identify the critical path(s).
If a programme fails to meet any of the above it could be said to be in error.
Definitions
The following terms are used in this article.
Term Description
Activity:  The execution of a discrete event of scope of unique work usually
utilising a limited number of resource types
3
ICE Construction Law Handbook,2007 edn.
4
Usually,though not always, a contract requirement. Programmes are dynamic when the timing of activities is
based on how they are linked together as opposed to being fixed to occur at a particular time.

Activity constraint:  A method of artificially constraining an activity to occuron a set date
or to certain time dependant criteria
Activity link:  The forecast relationship between two related activities
Activity link type:  Finish-to-start (FS) links identify a relationship between a
predecessor activity completing and its successor commencing.
Start-to-start (SS) links and finish-to-finish links relate to the start
and finishes respectively of two related activities. Start-to-finish links
are possible though counter-intuitive to most construction
practitioners
Activity link lag:  The programmed period of time between two related activity events
as applied to the activity relationship
Contract time
requirements:
 The contract boundary conditions (commencement, possession,
intermediary or completion milestones) or programme composition
requirements
Critical path
method (CPM):
 The method by which the timing and float of all activities is
calculated based on the activity durations, relationships and
constraints. Identifies the sequence of activities that describe the
critical path(s). Calculated by the planning software used to compile
the programme
Data date:  The date by which a programme is current. Also referred to as the
‘progress date’ or ‘update date’
Float:  Total float is the period an activity can be delayed without impacting
completion. Activities with zero float lay on a critical path
Programme:  The means the process of calculating and presenting how a project
is planned to be executed
Programme
Baseline:
 A programme that depicts the total contracted scope of works as at
commencement
Programme
Revised:
 A programme that depicts the scope of remaining works to
sometime after commencement and incorporates any revisions to
the contract requirements and the contractor’s intent
Programme
Mitigation:
 A programme demonstrating delay recovery in which faster
production rates and / or revised construction logic than that
previously identified in the (baseline or revised) programme is
adopted
Typical scheduling errors
The possible extent of errors made in respect of contractor’s programmes are numerous. The
following is a selection of the more common programming errors encountered.

Topic Mistake / Error
Conceptual errors
Programmes not
reflecting the
correct scope of
works
 Baseline programmes not including the whole contracted scope of
work or include for post-contract events or varied works
 Revised programmes providing incorrect depictions of the extent of
remaining works, omitting for varied works or revised intent
 Whole chunks of activities may miss critically important matters
such as; commissioning, third party interfaces, approvals
procedures and procurement lead times
Unreasonable
activity durations
 Overly short activity duration(s) rendering the programme
impractical
 Overly long activity duration(s) possibly hiding contractor float (i.e.
omitting to break long durations to detail required links instead of
lags, connecting activities with unnecessary multiple links simply
for timeline positioning)
Compliance to
contract
requirements
 Baseline programmes not complying with contract requirements
 Revised programmes5
depicting completion(s) later than the due
dates
Mitigation
programmes
 Achievement untenable. The contractor has to have the ability and
willingness to mitigate delay, and that all other parties are equally
able and committed
Intentional short
cuts
 Short cuts implemented to make a programme “fit” the project
period
 Phantom logic to fix activities in time, effectively create static
portions whereas the remainder is dynamic
 Updates including unregistered revisions of future activities
(durations and / or logic) in order to mask delays, only to emerge
later whereupon it becomes too late to address
Structural errors
Actual status
inconsistent with
the data-date
 Activity status6
is incongruent with the actual progress achieved
 Activity dates later than the data-date incorrectly recorded as as-
built
Activity
constraints
missing or
inappropriately
applied
 Constraints misused7
. Programmers sometimes adopt constraints
in lieu of reasoned activity linkage
 Necessary constraints not applied to activities representing the
contract boundary conditions
 Constraints inappropriately constraining activities impede CPM
calculations
5
In the case of unrecoverable delaythe contractor may programme to complete the works later than then the
due completion requirements.
6
when an activity actually commences,completes or the progress achieved.
7
Programmes are meantto be dynamic and activities flow dependanton the actual progress achieved and any
revision to durations or logic.

Missing or
inappropriate
logic links
 Missing necessary driving activity links result in inaccurate timing
of successor activities and inaccurate float calculations
 Activities with no successor activity may8
illustrate excessive float
 Missing non-driving links (between related activities) affects float
calculations and may suggest inaccurate construction sequences
 Excessive lag periods suggest hidden9
activities
 Negative lag periods can be anomalous10
Float, excessively
long or short
 Excessively long periods of float usually suggest an inappropriate
successor linkage or no successor at all
 Too many activities11
with short total float periods may suggest
engineered multiple critical paths
 Baselines containing12
negative float which identifies an activity
path completing beyond completion
Programme is not
dynamic
 Usually due to insufficient or inappropriate links and constraints the
programme may not be dynamic13
and becomes inoperable. It
remains static
Authorities
There are no definitive authorities tackling he matter of programme correction for the purpose
of preparing compensation programmes. Most commentators agree some form of correction
is warranted if necessary though none describe the actual process.
Pickavance14
identifies that merely because a programme has been approved or accepted
does not mean it fulfils the required level of accuracy necessary for proving the extent or
responsibility of delay. He continues suggesting that programmes are more often produced
for monitoring the construction process rather than for forensic examination, which may not
be subsequently undertaken.
The SCL Protocol15
suggests ‘any patently unreasonable or unrealistic logic, constraints or
durations should be corrected by agreement, failing which the contract administrator 's view
should prevail unless and until it is overturned under the contract dispute resolution
provisions’. The premise being that the contract administrator acts reasonably when
exercising its discretion, whom may be contractually bound to act impartially16
.
8
Referred to as ‘open-ends’.Exactly how the programme managementsoftware treats open-ends varies.
9
Finish-to-Startlinks with overly long lag periods are usuallyincluded for one of two reasons:firstly,that the lag
period is hiding an un-programmed activity, secondlythat the scheduler failed to identify suitable appropriate
linkage to another activity.
10
A negative lag suggests a successor eventoccurs before its preceding eventoccurs .
11
There is no definitive proportion of activities that oughtnot be critical. The author suggests 20% to 25% of all
activities to be critical or near critical as a maxima.
12
Depending how the programme constraints are applied revised programmes maycontain negative float if the
projectis expected to complete later than the current due completion date(s).
13
Programme is no capable ofundergoing CPM.
14
Keith Pickavance, ‘Delay and Disruption in Construction Contracts’,3rd
Edtn., 2005,pages 547 to 550.
15
Society of Construction Law,UK, publication ‘Rider 1 to the SCL Delay and Disruption Protocol’, para. 3.2.8,
dated July 2015.
16
For example under FIDIC 1987,Red Book.

Pickavance cites an arbitration17
case whereupon both parties’ experts agreed that the
baseline programme was not directly adequate for analysis. The arbitrator agreed that
programme was ‘illogical’ and was to be corrected in order to produce a ‘workable’ baseline
for the purpose of analysis.
Pickavance suggests that it is important that for all corrections the following information is
recorded:
i. Description of the error;
ii. Evidence the inadequacy;
iii. State opinions supporting the inadequacy;
iv. List relevant documentation;
v. Refer to witness statements (where relevant) replied upon, and;
vi. Describe all corrections made.
The SCL Protocol nor Pickavance however describe in any detail typical scheduling errors or
suggest how and when corrections are to be made.
Recording programme errors
Irrespective of whether programmeerrors are to be correctedor not once identified a proposed
compensation programme should be accompanied by a description of the programme
examination conducted detailing all errors encountered.
The first step in the correction process is to examine the whole programme and identify all
errors which might impact the contractor’s and owners liabilities as well as entitlements.
Wherever possible focus should be given towards activities that lay on, or close to, the
project’s criticaldelay(s) or those whichcaused delay / disruption. Programmeerrors unrelated
to the criticalpath(s), the contractor’s or owners positions can be identified and left uncorrected
since correction may not assist delay assessment.
For each programme examined, record or note as appropriate;
i) Programme name, filename, data-date and means of submission;
ii) All accompanying comments / method statements;
iii) Contract administrator’s response, and;
iv) Whether the programme was approved, consented, commentedor not commented
on at all.
For each programme error, record;
v) Activity(s) number, description and pertinent details;
vi) Description of the error including significance and impact in programme as a whole;
vii) When observed by contractor, if at all;
viii) Contract administrator’s comments (if any and known) and;
ix) Opinion of liability.
Corrections of Typical Errors
This section examines some of the more common scheduling errors and suggests how they
ought to be corrected to form a corrected compensation programme.
17
An unreported case.

As referred above it may not be possible to correct for conceptual errors. In such cases
remarks should be recorded explaining if a possible correction is not possible or feasible. All
necessary structural errors ought18
, where reasonably possible, be corrected.
Topic Comment
Conceptual errors
Scope of the
programme
 The programme should reflect the entire scope of remaining works
 Baseline programmes should reflect the contracted scope of work
only and no post commencement events or variation works
 Revised programmes, relevant to some point post-contract
commencement, should include for all remaining works and for all
known variations works, whether formally instructed or not19
, also for
any additional works resulting from any significant contractor faults
 Any necessary works which is not adequately covered by the
programme ought to be included by adding a new activity(s). The
duration of any new activity(s) should reflect the pace of work (i.e.
similar rates of resource consumption) for similar works already
included in the programme. Any new activity(s) should be linked to
obvious predecessor and successor activities
 It may be necessary to include new sections in the programme in
which case the programme’s WBS or Activity Codes should be
amended
Activity scope
and durations
 If the scope of an individual activity is too great or duration too long
consider incorporating a series of new subordinate activities.
Wherever possible the timing of these sub-activities should match the
original activity. This may introduce float to the subordinate activities
 If an activity duration is too short, in that it is impractical to complete
within the allotted duration, it should be extended to the shortest
duration reasonably possible cognisant of the extent of works known.
Generally, the contractor is responsible for any resultant delay to
completion20
. If the contractor can identify reasoned grounds21
for it
adopting an overly short activity durations these should be described
Compliance to
contract
requirements
 Ensure that the contract programme requirements are correctly
accommodated in the programme. For baseline programmes all
milestone and completion requirements are to be met or bettered, in
which case positive total float will be illustrated
 Review the particular contract requirements regarding preparation of
programme.
Mitigation
programmes
 Revised programmes which incorporate delay mitigate should reflect
the contractor’s actual intentions. All intended mitigation measures
should be specified and substantiated
18
It may well not be necessaryto correct certain structural errors,particularlythose which lay off the critical
path(s).
19
Contract administrators sometimes prefer revised programmes notto refer to variation works until they are
formallyinstructed.
20
Since the contractor accepted the contract completion requirements and was aware ofaware of the total scope
required it should have scheduled reasonable periods to execute all works .
21
For example it was instructed to adopt a shortduration.

 Use of mitigation programmes that substantially over-estimate the
contractor’s ability to recovery delay is discouraged. Unrealistic
programmes provide false record of the contractor’s ability and intent
 If an unrealistic mitigation programme is intended for a delay analysis
the contactor may consult the contractor administrator as to whether
the unrealistic programme should be corrected or left as is
 Use of an unrealistic mitigation programme may provide exaggerated
period(s) of delay entitlement. Whereas a corrected mitigation
programme directly may identify contractor culpability22
Structural Errors
Activity status  Activities commencing later than the programme data date cannot be
assigned actual dates nor percentage complete greater than zero. If
they do, investigate and assess the correct situation
 Activities and / or events completing prior to the programme data date
should refer to actual activity progress dates. If not, investigate,
assess and correct
 The recorded percentage complete should reflect the actual status of
progress achieved as at the programme data date. If not, re-assess
and correct
Constraints  Use of activity constraints should be kept to a minimum
 Applied activity constraints which inhibit a programme from being
dynamic should, ideally, be removed or revised to a different type of
constraint
 Activity constraints should reflect achievement of a contractual
requirement by a particular day. Constraints should not absolutely fix
an activity to occur on a particular date23
Logic links  Inter-activity logic links should reflect the construction sequence logic
and not simply applied the make the programme operable (dynamic)
 Finish-to-Start links are ideal though Start-to-Start and Finish-to-
Finish links are also useful if suitable
 Finish-to-Start links with overly long lag periods (i.e. especially over 1
week) should be explained or removed and replaced by a new activity
(that represents the lag period) or linked to more appropriate activities
 All Start-to-Finish links should be removed and replaced
 For activities with no successor(commonlyreferred to as ‘open ends’)
a suitable successor link should be added
 All activity links with negative lags (more than a few days) should be
revised such that the links have close to zero, or positive, lag periods
 Missing logic links between activities may be common. Corrections,
in the form of added links, should be applied on the basis that they
reflect the likely sequence of construction. Ideally, linkages and
associated lag periods should be introduced so as not to alter the
22
When the unrealistic programme is corrected to incorporate more realistic activity durations and sequences the
completion dates will likelyextend. The contractor would be culpable for this delay unless itcan be s ubstantiated.
23
Use of activity constraints which absolutelyfix when an activity occurred should be limited to events wholly out
with the definitions ofthe contract, i.e. opening of a new bridge constructed under a separate contractwhich will
provide new access routes to the projectsite.

timing of related activities. The period of total float may well however
alter as a result
Total float  If the period of total float is overly long associated linkage should be
examined and if appropriate, links revised or new links added
 A programme containing a high proportion of activities with zero or
low total float it may indicate a programmer’s over-zealous use of
activity linkage. Linkage to be reviewed and corrected where
appropriate
 For baseline programmes, negative float suggests that completion or
a milestone will not be met. All such incidences should be identified
and investigated and wherever reasonable, corrected to remove all
negative float
The
programme is
not dynamic
 Once all errors are identified, recorded and for those necessary
corrected, the programme is rescheduled24
and the critical path(s)
determined. If the programme is not dynamic (it does not reschedule
correctly) blocking linkage and constraints should be re-reviewed to
establish the source of any error. This process is repeated until
programme becomes dynamic and identifies a reasonable critical
path(s).
 Whereupon the critical path(s) deviates from the original critical
path(s) the programme should be re-reviewed to establish the causes
of suchalteration. It may be that the corrections incorporated were not
appropriate or that the critical path originally identified was incorrect
Incorporation of corrections
On the basis a programme contains errors and the parties agree some form correction is
needed the parties may still have different opinions as to how corrections ought to be
incorporated. On one hand, the contractor will likely seek to ensure that the corrected
programme will be sufficient to enable it to demonstrate the period(s) of time it considers it is
entitled too. The contract administrator may be vigilant that corrections do not exaggerate any
entitlements or hide contractor culpability.
The primary purpose of identifying and implementing programme corrections is to ensure that
the compensation programme is workable and that represents how the parties agreed the
works were intended to be done to the date the programme was first prepared. Implemented
corrections should therefore not favour one party over the other, but reflect how any competent
contactor might likely programme the project.
Programme corrections should endeavour to ensure that the timing of activities in the
correctedprogramme, once re-scheduled, remain as the un-corrected programme25
.This may
not however not be possible26
. Inclusion of new activities or new / revised activity linkage might
cause follow-on activities to occur later. In this case the default position is that the contractor
becomes liable for any variance to completion. It is suggested however that only in the event
24
Recalculated using the planning software used to create the programme.
25
The aim of retaining the timing of activities not associated with a particular programme error is desirable as to
do so retains the contractor’s planned intended timing to undertake such works. The programme should not
however be unreasonablymanipulated to achieve no overall programme change.
26
Owing to errors which are not corrected.

that the contractor can evidence an actual historical intent to mitigate delay to overcome the
programme error, when initially discovered, should programmemitigation be incorporated into
corrected programme and at the appropriate point.
Regarding the point at which errors should be incorporated there are two schools of thought.
The first is that correction for programme errors should be all be incorporated into the single
programme. This will enable ease of prospective delay analysis, say over a series of discrete
fixed period windows, with all errors corrected and fully incorporated prior to the analysis
commencing. On the other hand programme errors could only be corrected once the relevant
window has been reached or the error was discovered by the contractor during the course of
the project. Either way the contractor should consult the contract administrator before
commencing the analysis
The corrected programme should be fair to both parties. Identification of programme errors is
only usually done for the purposes of establishing a contractor’s entitlement to extension(s) of
time for the whole contract. Therefore any examination of the programme for errors should be
comprehensive and not singularly limited to identifying errors which the contractor consider
are necessary for its purposes.
Once all programme corrections are incorporated the programme should be rescheduled and
the completion dates and critical paths checked. All variance to the completion requirements
should be noted and causes identified and recorded. If the critical path(s) alters I may well be
worth reviewing contemporaneous project data to establish if such alternate paths were at all
considered by the parties concerned. If not, then it might be necessary to reconsider the
programme once more in order to revalidate the projects critical paths.
Lastly, following on from Pickavance’s comments for all programme reviews, errors and
corrections should be documented and where possible evidenced. Also, all programme errors
which the delay analyst elect not to correct (for whatever reason) reasons why correction is
not done should be recorded as well as an assessment of liability considered and described.
Conclusion
Correcting programmes for the purpose of assessing contactor’s entitlement and / or
culpability is both a reasonable practise and necessary. Learned authorities support the view
that the programme should be made workable if it is not workable though they do not describe
exactly how the correction process ought to be conducted.
To attempt to conduct a delay analysis exercise based on a programme that contains errors
will likely provide a results inconsistent with reality and fail to provide a fair apportionment of
responsibility. The purpose of delay analysis is to assess and demonstrate fair time
entitlements and / or identify culpabilities stemming from both employer and contractor risk
events. The consensus view in the construction industry is that contractors’ programmes
generally do provide the most appropriate basis for assessing time implications even if the
programme contains errors not apparent until detailed assessments are considered.
Contract administrators may fear proposed programme corrections will exaggerate the effect
of referred delay events or even somehow ‘let-off’ the contractor from its own culpable delay.
It is the contractor’s role, as the claimant, to convince the contractadministrator that the whole
correction exercise was comprehensive, transparent, properly evidenced and that it is
prepared with fairness with respect to both parties to the contract.
End

About the author
David Greig is an internationally recognised expert in delay analysis and has undertaken
numerous assignments as an expert witness and provided oral testimony and been acclaimed
for his competency, thoroughness and calmness and collected nature whilst under cross
examination.
David formed Greig Consulting is 2018 after a generation of international assignments in Asia,
the Middle East and Europe advising construction and oil & gas companies on matters for
programme, delay, risk management and contractual entitlements for time and money.

Delay Analysis - Correcting for Programme Errors

More Related Content

What's hot

Similar to Delay Analysis - Correcting for Programme Errors

Recently uploaded

Delay Analysis - Correcting for Programme Errors