Baseline vs. Current Schedule: What the Difference Reveals
Comparing a baseline schedule to the current update reveals how a project has drifted from its original plan — and who is responsible. Here is how to read a baseline comparison and what to do with the findings.
Every construction project starts with a plan — a baseline schedule that represents what the project team committed to when the contract was signed. From that point forward, actuals begin to diverge from the plan. Activities start late, durations extend, schedule logic gets revised, scope changes get incorporated.
A baseline comparison tells you the cumulative story of that divergence: how far the project has drifted from its original commitments, where the drift occurred, and — critically — when it occurred and what caused it.
This post explains how to conduct a baseline vs. current schedule comparison, what to look for in the output, and how to use the findings.
What a Baseline Comparison Is
A baseline comparison loads the original approved baseline schedule as Schedule A and the current schedule update as Schedule B, then produces a complete activity-by-activity comparison of every field that has changed between the two.
What Changes Most Between Baseline and Current
Dates
Date changes are the most visible category. Early start and early finish dates shifting forward (later than baseline) indicate delay. Shifts backward (earlier than baseline) indicate acceleration or schedule compression that may warrant scrutiny.
The most important dates to track are contractual milestones — the dates that have legal and financial consequences under the contract. If a key completion milestone has moved 45 days later than the baseline, that is a 45-day delay to a contractual commitment.
Durations
Duration changes reveal where work is taking longer than planned. An activity whose planned duration increased from 15 days to 28 days has had its scope changed, encountered productivity problems, or been extended for another reason. Understanding why a duration changed is central to understanding who is responsible for the resulting delay.
Logic Changes
Logic changes between the baseline and current schedule deserve particular attention because they can dramatically change the critical path analysis. A predecessor relationship that existed in the baseline but was removed in the current schedule may have been removed legitimately — or it may have been removed to float an activity off the critical path and make performance look better than it is.
Added and Removed Activities
Activities added since the baseline represent scope growth or more detailed planning. Activities removed represent scope reductions or consolidations. Either can have schedule implications that need to be understood in the context of the contract.
Float Changes
Total float in the current schedule that is significantly different from the baseline tells you about the float erosion. Activities that had comfortable float in the baseline but are now near-critical or critical have consumed their buffer — that consumption needs to be attributed to a cause.
How to Conduct the Comparison in Change Inspector
Load your approved baseline XER file and your current schedule XER file into Change Inspector. In the Compare module, set the baseline as Schedule A and the current update as Schedule B.
Work through the tabs methodically:
Overview tab first. Get the macro picture — how many activities were added, how many removed, how many changed. Check the data date of both files. Note whether the scheduled completion date has moved.
Schedule Dates tab. This tab shows side-by-side date comparisons for every changed activity. Sort by the magnitude of the date change to find the most delayed activities first.
Activities tab. Review changed activities with a focus on critical and near-critical activities in the current schedule. Duration changes on these activities are the primary drivers of schedule delay.
Relationships tab. Compare the logic between baseline and current. Flag any relationships that were removed from the baseline — these are the changes most likely to be significant in a claims context.
Gantt Diff tab. Sort by Delay. The visual picture of which activities have moved the most is often the clearest way to communicate baseline vs. current findings to a non-technical audience.
Using Baseline Comparison in Claims Analysis
In a delay claim, the baseline comparison establishes the foundation of your analysis. The typical sequence is:
- Establish the baseline. Confirm the approved baseline is a credible, logic-driven schedule that accurately represented the original plan. Run a DCMA health check on the baseline to assess its quality.
- Compare baseline to the delay period. Identify which activities were delayed and by how much. Establish which activities were on the critical path at the time of the delay event.
- Attribute the delay. Determine whether delayed activities were delayed by owner-caused events, contractor-caused events, or concurrent delay. This is where the change history of the schedule — tracked through update-to-update comparisons — becomes essential.
- Document everything. Export the baseline comparison report from Change Inspector. It becomes an exhibit in the claim analysis, showing objectively what changed from the original plan and when.
A well-documented baseline comparison is far more defensible than a narrative summary.
A Note on Baseline Integrity
The baseline comparison is only useful if the baseline is intact. This means the baseline XER file should be archived and protected from modification the moment it is approved. In P6, the approved baseline should be stored as a separate project file (not just a baseline assignment within the active project) and saved outside the active project management environment.