III.3 — Manage and Control Changes
III.3 · Last updated: 11/10/2026
Change control moved to the Business Environment domain
III.3 — Manage and Control Changes is the third task in the Business Environment domain of the 2026 ECO. The domain carries 26% of the exam and holds eight tasks. The ECO attaches four enablers to this one:
- Execute the change control process
- Communicate the status of proposed changes
- Implement approved changes to the project
- Update project documentation to reflect changes
Read together, the four describe a sequence. The exam asks more than whether a change was approved; it also asks what had to happen before the decision, who needed to hear about it afterwards, and which documents had to change as a result.
In 2021 this topic sat in the Process domain, and the 2026 ECO moved it to Business Environment. PMBOK® 8 looks at it from the same angle. The Guide places the change process (Assess and Implement Changes) among the processes of the Governance performance domain and says that domain's processes run through the whole project, from initiation to closure (PMBOK® 8, Guide p.16). Seen this way, the weight of a change question shifts. How the schedule gets recalculated becomes secondary, and the question that comes forward is who has the authority to make the decision. The task's neighbors reflect that: III.1 — Define and Establish Project Governance builds the governance structure, and III.3 decides on changes inside it.
🔴 A "III.3" label can point to two different topics
| 2021 | 2026 | |
|---|---|---|
| Number | II.10 | III.3 |
| Domain | Process | Business Environment |
| Title | Manage project changes | Manage and control changes |
Because the move runs in both directions, anyone working from older material can be caught twice. The 2021 III.3 covered the impact of external business environment changes on scope, and that topic is now III.8 — Evaluate External Business Environment Changes. Meanwhile II.10, the old home of change management, went to project closure in 2026. The fact that both topics have "change" in their names makes the mix-up easier, since one is about change requests coming into the project and the other is about shifts in the world outside it. If an older question bank tags something "III.3", the title is the only reliable way to tell which one it means. The full list of these shifts is in what changed in the 2026 PMP exam.
Who can ask for a change, and what it can touch
The Guide defines a change request as a formal proposal to modify a document, a deliverable, or a baseline. It can originate inside or outside the project, and any stakeholder may request a change (PMBOK® 8, Guide pp.116-117). Answer options that assume requests can only come from the sponsor or the customer are weak for that reason.
The process isn't tied to one phase either. Because changes can arise at any stage, it stays open from start to finish, and requests can affect project scope, product scope, components of the management plan, and project documents (PMBOK® 8, Guide p.28). The same page ties how much change request management a project applies to its scope, its complexity, its contract requirements, and the development approach in use.
Requests come in four types: corrective action, preventive action, defect repair, and update (PMBOK® 8, Guide p.30, Figure 2-11). The Guide describes preventive and corrective actions as the requests needed to eliminate or reduce a negative impact later in the project (PMBOK® 8, Guide p.117). The usual way to separate them on the exam comes from earlier editions' definitions. Work that brings an actual variance back in line with the plan is corrective, work that heads off a variance before it happens is preventive, and work that fixes a deliverable that does not conform is a defect repair.
In predictive projects, the process starts with the baseline
Under a predictive approach, changes are not formally controlled until baselines exist. Once a baseline is in place, every change should go through the formal process (PMBOK® 8, Guide p.29). The same page holds three more details the exam likes to probe. A request may start verbally, but it should be written down and entered into the change or configuration management system. Before approval it should normally carry its estimated schedule and cost impacts. And each documented request is approved, deferred, or rejected by a designated person, such as the project sponsor or the project manager, as the project management plan or organizational procedures specify.
That last detail softens a rule many candidates memorize, namely that the project manager can never approve a change. The Guide ties the authority to whoever the plan names, and it says separately that approved changes can come from the project manager as well as from a change control board (PMBOK® 8, Guide p.114). When a question turns on who holds the authority, the answer usually lies in what the plan says.
The schedule is the most tested example. In a predictive project, any change to the schedule baseline or to the agreed-upon schedule can only be approved through this process, by applying integrated change control (PMBOK® 8, Guide p.54). Building and tracking the schedule belongs to II.8 — Plan and Manage Schedule; the authority to change its baseline runs through here.
The change control board and the plan that creates it
Not every project has a board. The Guide says a change control board (CCB) or project board may be involved "when applicable" (PMBOK® 8, Guide p.30). Its glossary defines the board as a formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes, and for recording and communicating those decisions (PMBOK® 8, Guide p.266). The board itself is established by the change management plan. That plan is a component of the project management plan, and it documents the extent of the board's authority, its roles and responsibilities, and how the change control system will work (PMBOK® 8, Guide p.116). The same entry gives the board another name, steering committee. A question that uses both names is not describing two separate bodies.
What the project manager does while the board deliberates is the best-known question in this task, and the Guide answers it plainly. The project manager keeps executing the planned work and, at the same time, analyzes the impact and risks of accepting or rejecting the proposal so that negative effects stay small (PMBOK® 8, Guide p.30). Stopping the work and implementing the change by going around the board are both wrong answers for that reason. The risk side of that analysis connects to III.5 — Plan and Manage Risk.
Board approval is not always the last step. Depending on the nature of the change, customer or sponsor approval may be needed after the board approves, unless the customer or sponsor already sits on the board (PMBOK® 8, Guide p.30).
In adaptive projects, priority takes the place of approval
Adaptive approaches handle changes through backlog management instead of a formal change request process (PMBOK® 8, Guide p.30). When a stakeholder proposes a change, it is recorded as a product backlog item and added to the backlog. Nobody formally calls it a change request, yet its impact is still analyzed and its priority is set from that analysis.
There is no formal approval step, but the decisions still have equivalents. Giving an item a lower priority effectively defers it. Choosing not to add it to the backlog, or removing an item that is already there, rejects it. If a question about an agile team offers "fill in a change request form and take it to the board", this distinction helps; in that context the expected move is to add the proposal to the backlog and prioritize it by its impact.
After the decision
Three of the ECO's four enablers begin once a decision has been made, and the Guide describes this part as a sequence (PMBOK® 8, Guide p.114). Approved requests are implemented through the Manage Project Execution process. Deferred and rejected requests are communicated to the person or group that raised them. Whatever the outcome, the disposition of every request is recorded in the change log as a project document update. The Guide defines the change log as a comprehensive list of the changes submitted during the project, together with their current status (PMBOK® 8, Guide p.116).
So the enabler about communicating status goes beyond announcing what was approved. If the person whose request was rejected never hears about it, the work is incomplete by the Guide's own description.
An approved change rarely arrives alone, either. According to the Guide it may require new or updated cost estimates, schedule adjustments, resource requirements, and risk assessments, and it can bring updates to the project management plan and other project documents with it (PMBOK® 8, Guide p.30). That is exactly where the enabler about updating documentation lands. Since changes are made to improve on the original plan, the Guide also asks for their results to be monitored, which is the only way to see whether the intended improvement actually happened.
On the documentation side the two approaches diverge again. Predictive projects keep a change log that shows each change with its impact on the Scope, Schedule, Finance, Stakeholders, Resources, and Risk domains, while adaptive projects manage scope through a backlog (PMBOK® 8, Guide p.46).
Which changes need a formal request
The answer does not depend on how big the change looks. The configuration management plan specifies which project artifacts are under configuration control, and changes to those artifacts require a formal change request (PMBOK® 8, Guide p.29). The same plan describes how controlled artifacts are identified and how changes to them are recorded and reported (PMBOK® 8, Guide p.118).
Because the two terms are easy to confuse, the Guide spells out the difference in its tools section. Configuration control focuses on specifying deliverables and processes, whereas change control is concerned with identifying, documenting, and approving or rejecting changes to project documents, deliverables, or baselines (PMBOK® 8, Guide p.151). A correction that looks minor still needs a request if it touches a controlled artifact, so the thing to check in a question is which artifact the change affects.
About the citations
Every page number above refers to the PMBOK® Guide, Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked "ECO" separately.
⚠️ PMBOK® 8 contains two separate books in one volume, and their page numbering is independent:
- The Standard for Project Management — cited as Standard p. X
- A Guide to the Project Management Body of Knowledge — cited as Guide p. X
All citations on this page come from the second book, the Guide. The numbers are the book's printed page numbers.
This page describes the book; it does not replace it.
