But-For Delay: Reconstructing the Project Without the Delay

What But-For Analysis Is

But-for delay analysis takes the project’s actual, as-built record, removes one specific delay event from the logic network, and recalculates the schedule as if that event had never happened. The recalculated finish date is the hypothetical “but-for” date. The gap between it and the real, actual finish date is the delay attributable to that one event -- nothing else.

It’s most often reached for when a dispute turns on a single, well-defined event -- a late owner decision, a differing-site-condition ruling, or, in the example below, a slip in an owner-furnished equipment delivery -- and the question is specifically how much that one event cost the schedule, isolated from everything else that happened on the project. It depends on having a logic-linked CPM network (or a defensible reconstruction of one) so that removing the event’s impact propagates correctly through whatever depended on it, rather than being guessed at.

The method’s well-known limitation is that the result is only as good as the reconstruction. Which activities keep their actual dates, which are allowed to shift once the event is removed, and how far that ripple is allowed to travel through the network are all judgment calls -- and they’re exactly what courts and boards scrutinize most closely. Two analysts working from the same as-built data can produce two different but-for dates depending on how they answer those questions. (The term is also sometimes labeled “collapsed as-planned” in older literature -- see the FAQ below on why that label is better reserved for a related but distinct technique.)

Worked Example: Meridian Distribution Center

A ten-activity sequence for a fictional warehouse project, NTP (notice to proceed) on March 2. One activity -- G, owner-furnished switchgear -- was planned to take 70 calendar days from NTP to delivery. A late owner-directed change to the switchgear’s specification, issued after the equipment was already in fabrication, pushed the actual delivery to 110 days -- a 40-day slip in that one activity. Every other activity happened exactly as sequenced, with no deviation of its own, which keeps this first pass clean enough to isolate the mechanism.

The Actual As-Built Record

Actual substantial completion: August 1 (day 152 from NTP). Because G was already the controlling predecessor for electrical rough-in even under the original plan (70 days versus structural steel’s 62), it had no float to absorb its own slip -- the full 40-day increase in G passes straight through H, I, and J to the finish date.

The But-For Reconstruction

Remove the delay event: hold G to its original 70-day procurement duration and recalculate everything downstream of it. Activities A through F are untouched by this event and keep their actual dates; only G, H, I, and J recalculate.

But-for substantial completion: June 22 (day 112 from NTP). In this simplified example -- where nothing else on the project deviated from plan -- the but-for network happens to reduce back to the original baseline logic exactly. On a real project with other genuine deviations sitting alongside the one event being tested, the but-for schedule is typically its own distinct reconstruction, not simply a return to the baseline.

The Delay Attributable to the Event

Actual completion (August 1) minus but-for completion (June 22) leaves a 40-calendar-day delay attributable to the switchgear specification change -- matching the event’s own 40-day slip exactly, because nothing downstream had spare float to soak any of it up first. That one-to-one match won’t always hold: if the steel-erection path (D) had instead finished closer to or past G’s actual delivery date, some or all of the 40 days would have been absorbed by float already sitting on that path, and the but-for gap would come out smaller than the event’s own duration.

Frequently Asked Questions

Is but-for analysis the same thing as “collapsed as-planned”?

Not exactly, and the two get conflated often enough that it's worth being precise. Some older literature does use “collapsed as-planned” as a rough synonym for but-for reasoning. More commonly, though, that label is reserved for a related but distinct technique that starts from the original baseline (as-planned) schedule and collapses alleged excusable delays out of it going forward, rather than starting from the as-built record and working a single event back out of it -- which is what this article walks through. Treat them as cousins, not interchangeable terms.

When is but-for analysis the right tool?

It works best on a single, discrete, well-defined delay event -- a late owner decision, a differing-site-condition ruling, a slip in owner-furnished equipment, as in the example above -- where the question is specifically “how much did this one thing cost the schedule.” It's less suited to a sprawling, multi-event claim spanning the whole project, where a period-by-period or windows-based method usually holds up better.

What's the main criticism of but-for analysis?

The result is only as good as the reconstruction. Deciding which activities' logic and durations get held exactly as they actually happened, versus which are allowed to shift once the event is removed, involves judgment calls -- and different analysts working from the same as-built data can land on different but-for dates depending on those calls. Courts and boards scrutinize exactly this: not just the final day count, but the assumptions that produced it.

Does the but-for schedule always match the original baseline?

Only when nothing else deviated from plan, as in the simplified example above. On a real project, other actual delays and changes almost always exist alongside the one event being tested -- so a proper but-for reconstruction keeps those other actual deviations in place and removes only the single event in question. That version is typically its own distinct network, not simply a return to the baseline.