Learning Center
How to Compare Two Schedule Updates Without Losing Your Mind
Without dedicated comparison software, comparing two P6 schedule updates comes down to a spreadsheet, a sort by Activity ID, and a lot of careful eyeballing. It works -- until an activity gets renamed or renumbered, at which point the whole row-alignment approach quietly stops telling the truth.
The Manual Process, Step by Step
This is the process most schedule analysts and PMs actually use when they don’t have a comparison tool on hand -- not a hypothetical, the real sequence of steps.
1. Export both updates to Excel, or open two P6 windows side by side
Most people export each update's activity layout to Excel (P6's own export, or a copy-paste from the activity table) because Excel is easier to sort, filter, and annotate than P6's grid. Some skip the export and just open two P6 sessions side by side, but that only really works if both updates fit on one screen at once -- past a couple hundred activities, you're scrolling both in lockstep.
2. Sort both lists by Activity ID so the rows line up
The whole approach depends on row N in the "before" sheet and row N in the "after" sheet being the same activity. Sorting both by Activity ID (not by start date, not by WBS order, which can itself shift between updates) is what makes that alignment possible -- as long as the ID itself hasn't changed.
3. VLOOKUP or manually match each row between the two sheets
A VLOOKUP keyed on Activity ID pulls the "after" values onto the same row as the "before" values, so each activity's two snapshots sit next to each other. Without a formula, this is done by eye -- scanning down both sorted lists and manually copying the matching row's values across, which is exactly as tedious and error-prone as it sounds on anything past a hundred rows.
4. Check dates, float, and duration column by column
With both snapshots side by side, the actual comparison is scanning across: did Planned Start move? Did Planned Finish move? Did Total Float change sign or magnitude? Did Duration change? There's no single "changed" flag -- you're eyeballing four or five columns per activity and deciding, row by row, whether the difference is real or just rounding.
5. Reconcile the relationships table as a completely separate exercise
Predecessor and successor logic doesn't live in the activity table at all -- it's a separate list of relationship rows (each one a predecessor/successor pair with a type and any lag). Comparing logic changes means exporting or copying that list too, sorting it by some combination of predecessor and successor ID, and running the same manual matching process a second time, on a completely different set of rows than the activity table.
6. Watch for activities that got renamed or renumbered
This is the step that quietly invalidates everything above it. If a scheduler renumbers an activity, splits it, or a re-import regenerates its underlying ID, the Activity ID you sorted and matched on no longer lines up between the two sheets. The row-alignment approach doesn't fail loudly -- it fails by silently reporting a real activity as deleted from one update and a brand-new, unrelated activity as added in the other.
A Small Example -- and Where It Breaks
Here’s what a manual comparison spreadsheet might look like for six activities spanning two monthly updates, after sorting both by Activity ID and matching rows by hand. The analyst added the note column while going through it.
| ID (Before) | ID (After) | Activity | Finish (Before) | Finish (After) | Analyst’s Note |
|---|---|---|---|---|---|
| A1010 | A1010 | Mobilization | 10-Mar | 10-Mar | No change |
| A1020 | A1020 | Site Survey | 17-Mar | 17-Mar | No change |
| A1030 | — | Excavation | 05-Apr | — | Not found under A1030 in Update 2 -- looks deleted |
| — | A1035 | Excavation | — | 12-Apr | Wasn't in Update 1 under A1035 -- looks like a new activity |
| A1040 | A1040 | Foundations | 19-Apr | 26-Apr | Slipped 7 days -- but why, if its predecessor “disappeared”? |
| A1050 | A1050 | Steel Erection | 10-May | 10-May | No change (float absorbed the slip upstream) |
The two highlighted rows are the same piece of work. Excavation was A1030 in the first update and got renumbered to A1035 in the second -- maybe the scheduler split it out under a new numbering block, maybe it came back through a re-import that regenerated the ID. Either way, sorting by Activity ID can only match rows whose ID stayed the same, so the spreadsheet reports it as one activity disappearing and an unrelated one appearing in its place. That’s the same activity-ID instability covered in what an XER file actually stores -- it isn’t specific to Excel, it’s inherent to matching on an ID that a P6 operation can change.
Notice, too, what the false delete-and-add hides: Foundations slipped seven days between updates, and that slip almost certainly traces back to the renumbered excavation activity -- but with A1030 and A1035 sitting on two disconnected rows instead of one, that causal link isn’t visible anywhere in the sheet. The analyst has to notice the coincidence and go dig through both updates’ logic by hand to confirm it.
Why This Doesn’t Scale
Six activities and one renumbering is already enough to trip up a manual comparison. A real construction schedule update commonly runs to 1,000 or more activities, each with several columns worth checking, plus a relationships table that’s frequently larger than the activity table itself. A few things compound at that scale:
- Column-by-column eyeballing across a thousand rows isn’t just slow -- it’s unreliable. A changed float value two columns over from where your eye is focused is easy to miss entirely.
- Every renamed or renumbered activity has to be caught by a human noticing a suspicious pattern (a familiar name next to an unfamiliar ID), not by the spreadsheet itself -- there’s no formula that flags it automatically.
- The relationships table has to be reconciled as a fully separate manual pass, on its own set of rows, with its own version of the same ID-matching problem.
- Any renumbering discovered late means re-checking every note already written for that activity and anything downstream of it, since the earlier rows may have been comparing the wrong things without anyone realizing it.
Claims Digger automates exactly this process. It matches activities across two uploaded snapshots the way a human reviewer actually would, checks every date, float, and duration column for each match, reconciles the relationships table separately, and correctly handles activities that were renamed or renumbered between updates instead of reporting them as unrelated deletions and additions. See how it works.
Frequently Asked Questions
- Can I really do this in Excel with just VLOOKUP?
- Yes, for a small schedule with stable Activity IDs and no logic changes to speak of, a VLOOKUP-based comparison is a perfectly reasonable way to spot-check a handful of activities. It stops being reasonable once the schedule runs into the hundreds or thousands of rows, or once you need to check relationships as well as dates -- at that point the manual matching and eyeballing simply take too long to do reliably.
- What's the single biggest way this goes wrong?
- A renamed or renumbered activity. Because the whole approach depends on Activity ID being a stable key to sort and match on, one activity changing ID between updates makes it look like that activity was deleted and an unrelated new one was added -- even though it's the same scope of work. Everything downstream of that activity in your notes can end up misattributed too.
- How do I compare the relationships (logic), not just the dates?
- As its own separate pass. The predecessor/successor list isn't part of the activity table -- it's a different set of rows entirely, each one a predecessor-successor pair with a relationship type and lag. Comparing logic changes means exporting or copying that list from both updates and running the same sort-and-match process against it a second time, independent of whatever you found in the activity dates.
- At what point should I stop doing this by hand?
- Once a single renamed or renumbered activity would take real effort to track down, or once the row count makes column-by-column eyeballing unreliable -- for most real construction schedules, that's well under the 1,000-plus activities a typical multi-month update actually contains.
Part of the Claims Digger Learning Center. Related reading: What Is an XER File? · Full glossary