Learning Center
Multi-Update Schedule Tracking: Why Two-File Comparison Isn’t Enough
Comparing just the baseline to the final schedule answers “how much did it slip in total.” It can’t answer “when did it slip, and what was driving the finish date at that point” -- and that second question is usually the one a delay dispute actually turns on.
One Number Can Hide Two Very Different Stories
A project baselined with 18 days of float on its finish activity, ending at −9 days of float by the final update, shows a 27-day swing either way you look at it. But how that swing happened -- gradually across nine monthly updates, or entirely within one -- points to completely different causes, and completely different evidence for who’s responsible.
Worked Example: The Same Swing, Two Ways
Both fictional scenarios below start and end at the exact same two float values -- only the path between them differs:
| Update | Total Float (days) |
|---|---|
| Baseline | 18 |
| Update 3 | 20 |
| Update 6 | 4 |
| Update 9 (final) | -9 |
A comparison limited to baseline-vs-final would show identical results for both scenarios -- the exact same start and end float values. Only tracking every update in between reveals that they’re fundamentally different stories, one gradual and one event-driven.
Claims Digger keeps every schedule update you upload as its own comparable snapshot -- not just the two you happen to compare in a given session -- so distinguishing gradual erosion from a single sharp event is a matter of looking at the trend across updates you already have, not requesting historical files you may no longer have access to. See how it works.
Frequently Asked Questions
- Isn't comparing baseline to the final update enough to know the total delay?
- It tells you the total slip in dates, but not when it happened or why -- a project could show the same final delay whether it happened gradually across nine updates or entirely within one bad month, and those two stories call for completely different causation arguments.
- How many updates does a real project usually produce?
- It varies widely by project size and contract requirements, but monthly updates across a one-to-two-year project routinely produce a dozen or more separate schedule versions -- each one a real data point, not just an intermediate step to the final comparison.
- Is this the same thing as windows analysis?
- Closely related -- windows analysis is the formal delay-attribution technique built specifically on top of this kind of multi-update tracking, dividing the same sequence of updates into windows and attributing delay days within each one. Tracking the full sequence is the raw material; windows analysis is one specific way to use it.
Part of the Claims Digger Learning Center. Related reading: Windows analysis walkthrough · Float erosion and negative float