Every scheduler knows the feeling. The new update lands, the data date has moved forward a month, and the finish date has slipped eleven working days. Someone on the project team asks the obvious question: why?
The answer is somewhere in the file. Finding it is the hard part.
On most PM/CM projects, a schedule update is not really reviewed. It is investigated. The scheduler, the PM, or the owner's rep opens two versions of the P6 schedule side by side and starts hunting for clues. That hunt can eat an afternoon on a small job and several days on a large one.
This post walks through why that happens, where the hours actually go, and what a better workflow looks like, whether or not you ever use a tool to help.
The question is simple. The evidence is scattered.
A typical update review is trying to answer a short list of questions:
- Did the critical path change, and if so, why?
- Which activities lost float, and how much?
- Did anyone change logic, durations, or calendars instead of just statusing progress?
- Are there activities with actual starts out of sequence?
- What should we tell the owner in the OAC meeting?
None of those questions are exotic. The problem is that the evidence for each one lives in a different place. Some of it is in the activity table. Some of it is in relationships. Some of it is in a constraint someone added and forgot to mention. Some of it is in the narrative the contractor submitted, which may or may not match the file.
So the reviewer becomes a detective, piecing together a story from fragments.
Where the hours actually go
When we sit with scheduling and project controls teams, the time sink is rarely one big task. It is a stack of small, manual steps that repeat every cycle.
1. Lining up two versions
First you need a clean baseline for comparison: last month's accepted update against this month's submission. That sounds trivial until you have renamed activity IDs, added fragnets, deleted activities, and a WBS that got reorganized halfway through the job.
2. Diffing by hand
Many teams still export both versions to Excel and build lookup formulas to see what moved. Others scroll through layouts in P6, toggling filters. Either way, someone is visually comparing hundreds or thousands of rows looking for the handful that matter.
3. Separating progress from edits
This is the part that takes real judgment. A date moving because work was late is normal. A date moving because someone shortened a duration, deleted a predecessor, or changed a calendar is a different conversation. Telling those apart requires checking logic and attributes, not just dates.
4. Tracing the driving path
Once you see the finish slipped, you need to walk backward through the logic to find what is actually driving it. In a dense schedule, that can mean following a chain of dozens of relationships, some of which changed this period.
5. Writing it up
Finally, all of that has to become plain English. The PM needs talking points. The owner wants a narrative. The executive wants two sentences. The scheduler who did the detective work now has to translate it for three different audiences.
By the time the write-up is done, the next update is already on its way.
Why this matters beyond the scheduling team
It is tempting to treat this as a scheduler productivity problem. It is bigger than that.
Decisions get made late. If it takes a week to understand why the schedule slipped, the team is reacting to last month's problem while this month's problem is forming.
Issues hide in plain sight. When review time is tight, people check the finish date and the critical path and move on. Quiet logic changes, shrinking float on near-critical work, and out-of-sequence progress slip through until they become claims or recovery schedules.
Senior people do junior work. Your most experienced schedulers and CMs are the people who should be asking hard questions about the plan. Instead, a large share of their time goes into lining up spreadsheets.
Documentation suffers. If a dispute shows up a year later, you want a clear record of what changed each period and why. Rushed reviews produce thin records.
What a better workflow looks like
The goal is not to replace the scheduler's judgment. It is to stop spending that judgment on grunt work. Here is a practical way to structure the review, with or without new tools.
Standardize the comparison
Agree on what gets compared every cycle and in what order. For example:
- Finish date and key milestone movement
- Critical and near-critical path changes
- Logic changes (added, deleted, or modified relationships)
- Duration and calendar changes on incomplete work
- New or changed constraints
- Out-of-sequence progress
- Float erosion on the top paths
A fixed checklist sounds basic, but it turns an open-ended hunt into a repeatable review.
Separate "what changed" from "what it means"
The first pass should be mechanical: a complete list of differences between the two versions. The second pass is where the expert asks whether those changes are reasonable. Mixing the two is what makes reviews slow and inconsistent.
Write the narrative from the evidence, not from memory
Draft the update narrative directly from the list of changes. Each claim in the narrative should point back to a specific activity, relationship, or constraint. That makes the narrative faster to write and much easier to defend.
Keep the history
Save each period's comparison results. Over a few months, patterns appear: the same subcontractor's work keeps slipping, the same area keeps losing float, durations keep getting compressed to protect the finish date.
Where AI helps, and where it does not
This is a workflow where AI can genuinely take work off people's plates, because the first pass is mostly structured comparison and summarization.
Where it helps:
- Comparing two schedule versions and listing what changed, including logic, durations, constraints, and calendars
- Flagging float erosion and critical path shifts so reviewers start in the right place
- Summarizing changes in plain English so the PM and owner can follow along without CPM expertise
- Producing a consistent first draft of the update narrative for the scheduler to edit
Where it does not replace people:
- Deciding whether a logic change is legitimate or an attempt to hide a delay
- Understanding field conditions the schedule does not capture
- Negotiating with contractors and owners about what the update should say
What you need to get right:
- Data quality. If activity IDs, codes, and WBS are inconsistent from period to period, any comparison gets harder. Clean structure pays off.
- Human review. The output is a starting point. The scheduler still signs off.
- Security. Schedules contain sensitive project information. Know where your files go and who can see them.
How we approach it
At InstinctIQ, we work as a forward-deployed team. That means we start by sitting with your schedulers and PM/CM staff, watching how an update review actually happens on your projects, and then fitting technology around that process instead of asking you to adopt a new one.
For scheduling specifically, IQ-Insights provides AI schedule analytics in plain English, including schedule comparisons and float analysis, so your team starts each review with the changes already surfaced. When a project needs more hands, Hire a Scheduler adds remote scheduling support alongside your team.
But the checklist above works on its own. If you adopt nothing else from this post, standardize the comparison and separate "what changed" from "what it means." Your next update review will be faster.
A useful next step
Pick your last two schedule updates on one active project. Time how long it takes your team to answer one question: what drove the change in the finish date?
If the answer is "longer than it should," we are happy to walk through that comparison with you and show what the same review looks like when the detective work is already done. Reach out through our site and send us a schedule pair to talk through.
Ready to see IQ‑Insights in action?
Join hundreds of AEC teams already saving hours every week.