As-planned vs as-built: the oldest delay method, done properly

Lay what was planned over what actually happened and look at the difference. As-planned vs as-built is the oldest, simplest and most intuitive delay method there is — which is precisely why it is both beloved by tribunals and routinely demolished under cross-examination. The difference between the two outcomes is workmanship.

The method everyone already understands

Every delay analysis method ultimately answers the same question — what made completion late, and by how much? — but only one of them can be explained to a tribunal in a single sentence. As-planned vs as-built (APAB) overlays the approved programme on a factual record of what actually happened, and reads the delay off the comparison. In the AACE classification (Recommended Practice 29R-03) it is MIP 3.1: observational, static, gross. Observational because it examines records rather than simulating anything; static because the logic is never re-run; gross because it considers the whole period in one comparison rather than window by window.

No software wizardry, no inserted fragnets, no re-running of CPM calculations with hindsight settings. That austerity is the method's whole personality — its greatest strength and the source of every attack on it.

Why tribunals like it — and why opponents don't

Decision-makers like APAB for an unfashionable reason: they can check it themselves. A judge or arbitrator can hold the planned bar against the as-built bar and see the six weeks with their own eyes. There are no modelling assumptions to take on trust, no expert's black box, no debate about whether the analyst's fragnet durations were self-serving. In a field where methods can descend into duelling simulations, transparency buys real credibility — and tribunals have said so often enough that no competent opposing expert will dismiss a well-built APAB out of hand.

What they will do instead is attack its three genuine weaknesses:

• It shows effect, not cause. The overlay proves the groundworks finished eleven weeks late; it says nothing about why. Causation has to be supplied separately, from records — and a bare overlay submitted as if the gap itself proved entitlement deserves the kicking it will get.
• It ignores the changing critical path. A static comparison assumes the path to completion stayed where the baseline put it. On real projects criticality migrates, and a delay to an activity that had drifted off the critical path may have cost nothing. Methods that track the path through time — windows and time impact analysis — exist precisely to answer this.
• It assumes the as-planned was achievable. The comparison treats the baseline as the yardstick of what should have happened. If the baseline was logic-thin, optimistic or constraint-rigged, the measured "delay" partly measures the plan's fantasy rather than anyone's culpability.

When APAB is the right tool

Choosing a delay method is itself a strategic decision — we've written about how to choose before someone chooses for you — and APAB earns its place in four situations:

• Simple projects. Short duration, an obvious and stable critical path, a handful of delay events. Deploying a full retrospective TIA on a 9-month fit-out is using a microscope to read a road sign.
• Gross-delay demonstrations. When the question is "was the project late and roughly where did the time go?" rather than "allocate every day between the parties" — adjudications, early settlement discussions, executive briefings.
• As a sanity-check companion. Run alongside a modelled method, the overlay is a cheap cross-examination of your own analysis. If the TIA says the employer caused 30 weeks of delay and the as-built shows the project finished 12 weeks late, one of them needs a better story.
• When the updates don't exist. Observational window-based methods need a chain of decent contemporaneous updates. If the project never kept them — see our piece on baseline and update discipline — APAB built from primary records may be the only honest option left.

Doing it properly

Validate the as-planned first

Your yardstick goes on trial before your delay does. Before relying on the baseline, run it through a structural quality review — in practice, a 14-point check: open ends, leads and lags, constraint abuse, float profile, a critical path that actually responds to delay. An APAB built on a baseline with 25% missing logic invites the inevitable: "your entire analysis measures deviation from a programme that could never have been achieved." Find that out from your own review, not from the other side's expert report.

Build the as-built from records, not memory

The as-built programme is a piece of evidence and must be constructed like one: daily diaries, inspection and test records, progress photographs with dates, delivery tickets, the actual dates recorded in contemporaneous updates. Interviews fill gaps; they do not substitute for documents. Every as-built date should be traceable to a source, because in cross-examination it will be traced to a source — by someone else, if not by you.

Align the calendars

An unglamorous trap that catches real analyses: planned bars on a five-day calendar overlaid on as-built dates that include weekend working, holiday shutdowns or a different working pattern will manufacture phantom delay (or phantom recovery) out of nothing. Convert both sides to a common calendar basis before measuring a single gap.

Compare at activity level, not just completion

The lazy version compares two finish dates and stops. The proper version works path by path and activity by activity: where did each delay first appear, did it propagate or get absorbed, what was happening on the other paths at the time? That granularity is what lets you connect each slice of delay to a cause and a record — which is the entire difference between an analysis and a picture.

How the method gets abused

Cherry-picked activities. An overlay that shows only the activities delayed by the other side, omitting the ones the presenting party delayed itself, is advocacy wearing a methodology costume. It tends to unravel the moment the opposing expert produces the full activity set — and on a network-quality review the omissions are usually findable in minutes.

The total-time claim. The grandest abuse: "the contract said 36 weeks, it took 42, the employer caused events during the project, therefore the employer owes 6 weeks." This is the global claim in temporal form, and it fails for a structural reason — it assumes, without demonstrating, that every lost day traces to the other party, that none of the delay was concurrent, and that the original duration was achievable. Tribunals have rejected total-time arguments consistently because they do not survive contact with the obvious question: what about the delay you caused? Where both parties' delays genuinely overlap, you are in concurrent delay territory, and a method that cannot even see concurrency cannot allocate it.

Strengths, weaknesses and how it lands