Impacted As-Planned Analysis: Fast, Cheap and Easy to Attack

Impacted as-planned analysis is a delay analysis method that adds delay events, modelled as fragnets, to the original baseline programme and measures how far the planned completion date moves. It is generally the quickest and cheapest method in common use. It is also the easiest to dismantle, because it never asks what actually happened on site.

Most contractors reach for it because the inputs are already on the planner's desk: one baseline programme and a list of employer events. That convenience is the method's whole appeal and most of its weakness. Sometimes called impacted baseline or plan plus delay analysis, it is one of six delay analysis methods in the Society of Construction Law Delay and Disruption Protocol.

How Does Impacted As-Planned Analysis Work?

The baseline programme is the yardstick, so it has to deserve that status. Under FIDIC it is the programme submitted under Sub-Clause 8.3, which the 2017 editions require to show logic links, float and the critical path. The Protocol expects the analyst to confirm first that its sequences and durations are reasonable, realistic, achievable and properly logic-linked.

Each delay event is then built as a fragnet, a small logic-linked group of activities representing the work or disruption that flows from it. The Protocol calls it a sub-network. For late access it may be one activity, while a variation fragnet holds the instruction, the new work and its links into the programme.

The fragnets go in, the software recalculates, and the shift in planned completion is the claimed delay. Suppose the baseline shows completion on 30 June. A fragnet for late handover of a substation area moves it to 21 July, a design change moves it to 4 August, and the analysis reports 35 days. That figure becomes the extension of time request and the defence to liquidated damages, so every weakness in the model travels with it.

Why Is It So Fast and Cheap?

The Protocol describes the method as generally 'the simplest and least expensive form of delay analysis'. It needs only a logic-linked baseline and a selection of events to model. There are no monthly updates to verify, no as-built programme to reconstruct and no progress data to reconcile.

It suits an event early in the project, an application that must go in quickly, or a modest claim that cannot carry a forensic budget. A planner with a clean baseline can often produce one in days. But an analysis that is cheap to build is also cheap to rebut, because the other side only has to show that it ignores what happened on site.

Why Is the Method So Easy to Attack?

The Protocol names the core limitation itself: the method 'does not consider actual progress and changes to the original planned intent'. Its critical path is judged from the outset of the project, with no account of progress. If that path moved during the job, as it does on most projects, the analysis measures delay against a sequence the works no longer followed.

The second weakness is what the model leaves out. Only the selected events go in, so the contractor's own late procurement, slow mobilisation or thin resourcing never appear. The whole movement is then attributed to the employer, even where the works were already late and the employer event sat on a path with float.

The third is that the answer is theoretical. It shows what the events would have done to the plan, not what they did to the works, and optimistic baseline durations flow straight into the result. With liquidated damages of QAR 40,000 a day, for example, an expert who cuts a 60-day result to 20 days moves QAR 1.6 million of exposure back onto the contractor.

An event can be entirely the employer's fault and still not delay completion by a single day. The method cannot tell the difference, and opposing experts know it.

What Have Courts Said About the Method?

English courts have been direct. In Great Eastern Hotel Company v John Laing Construction (2005), the construction manager's expert compared actual design release dates with the original construction programme. His evidence was that late design information caused or contributed to critical delay. His Honour Judge David Wilcox rejected that evidence. The impacted as planned analysis, he held, 'takes no account of the actual events which occurred on the Project and gives rise to an hypothetical answer'.

The judge also noted that the programme used had been superseded by later versions of the procurement programme. The judgment describes the expert he preferred as also using an impacted as planned analysis, but run month by month as the project proceeded and taking account of the actual events. Not the label. The engagement with what happened.

Adyard Abu Dhabi v SD Marine Services [2011] EWHC 848 (Comm) concerned causation rather than a named method, but it exposes the same flaw. Hamblen J endorsed an example of a contractor months late through its own default, whose employer changes a paint colour a week before the original completion date.

Impacting the five-week paint delivery against that date would yield four weeks of extension, although the paint would still arrive before the late wall was built. Notional or theoretical delay, the judge held, does not suffice. On a GCC project these English decisions and the Protocol persuade rather than bind, so the contract comes first.

When Is Impacted As-Planned Analysis Still Acceptable?

The method is not banned. The Protocol accepts that in limited circumstances it may be sufficient for assessing an extension of time, citing two examples:

• A contract that dictates the method, where the parties already chose its limitations
• Delay events right at the outset of the works, where there is little progress to ignore

It also works as a screen before the contractor pays for a full analysis, provided nobody mistakes the screen for proof. On a small claim, the Protocol's selection criteria of proportionality, time available and forum can justify a lighter method that states its limits openly.

It stops being acceptable after completion, run as if the project had followed the plan. Core Principle 11 warns that even the prospective analysis the Protocol recommends during the works may no longer be appropriate once they are complete. Where the baseline is the problem but site records are strong, collapsed as-built analysis works from what actually happened instead.

Impacted As-Planned vs Time Impact Analysis

Both methods insert fragnets and both measure the effect on completion prospectively. The difference is one step. Time impact analysis first brings the programme up to date with progress and all employer and contractor delays immediately before each event.

On the first day of the works the two give the same answer, because there is no progress to update. They diverge as the job moves on. That fits the Protocol's approach: impacted as-planned for events at the outset, time impact analysis for live applications. The extra step costs planner time, and skipping it can cost the claim. Our comparison of time impact analysis vs windows analysis covers what changes after completion.

How to Make the Analysis More Defensible

Six steps make the analysis harder to attack:

1. Validate the baseline and show the validation, using the programme the contract recognises rather than the tender programme. AACE International's recommended practice 29R-03 asks for every change to the baseline to be tabulated and justified.
2. Build each fragnet from instructions, correspondence and resource logic, then set its durations to zero and confirm completion does not move, proving the inserted logic is not creating delay by itself.
3. Insert events one at a time in date order, so each event's increment is visible.
4. Model the contractor's own known delays, or at least list the significant ones left out.
5. Reconcile the result to actual completion and explain any gap through mitigation, acceleration or contractor delay.
6. Try to agree the method early. The Protocol recommends agreement before significant after-the-event work and warns that failure to consult may count when costs are allocated.

Where monthly updates exist, the same fragnets can go into the update current at each event, turning it into a time impact analysis without starting again. The problem is rarely the fragnets. It is the programme they go into.

We review hundreds of extension of time claims across the GCC every year. The impacted as-planned submissions that fail share three features: a tender programme as the baseline, no contractor delays in the model and no reconciliation to actual completion. The same gaps sit behind many of the reasons EOT claims get rejected.

At CALIM, we audit the baseline and the records before choosing a method, and where impacted as-planned is the proportionate choice we build it to withstand these attacks. Contractors facing a live EOT application or a disputed extension can brief an independent delay analysis consultant before the first fragnet is drawn.

Frequently Asked Questions