III.3 — Manage and Control Changes
III.3 · Last updated: 24/08/2026
Where this task sits
III.3 — Manage and Control Changes is a task in the Business Environment domain of the 2026 ECO. The domain carries 26% of the exam and holds eight tasks.
In the 2021 ECO, this topic was not here.
The four enablers the ECO attaches to this task follow a sequence: execute the change control process, communicate the status of proposed changes, implement approved changes, and update project documentation to reflect them. The exam is not only asking about the "approved or not" decision — it asks about what comes before and after it.
The move: from II.10 to III.3
| 2021 | 2026 | |
|---|---|---|
| Number | II.10 | III.3 |
| Domain | Process | Business Environment |
| Title | Manage project changes | Manage and control changes |
Adding control to the title is not cosmetic: the 2026 wording names managing a change and controlling it as two separate things — one is responding to a request, the other is putting it through a formal gate.
That distinction matches how the PMBOK® Guide is organized. It places the change process (Assess and Implement Changes) inside the Governance Performance Domain, and notes that this domain's processes span the whole project from initiation to closure (PMBOK® 8, Guide p.16 — Figure 2-2). PMBOK treats change control as governance work, not process bookkeeping.
Why the domain change matters
If you file change under Process, you study it next to estimating and replanning. In 2026 its neighbors are III.1 Define and Establish Project Governance, III.2 Plan and Manage Project Compliance, and III.4 Remove Impediments and Manage Issues — decision authority, thresholds, and conformance. That neighborhood shifts the language of the questions too: less "how do we update the schedule," more "who is authorized to make this call."
If you build your study plan around domain weights, the topic having moved out of the 41% domain and into the 26% one changes the hours you give it.
🔴 Do not trust the number
III.3 is the most deceptive number in the whole ECO, because the swap runs both ways:
- In 2021, III.3 was the impact of external business environment changes on scope. In 2026 that topic is III.8 — Evaluate External Business Environment Changes.
- In 2026, III.3 is change management. In 2021 that topic was II.10 — and that number now belongs to project closure.
So two sources both labeled "III.3" may cover two completely different subjects. Worse, both use the word change: one means change requests coming into the project, the other means business environment changes outside it. Match on the title, never the number.
For the general shape of this trap and its other instances, see what changed in the 2026 PMP exam; for a neighboring move, see III.5 — Plan and Manage Risk.
What a change request is, and who can raise one
The Guide defines a change request as a formal proposal to modify a document, deliverable, or baseline. Requests may originate inside or outside the project, and any stakeholder may request a change (PMBOK® 8, Guide p.116–117).
The process is open from the start of the project through its completion, and requests can affect project scope, product scope, project management plan components, and project documents (PMBOK® 8, Guide p.28).
Requests come in four forms: corrective action, preventive action, defect repair, and update (PMBOK® 8, Guide p.30, Figure 2-11). The exam tests the split like this: the deviation already happened, so corrective; it has not happened yet, so preventive; the deliverable itself is non-conforming, so defect repair.
"Approval" is not the same thing in predictive and adaptive
This is the most productive distinction in III.3 questions.
In predictive approaches, changes are not formally controlled until baselines exist; once a baseline is set, every change goes through the formal process. A request may start verbally, but it is written down, and it is expected to carry estimated schedule and cost impacts before it can be approved (PMBOK® 8, Guide p.29).
In adaptive approaches, backlog management takes the place of a formal change request process. A proposal becomes a backlog item, its impact is analyzed, and it is prioritized. There is typically no formal "approval" step — but there are equivalents: assigning the item a low priority amounts to deferring it, and not adding it to the backlog, or removing it, amounts to rejecting it (PMBOK® 8, Guide p.30).
The Guide draws the same line on the artifact side: predictive projects keep a change log, adaptive projects use a backlog (PMBOK® 8, Guide p.46).
What to do while the board decides
A change control board (CCB) is a formally established group that reviews, evaluates, approves, defers, or rejects changes, and documents and communicates those decisions (PMBOK® 8, Guide p.30). The board and the extent of its authority are established by the change management plan (PMBOK® 8, Guide p.116).
The classic exam question here: what should the project manager do while the CCB has not decided yet? The Guide's answer is not "wait" — keep executing planned tasks while analyzing the impact and risks of the proposal being accepted or rejected (PMBOK® 8, Guide p.30).
What happens after the decision belongs to this task too: requests are approved, deferred, or rejected; approved ones are implemented through project execution, deferred and rejected ones are communicated back to whoever requested them, and every disposition is recorded in the change log (PMBOK® 8, Guide p.114). That is exactly what the ECO's "communicate the status" and "update documentation" enablers point at.
Configuration control and change control are not the same
The Guide names them separately: configuration control is concerned with specifying deliverables and processes, while change control is concerned with identifying, documenting, and approving or rejecting changes to project documents, deliverables, or baselines (PMBOK® 8, Guide p.151).
Which artifacts sit under configuration control is stated by the configuration management plan — a set of procedures for tracking project artifacts and recording and reporting changes to them (PMBOK® 8, Guide p.118). If an artifact is in that set, changing it requires a formal change request (PMBOK® 8, Guide p.29).
The practical consequence: the answer to "does this need a formal change request?" does not depend on how big the change is, but on whether the artifact it touches is under configuration control.
About the citations
All page numbers above refer to the PMBOK® Guide, Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked as "ECO."
⚠️ 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
Every citation on this page comes from the second part, the Guide. The numbers are the book's printed page numbers.
This page explains the book; it does not replace it.
