Study guide
7.2 The Change Control Process and Impact Assessment
APM Project Fundamentals Qualification PFQ
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Project Management & Operating Environment
1.1 Projects vs Business as Usual (BAU) 1.2 Programmes, Portfolios, and Strategic Alignment 1.3 Operating Environment and PESTLE Analysis
2 Chapter 2: Project Life Cycles
2.1 Linear Project Life Cycles and Phase Gates 2.2 Iterative and Hybrid Life Cycles 2.3 Extended Life Cycles, Handover, and Benefits Realization
3 Chapter 3: Roles, Governance & Organization
3.1 The Project Sponsor and Governance Board 3.2 The Project Manager and Project Team 3.3 Users, Product Owners, and the Project Management Office (PMO)
4 Chapter 4: Business Case, Benefits & Stakeholders
4.1 Purpose, Content, and Roles in Developing the Business Case 4.2 Benefits Management and Value Tracking 4.3 Stakeholder Analysis and Engagement Matrix
5 Chapter 5: Project Management Plan & Estimating
5.1 Project Management Plan (PMP) and Deployment Baselines 5.2 Estimating Methods and the Estimating Funnel 5.3 Project Reporting, Variance Tracking, and Success Criteria
6 Chapter 6: Scope Definition & Breakdown Structures
6.1 Scope Management Principles in Linear vs Iterative Delivery 6.2 Product Breakdown Structures (PBS) and Work Breakdown Structures (WBS) 6.3 OBS, CBS, and the Responsibility Assignment Matrix (RACI)
7 Chapter 7: Change Control & Configuration Management
7.1 Requirements Definition and Acceptance Criteria 7.2 The Change Control Process and Impact Assessment 7.3 Configuration Management and Version Verification
8 Chapter 8: Schedule Planning & Critical Path
8.1 Scheduling Principles, Gantt Charts, and Milestones 8.2 Critical Path Analysis, Dependencies, and Float 8.3 Time Boxing and Iterative Schedule Control
9 Chapter 9: Resource Optimization & Procurement
9.1 Resource Optimization: Allocation, Smoothing, and Levelling 9.2 Procurement Strategy and Supplier Selection 9.3 Contract Types and Supplier Reimbursement Methods
10 Chapter 10: Risk and Issue Management
10.1 Principles of Risk Management and the Risk Process 10.2 Threat and Opportunity Response Strategies 10.3 Risk Registers, Ownership, and Risk vs Issue Distinction 10.4 Issue Management Process, Escalation, and Governance
11 Chapter 11: Quality Management & Project Reviews
11.1 Quality Definitions, Management, and Quality Planning 11.2 Quality Assurance vs Quality Control 11.3 Project Reviews, Decision Gates, and Audits
12 Chapter 12: Project Communication Management
12.1 Principles of Project Communication and Communication Models 12.2 Communication Methods: Advantages, Limitations, and Barriers 12.3 Developing and Benefiting from a Project Communication Plan
13 Chapter 13: Leadership, Teams & Conflict
13.1 Leadership Styles and Influencing Team Performance 13.2 Team Development Models: Tuckman and Belbin 13.3 Team Challenges, Conflict Resolution, and Collaboration
7.2 The Change Control Process and Impact Assessment
Key Takeaways Explain This Topic AI
Change control is the formal governance process that ensures all proposed modifications to an approved project baseline are captured, evaluated, approved, rejected, or deferred.
Project change control (governing baseline adjustments) is fundamentally distinct from organizational change management (supporting people and culture through business transition).
BoK7 lists six steps to control change: log change request, initial evaluation, detailed evaluation, recommendation, update plans and implement — "recommendation" is a named step and is frequently the answer to "which of the following is an activity in a typical change control process?".
A rigorous impact assessment evaluates proposed changes holistically across the Triple Constraint and broader project dimensions: Time, Cost, Quality, Scope, Risk, and Business Benefits.
Governance relies on defined tolerances; changes within delegated tolerance can be decided by the project manager, while baseline breaches require escalation to the Project Sponsor or Change Control Board (CCB).
Last updated: September 2026
7.2 The Change Control Process and Impact Assessment
Definition (APM BoK7): Change control is the process through which all requests to change the baseline of a project, programme or portfolio are identified, evaluated and approved, rejected or deferred . The BoK7 glossary phrases the same idea as requests being "captured, evaluated and then approved, rejected or deferred" .
BoK7 also warns not to confuse change control with the wider discipline of change management , "the overarching approach taken in an organisation to move from the current to a future desirable state" . Change control is a subset of change management — "it is useful to not mix up the language".
Projects are conducted in dynamic, evolving environments. Unforeseen ground conditions in civil engineering, shifting regulatory statutes, emerging technical discoveries, or revised client priorities make change an inevitable reality of project delivery. However, unmanaged change is fatal to project success. When changes occur ad hoc without formal evaluation, projects suffer from uncontrolled scope creep, cost overruns, missed deadlines, and compromised safety.
The purpose of Change Control is not to prevent change from occurring, but to ensure that every proposed modification to the approved project baseline is captured, systematically evaluated for its total impact, and subjected to informed decision-making by authorized governance bodies before any work proceeds.
Change Control vs Organizational Change Management
A critical distinction tested on the APM PFQ examination is the fundamental difference between Change Control (project baseline control) and Change Management (organizational / business change management). +-----------------------------------------------------------------------------------------+
- | CHANGE CONTROL VS CHANGE MANAGEMENT |
- +-----------------------------------------------------------------------------------------+
- | PROJECT CHANGE CONTROL | ORGANIZATIONAL CHANGE MANAGEMENT |
- | - Focus: Project Baselines & Scope | - Focus: People, Culture & Behaviors |
- | - Governs: Time, Cost, Quality, Deliverables | - Governs: Adoption, Training, BAU |
- | - Tools: Change Requests, Change Log, CCB | - Tools: Kotter, ADKAR, Stakeholder |
- | - Target: Protects project performance | - Target: Ensures business benefits |
- +-----------------------------------------------------------------------------------------+
- 1. Project Change Control
Project change control is an internal project governance mechanism focused on the Performance Measurement Baseline (PMB) —comprising approved scope, schedule, budget, and quality specifications. It establishes formal procedures for requesting, assessing, and authorizing alterations to what the project team is committed to deliver.
2. Organizational Change Management
Organizational change management focuses on the human, behavioral, and cultural transition required to embed project deliverables into Business as Usual (BAU) operations. Delivering a new digital system, hospital wing, or automated manufacturing line is useless if employees resist using it, operate with old habits, or refuse to adopt new workflows. Organizational change management employs behavioral models (such as John Kotter's 8-Step Change Model, Lewin's Change Model, or Prosci's ADKAR framework) to address user anxiety, conduct stakeholder communication, deliver training, overcome resistance, and sustain organizational benefits realization.
Dimension Project Change Control Organizational Change Management
Primary Focus Maintaining baseline integrity (scope, time, cost, quality). Transitioning people, culture, and organizational behaviors.
Core Subject Documents, contracts, specifications, schedules, budgets. Human stakeholders, operational staff, organizational structures.
Governance Authority Project Manager, Change Control Board (CCB), Sponsor. Business Change Managers (BCMs), Sponsor, Line Managers, HR.
Key Mechanisms Change Requests, Change Logs, Impact Assessments. Stakeholder engagement plans, training programs, pulse surveys.
Primary Risk Scope creep, unbudgeted expenditure, delivery delay. User resistance, shelfware, failure to realize business benefits.
The Stages of a Typical Change Control Process
Assessment criterion 5.7 asks you to "outline the stages in a typical change control process". BoK7 names six steps that the project professional implements to control change, and exam questions are written from these names — particularly recommendation , which candidates often miss because generic change-control diagrams fold it into "approval". +---------------------------------------------------------------------------------------------------+
- | 1. LOG CHANGE -> 2. INITIAL -> 3. DETAILED -> 4. RECOMMEND- -> 5. UPDATE -> 6. IMPLEMENT |
- | REQUEST EVALUATION EVALUATION ATION PLANS |
- +---------------------------------------------------------------------------------------------------+
BoK7 step BoK7 wording
Log change request "A change register (or log) records all changes identified or requested from whatever source and whatever their status."
Initial evaluation "The change is reviewed to consider if it is worthwhile evaluating in detail or should be rejected."
Detailed evaluation "Considering the impact on baseline success criteria, benefits, scope, quality, time, resources, costs, risks, stakeholder engagement or any other criteria important to achieving the business case."
Recommendation "Is made to the sponsor and/or wider governance board to approve, reject or defer the change. The sponsor is accountable for ensuring a decision is made and communicated."
- Update plans "If a change is approved, plans are updated to reflect the change."
- Implement "The necessary actions and monitor through to completion."
BoK7 adds two practical points: where change has been implemented without formal authorisation , the project professional adopts a retrospective process so that forecasts remain realistic; and in some circumstances it is appropriate to impose a change freeze , defined in the glossary as "a point after which no further changes to scope will be considered".
The walkthrough below expands those six steps into the practical stages a project team actually runs. +-----------------------------------------------------------------------------------------+
- | THE PRACTICAL CHANGE CONTROL WORKFLOW |
- +-----------------------------------------------------------------------------------------+
- | 1. REQUEST --> 2. LOG --> 3. IMPACT ASSESSMENT --> 4. EVALUATE & DECIDE --> 5. IMPLEMENT |
- +-----------------------------------------------------------------------------------------+
- Stage 1: Request (Raising the Change Request)
Any project stakeholder—including the client, sponsor, project team member, external contractor, or end-user—may identify a potential change. The originator must submit the proposal formally by completing a standardized Change Request (CR) form. Verbal, informal, or "corridor" requests are strictly prohibited.
A formal Change Request captures:
- The unique title, date, and originator's identity;
- A comprehensive description of the proposed modification;
The fundamental justification / rationale (e.g., technical necessity, regulatory compliance, client enhancement, cost reduction);
Proposed urgency or deadline for decision.
Stage 2: Log (Recording in the Change Register)
The project manager or project support office (PMO) receives the Change Request and immediately enters it into the Change Log (also known as the Change Register). Logging guarantees accountability and visibility, ensuring that no request is misplaced or forgotten.
The Change Log records:
- Unique tracking identifier (e.g., CR-2026-089 );
- Date submitted;
- Originator and designated lead assessor;
Current status (e.g., Logged, Under Assessment, Awaiting Decision, Approved, Rejected, Deferred, Implemented, Closed).
Stage 3: Impact Assessment (BoK7 initial evaluation, then detailed evaluation)
BoK7 splits this into two: an initial evaluation that decides whether the request is even worth evaluating in detail or should be rejected outright, and then a detailed evaluation of the impact. The project manager, supported by technical leads, estimators, schedulers, and risk analysts, conducts a thorough, multidisciplinary Impact Assessment . The cardinal rule of impact assessment is that changes must never be viewed in isolation; a seemingly trivial technical adjustment can trigger severe repercussions across the entire project.
The impact assessment evaluates the proposal against the Triple Constraint and broader project parameters:
Scope: How does this change modify the WBS, product descriptions, and technical specifications?
Schedule (Time): Does the change alter activities on the Critical Path? What is the net impact on key milestones and final completion date?
Cost (Budget): What are the direct costs (materials, subcontractor fees, labor hours) and indirect costs (contingency consumption, software licenses)?
Quality: Does the modification enhance, degrade, or introduce risk to the quality and performance thresholds of deliverables?
Risk: What new secondary threats or opportunities are introduced? Does it alter existing risk profiles?
Business Case & Benefits: Does the change improve, delay, or undermine the return on investment (ROI) or strategic benefits justified in the business case?
Alternative Options: Does a lower-cost or faster alternative exist that fulfills the underlying need?
Stage 4: Recommendation and Decision (Governance Review)
The project manager makes a formal recommendation — BoK7’s fourth named step — to the sponsor and/or wider governance board to approve, reject or defer. BoK7 is explicit that "the sponsor is accountable for ensuring a decision is made and communicated" . The completed Change Request, accompanied by its detailed impact assessment and that recommendation, is submitted to the designated Change Authority . Depending on established project tolerances, this authority is typically the Project Sponsor or the Change Control Board (CCB) .
The Change Authority reviews the proposal against the strategic priorities of the business and makes one of four formal decisions:
Approve: The change is accepted as proposed. The baseline will be adjusted, and additional time and funding will be allocated.
Reject: The change is formally dismissed. The project continues strictly according to the existing baseline. The rationale for rejection is documented and communicated to the originator.
Defer: A decision is postponed until a future date or milestone (e.g., awaiting regulatory clarification or Phase 2 delivery).
Request for Information (RFI): The submission is returned to the project team because the impact assessment was incomplete or further technical analysis is required.
Stage 5: Implement and Update (Baselining and Action)
Once a change is approved, the project manager takes concrete steps to operationalize the decision:
Update Baselines: Re-baseline the Project Management Plan (PMP), including the Scope Statement, WBS, WBS Dictionary, Schedule (Gantt chart), and Cost Baseline;
Update Governance Registers: Record the decision and date in the Change Log; update the Risk Register and Requirements Traceability Matrix (RTM);
Issue Work Authorizations: Issue revised work orders, work packages, and contractor contract amendments;
Communicate: Formally inform the originator, team members, suppliers, and key stakeholders of the approved change;
Execute and Verify: The project team carries out the work under updated baseline controls and validates the completed deliverable against revised acceptance criteria.
Change Control Stages: Inputs, Activities, and Outputs
Stage Primary Inputs Core Activities Key Outputs Lead Roles
1. Request Identified issue, new requirement, regulation, defect report. Complete formal Change Request (CR) form with rationale. Completed Change Request (CR). Originator (Client, User, Team).
2. Log Completed Change Request. Assign unique ID, log in Change Register, assign assessor. Updated Change Log / Register. Project Manager / PMO.
3. Impact Assessment (BoK7: initial evaluation, then detailed evaluation) Change Request, PMP, Schedule, Cost Baseline, Risk Register. Screen out non-starters, then evaluate impact on success criteria, benefits, scope, quality, time, resources, costs, risks and stakeholder engagement. Detailed Impact Assessment. Project Manager & Technical Specialists.
4. Recommendation & Decision (BoK7: recommendation) Change Request + Impact Assessment report. Project manager recommends approve / reject / defer; Change Authority decides; sponsor is accountable for ensuring a decision is made and communicated. Formal Decision Record (Approved / Rejected / Deferred / RFI). Project Manager; Change Authority (Sponsor / CCB).
5. Implement & Update Approved Change Record, original baselines. Re-baseline PMP, update WBS & RTM, issue work orders, execute. Revised Baselines, Contract Amendments, Closed Log Entry. Project Manager & Delivery Team.
Delegated Authority, Tolerances, and the CCB
To prevent governance paralysis, projects do not submit every microscopic change to executive leadership. Instead, projects operate using a framework of delegated authority and tolerances . +-----------------------------------------------------------------------------------------+
- | DELEGATED AUTHORITY TIERS |
- +-----------------------------------------------------------------------------------------+
- | STEERING COMMITTEE / EXECUTIVE --> Strategic scope, business case viability, contracts|
- | CHANGE CONTROL BOARD (CCB) --> Cross-functional baseline changes outside PM bounds|
- | PROJECT SPONSOR --> Budget & schedule tolerance consumption |
- | PROJECT MANAGER --> Minor changes within delegated tolerances |
- +-----------------------------------------------------------------------------------------+
- Understanding Tolerances
Tolerances are the permissible boundaries of variance agreed between the Project Sponsor and the Project Manager regarding project constraints. Tolerances are defined in the Project Management Plan across key dimensions:
- Time Tolerance: e.g., ±2 weeks against intermediate delivery milestones;
- Cost Tolerance: e.g., ±5% or £25,000 spend variance against the cost baseline;
Scope / Quality Tolerance: e.g., acceptable technical parameter variations.
If a proposed change can be absorbed entirely within the Project Manager's delegated tolerance without impacting final milestone dates, exceeding allocated contingency funds, or altering agreed quality, the Project Manager is authorized to approve and execute it directly.
However, the moment a change is forecast to breach tolerance , the Project Manager has an inescapable duty to escalate the decision to the Project Sponsor or the Change Control Board.
The Change Control Board (CCB)
On complex or multi-stakeholder projects, the authority to approve baseline modifications is vested in a Change Control Board (CCB) . The CCB is a formally constituted committee comprising key project governance representatives:
- Project Sponsor (or designated Chair): Holds financial accountability and ultimate business case authority;
- Project Manager: Presents impact assessments and implementation logistics;
- Senior User Representative: Evaluates operational impact, usability, and training implications;
Senior Supplier / Technical Lead: Evaluates technical viability, engineering safety, and supply chain capacity;
Finance / Commercial Officer: Ensures contractual terms and capital reserves are respected.
Emergency Change Protocols
In rare instances (e.g., severe health and safety risks, structural failure, critical cybersecurity breaches), immediate action is required before formal CCB assembly can take place. In such emergencies, the Project Manager is empowered to execute immediate remedial action to protect life, asset, and environment. However, the formal change control paperwork, retroactive impact assessment, and baseline ratification must be completed immediately following stabilization.