P6 Schedule Comparison
Last reviewed 16 September 20268 min read
Claim Digger by its current name — the report that proves what changed, and the only acceptable proof that nothing did
🟩 In one line: Schedule Comparison (Tools → Schedule Comparison; called Claim Digger before P6 8.3) lists every difference between two versions of a project — activities added and deleted, dates, durations, logic, constraints, calendars, codes, resources — and its two jobs are the monthly change table and the zero-date-change proof after any clean-up, Global Change or fragnet insertion.
👤 Who this is for: J/M. Prerequisites: p6-baselines-assign-and-maintain, monthly-update-checklist.
First, let's be honest about why this page exists
Every convention in this hub that says "prove zero date change" or "archive the comparison per event" is pointing at this one tool. It is not glamorous and the report is ugly, but it is the only P6 output that answers "what did you change?" with a list instead of an opinion.
The tool is also misread. It tells you what is different, activity by activity; it does not tell you why, and it does not tell you which difference drove the completion date. That is the planner's job, done on the longest path with the report open beside it.
🟨 The standard — what "good" looks like
| Source | What it asks for (paraphrased) | Use of the comparison |
|---|---|---|
| AACE RP 53R-06 | Update review compares to the baseline and to the previous update; identifies logic, duration, calendar and constraint changes | The monthly report, both directions |
| AACE RP 52R-06 | TIA records the unimpacted and impacted schedules and the differences | Comparison archived per fragnet |
| SCL Protocol 2nd ed., Guidance Part B and Core Principle 4 | Contemporaneous records of programme changes | The archived report is that record |
| GAO Schedule Assessment Guide, BP 9 and 10 | Document changes at each update; maintain baseline traceability | Same |
| DCMA 14-Point | Assessment repeatable across updates | Comparison shows what moved between assessments |
| Convention (schedule-narrative) | Change table lists every logic, duration, calendar, constraint change | Built from the comparison output, not from memory |
🟢 Rule: run it twice every update — against the previous accepted update for the change table and against the Project Baseline for the variance picture — and once after every clean-up, Global Change or Reflection merge to prove the dates did not move; archive every report with the file it describes.
How it actually works
1. Running it
| Step | Action | Note |
|---|---|---|
| 1 | Open the current (revised) project | Both projects must be in the same database, or one must be a baseline of the other |
| 2 | Tools → Schedule Comparison | Older builds: Tools → Claim Digger |
| 3 | Original project: choose another project (previous update imported under "Received"/archive node) or a baseline of the current project | Baseline route is quickest for the Project Baseline comparison |
| 4 | Output: HTML for reading, CSV for pasting into the narrative table | Set the output folder to the update archive |
| 5 | Options → tick the data groups | See table below |
| 6 | Compare | Report opens; file saved |
2. Which groups to tick
| Group | Monthly change table | Zero-change proof | TIA / fragnet |
|---|---|---|---|
| Project-level: data date, scheduling options, calendars | Yes | Yes | Yes |
| Activities added / deleted | Yes | Yes | Yes |
| Activity dates: start, finish, actual, early/late | Yes | Yes (must be empty) | Yes |
| Durations: original, remaining | Yes | Yes | Yes |
| Percent complete | Yes | No | No |
| Constraints | Yes | Yes | Yes |
| Calendar assignment | Yes | Yes | Yes |
| Relationships added / deleted / lag / type changed | Yes | Yes | Yes |
| Activity codes, UDFs | Optional | Yes after code Global Change | No |
| Resources / assignments / costs | Where loaded | Where changed | Where loaded |
| Notebooks, steps, expenses | Optional | No | No |
Untick what you don't need; a full-options report on 3,000 activities runs to hundreds of pages and nobody reads it.
3. Reading it
The report is grouped by data type, then by activity. Read it in this order:
- Project-level — did the data date, scheduling options or a calendar change? If a calendar changed, half the date differences below are that.
- Added / deleted activities — every one should trace to a variation node, a split mapping row or a documented correction. Renamed IDs appear here as one delete and one add.
- Relationships — every added, deleted or altered link needs a row in the change table with a reason (hard-logic-vs-soft-logic).
- Constraints — every added or moved constraint needs a register row with a document reference; every removed one, a note.
- Durations — remaining-duration changes on in-progress activities are expected and should each have a Forecast Basis note; original-duration changes on not-started activities are corrections and go in the change table.
- Dates — last, and only to confirm they are explained by 1–5.
Then put the report down and walk the longest path from the data date to find which of those changes drove the completion movement. The report never says.
4. The zero-change proof
After a redundant-logic clean-up, a Global Change on codes, a duration-type correction or a Reflection merge that was supposed to be neutral: run the comparison with dates, durations, constraints, calendars and relationships ticked. The dates section must be empty. If it isn't, the change was not neutral, and the report tells you which activity to look at. Archive the report next to the change record — it is the evidence the reviewer asks for.
5. Limits worth knowing
- Matching is by Activity ID. Renumbering, splitting or copying activities breaks the match; use the Split From mapping table (splitting-in-progress-activities) for the transition month.
- It compares stored values, not causes. A remaining-duration change and a calendar change both move a date; the report shows both; you decide which mattered.
- It does not compare layouts, filters or user preferences.
- Large comparisons are slow; run overnight for multi-project files or tick fewer groups.
- Comparing against a baseline uses the baseline as the "original"; make sure it is the one you meant (Assign Baselines).
6. Where the outputs go
| Output | Destination |
|---|---|
| Upd09 vs Upd08 (CSV) | Narrative change table; archive folder Upd09 |
| Upd09 vs Project Baseline (HTML) | Archive; variance narrative |
| Clean-up / Global Change proof | Archive with the change record |
| Fragnet impacted vs unimpacted | Archive per change ref (VO-014) with the Reflection XER |
| Received sub file vs their previous | Reconciliation table (check against your copy) |
🟥 Where people go wrong
- Change table written from memory. Twelve of the nineteen logic changes make it in. The comparison lists all nineteen; paste the CSV and annotate.
- Reading only the dates section. Two hundred date differences, no idea why. Project-level first, then added/deleted, relationships, constraints, durations — the dates are the consequence.
- Trusting a clean report after renumbering. Every renumbered activity shows as delete plus add and nothing "changed." Renumber before the baseline or carry a mapping table.
- Comparing against the wrong original. A user baseline left pointing at a recovery target produces a report full of differences that mean nothing. Check Assign Baselines before you run it.
- Running it once a month. It is also the proof after every clean-up and every merge. Reflection → change → comparison → merge is the sequence; skipping the comparison is skipping the evidence.
- Not archiving. The reviewer asks in month 14 what changed in month 6. The report either exists in the folder or the answer is "I don't remember."
⚖️ When you're challenged
"You say you only cleaned redundant logic. How do I know nothing moved?" Schedule Comparison of the cleaned project against the previous one: relationships section lists the 84 links removed, dates section is empty, durations section is empty. Report's in the transmittal.
"Your change table has nineteen logic changes. Last month it had four. What happened?" The comparison is the source both months, so the count is real. Eleven of the nineteen are the VO-014 fragnet links, tagged with the change ref; six are the façade re-sequence from the recovery plan, each with a Logic Basis note; two are corrections. All nineteen have a reason in the table.
"The comparison shows 300 date changes. Explain them." One calendar exception — the Eid holiday added to the site calendar — moves every activity after it. It's the first line of the project-level section. Strip that out and there are eleven date changes, each traceable to a remaining-duration entry with its basis.
📄 Related pages
- Schedule Narrative — the change table this feeds
- Monthly update checklist — where the two comparisons sit in the cycle
- Time Impact Analysis — the impacted/unimpacted pair
- Redundant Relationships — the zero-change proof after clean-up
- P6 Global Change — the proof after a bulk edit
- P6 Reflections and What-If — the proof before a merge
- P6 Baselines: Assign and Maintain — choosing the right original
✏️ Worked example
Update 09 on a Riyadh hospital, DD 1 October, comparison against Upd 08:
| Section | Count | Traced to |
|---|---|---|
| Project-level | 1 | Data date 1 Sep → 1 Oct; scheduling options unchanged; calendars unchanged |
| Activities added | 6 | VO-014 fragnet (Change Ref code) |
| Activities deleted | 0 | — |
| Relationships added | 8 | 6 within VO-014; 2 façade re-sequence (Recovery R1-02, Logic Basis notes) |
| Relationships deleted | 3 | 1 façade preference link (R1-02); 2 redundant links removed (proof report attached) |
| Constraints | 1 removed | Start On or After on façade L3, no document basis (R1-01) |
| Original duration changes | 2 | Corrections on not-started blockwork L11–L12 (take-off revision, quantity sheet rev 4) |
| Remaining duration changes | 41 | In-progress activities, each with Forecast Basis |
| Date changes | 212 | Consequence of the above; completion 1 Dec vs 20 Nov (+9 VO-014, +2 own) |
The change table in the narrative had 61 rows — 6 + 8 + 3 + 1 + 2 + 41 — every one from the CSV. Time: 40 minutes including annotation.
📖 References
- AACE International RP 53R-06, Schedule Update Review – As Applied in Engineering, Procurement and Construction
- AACE International RP 52R-06, Time Impact Analysis – As Applied in Construction
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 4; Guidance Part B
- GAO Schedule Assessment Guide (GAO-16-89G), Best Practices 9, 10
- DCMA 14-Point Schedule Assessment
- Oracle Primavera P6 Professional User Guide — Schedule Comparison (Claim Digger) (field labels as in P6 Professional v20; earlier versions differ)
From the field
Notes, corrections and additions from people who've done this on a real job. Everything is checked before it appears here.
Loading notes…
Checked before it appears. No client, project or employer names. Your name is shown; your email never is. Terms.