Impacted As Planned Analysis: What It Is, How It Works, and When It Fails in Construction Claims

On a live project, delay entitlement often turns on one practical question: if this event had not happened, would completion still have moved? That question is really important when parties are pricing risk, issuing notices, resisting liquidated damages, dealing with delays and disruptions, or when a contractor is preparing an extension of time claim. The difficulty is that some delay methods produce a neat answer on paper while missing what was actually driving the job at the time.

Impacted as planned analysis is a modeled, additive delay analysis method that inserts delay events into the original baseline programme and recalculates the projected completion date. Within the wider group of construction delay analysis methods, it is best understood as a baseline-based simulation rather than an analysis of actual project performance.

Its attraction is obvious – It is simpler and cheaper than many other forms of forensic schedule analysis, and it can be useful when delay events arise very early and there is little reliable progress data to work with. But that same simplicity is also the method’s biggest weakness. In claims, the commercial risk is that impacted as planned can overstate or understate entitlement because it assumes the original programme remained a reliable model of the job.

On real projects, logic changes, progress diverges, trade interfaces move, variation requests and orders intervene, and resequencing alters the path to completion. That is why this method is often challenged once the dispute turns serious.

What impacted as planned analysis actually does

Within the broader construction claims and contract administration process, impacted as planned analysis is a prospective model built on a single schedule base. The analyst takes the original baseline programme, adds modeled delay events as fragnets or inserted activities, runs the CPM (critical path method) calculation again, and measures the movement in planned completion.

The SCL Delay and Disruption Protocol describes the method as introducing delay event sub-networks into a logic-linked baseline programme to determine the prospective effect on the completion dates shown in that programme. AACE International classifies that same family of analysis under modeled, additive, single-base implementation in Recommended Practice 29R-03.

That sounds straightforward, and it is. But it also means the output is only as reliable as the baseline logic, durations, calendars, constraints, and critical path assumptions sitting underneath it. If the baseline was never a sound model of delivery, the impacted result will only give a more technical-looking version of the same weakness.

That is the key distinction between impacted as planned analysis and more fact-sensitive approaches such as time impact analysis or the window analysis method.

How the method works in practice

A typical impacted as planned analysis follows a short sequence:

Select the original accepted baseline programme.
Check that it is logic linked, reasonably complete, and capable of producing a credible critical path.
Identify the delay event or events to be modeled, such as late access, a major variation request, a formal variation order, revised design information, or a latent condition event.
Insert those events into the baseline as additional activities, fragnets, restraints, or duration impacts.
Recalculate the programme.
Compare planned completion before and after insertion.
Use the difference as the modeled delay outcome.

If the baseline showed completion on 30 September and the impacted model shows 20 October, the analysis will usually say the modeled event caused 20 days of delay to planned completion.

In practice, the method measures the effect of the inserted event on the baseline model, not automatically the effect on actual completion. It has not yet asked whether the contractor was already behind, whether the logic had changed, whether float had already been consumed, whether mitigation was underway, whether unresolved RFI issues were affecting progress, or whether another delaying event was running at the same time. Those questions usually decide whether an extension of time claim survives scrutiny.

The core assumptions behind impacted as planned

This method depends on assumptions that are often difficult to defend once a claim becomes contested.

First, the baseline must be reliable. The SCL Protocol says the analyst should confirm that the baseline sequence and durations are reasonable, realistic, achievable, and properly linked. In practical terms, that means the programme must be more than an approval document. It needs to be a credible operational model of how the works were actually intended to be delivered. If the baseline was optimistic, incomplete, over-constrained, or poorly logic-tied, the model will simply reproduce those defects in a more formal format.
Second, the method assumes the original logic still matters. That is a major assumption on infrastructure, building, and industrial jobs where procurement drift, resequencing, access restrictions, changes introduced by RFIs, unexpected events, such as latent conditions, and trade stacking change the actual driving path. Impacted as planned analysis works on the premise that the baseline logic remains the right logic to test against.
Third, it assumes delay can be understood by adding events to the baseline without bringing actual progress into the analysis. That is exactly where the method becomes vulnerable. The SCL Protocol identifies impacted as-planned as materially limited because it does not consider actual progress, actual productivity, or changes to planned intent as the job develops.
Fourth, it assumes the baseline critical path remains the relevant path. On many projects, that stops being true quickly. Once actual progress departs from plan, the path driving completion may shift to different workfaces, procurement packages, interfaces, testing sequences, or areas affected by exhausted float.
Fifth, it assumes concurrency can be treated fairly within a static model. In practice, that is often where the method breaks down, especially when concurrent delay arguments are central to entitlement and the parties are already debating notice compliance under a time bars.

Variation & Claims Toolkit

Weak delay positions usually start with weak records, not weak arguments.

If impacted as planned is only giving you a provisional answer, the Variation & Claims Toolkit helps tighten notices, variation records, and claim support documents before entitlement positions harden.

Access Practical Templates for Variations and Claims →

A simple illustrative example

Assume a contractor’s baseline programme shows this sequence on the critical path:

Foundations: 20 days
Structure: 40 days
Cladding: 25 days
Testing and commissioning: 15 days

The planned completion is day 100.

Now assume the employer issues a late structural redesign that adds 10 days before structure can progress. In an impacted as planned delay analysis, the analyst inserts a 10-day fragnet into the baseline before or within the structural works. The recalculated programme shows completion on day 110. The conclusion is that the event caused 10 days of modeled critical delay.

That conclusion may be acceptable if the event happened right at the start and the baseline still reflected the job.

But now add real-world facts. By day 35, the contractor was already late on foundations because of under-resourcing. By day 50, the structure sequence had been resequenced to suit steel delivery. By day 60, the cladding package had its own procurement issue. By day 65, a delayed response to an RFI query and a separate variation order changed the workface sequence again.

The original 10-day baseline impact may no longer represent the real driver of completion at all. In that situation, a more contemporaneous method such as time impact analysis or the window analysis method is usually more defensible because those methods are better able to deal with actual progress and changing criticality.

When impacted as planned can be useful?

However, used carefully, the method still has value. It is simple to explain to project teams, commercial managers, tribunals, and clients who need to understand the broad mechanism of a delay event without immediately moving into a full forensic exercise.

It is often quicker and less expensive to produce than methods that depend on validated updates, reliable progress records, and detailed as-built evidence. That is one reason it still appears regularly in the early stages of construction claims.

It can be especially useful very early in the project, especially where a delaying event occurs close to commencement and there is little meaningful actual progress yet to assess. The SCL Protocol notes that limited early-stage circumstances may justify its use, particularly where the contract requires it or where the relevant event arises at the outset of the works.

It can also be a practical internal planning tool when the team is testing possible exposure before formal claim preparation, issuing a notice of delay, considering whether an early warning notice should trigger mitigation discussions, or deciding whether the event is likely to support a formal extension of time claim.

Variation & Claims Toolkit

Weak delay positions usually start with weak records, not weak arguments.

Access Practical Templates for Variations and Claims →

Where the method fails in construction claims

One weakness is that it ignores actual progress. The SCL Protocol distinguishes between prospective assessments taken from the outset and contemporaneous approaches that account for progress achieved and evolving future strategy. If the project moved away from the baseline logic, impacted as planned delay analysis can misidentify the critical path and produce the wrong answer.

Another weakness is that it freezes logic. Real projects do not stay frozen. Access changes, procurement shifts, trade interfaces move, temporary works evolve, design release dates slip, and employer instructions alter the sequence through a variation order. A static baseline model cannot properly capture that development, so it may attribute delay to the wrong sequence of work.

Mitigation and resequencing create another problem. If the contractor changed work fronts, accelerated procurement, revised temporary works, or altered sequencing to absorb part of the event, a pure baseline insertion will not measure that response properly. The method tests what the event would have done to the original plan, not what it actually did once the team reacted to it.

Concurrency is another pressure point. If employer-risk and contractor-risk events overlap, a simple additive model can make one side’s event appear fully critical when the job was already being delayed by something else. This is often one of the most contentious issues and creates clear entitlement arguments around EOT, compensation, prolongation costs, and the treatment of concurrent delay

The method can also distort cause and effect. A baseline-based insertion may show a delay to planned completion, but that does not prove the event delayed actual completion in the way required for a serious claim. This is one reason parties often move toward more fact-sensitive approaches such as as-planned vs as-built analysis or the window analysis method when the dispute matures.

Finally, impacted as planned is vulnerable where notice and procedural compliance already matter. Even a favorable modeled result may not rescue a weak claim if the contract requires timely notices, records, and program updates because of time bars.

Impact As Planned Analysis for Contractors

For contractors, impacted as planned can be useful as an early screening tool, but it is dangerous to rely on it as the sole basis for entitlement once the project has materially progressed.

It may help frame an initial claim position, support early correspondence, or quantify a provisional EOT view after a major owner-caused event such as late information, access delay, or a formal variation order change. It can also help a commercial team explain why a delay event matters before the full record is assembled and before a fuller review under another delay analysis method is carried out.

The risk is that the model may exaggerate owner responsibility if the contractor was already late, if mitigation was possible, if resequencing changed the driving path, or if the baseline critical path had already ceased to reflect reality. In that situation, relying too heavily on impacted as planned can weaken credibility rather than strengthen the claim.

Contractors should also remember that delay entitlement is rarely just about days. It usually feeds into EOT, exposure to damages, demurrage, and disruption arguments,. A method that does not handle the facts properly can harm all of those downstream positions, particularly where the employer is already pointing to concurrent delays, or non-compliance with early warnings and notice of delay.

Impact As Planned Analysis for Owners and Clients

For owners and clients, impacted as planned is often the first method put forward because it is relatively easy to commission and easy to read. That can be attractive where a quick position is needed on whether to grant time, reject a claim, or reserve rights.

But owners should be careful about accepting a baseline-only answer at face value. If the contractor’s actual progress had already diverged from the accepted programme, the method may over-credit an employer event. That can lead to avoidable EOT awards, weak rejection decisions, or distorted negotiation outcomes.

There is also a defensive use for owners. When a contractor relies on impacted as planned, the owner’s review should test whether the baseline was realistic, whether actual progress had moved the driving path, whether concurrency existed, whether mitigation or resequencing had altered criticality, whether the inserted event logic matches what happened on site, and whether the claim also falls short on procedure under a time bar requirements. Those are usually the pressure points where the analysis either holds up or falls apart.

Impacted as planned versus more robust methods

Method	Core input	What it tests	Strength	Weakness	Use case
Impacted as planned	Baseline programme	Modeled delay impact on completion	Simple and low-cost	Ignores actual progress	Early-stage screening
Time impact analysis	Updated programme	Delay effect at time of event	Reflects live status	Needs reliable updates	Live EOT assessment
Window analysis	Programme updates	Critical path shifts	Captures concurrency	Resource intensive	Dispute analysis
As-planned vs as-built	Baseline vs actual	Overall variance	High-level comparison	Limited causation insight	Retrospective review

The practical point is simple. Impacted as planned may be enough for an early screening exercise, but once the dispute turns on actual progress, resequencing, concurrency, or mitigation, more robust methods usually carry more weight.

Variation & Claims Toolkit

If the baseline no longer reflects the job, your claim records need to do more work.

Use the toolkit to tighten notice wording, variation records, reservations of rights, and claim support documents when impacted as planned is no longer enough on its own.

Access the Toolkit and Templates →

Practical checklist before relying on impacted as planned

Before using impacted as planned analysis in a claim, ask these questions:

Is the baseline programme accepted, logic linked, realistic, and complete enough to operate as a credible single base?
Did the relevant delay event occur very early, before meaningful progress divergence?
Are there reliable updates showing that the baseline logic remained broadly valid after the event?
Is there evidence of concurrent delay or contractor-caused delay running at the same time?
Did resequencing, mitigation, acceleration, procurement changes, latent conditions, or access changes alter the driving path?
Has float in the program already been consumed or materially reduced?
Is the claim likely to face close scrutiny in adjudication, arbitration, or litigation?
Do the contract notice and record requirements support the delay position, including any notice of delay and time bar requirements?
Would a contemporaneous method such as time impact analysis or the window analysis method produce a more defensible answer?

If several of those answers are unfavorable, impacted as planned is probably not the right primary method.

Conclusion

Impacted as planned analysis is a modeled, additive, single-base way to assess delay by inserting events into the original baseline programme and measuring the movement in planned completion. That simplicity makes it attractive, especially early in the job and especially where there is not yet enough actual progress data to support a more developed analysis.

But the same simplicity is why it is often challenged in construction claims. The method assumes the baseline remained a reliable model, assumes the original logic still governs, and largely ignores actual progress, changing logic, mitigation, resequencing, and concurrent delay.

Those issues are usually central to real entitlement disputes. If the project facts have moved materially beyond the original baseline, more robust methods such as time impact analysis, the window analysis method, or as-planned vs as-built analysis will usually provide a stronger and more defensible answer.

FAQ

What is impacted as planned analysis in simple terms?

It is a delay analysis method that inserts a delay event into the original baseline programme and measures how much the planned completion date moves. It is a modeled baseline exercise, not a reconstruction of actual project performance.

Is impacted as planned analysis reliable for a formal EOT claim?

Sometimes, but usually only in limited circumstances. It can be useful very early in the project where progress has not materially diverged from the baseline. Once actual progress, resequencing, mitigation, or concurrency become important, it is often too weak to stand alone.

How is impacted as planned different from time impact analysis?

Time impact analysis normally tests the event against a contemporaneous or updated programme, while impacted as planned tests it against the original baseline. That makes time impact analysis more fact-sensitive once the project has moved away from the original plan.

Why is impacted as planned often challenged?

Because it can misstate delay if the baseline was unrealistic, if the critical path changed, if mitigation occurred, or if concurrent events were already affecting completion. The method can produce a neat modeled result without proving real-world causation.

When should impacted as planned not be the primary method?

Usually when the project is well advanced, the accepted programme is outdated, there are major sequencing changes, concurrency is disputed, or the claim is likely to face detailed expert review, adjudication, arbitration, or litigation.

Need Help?

If you need to test whether an impacted as planned position will hold up commercially and contractually, Denys can help you review the records, method choice, and claim strategy before the dispute hardens.