22.4 Recommending Decisions and Updating Plans

The last two outcomes of the syllabus close the loop. Outcome 24d asks you to understand how to justify recommendations about whether to approve, reject or defer changes; outcome 24e asks you to understand the importance of updating plans and schedules to reflect and communicate changes. Together they cover the decision and everything that must follow it — because an approved change that never reaches the plan has not actually been made.

Justifying recommendations: approve, reject, or defer

The recommendation stage converts evaluation into a clear proposal for the decision authority (project manager within limits, CCB, product owner within product authority, sponsor/board when tolerances or business case are threatened).

Approve

Justify approval when evidence shows the change:

• Improves alignment with objectives, benefits, compliance, or risk position enough to warrant the impact
• Is feasible within (or with authorised stretch of) time, cost, and resource constraints
• Has acceptable residual risk after planned responses
• Has a clear implementation path and configuration update plan
• Sits within the delegated authority of the person/body approving — or is correctly escalated

Conditions often strengthen approval: "approve subject to extra testing," "approve only for pilot sites," "approve if supplier variation is capped."

Reject

Justify rejection when:

• Value does not justify cost, delay, or risk
• The change conflicts with strategy, mandated constraints, or the business case
• It duplicates existing scope or is better handled outside the project
• Information remains insufficient after reasonable requests for clarity
• It would breach legal, safety, or ethical obligations (or attempt to bypass them)

Rejection should be reasoned and recorded, not personal. Offer alternatives where helpful (defer, smaller option, BAU process change) so stakeholders see fairness.

Defer

Justify deferral when:

• Timing is wrong (e.g. freeze period before go-live, await regulatory clarification, await funding gate)
• Dependencies are missing (data, supplier, design decisions)
• Capacity is better used on higher-priority critical path work now, but the idea retains merit later
• More information is needed by a defined date (deferral is not indefinite neglect)

Deferral needs a review trigger (date, event, or gate). Open-ended "maybe later" without ownership becomes a hidden backlog of unmanaged expectation.

Escalation and authority

Recommendations must match governance:

• Within PM tolerance → decide and record
• Within CCB / change authority → recommend with options
• Breaks time/cost/benefit tolerances or strategic fit → escalate to sponsor/board with a decision pack

A change control board reviews significant requests and decides or recommends within delegated authority; it does not replace the sponsor’s accountability for the business case.

Scenario C — justified deferral

Three weeks before a regulated cutover, a department requests a major UI redesign. Detailed evaluation shows high retest burden and risk to the compliance date. Recommendation: defer the redesign to the next release, keep the baselined UI for cutover, and schedule a discovery spike post-go-live. Justification: protecting mandatory benefits and compliance outweighs discretionary usability gains in this window. Record the deferral with a review date so the requester is not ignored.

Updating plans, schedules, and communication

Approval without re-planning is incomplete change control. Once a change is authorised:

1. Update the schedule — activities, dependencies, milestones, resource assignments.
2. Update cost baseline / budget and any contract variations.
3. Update scope and requirements baselines and traceability links.
4. Update risk and issue registers for new or changed exposure.
5. Update quality, test, and training plans so acceptance still matches the product.
6. Update configuration records — versions, status accounting, related CI links.
7. Update benefits forecasts if value or timing changed.
8. Communicate the new baseline to the team, suppliers, stakeholders, and operations as needed.

Why this matters

• Control: progress is measured against the current authorised plan.
• Coordination: multi-discipline teams and suppliers stop working to obsolete instructions.
• Assurance: reviewers can see that approved changes were incorporated.
• Morale and trust: people hear decisions officially rather than through rumour.
• Handover: BAU receives the product that was actually agreed, not an oral history.

Communication should be proportionate and targeted: a one-line CR close notice may suffice for a tiny text change; a milestone move needs sponsor confirmation, supplier notices, and user communications. State what changed, from when, who is affected, and where the new baseline lives.

Scenario D — approved but not re-baselined

A CCB approves a two-week extension and extra interface work. Nobody updates the schedule or budget. Weekly reports still show the old milestone as "amber" for unexplained reasons; finance still holds the old cost baseline; testers build scripts for the pre-change scope. Implementation becomes chaotic. Correct close-out: update plans and baselines, reissue the schedule, adjust EVM baselines if used, brief suppliers, and only then treat the CR as ready for controlled implementation and closure.

Link to requirements and configuration management

Change control decisions and configuration management are tightly coupled:

• Requirements management establishes and baselines need; change control decides whether baselined requirements may change.
• Configuration control ensures products and documents are updated to the authorised version after a decision.
• Status accounting records which CR affected which configuration item and what the current approved state is.
• Verification/audit confirms as-built matches the post-change baseline before gates or handover.

If change control approves but configuration records lag, the project has a paper truth and a physical truth that diverge — a classic exam scenario for failed handover.

Implementation checklist (exam-friendly)

1. Confirm decision and conditions are recorded on the CR.
2. Update baselines and integrated plans.
3. Update configuration items and withdraw superseded versions from use.
4. Brief those who must act differently.
5. Implement and verify (including tests/acceptance as needed).
6. Close the CR with evidence; capture lessons if material.

Common exam traps

• Treating change control as automatic rejection of all change.
• Assessing only cost or only the requester’s preference.
• Approving without authority or without plan updates.
• Confusing defer with ignore.
• Ignoring benefits, risk, and stakeholders in impact assessment.
• Separating change decisions from configuration updates.
• Assuming iterative backlog movement replaces control of baselined commitments.

Answer pattern for long-response questions

1. Capture/log the change request with essential content.
2. Assess impact across key dimensions and compare options.
3. Recommend approve, reject, or defer with justification against objectives, business case, risk, and authority.
4. If approved, update plans/schedules/baselines and communicate.
5. Implement under configuration control and close with evidence.

That structure covers LO24(b)–(e): request content, options and impact assessment, justified recommendations, and the importance of updating and communicating plans after change.