How to review a 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 distort float on everything downstream without leaving a trace.
• 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 the previous 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 update 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 period 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 period'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 the next update'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. A ratio above 1.0 is a screening heuristic, not proof: legitimate SS/FF overlap produces it too. What it earns is a question the update has to answer, namely what production rate the stacking assumes and who agreed to it. This single number, read alongside the 600-day test, 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 period 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 swapped without anyone saying so.

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 period'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 update review is the only chance to meet it while the facts are still cheap to establish.