Teams often ask for a “new programme” when the finish date is under pressure. That request is too vague. Sometimes the baseline is still right and the job is late. Sometimes the scope, method or access has changed and the old network no longer describes the work. A recovery schedule and a revised schedule are both legitimate tools. They are not interchangeable.
If you mix them up, you either paper over delay with a false acceleration story, or you quietly replace the baseline without change control. Directors then lose the one thing a schedule is supposed to protect: a comparable forecast against an agreed plan.
Two different questions
A recovery schedule answers: can we still hit the current contractual or committed finish, and what must change in sequence, resource or method to get there? The target date usually stays. The path to it does not.
A revised schedule answers: what does the programme look like after approved change, new constraints, or a formal change to the completion obligation? The network, and often the dates, move because the job itself moved.
One is a response to performance. The other is a response to change. Treating performance failure as if it were a scope revision, or treating a variation as if it were only a productivity problem, produces a file nobody can defend later.
What a recovery schedule is for
Use recovery when the approved baseline is still the right description of the work, but progress, remaining duration and the critical path show the finish is slipping. The recovery file is the honest attempt to claw time back without pretending the delay never happened.
- Re-sequence work that can safely overlap or move off the driving path.
- Add shifts, crews or temporary works only where the site can actually absorb them.
- Reduce remaining duration only with a named method change the package manager will own.
- Keep the original baseline available so variance and delay remain visible.
A recovery schedule is not a magic finish date. It is a proposal. Leadership must accept the cost, risk and access consequences. If those are refused, the forecast stays late. That outcome is clearer than a recovery programme that only exists in the Gantt chart.
What a revised schedule is for
Use a revised schedule when the work has changed in a way the current baseline cannot carry: instructed variation, design change, different access, a new sectional completion, a changed possession regime, or a contractual amendment to dates. The network must be rebuilt to match the new reality.
Under many contracts the revised programme then becomes the candidate for a new baseline, but only through the change-control or acceptance process the contract requires. Revising the live file while leaving the official baseline untouched is ordinary update practice. Calling that file a new baseline without acceptance is not.
Side-by-side: recovery vs revised
| Question | Recovery schedule | Revised schedule |
|---|---|---|
| Trigger | Late against an agreed plan | Approved change to scope, method, access or obligation |
| Target date | Usually held; path changes | May move with the change |
| Baseline status | Original baseline kept for comparison | May become the new baseline after acceptance |
| Main risk if misused | Fake acceleration; delay hidden | Silent re-baseline; variance wiped |
| What directors should demand | Named actions, cost and residual risk | Change reference, new logic, acceptance route |
When people pick the wrong one
The common error on a late job is to “revise” the programme until the finish looks healthy again, without a variation or an accepted acceleration agreement. That is not revision. It is erasure. The next claim or board review then has no clean as-planned position.
The opposite error is also common. A major design change lands, and the team tries to recover the old date with overtime alone. The network still shows the old sequence. Recovery effort is spent on a path that no longer exists. The revised schedule should have come first.
How to decide in one meeting
Ask four questions in order. Has the scope, access or contractual date obligation changed with an instruction or agreement? If yes, start with a revised schedule. If no, is the baseline still a fair description of the remaining work? If yes and you are late, build recovery. If the baseline itself is broken—open ends, fantasy durations, unconstrained float—do a schedule health repair before you call the file either recovery or revision.
Then name the owner. Recovery needs a site and commercial owner for every acceleration step. Revision needs a change reference and a clear statement of what the new baseline will be measured against once accepted.
What good recovery looks like in the file
Good recovery is specific. It names the activities that move, the resource change, the weekend or shift assumption, and the activities that cannot compress. It shows the residual near-critical paths. It states what happens if one acceleration step fails.
Bad recovery is a global productivity uplift, a hard constraint on the finish milestone, or remaining durations cut to fit the date. Software will calculate a green finish. The site will not.
What good revision looks like in the file
Good revision traces every material network change to a change event. New activities appear for new scope. Deleted scope is removed or zeroed through control, not left as floating junk. Calendars and constraints are updated for the new access story. The narrative explains which dates moved because of change and which moved because of performance.
If performance delay and change are both present, say so. You may need a revised network for the new scope and a separate recovery proposal against the dates that remain contractual. Bundling both into one unexplained “new programme” is how arguments start six months later.
Commercial and reporting consequences
Recovery without an agreement to pay for acceleration can create an unpaid cost story. Revision without acceptance can destroy the baseline you need for earned value and delay analysis. SPI and CPI against a quietly rewritten plan will look healthier while the project is not.
Directors should refuse any “new schedule” that does not state whether it is recovery, revision, or both—and which baseline remains the official comparison until acceptance.
A practical rule
If the plan is still right and the job is late, you need recovery. If the job changed, you need revision. If both happened, say both, in that order of logic: revise the network to match the work, then recover only what the contract and the site still require.
EVM Solutions builds recovery and revised programmes as part of planning and project controls support, including schedule health checks before either file is issued. If your team is about to publish a “new programme,” send the current baseline, the change log and the forecast finish first. The label on the file matters less than whether the next board pack will still be comparable to last month.
