Study guide
22.4 Recommending Decisions and Updating Plans
APM Project Management Qualification PMQ
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Exam Format & Question Types 1.3 How to Study for APM PMQ
2 Life Cycles
2.1 Linear Life Cycles and Why Work Is Phased 2.2 Iterative and Hybrid Life Cycles 2.3 Project Life Cycles and Extended Life Cycles 2.4 Choosing a Life Cycle: Context, Culture, Strengths and Limitations
3 Governance Arrangements
3.1 Functional, Matrix and Projectised Structures 3.2 Governance Frameworks, Policies and Delegated Responsibility 3.3 Life-Cycle Impact on Governance and Limits of Financial Authority 3.4 Project Roles and Responsibilities 3.5 Project Manager and Project Sponsor Through the Life Cycle 3.6 Linking Projects to Organisational Objectives
4 Sustainability
4.1 Sustainability Responsibilities, Principles and Impact 4.2 Monitoring and Reporting Sustainability Measures
5 Business Case
5.1 Business Case Fundamentals and Analysis Tools 5.2 The Business Case as Baseline and Reviewing Change
6 Procurement
6.1 Procurement Strategy: Purpose and Contents 6.2 Supplier Selection and Negotiation 6.3 Features of Different Contractual Relationships 6.4 Supplier Reimbursement Methods
7 Reviews & Assurance
7.1 Reviews, Decision Gates, Benefits Reviews and Audits 7.2 What Gets Reported and Informing Decisions 7.3 Why Activities Are Re-Planned After a Review 7.4 Project Assurance
8 Transition & Benefits Management
8.1 Transition Requirements and Business-as-Usual Readiness 8.2 Knowledge Transfer and Agreeing the Transition Plan 8.3 Benefits Management: Identification to Realisation 8.4 Aligning and Communicating Benefits
9 Stakeholder Engagement & Communication
9.1 Stakeholder Analysis, Influence and Engagement 9.2 The Communication Management Plan and Its Benefits 9.3 Managing Stakeholder Expectations 9.4 Communication Methods and Tailoring the Message 9.5 Factors That Help and Hinder Communication
10 Conflict Resolution
10.1 Sources and Impacts of Conflict 10.2 Addressing Conflict and the Thomas-Kilmann Model
11 Leadership
11.1 Leadership, Motivation and Team Performance 11.2 Changing Leadership Styles for the Situation 11.3 Coaching, Mentoring and Emotional Intelligence
12 Team Management
12.1 Team Development Stages and Models 12.2 Characteristics and Benefits of Effective Teams 12.3 Leading Virtual and Hybrid Teams
13 Diversity & Inclusion
13.1 Diversity Characteristics and the Equality Act 13.2 Incorporating Diversity and Diverse Thinking 13.3 Conscious and Unconscious Bias and Fair Treatment
14 Ethics, Compliance & Professionalism
14.1 Continuing Professional Development and Competence 14.2 Sources of Specialist Advice and Standards 14.3 The Legal and Regulatory Landscape
15 Requirements & Solutions
15.1 Establishing Scope Through Requirements Management 15.2 Managing Scope Through Configuration Management 15.3 Solutions Development and Prioritisation
16 Quality Management
16.1 Quality Planning, Indicators and the Business Case 16.2 Quality Control and Success Criteria
17 Integrated Planning
17.1 The Integrated Project Management Plan: Format and Contents 17.2 Why an Integrated Plan Matters
18 Schedule Management
18.1 Defining Scope and Breakdown Structures 18.2 Dependencies and What Drives the Schedule 18.3 Re-Estimating and Schedule Optimisation
19 Resource Management
19.1 Determining Resource Requirements and Availability 19.2 Organisational Breakdown Structure and RACI 19.3 Categorising and Allocating Resources 19.4 Resource Smoothing and Resource Levelling
20 Budgeting & Cost Control
20.1 Creating a Budget and Cost Types 20.2 Earned Value and Cost Forecasting 20.3 Monitoring and Reporting Financial Performance 20.4 Closing Down Project Finances
21 Risk & Issue Management
21.1 Benefits of Risk and Issue Management and Contingency Planning 21.2 The Risk and Issue Management Processes 21.3 Proactive and Reactive Risk Responses 21.4 Governance in Risk and Issue Management
22 Change Control
22.1 The Change Control Process and Its Stages 22.2 What a Change Request Must Capture 22.3 Assessing Options and the Impact of a Change 22.4 Recommending Decisions and Updating Plans
22.4 Recommending Decisions and Updating Plans
Key Takeaways Explain This Topic AI
A recommendation must be justified by evidence — impact, options, benefits, and risk — rather than asserted as a preference.
Approve, reject, and defer are all legitimate recommendations; deferral is a decision with a stated interim risk, not indecision.
The recommendation goes to the authority whose delegated limits cover the change, which is why financial authority and tolerances matter here.
An approved change must be written into the plans, schedule, budget, risk register, and configuration records, or the baseline no longer matches reality.
Changes must be communicated to everyone affected, including suppliers and operational teams, or people continue working to superseded instructions.
Last updated: August 2026
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.
Decision Strong justification includes Weak justification
Approve Impact vs value, residual risk, authority, implementation plan "Sponsor likes the requester" with no impact evidence
Reject Objective conflict, poor value, unacceptable risk, out of mandate Silence, or "we never change anything"
- Defer Timing logic, dependencies, review date/owner Parking indefinitely to avoid a difficult conversation
- 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:
Update the schedule — activities, dependencies, milestones, resource assignments.
Update cost baseline / budget and any contract variations.
Update scope and requirements baselines and traceability links.
Update risk and issue registers for new or changed exposure.
Update quality, test, and training plans so acceptance still matches the product.
Update configuration records — versions, status accounting, related CI links.
Update benefits forecasts if value or timing changed.
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)
Confirm decision and conditions are recorded on the CR.
Update baselines and integrated plans.
Update configuration items and withdraw superseded versions from use.
Brief those who must act differently.
Implement and verify (including tests/acceptance as needed).
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
Capture/log the change request with essential content.
Assess impact across key dimensions and compare options .
Recommend approve, reject, or defer with justification against objectives, business case, risk, and authority.
If approved, update plans/schedules/baselines and communicate .
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.