22.2 What a Change Request Must Capture

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.2 What a Change Request Must Capture

Key Takeaways Explain This Topic AI

A change request records a unique reference and date, who raised it, the description, the justification, priority, affected configuration items, assessed impact, options, recommendation, the decision and decision maker, and implementation status.

A request that states what is wanted without stating why cannot be evaluated, because there is nothing to weigh the cost against.

The decision record — who authorised what and when — is what allows the project to explain later why a baseline moved.

Assessed impact must span cost, schedule, scope, quality, risk, resources, and benefits, not cost alone.

Rejected and deferred changes stay on the log with their reasons, which prevents re-raising, manages expectations, and preserves the analysis if circumstances change.

Last updated: August 2026

Outcome 24b is deliberately narrow: know what should be captured and recorded in change requests . It is a knowledge outcome, which means it can be tested as a short-response "list" item as easily as in a long response — so learn the content list precisely.

From request content to controlled implementation

Section 16.1 covered the stages of change control. This section deepens what examiners test next: what goes in a change request , how to assess impact and options , how to justify approve / reject / defer , and why updating plans and communicating is part of control — not optional admin. It also links change control to requirements and configuration management so decisions stay consistent with what is actually built and recorded.

What should be captured in a change request

A change request (CR) is the controlled record of a proposed change. Poorly completed requests force guesswork; well-completed requests enable fast, fair evaluation.

• Field / content Why it is needed
• Unique ID and date raised Traceability, ageing, and audit
• Requester and role Ownership of clarification; stakeholder context
• Clear description of the proposed change Everyone evaluates the same proposal
• Rationale / business justification Links to value, compliance, risk reduction, or problem solved
• Related baseline items Requirements IDs, WBS elements, configuration items, drawings, backlog items
• Category / type Scope, technical, commercial, regulatory, defect vs enhancement (as used by the organisation)
• Priority and urgency Supports triage; separates "nice soon" from "safety now"
• Known constraints and deadlines External go-live, legal dates, supplier notice periods
• Initial estimate of impact (if known) Starting point for evaluation — not a substitute for detailed assessment
• Attachments / evidence Specs, incident logs, customer feedback, regulatory notices
• Status and decision fields Proposed → under evaluation → approved/rejected/deferred → implemented/closed
• Decision record Who decided, when, conditions, and rationale
• Quality of the request

Describe the change in outcome terms where possible ("retain personal data for seven years to meet regulation X") not only a vague solution ("make the system better").

Separate defect correction (product does not meet baselined requirement) from enhancement (new or changed need) — both may use the process, but authority and funding treatment can differ.

Record assumptions explicitly so detailed evaluation can test them.

Scenario A — incomplete request

A supplier emails "we recommend using valve type B." No ID, no impact on programme, no warranty comparison, no link to the baselined specification. Initial evaluation should return for completion , not invent missing facts. A complete CR would identify the configuration item, reason (availability, cost, performance), constraints, and any standards affected.

Why each field earns its place

A change request is not a form for its own sake. Each field exists because a decision maker cannot decide without it, or because someone later needs to reconstruct why the decision was taken.

• Field Why it is needed
• Unique reference and date Allows the change to be tracked, reported, and audited through to implementation
• Raised by Identifies who to return to for clarification and who holds the underlying need
• Description of the change States precisely what is being requested, in terms that can be evaluated
• Reason / justification Distinguishes a genuine need from a preference, and links to benefit or obligation
• Priority or urgency Determines whether it can wait for the next scheduled decision point
• Affected items / configuration items Identifies exactly which baselined items would change
• Assessed impact Cost, schedule, scope, quality, risk, resources, and benefits consequences
• Options considered Shows the decision maker the alternatives, including doing nothing
• Recommendation Gives an evidence-based professional view for the authority to accept or reject
• Decision, decision maker and date Records who authorised what, and when — the audit trail
• Implementation status Confirms the change was actually made, not merely approved
• The two fields most often missing

Reason. A request that says what without saying why cannot be evaluated, because there is no way to weigh the cost against anything. "Add a second approval step" is a preference; "add a second approval step because the regulator requires segregation of duties for payments above £50,000" is a justified requirement with a clear consequence for rejecting it.

Decision record. Approving a change verbally and implementing it without recording the decision, the decision maker, and the date leaves the project unable to explain later why the baseline moved. It also breaks the link between the change and the configuration items it altered.

Recording rejections as carefully as approvals

Rejected and deferred changes must stay on the log with their reason. Three benefits follow: the same request is not re-raised repeatedly through different routes; the requester receives an explicit answer, which is expectation management; and if circumstances change, a deferred item can be reconsidered with its original analysis intact rather than re-worked from scratch.