Reviewing a monthly schedule update in thirty minutes

The monthly update review is the most frequently performed task in project controls and the least frequently taught. Most people do it by opening the file, looking at the completion date, scrolling the Gantt for a while and forming an impression. There is a better routine, it is documented in an AACE recommended practice almost nobody reads, and it fits inside half an hour if you do the cheap disqualifying checks first.

What you are actually being asked

Be clear about the question before you open anything. You are not being asked whether this is a good schedule — that was settled, or should have been, at baseline. You are being asked two narrower things:

• Is this a truthful account of the period? Does what the file says happened match what happened?
• Is the forecast that follows from it defensible? And if the date moved, do we understand why and who owns it?

Everything in the routine below serves one of those two questions. Anything that serves neither is a baseline conversation, and belongs in a different meeting.

AACE International's RP 53R-06, Schedule Update Review, frames the task the same way: the reviewer's job is to assess the reasonableness of the changes made to the schedule as a result of the change in project status and progress. Not the schedule — the changes. That single reframing is what makes thirty minutes enough.

The order matters more than the content

Run the checks in increasing order of cost. Several of them can disqualify the submission outright, and there is no point tracing a driving path through a file that turns out to have been scheduled on a different data date than the one on the cover sheet.

Stage 0 — integrity (2 minutes)

Four things, all of which are yes/no and any of which sends the file back.

Data date. Does it match the reporting period and the cover sheet? A data date a week adrift makes every variance in the submission wrong by a week, and it happens far more often than it should.

Calendars. Have any calendar definitions changed since the last revision — working days, holidays, hours per day? A changed calendar silently rescales every duration and every float value in the file. It is the least visible material change anyone can make to a schedule.

Scheduling settings. Retained logic or progress override? Any change here between revisions makes the two incomparable, and part of any date movement is arithmetic rather than fact. The full argument is here; for the review, it is a two-second look at the options dialog and a question in the covering email if it moved.

Does it re-run clean? Reschedule on the stated data date and confirm you reproduce the submitted dates. If you do not, something in the file was edited after the last schedule run, and every date you are being asked to accept is stale.

Stage 1 — the diff (4 minutes)

This is the heart of 53R-06 and the part most reviews skip entirely. There are eleven things that can differ between two revisions, and each one has a characteristic meaning.

Doing this by eye is not realistic on a five-thousand-activity file. Do it with a comparison — P6's own Schedule Comparison, or any tool that produces a change list — and then read the list rather than the schedule. The output you want is one page: what was added, what was removed, what was re-logicked, and where the constraints moved.

Stage 2 — progress truth (5 minutes)

Four tests on the recorded progress itself.

Actuals beyond the data date. Any activity with an actual start or finish later than the data date is a data error by definition — the file is claiming something happened in the future. This is what the DCMA "invalid dates" check catches, and it should be zero.

Remaining durations on started activities. The pattern to look for is activities that started months ago and whose remaining duration has not moved. That is not progress being recorded; it is an activity that stalled and nobody adjusted. It is also, on a claim project, exactly where disruption hides.

Out-of-sequence progress. Take the count, and more importantly the trend. A stable handful is healthy. A number rising every period on the same paths, with no logic revisions, means the schedule has stopped describing the project.

Activities that should have started and did not. Filter for incomplete activities whose baseline start has passed. This is the cheapest early-warning report in project controls and it takes one filter to produce.

Stage 3 — the forecast (6 minutes)

Now, and only now, look at the answer.

Trace the driving path to the completion milestone and confirm you can follow it back to the data date without leaving the logic. If a constraint intervenes, the "critical path" is not a critical path. If the path runs through activities whose progress has been overridden, the path is conditional on a setting. If you cannot trace it at all, nothing else in this stage is meaningful — see critical path vs longest path for why the two often disagree.

Then compare the total float profile against the previous two revisions. This is the part of the review with real predictive value, because float erodes before dates move. A path with 30 days of float that falls to 18, then 6, then −4 has been telling you for three months what the completion date announced in month four.

Finally, if the completion date has moved, resolve three questions before the meeting: what moved (which path, which activities), why (progress, re-sequencing, added scope, or a change of scheduling arithmetic), and who owns it. A date movement with no attribution is a number, not a status report.

Stage 4 — quality trend (5 minutes)

Run the structural check and — this is the part that matters — compare it with the previous three revisions rather than against a threshold. Absolute scores tell you about the planner. The trajectory tells you about the project.

The pattern to watch for is quality degrading while the reported date holds. Constraints creeping up, logic density falling, negative float appearing, high-float counts rising as successors are dropped. It is the signature of a team keeping a date alive in the model that they have already lost on site, and it typically shows two to three updates before the date finally moves.

Stage 5 — the narrative test (8 minutes)

Read the narrative last, with your own findings already written down. Then apply one test: does the story explain the arithmetic, and does the arithmetic support the story?

The failures are usually asymmetric in a telling way. Narratives describe progress that the file does not show; they explain a date movement by an event the driving path does not run through; they omit the constraint that was added; they attribute a slip to a cause that lies on a path with 40 days of float. Where the two disagree, the file is the primary record and the narrative is advocacy — and noting the specific discrepancy, in writing, is the single most valuable output of the whole review. It is also the reason writing the narrative from the data rather than from memory is worth insisting on.

What to write back

Keep the response short, specific and structured so it can be answered rather than debated. Six lines is usually enough:

1. Status of the submission — accepted, or the extent to which it does not comply. Say which, and against what obligation.
2. Undeclared changes — the list, with activity IDs. Not "some constraints were added".
3. Progress items — actuals beyond the data date, stalled activities, out-of-sequence trend.
4. The forecast — driving path in one sentence, float trend in one number, date movement with attribution.
5. Quality trend — the score against the last three revisions, and what is driving the direction.
6. What you need before next period — one or two items, each actionable.

One note on tone that is also a contractual point. Under both NEC4 and FIDIC, the reviewer's obligation is generally to state the extent of non-compliance within a defined period, not simply to reject. Vague dissatisfaction is not a valid response under either form, and on FIDIC in particular, silence within the review window can amount to deemed no-objection. A specific list is both better practice and better protected.

On your own schedule: get the change list and the quality trend in one pass — two revisions in, one page out, parsed in your browser with nothing uploaded.