Automating the monthly schedule update comparison without losing the explanation

Every month a scheduler lines up two XER exports, finds every duration, tie and actual date that changed between them, and then has to tell the owner why the contract milestone moved. The first half of that job is the same two files and the same field-by-field comparison each time, which makes it the part of project controls most worth handing to software. The reason a date moved needs a record and a person who has checked it, and the workflow below automates the comparison without letting a tool fill in the reason.

Start from the owner's questions

"Automate project controls" can mean cost forecasting, progress capture or document control. For the update review, the deliverable is the narrative that goes to the owner with the monthly submission, and the comparison exists to answer five questions in it.

• Which contract milestones moved between the accepted update and the proposed one?
• Which changes are new progress and which are edits to the model?
• What record supports each change?
• What is still unconfirmed?
• Who has to decide something, and by when?

A comparison that produces a chart for every changed activity and leaves those questions open still leaves the scheduler writing the narrative from scratch. Judge any tool on whether the five answers come out faster and still hold when another scheduler checks them against the two files.

Lock the input pair

Keep the last accepted update and the current proposed update as separate XER exports, and write down the project ID, data date and revision of each. If the current file is still being edited, say so in the file name and in the report header.

Check that both exports contain the project you think they contain and that Activity IDs carry over between them. A file name tells you what someone meant to export, while the project list inside the XER tells you what was actually exported. A renamed copy of last month's file will otherwise produce a comparison that shows almost nothing changed.

When an input gets corrected, issue it as a new revision and note which report it replaces. Overwriting the original leaves the team arguing over a report whose source file no longer exists.

Split progress from model edits

A schedule update mixes two kinds of change. Progress is new Actual Start and Actual Finish dates and revised Remaining Duration on work underway. Model edits are added or deleted relationships, changed lags, new constraints, calendar reassignments and added activities. Software can sort most changes into one of those groups, because each one is a field-level difference between two files. The exception is an actual date that changed after it was already reported, which is neither progress nor a model edit and needs its own question.

What the comparison cannot supply is the reason a value changed. A Remaining Duration that went from 15 to 22 days could reflect a new production rate, added scope or a typo being fixed. The review table should show what the files prove next to what the reviewer still has to collect.

In the report, "Remaining Duration increased from 15 to 22 days" is the observation. "Production has dropped on that activity" is an explanation, and it only goes in once someone has produced the field record behind it.

Trace back from the milestone

The largest movement in the activity list is rarely the one that explains the milestone. Start at the milestone the owner tracks and walk back through its driving predecessors before ranking changes.

Take a hypothetical dry-in milestone that moves from March 3 to March 11. In the same update a roofing activity moves twelve days and a curtain wall activity moves four. Neither number tells you which change produced the eight days. That depends on the driving relationships, the float each activity carried, the calendars and any constraints, and you only find it by tracing the path. Adding the activity movements together and calling the total project delay is the error this step exists to stop.

Make the draft show its basis

An automated narrative is worth using when every finding points to the activities and the milestone it affects, and says plainly what is still open. "The current update adds a finish-to-start tie from switchgear delivery to energization; the reason for the edit has not been confirmed" is a usable sentence. A confident cause written to make the paragraph flow does more harm than the open question, because the owner will repeat it in the next meeting.

Keep recommended actions in their own section. Confirming a delivery date or modeling a resequence is a next step, and the narrative should not describe it as recovery already achieved.

Name the reviewer

One named person checks the draft before it becomes the owner report. That person confirms the input pair, the milestone selection, the material findings and every sentence about cause or responsibility. They also look for what is missing, since a report can be accurate line by line and still leave out a scope change everyone discussed in the progress meeting.

See the comparison on your own update

In Pathizer the comparison is calculated from the schedule data, and AI drafts only the narrative language, which is labeled for the scheduler to review. The fairest test is a month your scheduler has already reported by hand. Put that month's two XER files through the free Update Compare at pathizer.com/xer-update-compare, which needs no sign-in and reads the files in your browser, and set its list of changed activities and relationships beside the report you issued, starting with every place they disagree.