Manage and Control Changes

Introduction

This lesson covers task 3 of the Business Environment domain in the July 2026 PMP Examination Content Outline. Business Environment carries 26% of the exam. Change is certain on every project: customers learn what they really need, regulations evolve, suppliers fail, estimates prove wrong. The question is never whether changes will come, but whether they are managed. A project where changes are approved informally drifts away from its baselines and its business case; a project where every change is blocked delivers something nobody needs.

The exam tests situations such as: a stakeholder asks a team member directly for an extra feature; an urgent change must be implemented before approval; a product owner reprioritizes the backlog in the middle of an iteration; a change affects several knowledge areas at once. You must apply the right process for the approach, evaluate the impact, obtain the decision from the right authority, communicate the status, implement what is approved, and update the documentation. After this lesson you will be able to do this in predictive, agile, and hybrid projects.

Learning objectives

• Explain the purpose of integrated change control and the roles of the change control board.
• Process a change request from submission to closure.
• Assess the impact of a change on scope, schedule, cost, quality, resources, risks, and benefits.
• Communicate the status of proposed changes and implement approved changes.
• Update the baselines and project documents after a change.
• Handle changes in agile projects through backlog refinement and prioritization, and in hybrid projects through the combination of both.
• Recognize and respond to scope creep, urgent changes, and unauthorized changes.

1. Why change control exists

Change control protects the baselines and the objectives of the project while still allowing necessary adaptation. A baseline is the approved version of the scope, schedule, or cost that is used for comparison. If you change a baseline without approval, you lose the ability to measure performance and you hide the consequences from the sponsor.

Change control answers four questions: Is the change needed and valuable? What are its effects? Who has the authority to approve it? Has it been communicated and carried out properly?

Types of changes:

2. The change control process

For predictive and hybrid projects with formal baselines, the process generally follows these steps. In an organization the exact form comes from its policy; on the exam, expect the logic below.

1. Prevent unnecessary changes. Clarify requirements early, validate them with stakeholders, and agree on acceptance criteria. Not every change is avoidable, but many are.
2. Capture the request. Anyone can raise a change request, in writing, through the project's channel. Record it in a change log with a unique identifier, the requester, the date, the description, and the reason.
3. Perform a preliminary check. The project manager verifies that the request is clear, belongs to the project, and is not a duplicate. Informal verbal requests are written down before analysis.
4. Assess the impact. Evaluate the effects on scope, schedule, cost, quality, resources, risks, procurement, stakeholders, benefits, and compliance. Identify options, including doing nothing.
5. Submit to the decision authority. Depending on the thresholds of the governance plan, the project manager, the sponsor, the change control board (CCB), or the steering committee decides.
6. Decide. Approve, reject, or defer, with the reasons recorded. A request may also be sent back for more information.
7. Communicate. Inform the requester and affected stakeholders of the decision and of its consequences.
8. Implement. If approved, update the plans and baselines, assign the work, and track it. The work is not started before approval, except for approved emergency procedures.
9. Verify and close. Check that the change was implemented as approved, update the documents, and close the entry in the log.

Change control board

The CCB is a group formally chartered to review, evaluate, approve, delay, or reject changes. Its members come from the groups affected, such as the sponsor or business owner, technical leads, finance, quality, and sometimes the customer. The charter defines its authority, quorum, meeting schedule, and how decisions are recorded. For urgent matters it may define a fast path, for example a decision by two named members within 24 hours, to be ratified later.

The project manager does not approve a change that exceeds their authority, and does not let the CCB become a bottleneck by bringing every minor item to it. Thresholds in the governance plan define which changes the project manager can approve alone.

Configuration management

Change control is closely linked to configuration management, which identifies the versions of deliverables and documents, controls who can modify them, records the status, and verifies integrity. Without configuration control, the team can build on an outdated requirement document, and the approved change is lost.

3. Assessing the impact of a change

A common error is to look only at the requested feature. The project manager looks at all areas and at the whole project.

Techniques include expert judgment, meetings with the team, models, prototypes, simulations, and impact analysis on the schedule network or the cost estimate. Present at least two options when possible, such as full implementation, a reduced version, deferral to a later release, or rejection, with a recommendation.

Worked example: evaluating a change request

Scenario. A project builds a customer portal with a budget of 600,000 and a planned finish in 20 weeks. In week 12, the marketing director asks for a loyalty-points module. The team estimates 5 weeks of work for 4 people, an extra cost of 60,000, and a dependency on a vendor interface that is not yet contracted. The governance plan states that changes up to 20,000 can be approved by the project manager, between 20,000 and 80,000 by the sponsor, and above 80,000 by the steering committee. The work on the critical path would slip by 3 weeks.

Step 1: record the request. Enter it in the change log with the requester and reason.

Step 2: assess the impact. Cost: 60,000 (10% of the budget). Schedule: a 3-week delay on the critical path, so a finish in week 23. Risks: the vendor interface is not contracted; testing capacity is tight. Benefits: expected increase in repeat purchases, estimated at 150,000 in the first year according to marketing. Quality: new test cases needed.

Step 3: build options. (a) Implement now: +60,000, +3 weeks. (b) Implement a reduced version: +25,000, +1 week. (c) Defer to a second release after launch: no change to the baseline now, benefit later. (d) Reject.

Step 4: identify the authority. 60,000 lies between 20,000 and 80,000: the sponsor decides. The project manager prepares the analysis, a recommendation (for example option b or c), and presents it.

Step 5: record the decision and communicate it. Suppose the sponsor selects option c. Document the reasons, add the item to the product backlog for release 2, and inform the marketing director and the team.

Step 6: update the plans. No baseline change for option c; update the change log, the backlog, the stakeholder register, and the risk register (a stakeholder risk of dissatisfaction).

Why other choices are weaker. Starting the work because marketing is influential bypasses the approval and the thresholds. Rejecting without analysis ignores the benefits and damages the relationship. Approving it alone exceeds the project manager's authority. Absorbing it with no change to the schedule hides a 3-week impact and reduces trust.

4. Communicating the status of proposed changes

Stakeholders want to know whether their request is accepted, when, and what it will cost. Poor communication creates informal workarounds.

• Keep the change log visible, with status (submitted, under analysis, approved, rejected, deferred, implemented, closed).
• Tell the requester when their request is received, when the decision is made, and why.
• Inform affected teams and stakeholders as early as the impact analysis shows they will be touched.
• Report approved changes and their cumulative effect in status reports, for example the number of changes, cost and schedule impact to date, and trends.
• Use the communications plan to choose the channel and the audience. Rejections are explained respectfully, with alternatives.

A growing number of requests from a stakeholder can signal unclear requirements, a misunderstanding of the vision, or a lack of engagement. Look for the cause, not only for the process.

5. Implementing approved changes and updating documents

After approval:

1. Update the project management plan components affected (scope, schedule, cost baselines, plans for quality, resources, risk, communications, procurement).
2. Update project documents such as the requirements documentation, traceability matrix, risk register, assumption log, stakeholder register, and backlog.
3. Assign the work and ensure it is done as approved, checking that the team uses the correct version.
4. Verify the result through quality control and, if needed, validation with the customer.
5. Update the lessons learned register.
6. Close the change entry and keep the history for audit.

Never implement a change and then ask for approval; never approve a change without updating the baselines. A baseline changes only through formal approval, and the previous baseline is kept for comparison.

6. Changes in agile and hybrid projects

Agile approaches welcome change, but not chaotically. The mechanisms differ.

Key practices:

• The product owner orders the backlog by value and decides on changes of priority and content. The team gives estimates and the effect on the forecast.
• Backlog refinement is where new items are clarified, estimated, split, and ordered before they enter an iteration.
• Within an iteration, the scope is protected: the team should not accept new work casually. If the product owner brings an urgent item, the team assesses whether the iteration goal remains possible; the item can replace another of similar size, or wait for the next iteration. If the goal is no longer valuable, the iteration can be cancelled by the product owner.
• Formal change control still applies to items that touch fixed commitments: contract scope or price, a fixed budget, a regulatory milestone, or a release date promised to external parties. In these cases a hybrid process is common: the backlog moves freely within a fixed envelope, and the sponsor or CCB approves changes to the envelope.
• Trade-off thinking. In agile projects, adding something means removing or deferring something else, or accepting a later release. The team shows the effect on the burnup chart or release forecast.

Worked example: a mid-iteration request in a hybrid project

Scenario. A team works in two-week iterations inside a fixed-price contract for a logistics system. On day 4 of an iteration, a customer manager asks a developer to add a new filter to a delivery screen. The product owner is absent today. The iteration goal is a working route-planning function required for the contractual milestone next week. The filter was not in the backlog.

Step 1: do not accept the work informally. The developer explains politely that requests go through the product owner and records the request.

Step 2: record it in the backlog or change log with the requester and reason.

Step 3: evaluate with the product owner as soon as they are available. Estimate: 3 points. Value: moderate. The iteration goal and the milestone are at risk if the item is added.

Step 4: decide. The product owner decides to place the item in the next iteration. The contract scope is not affected because the item is within the existing functional description (the project manager checks the contract).

Step 5: communicate the decision and the planned timing to the customer manager.

Step 6: reflect in the next refinement and retrospective how requests reach the team, and agree on a clear intake path.

Why other choices are weaker. Accepting the work immediately jeopardizes the iteration goal and the milestone. Refusing the customer without recording the request ignores the value of feedback. Asking the customer to submit a formal contract amendment is excessive because the request is within scope. Letting the developer decide alone removes the product owner's authority.

7. Scope creep, urgent changes, and unauthorized changes

Scope creep is the uncontrolled growth of scope without matching adjustments to time, cost, and resources. It occurs through small, informal additions ("while you are there..."), gold plating by the team, or stakeholders going directly to team members. Prevent it with clear scope, a visible change process, and training of the team to redirect requests. If it has already occurred, assess the effect, raise a change request to regularize what is justified, and remove what is not.

Gold plating is adding features beyond requirements without approval. It adds cost and risk and should be avoided, even when well-meant.

Urgent changes (for example, a critical security flaw) follow an emergency procedure defined in advance: a limited group approves quickly, the change is implemented, and the full documentation and ratification follow. The project manager must not ignore the process; they use the fast path.

Unauthorized changes are found after the fact. The response is: stop if the effect is harmful, assess the impact, inform the authority, decide whether to keep, regularize, or reverse the change, record it, find the cause (weak controls, pressure, misunderstanding), and take preventive steps. Do not hide it.

8. Common pitfalls and exam tips

• Pitfall: starting work before approval. It breaks control.
• Pitfall: analyzing only cost. Other areas, especially risks and benefits, are affected.
• Pitfall: using the CCB for trivial matters. Define thresholds.
• Pitfall: forgetting to update the baselines and documents. The next report will be wrong.
• Pitfall: using formal change control as an excuse to refuse everything.
• Pitfall: treating agile as "no change control." The backlog and the product owner are the control.
• Pitfall: saying yes to a senior stakeholder without analysis.

Exam tip: The first step with a change request is usually to evaluate its impact (after recording it), not to approve, reject, or implement.

Exam tip: Look for the answer in which the correct authority decides after an impact analysis with options.

Exam tip: If a change was already made without approval, assess and inform; do not hide it and do not silently reverse it.

Exam tip: In agile questions, the product owner prioritizes; the team does not accept scope informally, and the iteration goal is protected.

9. Mini case study: the contract warehouse system

Context. A project manager leads a predictive project to deliver a warehouse management system for a distributor under a fixed-price contract of 1,200,000 over 40 weeks. In week 22 three requests arrive: (1) the operations manager asks the lead developer to add barcode support for returns, a feature not in the requirements, saying "it only takes two days"; (2) the finance director asks that the invoice export use a new tax format starting next quarter, a legal requirement; (3) a developer has already built an extra dashboard that was not requested because "users will love it". The project is two weeks late on the critical path and the CCB meets every second Thursday.

Question. What should the project manager do?

Solution (commented).

1. Request 1 (barcode support). Record it and ask the operations manager for a written change request. Do not start the work. Assess the effect: two days for development, but also testing, documentation, training, and the interface with scanners; perhaps one week and a cost of 15,000. Evaluate against the contract (fixed price, so a contract amendment may apply) and the governance thresholds. Bring options and a recommendation to the CCB.
2. Request 2 (tax format). It is a legal requirement, so the compliance impact weighs strongly. Register it as a change request with the legal reference, assess the cost, schedule, and risks, and ask for fast treatment because of the deadline. The CCB or sponsor can use the fast path if the next meeting is too late. Update the baselines when approved.
3. Request 3 (extra dashboard). This is gold plating. Stop further work, assess the effect (effort already spent, maintenance, testing, risk), and inform the sponsor. If the dashboard has real value, submit it as a change request; otherwise remove it. Coach the developer and remind the team of the process.
4. Communicate the status of each request to the requesters and in the next report, including the cumulative effect of changes on schedule and cost.
5. Update the change log, scope baseline, WBS, schedule, cost baseline, risk register, and requirements traceability for every approved change.
6. Address the cause. Hold a short session with the team and key stakeholders on how to submit requests, and ask the sponsor to reinforce the rule. Review the existing delay as a separate matter, reporting it and its recovery options.
7. Do not accept the barcode request because it "only takes two days", delay the legal change until the CCB because the process says so, or hide the dashboard.

Key terms

• Change request: a formal proposal to modify any document, deliverable, or baseline.
• Change control board (CCB): a formally chartered group responsible for approving or rejecting changes.
• Baseline: the approved version of scope, schedule, or cost used for comparison.
• Change log: a record of all changes and their status.
• Configuration management: the control of versions and status of deliverables and documents.
• Scope creep: uncontrolled expansion of scope.
• Gold plating: adding unrequested extras to a deliverable.
• Backlog refinement: the ongoing activity of clarifying, estimating, and ordering backlog items.
• Product owner: the person who owns and orders the product backlog.
• Emergency change: a change implemented under a fast procedure to prevent serious harm.

Summary checklist

• I record every change request and assess its impact before any decision.
• I evaluate scope, schedule, cost, quality, resources, risks, benefits, and compliance.
• I bring options and a recommendation to the right authority within the thresholds.
• I communicate the status and the result of each proposed change.
• I implement only approved changes and update baselines and documents.
• I handle changes in agile projects through the product owner, refinement, and protected iteration goals.
• I detect and manage scope creep, gold plating, urgent, and unauthorized changes.
• I keep a change log and learn from the causes of changes.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, About the new PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)
• PMI, Project Management Professional (PMP): https://www.pmi.org/certifications/project-management-pmp (opens in a new tab)
• PMI, Agile Practice Guide and PMBOK Guide overview: https://www.pmi.org/standards (opens in a new tab)