7.2 The Change Control Process and Impact Assessment

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.

---

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 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:

1. Approve: The change is accepted as proposed. The baseline will be adjusted, and additional time and funding will be allocated.
2. 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.
3. Defer: A decision is postponed until a future date or milestone (e.g., awaiting regulatory clarification or Phase 2 delivery).
4. 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

---

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.