Key Concepts
Change on projects is inevitable, and the discipline is not avoiding it but managing it. This task covers making sure changes are recognized, reviewed by the right people, decided in line with governance, communicated honestly, and reflected in the plans the team works from.
Changes to projects are inevitable. Work is conducted over a life cycle in which the market, technology, and stakeholder requests continue to evolve. Denying all changes would make managing projects simpler, but that is not a luxury project managers have. The discipline this task covers is not change avoidance; it is change control. We make sure changes are recognized, reviewed by the right people, decided in line with our governance, communicated honestly, and reflected in the plans the team is working from.
Causes of Project Changes
Common sources of changes include:
- Missed requirements – items that were not captured initially but are now obviously needed. “Pressing the power button switches the hover-bike on. Pressing it again should switch it off.”
- New regulations – laws and policies change over time and may lead to project scope changes. “All hover-bikes must come with Wear-a-helmet stickers.”
- Specification changes – requirements change, or testing reveals the need to change a specification. “Upon testing, the hover-bike should default-hover at 15cm to avoid common obstacles such as curbs.”
- Inaccurate initial estimates – sometimes the original estimate for work is wrong. As more is learned about the tasks, the estimates and schedules need updating. “Bill’s 10-minute fix to the hill-stalling problem is in week 2 of development and is now re-estimated as a 4-week delay.”
- Market competition – competitor product releases or shifting perceptions force a rethink of the original business case or scope. “Mega-Smash-Bikes have launched a $999 hover-bike that will do 80 km/h. We need to match or exceed this and hire more injury lawyers.”
Predictive approaches try to limit the number of changes accepted so only the most critical get through. This protects the original plans and baselines but is problematic when change rates are high.
Agile approaches welcome change and continuously reprioritize the backlog to reflect remaining urgencies and new requests. This works when stakeholders understand the flexibility, and is problematic when people are expecting a largely unchanging upfront plan.
Hybrid approaches use lightweight versions of traditional artifacts (vision, scope, release plans), gain formal agreement on the core scope, and then empower the Product Owner to manage scope evolution inside that envelope. Anything that threatens the agreed envelope is escalated to a Change Control Board.
3.3.1 Execute the Change Control Process
The change control process is the set of agreed steps for handling a request from the moment someone raises it to the moment its outcome is recorded. The detail of the process varies by approach, but the elements are consistent: who can raise a change, what evaluation it gets, who decides, what tolerance applies, and what happens once the decision is made.
Change Management Plan
Predictive, plan-driven life cycles define how they will handle changes in a Change Management Plan. The document explains how the change control process works and documents the roles and responsibilities of the Change Control Board. Organizational culture directly influences how an organization manages changes. An organization in a highly regulated environment tends to have a cautious, formal, and rigid culture, leading to rigorous change procedures with multiple levels of approval. Organizations in new or rapidly evolving environments tend to take a lighter-touch approach.
A change management plan typically covers:
- Approval levels for changes
- The structure of the Change Control Board, if one is used
- The change control process itself
- The tools used to track and communicate change decisions
- The emergency change process
Change Control Board (CCB)
A Change Control Board is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project. The board represents key stakeholders and assesses changes in terms of cost, schedule, risk, and value impact. They are created to manage all change requests fairly. A CCB may meet on demand for high-priority requests or on a regular schedule, such as once a week or once a month. In addition to deciding on project changes, they are responsible for recording and communicating those decisions.
Once the CCB makes a decision, the scope of the change is compared to the established tolerance thresholds. Changes inside thresholds can be approved and initiated by the project manager. Changes outside the thresholds usually require the project sponsor to approve.
Product Owner as a Change Control Board
Agile approaches are often used in high-change environments where many scope and trade-off decisions need to be made daily. In those situations, getting the change control board together, bringing them up to speed, and letting them debate the pros and cons would just take too long. Instead, the Product Owner is empowered by the business to make scope, priority, and change decisions on behalf of the sponsor. They are trusted to do the right thing, act on behalf of the business and customers, and manage the bulk of all change decisions themselves. Unless a change would materially affect the project outcome, the Product Owner approves, rejects, and defers changes daily.
Product Owners often consult with the Scrum Master, team lead, and team members to get information about estimates, dependencies, and risks, but otherwise have the autonomy to make project decisions.
3.3.2 Communicate the Status of Proposed Changes
Change requests live in a queue between “raised” and “decided,” and stakeholders need visibility into where their request sits. The cost of poor change-status communication is twofold: stakeholders push the same request through multiple channels, and the team starts working on items they think are approved but are not.
Practical communication of proposed changes covers a few basic disciplines:
- A single source of truth – every active change request has a unique identifier and a current status (proposed, under review, approved, rejected, deferred, implemented). Tracked in a tool everyone can see.
- Visible status updates – change status appears in regular project reports and on information radiators (dashboards, change logs on the project site, or a column on the team’s board).
- Direct communication with the requester – the person who raised the change is told the decision and the reasoning, not just left to find out by accident.
- Stakeholder briefings before the decision lands – for changes that materially affect cost, schedule, or scope, key stakeholders hear about the proposal and the recommendation before the formal decision is communicated. This avoids surprises in front of an audience.
In agile environments, the backlog is the change-status board. New requests sit in the backlog with a priority, and reprioritization is visible at every iteration planning meeting. The discipline is the same: stakeholders should never have to guess where their request stands.
3.3.3 Implement Approved Changes to the Project
As the project progresses, we continuously monitor change requests, risks, issues, and team performance. Then, based on these factors and customer or sponsor guidance, we update our plans to deliver project outcomes and comply with our organization’s agreed procedures
Integrated Change Management
Traditional projects manage compliance and change through Integrated Change Management. When a potential change is identified, it is sent to the Change Control Board, which evaluates it. The CCB assesses the change against the scope as defined by the charter and weighs the options. The CCB decides, updates the change request status, and communicates their decision to the relevant stakeholders. If the change was approved, the project manager starts updating and re-baselining the plans. The change is then actioned through execution of the revised plans.
Changes and the Backlog
Using agile approaches, the Product Owner runs steps similar to Integrated Change Management, just by themselves and with less documentation. The Product Owner monitors the internal and external business environment for opportunities, threats, and change requests that might affect the project. When a potential change is identified, they evaluate it, consult with stakeholders such as customers and team members, and decide whether to decline, defer, or approve.
If approved, the change is given a priority and placed in the backlog, which displaces lower-priority items down the list. There is a “water-line” of agreed work below the original backlog. Accepting a change means the Product Owner and other stakeholders accept that it displaces a similarly sized lower-priority piece of work. We can accept changes even late in the life cycle, but we cannot defy the laws of time and space.
An important note about agile projects: all work goes in the backlog. We do not maintain a separate list of change requests or defect fixes. Everything lives in the backlog, so priorities and remaining work stay visible to everyone.
Backlog Reprioritization
In addition to new requests or changes being introduced into the product backlog. Product Owners also reprioritize items in the backlog as priorities change.
3.3.4 Update Project Documentation to Reflect Changes
Approving a change does not finish the work; it starts the next round of bookkeeping. The project documentation has to reflect the new reality, or the team will be working from one set of assumptions while reporting against another.
Documents that typically need updates after an approved change include:
- Scope statement, WBS, or backlog, depending on approach
- Schedule and updated baselines
- Cost baseline and budget
- Risk register, where the change introduces or retires risks
- Quality management plan, where the change affects acceptance criteria
- Stakeholder register, where new groups become affected
- Communication plan, where the change affects audiences or cadence
- Project management plan or product roadmap
Re-baselining
Once an approved change affects the agreed cost, schedule, or scope baseline, the project manager re-baselines so future variance reports compare against the new agreement. Without re-baselining, every status report shows the same growing variance, which obscures whether current execution is on track. Re-baselining requires the same governance authority that approved the change in the first place; project managers do not unilaterally adjust baselines because variance numbers look bad.
Configuration Management
On product-heavy projects, changes also flow through configuration management to keep deliverable versions, related documentation, and approval records aligned. The change control process and the configuration management system work together: change control decides whether something gets done, and configuration management tracks what version is in play once the change is implemented.
Lessons Learned Register
Significant changes are usually rich material for the Lessons Learned Register. Why did the change occur? Was it preventable, or to exploit a great opportunity? What signal did we miss earlier in the project that would have surfaced this need sooner? Capturing these lessons during the project, rather than only at closure, makes them useful to the current team and to other projects in the organization.
Deliverables and Tools
- Change Management Plan – A component of the project management plan documenting the change control process, approval levels, the structure of the Change Control Board, the tools used to track and communicate decisions, and the emergency change process.
- Change Control Board (CCB) – A formally chartered group representing key stakeholders, responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project, and for recording and communicating those decisions.
- Change Request – A formal proposal to modify any project document, deliverable, or baseline. Includes the proposed change, its business value, risks, mitigation, and likely cost.
- Change Log – A register of all change requests, their status, decisions, dates, and owners. Acts as the single source of truth for change activity on the project.
- Integrated Change Management – The traditional, end-to-end process by which changes are identified, evaluated by the CCB, decided, baselined, and executed through revised plans.
- Product Owner – The agile role empowered by the business to act as the change control authority for day-to-day scope and priority decisions, escalating only changes that materially affect outcomes.
- Product Backlog – The agile equivalent of the change log: all work, including new requests and changes, lives in the backlog with a priority, displacing lower-priority items below the agreed water-line.
- Baselines (Scope, Schedule, Cost, Performance Measurement) – The approved versions of the plan against which progress and variance are measured. Updated through formal change control when changes are approved.
- Configuration Management System – A collection of procedures, usually computer-based, that tracks project artifacts and controls the versions of deliverables and related documentation.
- Tolerances – Acceptable ranges of variation around scope, schedule, cost, and other project variables that determine whether the project manager can decide or must escalate.
- Project Charter – The authorizing document that defines the agreed scope against which the CCB evaluates incoming change requests.
- Risk Register – Updated where an approved change introduces, modifies, or retires risks.
- Stakeholder Register and Communication Plan – Updated where an approved change affects who is involved or how information is shared.
- Lessons Learned Register – Used to capture lessons from significant changes during the project rather than only at closure.
Related Topics
- 1.4 Engage stakeholders
- 2.1 Develop an integrated project management plan and plan delivery
- 2.2 Develop and manage project scope
- 2.8 Plan and manage schedule
- 2.9 Evaluate project status
- 3.1 Define and establish project governance
- 3.2 Plan and manage project compliance
- 3.5 Plan and manage risk
- 3.7 Support organizational change
- 3.8 Evaluate external business environment changes
- PMP Mind Map
FAQ
Is the goal to prevent all changes?
No. Change avoidance would make managing projects simpler, but it is not realistic; the discipline is change control, not change prevention.
What does change control involve?
Recognizing changes, reviewing them with the right people, deciding in line with governance, communicating honestly, and updating the plans.
What causes project changes?
Missed requirements, evolving markets, technology shifts, and stakeholder requests, among other sources.
How does this task fit into the 2026 PMP exam?
Task 3.3 sits in the Business Environment domain of the 2026 Exam Content Outline. The 2026 PMP Exam page has the domain and task breakdown and what changed in the new exam.
