Update the programme and reforecast

Pull the real progress off the site: hours booked, the daily diary, what each gang actually finished this week. Get it from the people doing the work, not from a guess made in the office.

Why: A reforecast is only as honest as the numbers going into it. Taking progress straight from field time and the diary is what stops the update becoming wishful thinking.

Go through the activities that were live and set each one honestly: done, part done with a real percentage, or not started. Update remaining durations where a task is running slower or faster than planned.

Why: Rounding a job up to done when it is at eighty percent is how programmes drift and everyone stops trusting them. Marking progress honestly is what keeps the schedule worth reading.

Let the schedule roll the actuals through the logic and recalculate. Read the new forecast finish, watch how the critical path has shifted, and see which activities have now pulled the completion date with them.

Why: The value of a live programme is that it tells you where you will land, not just where you have been. Reforecasting off real progress is what turns last week numbers into a decision you can act on.

Compare the reforecast to the baseline you locked and pick out where the job has slipped: which milestones have moved, how much float has been eaten, and which delays trace back to a change rather than to production.

Why: Knowing you are late is not enough, you have to know why and whose account it sits on. Tying slippage back to changes is what protects an extension of time claim before the delay is forgotten.

Issue the updated forecast to the client and the team with the reasons written plainly: what moved, by how much, why, and what is being done to pull it back. Keep it short enough that people actually read it.

Why: A forecast that stays on the planner screen changes nothing. Reporting it clearly, with the reasons, is what lets the client trust the number and lets the team agree the recovery before the next cycle.