Delay & Delay Analysis

DELAYS & DELAY ANALYSIS

DELAYS AND DELAYING EVENTS

•   Change happens… • Events occur that require a Contractor’s planned intent for executing the works to be changed. • Delays: • Delay to progress. • Delay to completion. completion.

CAUSATION

• Step 1: (Analysis of Facts) • Identify that an event has occurred. • Step 2: (Analysis of Facts) affects progress of the works. • Show that the event affects

• Step 3: (Delay Analysis) Demonstrate that this delay delay to progress progress causes a delay to • Demonstrate completion.

TIME EFFECT OF AN EVENT - PLAN • Planned programme: • Accepted programme update

TIME EFFECT OF AN EVENT - 1 • Condition 1: • The event causes no delay to progress and no delay to completion. Planned Completion

TIME EFFECT OF AN EVENT - 2 • Condition 2: • The event causes a delay to progress but no delay to completion. Planned Completion

TIME EFFECT OF AN EVENT - 3 • Condition 3: • The event causes a delay to progress and a delay to completion. Planned Completion 1

Planned Completion 2

INTRODUCTION TO DELAY ANALYSIS

• Impact of different types of delay event. • Impact of prospective and retrospective perspectives on the calculation of delay to completion.

• Principles of Delay Analysis

COMPONENTS

• Programme • Events • Progress Records/As-built • Contract requirements • Other supporting evidence

CHOOSING A METHOD • •

• •

• • •

Seek agreement What does the contract say?  – Likely or Actual delay to completion  – Method Specified What is to be proved?  – EOT or compensation or both What materials are available?  – Availability and Integrity of an As-Planned Programme , progress and/or As-Built Data; Limitations on budget and time? Complexity of Works in question Proportionality  – Small disputes do not justify expensive and time consuming analyses

CONTRACT TERMS - "If the Contractor is or is likely to be unavoidably delayed in achieving a completion obligation or milestone ... either  prospectively or retrospectively the time ... shall be extended“  - "... an extension of time ... shall be subject to the requirement that ... the event was the operative cause of the delay suffered ...“ 

• Likely to cause delay? • Likely to cause or has caused delay? • Has caused delay? • To what? • In relation to what?

WHAT IS TO BE PROVED • The prospective likely effect on the completion date for the purposes of an interim EOT • A retrospective actual effect on completion for the purpose of an EOT • A contemporaneous or retrospective actual effect on progress for the purposes of compensation for disruption • A retrospective actual effect on the contractor’s overheads for the purpose of prolongation

MATERIALS AVAILABLE As built records available? Programme available?

As-Planned  –vAs-Built Measures the difference between planned and actual activity durations

Recovery or acceleration ? Measures the effect of an event on completion by tracing the critical path through change in intent

AsPlanned Impacted

CPM ?

Updated with progress ?

Time-Impact

Retrospectively create a CPM programme

Retrospectively create a simulated asbuilt CPM programme

As-Built ButFor

Illustrates the effect of an Event on the chosen programme

Measures the effect of an Event on completion in the sequence of construction finally followed

PROPORTIONALITY • Quick, cheap and tend to be rough  – As-planned v as-built  – As-planned impacted • Time consuming, costly and tend to be thorough  – As-built But-for  – Time impact

METHOD

• Disregard labels, identify what is done. • AACE International Recommended Practice No. 29R-03

AACEI RP 29R-03: FORENSIC SCHEDULE ANALYSIS Table 1 – Nomenclature Correspondence (page 11)

ADVANTAGES & DISADVANTAGES NOT PREFERENCE … OR PREJUDICE!

METHOD IMPLEMENTATION • AACE International Recommended Practice No. 29R-03 Section 3 • OBSERVATIONAL • STATIC LOGIC 1 • : • PERIODIC 2:

As-Planned vs As-Built (‘in windows’)

• DYNAMIC LOGIC • : • RE-CONSTRUCTED UPDATES:

As-Planned vs As-Built in windows

• MODELLED • ADDITIVE • •

: :

• SUBTRACTIVE • • MULTI SIMULATION

As-Built But For

PROSPECTIVE V RETROSPECTIVE (WHEN?)

• Prospective:  – During currency of project  – Per SCL Protocol  – Contract requirement (e.g. NEC)  – Avoid disputes • Retrospective:  – During currency of project (after the event)  – Claim preparation  – Dispute resolution (expert analysis)

PROSPECTIVE V RETROSPECTIVE (HOW?)

• Prospective:  – Forward looking e.g. As-planned impacted, Time Impact

• Retrospective:  – Backward looking (e.g. Collapsed as-built, as-planned v asbuilt)

AS-PLANNED V AS-BUILT • Many variances of the type  – May have a Critical Path network as the as-planned programme;  – May have a reconstructed programme as a baseline  – May be carried out in “windows” or “time slices” • Simply compares;  – Planned programme and as-built programme  – Difference = delay & relief from LADs ( EOT) • Often amounts to a “total time claim”

AS-PLANNED V AS-BUILT

• METHOD: • Prepare an As-Built schedule with same activities as the AsPlanned schedule. • Identify the sequence of activities on the As-Built schedule which control the overall project duration – the Controlling Path. • Identify critical delay by comparing the duration, sequence and timing of the controlling activities of the As-Planned and As-Built schedules. • Research evidence to identify causes of the identified critical delays.

AS-PLANNED V AS-BUILT

Planned bars

1. identify a secondary effect

2. Infer a primary cause As built bars

DELAY

3. argue that the tertiary effect has resulted from the primary cause

AS-PLANNED V AS-BUILT Advantages • Cheap and quick to carry out • Useful review of delays and possible merits of allegations • Can be an acceptable proof where the effect is indisputably on the Critical Path, eg; • at the start of the job • at the end of the job • total suspension of the work

Limitations • Only retrospective • Easily manipulated to suit the preferred case • Cannot deal effectively with concurrent causes of delay • Does not calculate the effect of a cause but asserts the cause of the effect • Not related to the critical path

AS-PLANNED IMPACTED • Based on the planned programme • METHOD: 1.Identify the planned programme/ baseline 2.Establish excusable event based on planned intent 3.Model the event in planning software; 4.Add the event to the programme & recalculate the completion date 5.Compare revised end date to original end date. 6.Claim relief for the shift in timing on the programme 7.Repeat for next event

AS-PLANNED IMPACTED

1. Start with planned programme foundations

Contractual Completion Critical Date

structure roof & cladding

inspections

AS-PLANNED IMPACTED

Period of Delay

2. Identify a causal event

foundations

Contractual Completion Critical Date

Unforeseen ground structure roof & cladding

inspections

AS-PLANNED IMPACTED Primary cause

Inferred delay to progress

3. Calculate effect

Revised Completion Date

foundations

Contractual Completion Date

Unforeseen ground structure roof & cladding

Causes secondary effect – a delay to progress

inspections

Causes tertiary effect  – an impact on the planned completion date

IMPACTED AS-PLANNED Advantages

•

Fairly quick and easy to carry out

•

Easily understood

•

It can be used where as-built information is limited/ does not exist

•

Can be suitable method of proof if:

•

Project is of simple character

•

The planned programme was realistic and achievable

•

The critical path remains largely unchanged except for the effect of events

Limitations

• Ignores the as built history of the works • Cannot deal with concurrency • Ignores the effect of any change in sequence or acceleration • Takes no account of: • Progress • Resources • Changing logic

AS-BUILT BUT FOR • METHOD: • Remove delays from as-built schedule to ascertain when the project would have been completed “but for” these delays. • “Gross” method –  remove all at once; • “Stepped” method –  remove delays in reverse chronological order.

• Also known as “Collapsed As-Built ”. • Performed after the works are completed using as built programme as baseline • Evaluates effect of Events on the basis of the sequence of work that was actually followed • Analyses the earliest completion date but-for identified delaying events

AS-BUILT BUT-FOR •

Step 1: Creation of baseline

1. 2.

Create/assess as built programme Identify variances between planned & actual performance & infer cause for each Produce simulated as built programme  – Wind back the data-date  – Remove the “fixed” dates  – Substitute with planned dates and a logic network

3.

•

Logic can be based on updated progressed programmes produced during works

AS-BUILT BUT-FOR • Step 2:  – Remove delay events from simulated as-built programme  – Remove delaying activities in reverse chronological order & recalculate completion date

AS-BUILT BUT-FOR

1. identify secondary effect on progress

2. infer a primary cause

Original duration

Unforeseen ground

Actual Completion Date

foundations structure roof & cladding inspections

AS-BUILT BUT-FOR

3. Convert to critical path program foundations

Actual Completion Date Unforeseen ground structure roof & cladding inspections

AS-BUILT BUT-FOR

Secondary effect delay to progress foundations

4. Subtract identified effect

Causes tertiary effect - delay to completion

Earliest Completion Date

Unforeseen ground Reduced to zero days structure roof & cladding

inspections

AS-BUILT BUT FOR Strengths

• Factually based on actual built times - Easily understood • Can be used where there is no effective planned programme • Demonstrates cause and effect of actual timing of event, in sequence in which work was actually built • Can be used to demonstrate both • Excusable delay • Compensable delay ie loss and expense was suffered • Takes account of concurrency Limitations • Complicated • Requires accurate and complete as-built data • Requires logic reconstruction - Inferred logic may be challenged • Subjective?

• Takes no account of the planned intent • Does not identify the effect of events on the contractors intention at the time

TIME IMPACT ANALYSIS

• METHOD: • Research details of claimed event causing delay; • Model the event in planning software; • Link event into updated schedule; • Recalculate the critical path & Completion date. • Compare revised end date to updated dated schedule end date; • Repeat for all events in chronological order.

TIME IMPACT ANALYSIS

•

Analysis of the effects of delays  –  –  –

over the life of a project, sequentially, In light of the Contractor’s progress & future intentions

•

Update Contractor’s current planned programme to period before the Event.

•

Add Event to programme & calculate effect upon the planned programme

TIME IMPACT ANALYSIS

Preparation:

 –

Identify events & create ‘Fragnet’ for each event.

 –

List Events chronologically

 –

Identify planned programme current at time of Event current programme

 –

Check programme reasonable & fit for use as a baseline

 –

Re-create or review as-built programme.

 –

Assess progress information.

TIME IMPACT ANALYSIS As-planned programme

Contractual Completion Critical Date

foundations

structure roof & cladding inspections

TIME IMPACT ANALYSIS Updated programme

Slow progress

Revised Completion Critical Date after Update Contractual Completion Critical Date

foundations

structure

Updated data date

roof & cladding

Progress to activity Culpable delay to completion

inspections

TIME IMPACT ANALYSIS Revised Completion Critical Date after Update Contractual Completion Critical Date

foundations

Unforeseen ground structure

Updated data date

Event

roof & cladding

Progress to activity Culpable delay to completion Period of event delay to progress

inspections

TIME IMPACT ANALYSIS Revised Completion Critical Date after Event

Impacted programme

Foundations completed to update date

Remainder of foundations

Contractual Completion Critical Date

Unforeseen ground structure Event

Updated data date

roof & cladding

Progress to activity Culpable delay to completion Period of event delay to progress Period of event delay to completion

inspections

TIME IMPACT ANALYSIS • Advantages  – Cause and Effect  – Takes account of Progress/Resource/Logic  – Is the most accurate because it uses all planned, progress and as-built information  – Takes account of inadequate progress  – Takes account of changes in methodology and re-sequencing  – Can be used to resolve concurrent delay  – Takes account of acceleration  – Can deal with multiple Key Dates & Milestones • Limitations:  – Requires high quality information  – Can be time consuming and expensive  – Produces a high volume of output  – Complicated (and therefore slow)  – Prospective results can be inaccurate  – Difficult to communicate ( Skanska v Egger  [2004])

SMOKE AND MIRRORS • Smoke and mirrors - analysis that is not what it is described to be by its originator • Found in discrepancy between description of methodology and that actually adopted

SMOKE AND MIRRORS • As-planned v As-built generally understood • API & ABBF methodologies often understood • Few really understand Time impact analysis • “Windows”, “time impact” “time slice” and “snapshot” often used indiscriminately