Integrated change control

Every project changes. Stakeholders ask for more, risks occur, defects appear, laws change and estimates prove wrong. Change is not the problem; uncontrolled change is. Integrated change control is the process of reviewing all change requests, approving or rejecting them, and managing changes to deliverables, project documents and the project management plan, so that the plan and the work stay consistent and stakeholders know what has been agreed. This lesson covers the process, who decides, configuration management, how to assess impact and how change works in adaptive and hybrid projects. The 2026 exam outline places the task of managing and controlling changes in the Business Environment domain, reflecting its role in governance.

Why control change

Without change control, small additions accumulate until the project is doing much more than it was funded to do, with no extra time or money: scope creep. Different people work from different versions of the plan. Baselines lose meaning, so earned value and variance reports stop telling the truth. And stakeholders who were promised something find it quietly changed. With change control, every change is visible, its impact on scope, schedule, cost, quality, risk and benefits is understood before a decision is made, the right person decides, and plans and baselines are updated consistently.

Change control is not about saying no. Many changes are good: a corrective action that recovers a slipping schedule, a scope change that increases benefits, a defect repair. The aim is to make good decisions about changes and to implement approved changes cleanly. A process so heavy that people avoid it is as harmful as no process, so the level of control is tailored to the project and to the size of the change.

The change control process

A change control process, defined in a change management plan within the project management plan, typically has the steps shown below. Anyone involved in the project can request a change, but requests should be in writing (or entered in the change management system), even if they start as a conversation.

First, the request is recorded in the change log with an identifier, date, requester, description and reason. Second, the project manager, with the relevant specialists, analyses its impact on every objective: scope, schedule, cost, quality, risk, resources, procurement and benefits. Options are identified, because the choice is rarely just yes or no. Third, the person or body with authority decides: approve, reject or defer. Fourth, approved changes are implemented through direct and manage project work, plans and baselines are updated, affected contracts are changed through the procurement process, and stakeholders are told. Finally, the implementation is verified, for example by checking that the changed deliverable meets its updated requirements. Every request, whatever the outcome, stays in the change log with its decision and rationale.

A frequent exam scenario describes a stakeholder asking the project manager, or a team member, for a change. The correct sequence is almost always: evaluate the impact, identify options, submit a change request (or ask the requester to), obtain a decision from the right authority, then update plans and communicate. Wrong answers include implementing the change straight away, refusing it outright, or going directly to the sponsor without analysis.

Who decides: the change control board and authority levels

A change control board (CCB) is a formally constituted group responsible for reviewing, evaluating, approving, deferring or rejecting changes and for recording decisions. Its membership and authority are set out in the change management plan and the project's governance. Many projects define levels of authority so that small changes do not wait for a board meeting.

The project manager's authority to approve changes is whatever the governance gives; in many organizations it is small. The project manager's job is to make sure that changes are analyzed properly, presented clearly with options and recommendations, decided by the right people and implemented consistently. PRIN-131 described PRINCE2's equivalent, a change authority with a change budget; the idea is the same.

Analyzing impact

Impact analysis is the heart of change control. It looks beyond the obvious cost to ripple effects: does the change touch the critical path? Does it need a new permit, an approval or a contract change? Does it create risks? Does it affect quality requirements, other workstreams or benefits? A complete analysis presents options, such as doing the change now, later or partially, with the consequences of each.

# Impact assessment for change request CR-07: convert a storage room into a second community room
cr = {"scope": "Convert storage room to a community room: partition, door, AV kit, accessible counter",
      "cost": {"Design revision": 6, "Construction": 41, "AV equipment": 12, "Furniture": 7},
      "duration_days": 9, "on_critical_path": True, "float_days": 0,
      "quality": "Requires second accessibility review and fire separation check",
      "risk": "New permit amendment; landlord consent needed for new partition"}
cost = sum(cr["cost"].values())
delay = max(0, cr["duration_days"] - cr["float_days"]) if cr["on_critical_path"] else 0
print(f"Cost impact: {cost} ($000)   Schedule impact: +{delay} working days")
print("Quality:", cr["quality"])
print("Risk:", cr["risk"])
# Options the project manager presents to the change control board
options = [("Approve now, fund from new board money", cost, delay),
           ("Approve but build after opening (phase 2)", cost + 5, 0),
           ("Reject; use the meeting room booking system instead", 0, 0)]
print("\nOption                                               Cost  Delay to opening")
for o, c, d in options:
    print(f"{o:52s}{c:5d}{d:8d} days")

Cost impact: 66 ($000)   Schedule impact: +9 working days
Quality: Requires second accessibility review and fire separation check
Risk: New permit amendment; landlord consent needed for new partition

Option                                               Cost  Delay to opening
Approve now, fund from new board money                 66       9 days
Approve but build after opening (phase 2)              71       0 days
Reject; use the meeting room booking system instead     0       0 days

The board asked whether a storage room could become a second community room, a popular request from community groups. The work would cost $66,000 and, because the partition and accessible counter fall in the finishes sequence on the critical path, delay opening by nine working days. It also needs a second accessibility review, a fire separation check, a permit amendment and the landlord's consent, each adding risk. The project manager presents three options: approve now with new board funding, approve as a phase 2 change built after opening (slightly more expensive, at $71,000, because of mobilizing again, but with no delay to opening), or reject and rely on the room booking system. The board chooses phase 2, so the opening date is protected, and the decision is recorded as deferred with a target date.

The change log at month 7

The change log is the record of every change request and its status. It allows anyone to see what has been requested, what was decided, by whom and why, and it feeds lessons learned and audits.

# Change log for Project Compass at month 7 ($000 and working days)
log = [  # id, type, description, requested by, decision, cost, days
 ("CR-01", "update", "Correct WBS dictionary entry for data cabling", "PM", "approved", 0, 0),
 ("CR-02", "corrective", "Third encoding station to recover tagging rate", "PM", "approved", 9, -4),
 ("CR-03", "scope", "Add children's story-time projector", "Branch manager", "approved", 4, 0),
 ("CR-04", "defect repair", "Replace mis-sized millwork at service desk", "Fit-out lead", "approved", 0, 0),
 ("CR-05", "scope", "Add drive-up returns window", "Board member", "rejected", 85, 15),
 ("CR-06", "preventive", "Two-week kiosk soak test (lesson LL-022)", "Technology lead", "approved", 5, 0),
 ("CR-07", "scope", "Second community room", "Board", "deferred to phase 2", 71, 0),
]
approved = [r for r in log if r[4] == "approved"]
print(f"{len(log)} requests: {len(approved)} approved, "
      f"{sum(r[4] == 'rejected' for r in log)} rejected, {sum('deferred' in r[4] for r in log)} deferred")
print(f"Approved cost changes: {sum(r[5] for r in approved)}; net schedule effect {sum(r[6] for r in approved)} days")
by_type = {}
for r in log:
    by_type[r[1]] = by_type.get(r[1], 0) + 1
print("By type:", ", ".join(f"{k} {v}" for k, v in sorted(by_type.items())))

7 requests: 5 approved, 1 rejected, 1 deferred
Approved cost changes: 18; net schedule effect -4 days
By type: corrective 1, defect repair 1, preventive 1, scope 3, update 1

Seven requests have been raised. Five were approved, adding $18,000 to the cost baseline; the third encoding station also recovered four working days on the tagging activity, whose float the slower tagging rate had been eating away. The drive-up returns window (CR-05), requested by a board member, was rejected at $85,000 and 15 days, because it was outside the branch's purpose and budget; the reason was recorded and the board member informed. The second community room (CR-07) was deferred to phase 2. Two other changes from month 7 are not in this log because they changed funding rather than scope: the sponsor's release of the $120,000 management reserve and the board's additional $50,000 approved after the month 6 forecast (lesson 6). Both were processed as changes to the cost baseline and recorded in the reserve log and the board minutes; lesson 12 shows the final effect.

Approved changes update the baselines. The cost baseline becomes $2.4 million plus the approved changes and the released reserve and additional funding; the schedule baseline is updated for approved schedule changes; and from that point, earned value is measured against the revised baselines. PMP-130 stressed the rule behind this: baselines change only through formal change control, never quietly to make variances disappear.

Configuration management

Configuration management controls the product and its documentation. It identifies the items under control (configuration items, such as drawings, specifications, software versions and kiosk firmware), records their versions and status, and verifies that the delivered product matches its approved documentation. Its three main activities are configuration identification, configuration status accounting and configuration verification and audit.

Change control and configuration management work together. Change control decides whether a change is made; configuration management makes sure that, once it is made, every affected item is updated and versions stay consistent. On Project Compass, the kiosk firmware version is a configuration item. When CR-06 added the soak test, the vendor proposed a firmware update to fix K6's card reader. That update was approved through change control, installed on all kiosks, recorded as version 4.2.1 in the configuration register and verified on each unit, so that the library will never again discover, as it did at the central library, kiosks running different firmware without anyone knowing.

Change in adaptive and hybrid projects

Adaptive approaches expect change and build a lighter mechanism into their structure. New ideas go into the product backlog, and the product owner reorders it continuously; the team commits only to the work for the current iteration, which is protected from change during the sprint except in unusual circumstances. This means that most feature changes need no change request at all. Changes to the things that bound the work, such as the release goal, the budget, the team or a fixed date, still go through governance.

Project Compass shows both sides. When patrons in testing asked for a "notify me when available" feature, the product owner added it to the backlog and prioritized it above room booking for the second release, with no change request, because the release goal and budget did not change. When the board later asked for the app to support three additional languages, which would need a translation contract and an extra sprint beyond the app budget, the request went to the CCB as a scope change.

Integrated change control in a project should also be distinguished from change enablement in IT service management, which ITIL-140 covered. ITIL change enablement assesses and authorizes changes to live services and infrastructure, such as deploying the kiosk firmware update into production; project change control decides changes to the project's scope, schedule, cost and plans. A single change may need both: the CCB approves adding the firmware fix to the project, and the library's IT change process schedules its deployment to the live system.