Impacted as-planned, and why reviewers push back

Impacted as-planned is the method most often found in first-draft contractor claims. You take the baseline, insert the events you say the other side caused, and let the software push the completion date. It is simple and persuasive. It also ignores everything that actually happened on site, including the claimant's own delays. This lesson shows how it works, why reviewers push back, and when it is still a fair tool.

Learning outcomes

• Describe how an impacted as-planned analysis is built.
• Explain why the method tends to overstate the other party's delay.
• Test an impacted as-planned claim with five questions.
• Identify when the method is reasonable, such as early forecasts.

The lesson

How it works

Start with the accepted baseline. Model each delay event as a fragnet, a small set of activities with durations and logic, and insert it into the baseline. Recalculate. The movement in the completion date is the claimed delay. AACE RP 29R-03 classes this as modelled, additive, single base: MIP 3.6 [1].

Why reviewers push back

The method answers a hypothetical question: what would have happened if the plan had been perfect except for these events? It ignores actual progress, changes in sequence, the claimant's own delays and float that was used for other reasons. Because only one party's events are inserted, every day of movement looks like that party's fault. On a project where the claimant also had problems, the result overstates the claim, sometimes heavily. The SCL Protocol favours dealing with time contemporaneously and, after the fact, choosing a method that suits the records [2].

Five questions to test one

• Was the baseline accepted, and was its logic sound?
• Does each fragnet have a source document and a realistic duration?
• Were the claimant's own delays inserted too, or left out?
• Does the result match what the updates showed at the time?
• Is float use consistent with the contract's float provisions?

When it is fair

Impacted as-planned is reasonable for a prospective forecast early in a project, before many updates exist, and for a simple event on a project that ran close to plan. It is weakest as a retrospective proof on a project with many overlapping events.

Northgate worked example

Northgate Distribution Centre (fictional) is a 12,000 m² tilt-up warehouse in Vaughan, Ontario, built by Halvorsen Builders Ltd. (fictional) under CCDC 2-2020, with Ridgeline Architects Inc. (fictional) as Consultant. See the Northgate fact sheet. This course follows one delay claim from first notice to settlement. Ready-for-Takeover (M9) was due Friday, January 14, 2028 and was reached on Tuesday, March 14, 2028: 60 calendar days late. All events, dates and amounts are illustrative.

Halvorsen's Claim C-01 used impacted as-planned. Its scheduler inserted three fragnets into the baseline: the mezzanine redesign (35 days), the permanent power delay (14 days, presented as owner delay because the owner had not extended time) and the dock leveller decision (28 days, based on a 10-week lead time). Recalculating gave 52 days of owner delay.

View the data

Item	Value
Halvorsen: owner delay (impacted as-planned)	52 days
Corrected: compensable owner delay	18 days
Corrected: total extension of time	42 days

The owner's representative tested it with the five questions. The mezzanine fragnet ignored 25 days of float, which the August update shows was used. The power delay was caused by the utility, a neutral event. The dock leveller fragnet used a 10-week lead time when the supplier's quotation in the file said 8 weeks. And none of Halvorsen's own delays, the crane and the roof deck, were in the model. Corrected, the owner-caused compensable delay is 18 days, and the windows analysis in lesson 10 confirms it.

Your move

If you are the owner

• Ask for the native model. Check every fragnet's duration and logic.
• Insert the contractor's delays too. See how much of the movement survives.
• Compare with the updates. If the updates never showed the claimed path, ask why.
• Use it yourself only for forecasts. It is a planning tool more than a proof.

If you are the contractor

• Use it prospectively. For a time extension request at the time, it can be fair and quick.
• Source every duration. Quotes, lead times and logs.
• Include your own delays. A model that ignores them will be rerun by the reviewer.
• Reconcile with your updates. Explain any difference.

Common mistakes

1. Ignoring float already used. Inserting a delay into float that was gone overstates impact.
2. Unsourced durations. A fragnet without documents is an opinion.
3. Leaving out the claimant's delays. The commonest flaw.
4. Using it years later. Actual progress should be used when it exists.
5. Accepting the output without opening the model. The logic is where the errors hide.

Quick quiz

1. Which AACE MIP is impacted as-planned?

   1. 3.1
   2. 3.3
   3. 3.6
   4. 3.9

2. What is the main criticism of impacted as-planned?

   1. It is too expensive
   2. It ignores actual progress and the claimant's own delays
   3. It uses too many updates
   4. It cannot be done in P6

3. When is the method most reasonable?

   1. Retrospective proof on a complex project
   2. Prospective forecasts early in a project
   3. Never
   4. Only in court

4. What was wrong with Halvorsen's dock leveller fragnet?

   1. It was too short
   2. It used a 10-week lead time against an 8-week quotation
   3. It had no logic
   4. It was on time

5. Halvorsen's model showed 52 days of owner delay. What did the corrected analysis show as compensable?

   1. 0
   2. 18 days
   3. 42 days
   4. 52 days

Show answers and explanations

1. C. Modelled, additive, single base.
2. B. It models a hypothetical perfect project.
3. B. It works best as a forecasting tool.
4. B. The file showed an 8-week lead time.
5. B. 18 days of owner-caused compensable delay.

Key terms

Impacted as-planned

A modelled method that inserts delay events into the baseline and measures the movement.

Fragnet

A small network of activities representing one delay event.

Single base

Using one schedule, usually the baseline, as the model for all events.

Hypothetical delay

Delay calculated for a project that never existed: the plan with only selected events.

Lead time

The time from order to delivery of a product.

References

1. AACE International, Recommended Practice No. 29R-03, Forensic Schedule Analysis, table of contents and method taxonomy (revision April 25, 2011).
2. Fenwick Elliott, The SCL Delay and Disruption Protocol: a second edition (November 2017), summarizing the Society of Construction Law Protocol, 2nd edition (February 2017).
3. Miller Thomson LLP, Ontario Court underlines the evidence and analysis required to establish critical path delays (July 2021).
4. BRC, Northgate fact sheet (fictional case study, v1, November 4, 2026).

Verified on November 9, 2026.

Next lesson in this trackTime impact analysis step by step