How to review a monthly schedule update

1. Start at the data date

Confirm the data date (status date) moved to the agreed cutoff, and that it is the same date the narrative report claims. An update statused "as at" a date different from its data date is already telling two stories. Everything else in the review hangs off this one field, which is why it is checked first rather than assumed.

2. Check the statusing is internally consistent

Three tests, all mechanical, all frequent finds:

• Actuals after the data date. An actual start or finish recorded in the future is a forecast entered as fact. Zero tolerance; each one means the statusing process slipped.
• Work stranded behind the data date. Incomplete tasks with forecast dates in the past claim work is coming that should already have happened. They also silently distort float on everything downstream.
• Out-of-sequence progress. A successor showing progress while its predecessor has not reached the state the relationship requires means the network no longer models how the work is actually being done. One or two are normal life; a pattern means the logic needs repair, and how the tool was told to handle them (retained logic versus progress override in P6 terms) changes every downstream date.

3. Find out what changed besides progress

This is the step most reviews skip, and it is where updates hide their sins. Compare the update against last month's file, not against memory: added and removed tasks, duration changes on incomplete work, logic edits, constraint changes, calendar changes. Every one of these is a re-plan decision, and each one deserves a sentence of justification in the narrative. A finish date that "held" because three durations shrank and a link quietly disappeared did not hold at all.

The tell to watch for is compensating edits: slippage on the driving path in the same month as duration cuts further down the same path. Sometimes that is genuine mitigation with a plan behind it. Sometimes it is a date being defended with the duration field. The difference is whether anyone can explain how the shorter durations will be achieved.

4. Read the float story, not just the dates

Dates are the headline; float is the ledger. Track total float on the key paths from update to update. A programme whose completion date is stable while float erodes across the board is not stable, it is spending its buffer, and the month the buffer runs out the "sudden" slip will surprise everyone except the float trend. Negative float anywhere gets the standard treatment: which constraint or commitment is it measured against, and where is the recovery plan?

5. Interrogate the critical path

Three questions, in order. Did the critical path move, and does the movement have a cause you can point to in the month's events? Does the path still make physical sense, would a builder recognise it as the true drive to completion? And what is sitting near-critical, within ten or fifteen days of float, because next month's critical path is usually on that list already. A path that jumps between unrelated scopes from update to update is a symptom of logic or constraint trouble, not of an exciting project.

6. Test the remaining plan for compression

Sum the remaining duration of incomplete critical work and set it against the working days left to the finish. Critical work is nominally sequential, so a ratio above 1.0 means it has been stacked in parallel to hold the date, and the schedule is quietly assuming a production rate nobody has agreed to. This single number catches more defended dates than any amount of staring at the Gantt view.

7. Score performance against the baseline

Missed tasks (planned to finish by now, did not), milestone variance against baseline, and a running execution ratio such as BEI. None of these predicts anything on its own; their value is the trend across updates. A programme that misses 8% of its due tasks every month has established a pace, and the forecast should reflect that pace rather than the baseline's optimism. This is also the moment to confirm the baseline itself has not been quietly swapped.

8. Re-run quality and risk on the updated file

An update is a new schedule and deserves the same structural checks the baseline got: the DCMA 14-point screen catches the month's accumulated damage (new constraints, orphaned logic from deleted tasks, statusing artefacts). If the programme carries a probabilistic commitment, refresh the Monte Carlo too. P50 and P80 drift between updates gives earlier warning than the deterministic finish, which tends to be defended long after the probability of achieving it has collapsed.

9. Write the narrative from evidence

The review is finished when every moved date has a cause, every re-plan edit has a justification, and every erosion of float has an owner. That is the standard a forensic delay analyst will hold the record to years later, and the monthly review is the only chance to meet it while the facts are still cheap to establish.