PMP Integrated Change Control: Change Requests, CCB, Agile Change and Configuration Management

Integrated change control is the process of reviewing every proposed change to a project, analysing its effect on the whole project, deciding it through the authority the plan names, and then managing the approved changes to the deliverables, plans, baselines and documents. It is "integrated" because a change to one thing (a feature, a date, a supplier part) almost always moves others (cost, risk, quality, other work streams), and the decision has to see all of them at once.

The PMP Examination Content Outline (July 2026) lists four enablers for this task, and they form one loop:

1. Execute the change control process: capture the request, analyse its impact, and route it to the right decision-maker.
2. Communicate the status of proposed changes: requesters and stakeholders can always see where each change stands and why.
3. Implement approved changes: build exactly what was approved, under its conditions, and verify it.
4. Update project documentation: every affected plan, baseline, backlog, register and artefact reflects the change, under configuration management.

The rules that run this loop live in the change management plan (part of the project management plan): what counts as a change, who may approve which changes, thresholds, emergency procedures and the tools used (change log, change request form). Who holds decision rights in general is a governance question, covered in the project governance lesson; this lesson is about running changes through those rules.

In a predictive setting the process runs in the same order every time: document, analyse, decide, communicate, implement, verify, update. Skipping a step is the most common failure, and almost every scenario tests which step comes next.

A complete request form is not the same as an analysed request. The form records what is being asked; the impact analysis is the project manager's work that lets a decision-maker weigh it. Likewise, any judgement of whether a change is worth making belongs to the decision step, after the analysis, through the route the plan sets.

Capturing every change request, including informal ones

Every proposed change to approved scope, schedule, cost or other baselined items must become a documented change request, regardless of who asks or how. A remark in a hallway, a line in a meeting, a message in a chat thread: each is a change request the moment it would alter something approved, whatever the channel.

• Record it, do not refuse it. The project manager can write the request up on the requester's behalf and start the impact assessment straight away. Paperwork is the project manager's job, not a hurdle the requester must clear before anything happens.
• Do not act on it first. Low cost or convenience does not make a change pre-approved: small work can still affect a design, a contract or another team.
• Seniority and funding do not bypass the process. The plan's authority levels apply to everyone's requests, including those of senior or paying stakeholders; the process can move fast for them, but it is the same process.
• The change log is the register for changes; the issue log is for issues. Each log feeds a different decision path, so a change request belongs in the change log.

Being fast and being compliant are not opposites: a well-run process can turn an urgent, well-analysed request around within days. The exam favours moving a request quickly to the right authority over either refusing it or doing it informally.

Impact analysis is the assessment of everything a proposed change would affect, done before the change is decided. It covers scope, schedule, cost, quality, resources, risk, procurement and contracts, compliance, and other teams or streams that depend on the changed item, plus alternatives for absorbing the change.

Three points the analysis must get right:

• Integrated means every stream. A change in one stream can ripple into another: a revised data format in a reporting system, for example, can force rework in every team that consumes it. Any stream that can be consulted before the decision contributes its own impact and risks to the analysis, so the decision-maker sees the full cost of the change rather than part of it.
• "No change to the end date" is not "no impact". If added critical-path work is absorbed by fast-tracking or crashing, the analysis shows the added scope, the response used to hold the date, and the extra risk or cost that response brings (fast-tracking overlaps activities and raises schedule risk; crashing adds cost). The decision-maker weighs those consequences as part of the decision.
• Options help the decision. Presenting alternatives (descope something else, phase the change, use reserve within the plan's rules) gives the decision-maker real choices.

Analysis comes first. When a request arrives, assessing its impact is the step that comes before any decision about it.

The change management plan sets decision levels: typically the project manager may approve small changes within stated limits, the change control board decides changes to baselines above those limits, and the sponsor or a steering body decides changes beyond the board's authority (for example, to the business case, funding or charter-level objectives).

Delegated thresholds work as an and: a change must satisfy every condition (cost, schedule, scope, risk) to stay at the project manager's level, and breaching any single one moves it up. A threshold applies to the whole change as it really is, however it is packaged. Escalation also follows the defined levels in order, so each authority sees the changes the plan assigns to it.

Time-sensitive requests (a supplier discount that expires in days, a regulatory window) change how fast the decision is made, not who makes it. Most plans provide a fast route, such as an out-of-cycle meeting or an electronic vote, so the right authority can decide in time.

In adaptive delivery, change is expected and is absorbed through the product backlog: new ideas become backlog items, and the product owner decides whether and when they are built by ordering the backlog. There is no change control board for product-scope changes inside the team's remit, and the developers do not decide priorities.

The sprint goal protects work in progress. Under the Scrum Guide (2020), during a sprint no changes are made that would endanger the sprint goal; scope may be clarified and renegotiated with the product owner as more is learned, and only the product owner may cancel a sprint, when its goal becomes obsolete. A new request therefore usually lands in the product backlog, where the product owner can place it as high as its value deserves for the next sprint planning, while the current sprint goal stays intact.

Unrequested work is also a change. Work added without a request is made visible, and the product owner decides its fate, because the product owner owns product scope.

Routing changes on a hybrid project

Hybrid projects run both mechanisms, and the test is what the change touches:

Routing errors run both ways: formal control on story-level detail adds delay without adding control, and backlog-level approval of a contracted commitment bypasses the control that commitment needs. When backlog options are exhausted and a committed date, scope or cost still cannot hold, the gap is made visible through a change request so the right authority decides.

An emergency change is one the change management plan defines as too urgent to wait for the normal process, typically to prevent harm to people, protect the environment or restore a live service. The plan names who may approve it on the spot, and requires the change to be documented and reviewed by the board afterwards within a stated time.

• Use the emergency authority when the plan's criteria are met. When a situation fits the plan's definition, the named person approves the immediate action, and the change is then documented and reviewed within the time the plan sets. Both halves are part of the procedure.
• The plan's definition decides, not the requester's label. A request that falls outside the definition is a normal change, however pressing it feels; the normal process can still be fast.
• Emergency authority covers only the emergency. Anything beyond what the emergency requires is a separate change and follows the normal route.

An unauthorized change is one discovered after it was made without approval, such as a supplier quietly changing a component's firmware version or a team configuring a system differently from its design. The first step is to bring it into change control: document it as a change request, have the people qualified to judge it assess its impact, and let the right authority decide whether to accept, rework or reverse it. Any outcome chosen before that assessment, whether keeping it or undoing it, is a decision made without analysis. The same applies to gold plating by a team member.

A change request can propose one of four kinds of change, and telling them apart depends on what is being fixed:

A quick test: fixing the product is defect repair; fixing how the project is performing now is corrective; stopping it happening again is preventive; changing documentation is an update.

Stakeholders should be able to see where every change request stands and why, without having to ask. The project manager keeps the change log current (received, under analysis, with the board, approved, deferred, rejected, implemented, closed) and makes it visible to everyone who needs it, covering pending requests as well as decided ones, so status is available on demand rather than one query at a time.

• Every decision is communicated, including rejections. Update the log and tell the requester the outcome and the reason; the communication closes the loop for the requester.
• Approved changes are announced as soon as they are approved, so affected people can plan, not when the change is released.
• In agile settings, status is shown rather than reported: a visible, ordered product backlog tells stakeholders where their request sits, and iteration (sprint) reviews let them see and discuss requested items. The channel suits the audience: business stakeholders follow the backlog and reviews, while team-internal events serve the team.

An approved change is implemented exactly as approved: the same scope, the same timing and any conditions the board attached. Conditions attached to an approval (when work may start, which option was chosen) are part of the approved change, so convenience is not a reason to depart from them. When implementation shows the change is growing beyond the limits the change management plan sets, the revised position goes back to the decision-maker; whether reserve exists to cover it is for that authority to weigh. Changing either the cost or the solution without a decision alters the approved change.

After implementation the result is verified against the approved change with evidence, and only then is the change log entry closed. Verification (did we build what was approved?) is distinct from formal customer acceptance of deliverables, which is validation and happens at its own point.

Changes to procured work

Work a seller performs under contract can only be changed through the contract's change control procedure, by the people with contracting authority, typically the buyer's procurement or contract administrator. The project manager usually lacks that authority, so:

• CCB approval changes the project plan; it does not amend the contract. Before the vendor starts the new work, the contract is amended (or a contract change order is issued) by procurement.
• A seller's claim for extra payment is submitted and resolved through the contract's change procedure, where it is assessed and settled through the contract terms. Under a fixed-price contract, the price covers the agreed scope, so a buyer-initiated change to that scope can carry a price adjustment.
• A product owner's backlog authority stops at the contract boundary: telling a vendor to change contracted deliverables is a contract change.

Once a change is approved, every artefact the impact analysis listed as affected is updated: the relevant baselines (scope, schedule, cost), subsidiary plans, the release plan and backlog, the requirements traceability matrix, registers (risk, stakeholder), the contract scope documents and the change log. The impact analysis is the checklist: update every artefact the change actually touches and nothing it does not (a change that alters cost alone leaves the schedule baseline as it was). Each artefact is updated in its own right, since updating one does not update the others.

Configuration management controls the versions of the product and its documents so everyone works from the current approved version. Change control decides whether a change happens; configuration management makes sure the result is recorded, versioned and used. PMI's description of configuration management names three activities: configuration identification, configuration status accounting, and configuration verification and audit. General configuration management standards also describe configuration control, which controls changes to configuration items and overlaps with change control; version control is how it is put into practice day to day.

Version control (the working practice of configuration control) makes every edit start from the latest controlled version, so one approved change cannot silently overwrite another.

Two failures are classic configuration-management problems rather than change-control problems: parties working from different versions of an approved document (the current version was not issued and controlled), and changes lost because edits were not made from the latest version. The activities differ in timing: version control prevents lost edits as they are made, while status accounting and verification audits detect discrepancies after the fact.