7.3 Why Activities Are Re-Planned After a Review
Key Takeaways
- A review that never changes the plan is a reporting ritual rather than a control; re-planning is how review findings take effect.
- Triggers include emerging estimate accuracy, materialised risks, moved dependencies, approved change, resource shifts, benefit forecast changes, and assurance findings.
- Re-planning within tolerance is delivery management; re-planning that breaches a baseline requires change control and the correct approval authority.
- The approved baseline must stay visible so cumulative variance can be seen rather than reset each reporting period.
- Re-plan the whole picture — dates, resources, cost, dependencies, and benefits together — or the revised plan will fail at the next review.
Outcome 6d is a single line — understand why activities may be re-planned after a review — and it is the outcome that turns reviewing from a reporting ritual into a control. A review that never changes anything is not governance; it is minutes.
Why Activities May Be Re-Planned After a Review
Re-planning after a review is not a sign that the project "failed the meeting." It is often correct control. Activities are re-planned when review evidence shows the current plan is no longer a reliable route to objectives.
Common triggers:
| Review finding | Why re-planning follows |
|---|---|
| Schedule or cost forecast exceeds tolerance | Baselines, resource loading, or sequence must change |
| Critical risk materialises or rises | Contingent actions, buffers, or alternative approaches are needed |
| Scope or priority change approved | Work packages, backlog order, and dependencies must be rewritten |
| Quality/acceptance shortfalls | Rework, extra testing, or design change enters the plan |
| Business case weakened | Descope, resequence benefits-critical work, or prepare stop options |
| Gate conditions imposed | Conditional go requires new activities before full next-stage entry |
| Dependency failure (supplier, regulator, BAU) | Interface dates and critical path change |
| Benefits review shows low adoption | Transition, training, process, or product fix work is added |
Re-planning should update the integrated picture — schedule, resources, cost, risk, quality, and benefits — not only one Gantt bar. After re-plan, communicate the new baseline or iteration plan and reset reporting against it so the next review measures the right thing.
Scenario A — decision gate
A local authority digital project reaches a deployment gate. Progress is 90% of planned build, but user acceptance testing shows high defect density, the cost forecast is +14% against a 10% tolerance, and the benefits case assumed contact-centre savings that operations no longer endorse. The board should not treat "nearly finished" as automatic go. Appropriate actions: require a re-plan focused on defect clearance and a benefits revalidation with operations; approve only a conditional next step; or pause further spend until viability is restored. Communicating that decision to suppliers and the team prevents further work on unstable features.
Scenario B — benefits review
Six months after handover of a warehouse management system, throughput benefits are half the business-case figure because night-shift staff were never trained on the exception process. A benefits review identifies the gap, assigns operational owners, and feeds corrective actions. The project may already be closed, but the organisation still re-plans BAU activities — and may raise a small follow-on change — because reviews protect outcomes, not just project administration.
Scenario C — audit
An internal audit finds that supplier variations above the project manager’s financial authority were approved informally by email. Findings escalate to the sponsor. Delivery continues, but the plan now includes retrospective change control, contract regularisation, and a control check before the next gate. The audit did not replace the project manager; it forced governance back into the plan.
Answer Pattern for Long-Response Questions
When a PMQ scenario mentions a review:
- Name the review type (gate, benefits review, audit, or routine management review) and its purpose.
- State the information/data decision makers need.
- State the decision options (continue, conditional continue, re-plan, stop).
- Explain who must be informed and what actions they own.
- If the plan is no longer valid, explain why re-planning is required and what integrates into the new plan.
That chain matches LO6: reviews assess status and viability; reporting supports outcomes; data enables decisions; communication makes decisions real; re-planning restores a credible path to success.
Re-planning is a consequence of reviewing, not an admission of failure
State this explicitly in written answers, because the instinctive framing — "we had to re-plan, so something went wrong" — misses the syllabus point. Reviews exist to surface new information. If new information never changed the plan, collecting it would be pointless.
Legitimate re-planning triggers a review can surface:
| Trigger found at review | Typical re-planning response |
|---|---|
| Estimates proved optimistic as detail emerged | Re-estimate remaining work; reforecast dates and cost |
| A risk has materialised into an issue | Insert response activities; consume contingency; reforecast |
| A dependency moved outside the project's control | Resequence; add float; escalate the interface |
| Scope changed through approved change control | Rebaseline affected activities and resources |
| Resource availability changed | Re-level or re-smooth; renegotiate priority through governance |
| Benefits forecast shifted | Re-prioritise scope towards the benefit that still holds, or escalate viability |
| Assurance found a control gap | Add assurance, testing, or documentation activities |
Re-plan properly, or not at all
Poor re-planning is worse than none, because it destroys the ability to measure anything. Three disciplines matter:
- Change the plan through the right authority. Re-planning inside tolerance is delivery management; re-planning that breaches a baseline needs change control and, beyond delegated limits, sponsor or board approval.
- Keep the old baseline visible. If the plan is silently overwritten every month, nobody can see cumulative slippage — each report looks like a fresh start. Retain the approved baseline and report variance against it.
- Re-plan the whole picture. Moving a date without re-checking resources, cost, dependencies, and benefits produces a plan that is internally inconsistent and fails at the next review.
For a five-mark answer: name the trigger the review surfaced, the re-planning action, the authority needed, and the effect on the baseline and the business case.
Why may project activities need to be re-planned after a formal review?
After each monthly review a project manager updates the schedule so the plan always shows the current forecast, and does not retain the previously approved baseline. What is the main problem with this practice?