A forecast made after the fact.

A forecast made after the fact.

Of the four primary techniques, this is the one that needs the least, which is why it turns up more often than the other three combined.

The mechanics take a paragraph. Take the accepted baseline. Build a small network representing each delay event — a fragnet — and insert it into the logic at the point where it belongs. Re-run the calculation. The completion date moves, and the distance it moves is the extension of time you are claiming.

That is the whole of it. No as-built. No update series. No site diaries. A baseline, a list of events, and an afternoon.

The question it actually answers

Here is where it gets uncomfortable, and it is worth stating precisely because the imprecision is where claims die.

An impacted as-planned analysis does not tell you what delayed the project. It tells you what would have delayed the project, if the plan had been followed exactly and nothing had gone wrong except the events you inserted.

That is a hypothetical question, and the answer is a forecast. It happens to be a forecast produced after the events it forecasts, which is an unusual thing for a document to be, and the strangeness is not cosmetic.

Every one of the objections below comes from that single property.

Why it is everywhere, and why it fails

The strengths are real and shouldn't be sneered at. It is easy to understand, which matters more than engineers like to admit — Week 9 made the point that an analysis a tribunal can't follow is worth less than a simpler one it can. It carries the fewest variables between cause and effect. It can be run during the works. And it needs none of the evidence that Phase B spent four weeks describing.

The weaknesses are the same facts read from the other side.

Because it takes no account of what actually happened, it cannot see that the logic changed, that durations turned out different, or that the sequence was reorganised in month four. It cannot identify true concurrent delay, because your own delays are simply not in the model. And it will happily return an extension longer than the delay the job actually suffered, which is the point at which a reviewer stops reading and starts drafting a rejection.

The delays that are not in the picture

Take this job. Model the rock into the baseline, re-run, and out comes a number of days.

What the model does not contain is anything the contractor did. If the piling gang was already two weeks behind for its own reasons when the rock appeared, the impacted as-planned analysis is blind to it — not because it was concealed, but because the method has no place to put it. The baseline shows the plan, the fragnet shows the event, and everything else on the job is absent by construction.

So the answer arrives with the contractor's own delay silently removed. That is not fraud. It is the arithmetic doing exactly what it was asked to do, and the reason the other side's first question is always some version of what else was going on that month?

One at a time, or all at once

There's a second-order choice inside the method that changes the number.

Events can be inserted one at a time, in chronological order, re-running the calculation after each; or all of them can be inserted together and the model run once. The first is more defensible and slower. The second is quicker and tends to produce a larger figure, because interactions between events get counted in ways nobody has examined.

Neither approach is illegitimate, and this is the same pattern Week 9 described with window lengths: a conventional choice inside an agreed method, made silently, moving the answer. Say which one you did.

The paradox at the centre

Now the awkward part, and it is worth sitting with.

The method needs a baseline that is contractually compliant and genuinely represents what the contractor intended before starting. If the baseline has the defects Week 5 catalogued — open ends, constrained dates, missing scope — you have to repair it before you can impact anything.

But repairing a model whose entire output is hypothetical adds a further layer of your own judgement to a result that was already theoretical. You are now presenting a forecast, made after the fact, from a plan you partly rebuilt.

Which produces the paradox: the method is least defensible exactly where it is most tempting. A weak baseline is precisely the situation in which a team has no update series and no usable as-built either — and impacted as-planned is the only method left standing.

It points both ways

One property that rarely gets mentioned: nothing about this method belongs to the contractor.

An employer can build the same model containing only the contractor's delays and produce the mirror image — a projection showing the works finishing late for reasons the employer had no part in, and therefore an argument that delay damages should run. Same technique, same assumptions, same weaknesses, pointed the other way.

Worth remembering before serving one. A method resting on the plan was right and would have been followed is available to whoever wants it, and the party with the better records is usually the party that would rather not be handed it.

It also explains a pattern worth recognising. Where both sides run an impacted as-planned, the two reports often agree on every date, every fragnet duration and every piece of arithmetic, and differ only in which events went into the model. Risk Week 5 priced the rock at $48,450; whether the rock belongs in the model at all is not a technical question, and no amount of checking the calculation will answer it.

Where it does hold up

None of this makes the technique disreputable. It makes it a tool with a narrow correct application, reached for far outside it.

Used early, on one event, against a plan that has not yet been overtaken, it is a sensible way to ask what an instruction is about to cost. That is essentially the contemporaneous use, and it is the door into next week.

It also has a role the literature is explicit about and practitioners rarely mention: as a negotiating instrument. Where both parties can agree the baseline, the events and the fragnets, a shared simple model that everybody understands will settle more disputes than a rigorous one that only one side can check. Agreement on a rough answer beats a correct answer nobody accepts.

Practical insight

If you have an impacted as-planned analysis in front of you — yours or theirs — ask four questions in this order.

Which baseline was used, and was it the accepted one or a repaired version? If repaired, is there a schedule of what was changed? Were the events inserted one at a time or together? And what was the contractor's own progress at the moment each event was inserted?

The fourth question is the one that decides the meeting. If the analysis cannot answer it — and by construction it usually can't — then what you are holding is a statement about a plan, offered as a statement about a project.

That may still be the best available answer. It is a different thing from being the right one, and the difference is worth saying out loud before somebody else says it for you.

Key takeaways

✔ Impacted as-planned inserts delay events into the baseline and reads the movement of the completion date as the claim.

✔ It needs no as-built, no updates and no site record, which is why it is the most commonly submitted analysis.

✔ It answers a hypothetical: what would have happened had the plan been followed and nothing else gone wrong.

✔ The contractor's own delays cannot appear in it, so it cannot identify true concurrency and can overstate the entitlement.

✔ Inserting events one at a time and inserting them together give different answers; state which you did.

✔ Repairing a defective baseline to run it adds your judgement to an already theoretical result, so the method is weakest where it is most tempting.

✔ The method is symmetrical: an employer can run it with only your delays in it, on the same assumptions, against you.

✔ It is legitimate early, on a current plan, and as a negotiating model both sides agree — not as a reconstruction of thirty months in year three.

What's coming next

Take the same additive idea and stop pretending the plan never changed. Next week is time impact analysis: the same fragnets inserted not into the original baseline but into the programme as it actually stood on the day the event happened — the method most contracts point at, the one the guidance argues about most, and the one that needs the update series you may not have.