Run a delay analysis on a busy window and you may notice something alarming. The individual change impacts against Substantial Completion add up to 240 days, but the milestone only moved 60. The instinct is to call it a bug. It is the opposite. A set of per-change impacts that exceeds the actual milestone movement is the signature of concurrency, measured honestly.
This post explains why per-change impacts should not sum to the milestone movement, what goes wrong when a methodology forces them to, and how the analysis still reconciles against the one number everyone can verify: the actual movement of the milestone.
The Sequential Accumulation Trap
Start with the approach that produces numbers that do sum, because it is the approach most manual analyses quietly assume. Take every change between two schedule updates, put them in a sequence, and apply them one at a time. After each change, note how far the milestone moved. Each change gets credited with its incremental movement, and by construction the increments add up to the total.
Tidy arithmetic, and a serious problem: the attribution depends entirely on the order you chose. Consider two delays on parallel paths, each capable of pushing the milestone 30 days. Apply the steel delay first and it moves the milestone 30 days. Now apply the mechanical delay: the milestone is already at day 30, so it moves nothing. Sequential accumulation says the steel delay caused 30 days and the mechanical delay caused zero.
Reverse the order and the conclusion reverses with it. Same schedule, same changes, same milestone movement, opposite attribution. In a dispute where one party owns the steel delay and the other owns the mechanical delay, the sequencing choice decides who pays. An attribution that flips based on an arbitrary ordering decision is an attribution that will not survive scrutiny, and it should not.
Same two delays, two orderings
Steel measured first
Steel delay: 30 days. Mechanical delay: 0 days. The contractor responsible for steel bears the delay.
Mechanical measured first
Mechanical delay: 30 days. Steel delay: 0 days. The other party bears the delay.
The schedule contains no information that makes one ordering more correct than the other. The two delays are concurrent. Any methodology that produces different answers for different orderings is inventing information the network does not contain.
Parallel Paths, Same Starting Point
The fix is to stop pretending the changes happened in a sequence. FPM measures each change in the context the schedule network itself dictates. Where the network says one change genuinely depends on another, the measurement honors that dependency. But two changes on parallel paths have nothing connecting them, so neither is allowed to hide the other. Each is measured with its full effect, on its own path, against the same starting point.
Run the steel and mechanical example through this lens. The steel delay, measured on its own path: 30 days of push against the milestone. The mechanical delay, measured on its own path: 30 days of push against the milestone. The milestone itself moved 30 days. The two measurements add to 60, which is twice the actual movement, and both measurements are correct. Each one answers the question it was asked: how hard does this change push the milestone through the network?
This is also why the numbers are deterministic. Everything the measurement depends on is a fact of the schedule itself. There is no analyst-chosen sequence hiding inside the result. Rerun the analysis, rerun it on the other party's machine, rerun it a year later: the attribution is identical, because nothing in it was arbitrary.
The cost of this honesty is the property people expect from a column of numbers: the per-change impacts no longer sum to the milestone movement. When multiple drivers push concurrently, the measurements overlap. Concurrency is the overlap. Squeezing it out of the numbers doesn't remove the concurrency from the project. It just hides it from the analysis.
So How Do You Get Back to the Milestone Movement?
If measured impacts don't sum, how does the analysis reconcile against the thing everyone can verify, the actual movement of the milestone? By aggregating the way the network does: concurrent measurements compete, and the driving one wins. When parallel drivers push the same milestone, the milestone lands where the longest push puts it. Aggregation takes the maximum across concurrent paths, then accumulates through genuine dependencies.
This gives you both books at once. The per-change ledger records every driver at full measured strength, overlaps included. The milestone ledger reconciles to observed movement, because concurrent pushes were resolved by driving-path competition rather than addition. An audit that compares attributed movement against actual movement, window by window, closes. Nothing was double-counted, because nothing concurrent was ever added together.
We covered in an earlier post why measuring each change in the right network context is hard when the network itself is being rewired between updates. The concurrency handling described here sits on top of that machinery: first get each measurement's context right, then resolve the overlaps the way the network resolves them.
Measurement Is the Tool's Job. Apportionment Is Yours.
Concurrent delay is where forensic schedule analysis gets litigious. Whether concurrent delays excuse liquidated damages, whether apportionment should be 50/50 or follow some other split, whether a shadowed delay matters at all: these are questions of contract language, jurisdiction, and expert judgment. No measurement engine should be answering them.
What the engine should do is make the concurrency itself undeniable and precise. For every window between schedule updates, FPM's concurrent delay matrix lays out measured impact by category and by party-attributable change, filterable to delay drivers, mitigation, or both. The analyst arguing 60/40 apportionment does so from a grid of deterministic measurements rather than from a judgment call about which delay "felt" dominant. The opposing analyst, running the same data, gets the same grid.
That last point is the quiet one that matters most. Sequential accumulation hands each side a knob to turn: pick the ordering that favors your client. Concurrent measurement removes the knob. The numbers stop being negotiable, and the argument moves to where it belongs, which is what the numbers mean under the contract.
So the next time a delay analysis hands you impacts that sum to more than the milestone moved, don't reach for the bug tracker. Reach for the overlap. Somewhere in that surplus is a concurrent driver the sequential methods would have silently zeroed out, and it might be the one that decides your dispute.