A baseline-vs-update schedule comparison is the side-by-side review of your approved plan (the baseline) against the latest progressed schedule (the update) to isolate what moved and why. Done well, it separates real change — slipped dates, rerouted logic, added or deleted activities, calendar edits, critical path drift, and float erosion — from ordinary progress. The output is a defensible narrative you can carry into a progress meeting before anyone across the table spots the surprise first.
This guide covers what to compare, a review workflow to run before the meeting, the red flags that hide inside a "clean-looking" update, and how to report the deltas to stakeholders without drowning them in noise.
What is a baseline-vs-update schedule comparison?
The baseline is the schedule that was reviewed and accepted as the plan of record — the agreed dates, logic, durations, and calendars against which progress is measured. An update is the same schedule after the planner has statused it: entered actual start and finish dates, remaining durations, and moved the data date (the "as-of" line separating what has happened from what is forecast). Comparing the two answers one question: what is different, and is the difference progress or drift?
The trap is that most tools show you two files, not the delta between them. Eyeballing a 6,000-activity update against a baseline in two windows is how genuine change slips through. A proper comparison computes the difference per activity and per attribute, so you review a change list, not two full schedules.
What should you compare between baseline and update?
Progress alone will move dates. The job is to find the changes that are not explained by work getting done. Seven dimensions cover almost everything worth catching:
| Dimension | What you are looking for | Why it matters |
|---|---|---|
| Dates | Start/finish slips beyond what progress explains | The headline delay signal |
| Logic | Added, deleted, or re-typed relationships; new lags | Re-sequencing can hide or create delay |
| Durations | Original and remaining durations that changed | Silent duration growth masks slip |
| Added / deleted activities | New scope, or activities that vanished | Deletions can erase the record of a delay |
| Calendars | Working days, shifts, holidays edited | A calendar change moves dates with no visible cause |
| Critical path | Which path now drives completion | Drift onto a new path changes your risk story |
| Float | Total float consumed since baseline | Float erosion is early warning before dates slip |
A few of these deserve definition. Total float is how long an activity can slip without delaying project completion; free float is how long it can slip without delaying any successor's early start. Critical path drift is when the longest path through the network moves from one chain of work to another between periods. And float erosion is the quiet consumption of total float over successive updates — the path can look on-time for months while its cushion drains toward zero, then it goes critical all at once.
The order matters. Check calendars and logic first, because a calendar edit or a rerouted relationship causes date and float movement downstream. If you review dates before logic, you end up explaining symptoms instead of the cause.
A review workflow to run before the progress meeting
The goal before a meeting is not a forensic delay analysis. It is a fast, repeatable pass that leaves you with a short list of real changes and a one-line explanation for each. A workflow that holds up under time pressure:
- Run the mechanical diff first. Generate the change list — added/deleted activities, changed logic, changed durations, changed calendars, and date movement — before you form any opinion. Let the data set the agenda. The free schedule comparison tool does this baseline-vs-update diff on an XER or Microsoft Project file with no sign-up, which is enough for a quick pre-meeting pass.
- Reconcile the data date. Confirm the update's data date is where it should be and that every activity behind it is actually statused. Un-statused activities behind the data date and statused activities ahead of it both corrupt the comparison.
- Screen logic and calendar changes. Read every relationship and calendar edit. Each one needs a reason: a genuine re-sequence, a corrected error, or a client-directed change. Anything you cannot explain is a flag.
- Trace the critical path on both files. Note whether the driving path moved, and to what. A shift from civil works to steel is a story you need to tell, not discover live in the meeting.
- Rank by float consumed, not just by slip. Sort near-critical paths by total float remaining. The path that lost 15 days of float but has not slipped yet is often the real headline.
- Write one line per material change. For each item that survives screening, draft the plain-language reason now. That list is your meeting brief.
Steps 3 through 5 are where an in-file review pays off. Kazinex Planner keeps the two schedules side by side and lets you filter the comparison to just changed logic or just eroded float, and its AI copilot can walk the diff conversationally — "what logic changed on the commissioning path this period?" — so the screening pass takes minutes rather than an afternoon of layouts and filters.
Red flags: what a comparison should catch
Some patterns are innocent in isolation and damaging in aggregate. These are the ones worth naming explicitly, because they are easy to miss and hard to unwind later.
Sequestered float. Also called float sequestering: capturing float that belongs to the project through soft constraints, preferential logic, or padded remaining durations, so a party protects its own dates at the network's expense. The tell is total float appearing or migrating in ways that progress does not explain — a chain that gained float while work fell behind.
Constraint creep. The gradual accumulation of date constraints — Start On, Finish On, mandatory dates — added between updates. A single justified constraint is fine. A dozen new ones override the logic quietly, so the schedule calculates to dates that no longer reflect the network. Every new constraint in the diff needs a reason.
Logic churn. A high volume of relationship additions, deletions, and type changes in one period. Some churn is legitimate re-planning; a lot of it means the network is unstable and any critical-path conclusion drawn from it is fragile. Churn also erases the audit trail — if last month's driving logic is gone, proving what actually delayed the job gets much harder.
Deleted activities and dangling logic. Activities that disappear between baseline and update can remove the record of scope that slipped. Deletions also tend to leave open ends — activities with no predecessor or successor — that break continuous critical-path calculation.
Duration growth without status. Remaining durations that crept up on activities that have not started. It reads as a forecast tweak; it behaves as delay.
If you want an independent read on the update's health alongside the comparison, the free DCMA-14 quality scorer flags several of these — hard constraints, high float, negative float, and open ends — against the US Defense Contract Management Agency's 14-point standard.
How do you report the deltas to stakeholders?
Reporting is an exercise in subtraction. You found dozens of changes; the meeting needs the handful that move the completion date or the risk profile. Lead with the answer, then support it.
- Open with the completion-date delta and its single biggest driver. "Substantial completion moved out 11 working days, driven by the steel-delivery slip that shifted the critical path from civils to structural steel."
- Show the critical-path change, not just the number. A before/after of the driving path tells the story faster than any table of dates.
- Separate change from progress explicitly. State what moved because work got done versus what moved because logic, calendars, or constraints changed. Stakeholders trust the first and need to scrutinize the second.
- Quantify float erosion on near-critical paths. The path that has not slipped but lost most of its float is your leading indicator; naming it now prevents a nastier conversation next period.
- Keep the full change list as an appendix. The one-line-per-change list from your review supports every headline without cluttering the main message.
The comparison and its export live naturally in a schedule tool. See Kazinex Planner for the in-browser comparison, critical-path tracing, and diff export used through the workflow above.
The discipline underneath all of it is simple: compare attributes, not appearances; explain every change that progress does not; and walk into the meeting already holding the narrative rather than reacting to it.
Frequently asked questions
What is the difference between a baseline and an update in scheduling? The baseline is the approved plan of record; the update is that same schedule after actual dates, remaining durations, and a moved data date are entered — comparing them shows what changed since the plan was set.
What should you compare first, dates or logic? Compare calendars and logic before dates, because a calendar edit or a rerouted relationship is what causes downstream date and float movement — checking dates first only shows the symptoms.
What is sequestered float and why is it a red flag? Sequestered float is float that belongs to the project being captured through soft constraints, preferential logic, or padded durations so one party protects its own dates; it is a flag because it appears without progress explaining it and masks real slip.
Can you compare XER and Microsoft Project schedules without P6 installed? Yes — a browser-based tool can diff a Primavera P6 XER or Microsoft Project file directly, and the free comparison tool at schedule.kazinex.com/compare does a baseline-vs-update diff with no install or sign-up.