Why a date-only comparison is not enough
Every monthly submission carries a new forecast finish. Comparing that date with last month's tells you whether the project reads earlier or later, and nothing else. A forecast can improve because work was done, or because durations were shortened, links were loosened, a longer working week was declared, or a constraint was moved. Those are different situations for an owner, a project manager or a delay analyst, and they look identical in a milestone table.
The review a schedule update deserves is the one described in AACE International's Recommended Practice 53R-06 (Schedule Update Review): check that the status is real, that the history has not been rewritten, and that any change to scope, logic, durations, calendars or constraints is found and explained. That takes two files and a comparison of every field, not a glance at two dates.
Who this is for
- Owner's representatives and construction managers receiving a contractor's monthly update and deciding whether to accept it.
- Project managers and schedulers who need to explain, in a progress meeting, why the finish date moved.
- Delay analysts establishing what changed in a period before attributing any of it.
What you need
| Item | Notes |
|---|---|
| This month's update | A P6 XER export (or a Microsoft Project XML). This is the current file. |
| Last month's update | The same project, exported at the previous data date. This is the prior file. |
| The baseline (optional) | Adds baseline bars and variance to the same review. |
| Nothing else | No P6 licence, no installation. The files are read in your browser. |
The three questions a comparison answers
Trestle Path's Month-over-Month section is arranged as three passes, because these are the three questions a reviewer actually asks, in this order.
1. Did the finish move?
The forecast finish and every milestone, current against prior, and the critical path in both files. Which activities gained or lost float, and which ones moved onto or off the critical path.
2. Is the progress real?
What started and what finished in the period; remaining durations that changed; percent complete that changed; and the check that matters most, actual dates that were reported last month and read differently this month. A restated actual date means the record of what happened is being edited after the fact, which 53R-06 treats as a hard error.
3. What was changed to get there?
Scope: activities added, deleted or moved into a retired branch. Logic: relationships added, removed, re-typed or re-lagged, compared in hours so a calendar change does not masquerade as a logic change. Durations: original durations revised. Calendars: reassigned or redefined. Constraints: added, removed or re-dated.
Step by step
- Sign in and open the dashboard. Load this month's XER as the current update, last month's as the prior update, and the baseline if you have it.
- Press Run. The files are parsed in your browser; the calculations run on the calculation service from anonymous numbers and come back in about a minute.
- Open Month-over-Month. Read the three passes top to bottom; every number opens the activities behind it.
- For the detail, open Relationships Forensic (every link added, removed, re-typed or re-lagged) and Delayed Activities (the overdue backlog against the prior update, with the cause attached).
- Export. The Excel workbook carries every register as its own tab, so a finding can be traced to the exact rows that produced it.
Worked example: the month the forecast improved by 78 days
The Vireo Line Extension is a fictional 22,200 ft twin-bore metro extension with five underground stations, built as a demonstration set: a baseline and eight monthly P6 updates. Nothing in it is real. The set exists to show the case a date-only review cannot see, and this is that case: the August 2026 update against the July 2026 update.
The date-only comparison first. The forecast revenue service date moved from 2030-07-17 to 2030-04-30, 78 days earlier; substantial completion from 2030-02-26 to 2029-12-24, back inside the contract date of 2030-01-31 after two months outside it. Float on substantial completion rose from 2 days to 10. On those numbers the month was a success.
Now the full comparison, as the product reports it from the two files:
| Register | August against July | What it means |
|---|---|---|
| Work completed in the period | 0 activities | Nothing finished. One activity started (elevators and escalators at Rookery Point). |
| Progress and remaining durations | 16 percent-complete changes · 27 remaining-duration changes | Status was updated on in-progress work, as it should be. The earned position, by value, went from 77.7% planned to 74.5% earned. |
| Actual dates restated | 4 dates on 2 activities | Previously reported actual dates changed on two station entrance structures. Under 53R-06 that is a hard error: the record of what happened is being edited after the fact. Each needs a stated reason. |
| Original durations revised | 11 activities | 9 shortened, all in testing and commissioning, each by 5 to 11 per cent: systems integration testing 85 → 76 working days, high-speed dynamic testing 52 → 47, static testing 75 → 68. Two lengthened (tunnel M&E containment 140 → 157, communications 85 → 123). |
| Calendars | 1 calendar added · 6 activities moved onto it | A seven-day commissioning calendar that did not exist in July. Six testing activities moved from a five-day week to it. Same hours per day, so nothing was rescaled; Saturdays and Sundays became working days on the one branch already short of float. |
| Relationships | 15 added · 9 removed · 5 changed | Four testing-and-commissioning links that were finish-to-start in July are start-to-start in August with 45 to 80 day lags: dynamic testing, CBTC verification and integration testing now overlap. A fifth link, at Halyard Street station, kept its type and had its lag cut from 110 to 80 days. Whether a test can begin before the test that produces its inputs has finished is a technical question, not a scheduling one. |
| Constraints | 1 added · 1 removed · 1 re-dated | A start-on-or-after constraint added to operational readiness (the operator's earliest staff release, a third party's date inside the contractor's schedule); one removed from a platform activity; one milestone constraint moved. |
| Scope | 9 added · 3 deleted (1 retired) · 2 renamed | Three real activities added (a second-shift communications recovery package, an interim integration dry run, temporary platform access). Six added activities form a delay fragnet, claiming an extension of time for three events on the very path the same submission just compressed. Two activities deleted, one of them complete, and one moved into a retired branch. |
| Float | 45 activities changed float · 34 changed finish | The forecast improved and the float got tighter: 9 activities on zero float against 6 in July. A recovery built on work performed releases float along the path it recovered; this one released none. |
Every number above is read from the two XER files at their own data dates. Nothing is re-scheduled to produce it; the comparison reports what the contractor's own files say.
Reading the registers
Duration register
Original durations rarely change in a healthy update; when they do, it is usually in one direction and on one branch. Ask for the basis of each change. A duration cut on a not-started activity with no change in resources is a forecast, not a plan.
Relationship changes
A link re-typed from finish-to-start to start-to-start with a lag is the most common way to compress a path without touching a duration. The product compares lags in hours, on the calendar the link uses, so a calendar redefinition does not appear as dozens of phantom logic edits.
Calendar changes
A new calendar, or a redefined one, is a resource commitment: more shifts, more days. It belongs in the narrative with the crews that make it true. The register shows which activities moved and from which calendar to which.
Constraint register
Constraints applied, removed or re-dated between updates change what the critical path can be. A third party's date inside the contractor's schedule is an interface risk and should be named as one.
Changed-actuals register
An actual start or finish reported in the prior update and different in the current one. There are legitimate reasons (a keying error corrected), and each needs to be stated, because the alternative is a schedule whose history cannot be relied on.
Scope register
Added and deleted activities, with deleted-but-complete work and retired branches called out separately. Work that was reported done and then disappears from the file is the case to chase first.
What a comparison cannot tell you, and other limits
- It matches activities by ID. If the contractor renumbers activities between updates, the comparison sees deletions and additions instead of changes. The product warns when the overlap between the two files is low enough for this to be the cause.
- It reports what changed, not why. The registers give you the questions; the contractor's narrative and your own knowledge of the site give the answers.
- A comparison is not a delay analysis. It establishes the facts of a period. Attributing delay, and measuring it across several periods, is the job of a windows analysis (AACE 29R-03) or a time impact analysis (AACE 52R-06), which the product's Delay Analysis & Validation section performs from the same files.
- Microsoft Project XML exports carry less than a P6 XER: no activity codes or resource curves, and simpler calendars, so the calendar and resource registers are thinner for an XML pair.
Where to find it
Month-over-Month, Relationships Forensic and Delayed Activities are included in the Analyst and Expert plans, and in the fourteen-day trial, which opens every section. The Reader plan reads a schedule and loads last month's update as a baseline, but does not run the comparison registers. Current prices are on the pricing page.
Fourteen days free
Try it on your own schedule
Fourteen days free, no credit card, every section open. Your XER or XML file is read in your browser and never uploaded; only anonymous numbers reach the calculation service, and nothing is stored.