Navigation Section
Change – From a Project Management Perspective
References
***Change is not a disruption — it’s a certainty.
Change is Inevitable
Every project plan seems stable until it meets the real world. And in the real world, things move. Requirements evolve, priorities shift, technologies emerge, risks materialize, and stakeholders change their minds. In project management, The presence of change is not a sign of poor planning. In fact, the ability to respond to change deliberately is one of the defining traits of a well-managed project. A change-aware project manager doesn’t resist the unexpected. They expect it — and prepare to manage it in a way that aligns with both delivery and value.
When preparing for the PMP exam, it’s critical to understand that PMI does not treat change as negative by default. What matters is how it is identified, assessed, and integrated into the project system. Projects that embrace structured change are more likely to stay relevant and deliver value (see PMBOK 6 and PMBOK 7 in References).
What This Page Is About
This page explores what change really means in the context of PMI’s project management framework. It offers a grounded understanding of:
- What “change” refers to in a project
- How it impacts project elements like scope, schedule, and cost
- Why managing change is a leadership function, not just a control mechanism
- What PMI expects project managers to do with change requests and emerging issues
- How change can be both a source of opportunity and a source of risk
By the end, you’ll have a foundation solid enough to recognize how much you don’t yet know — and exactly where to look next (including The Discipline of Organizing in References).
What Is Change?
Change in PMI’s terms refers to any intentional or unintentional modification to the baseline of a project — including scope, schedule, budget, quality, resources, or risk posture. It can originate from nearly any direction: it can come from and OPAs; a stakeholder may adjust expectations, a compliance regulation may shift midstream, or project work might reveal flawed assumptions or hidden dependencies.
The key is that change always alters the agreed-upon plan in some way. It introduces uncertainty and often requires re-evaluation of decisions previously considered “locked.” PMI expects project managers not to fear change, but to anticipate it and manage it using an integrated, principled approach.
You don’t need to memorize a definition to succeed on the exam — you need to recognize when a situation represents a change, and what disciplined steps follow. Understanding the difference between evolving project needs and unmanaged scope creep begins here.
Why Change Is Often a Good Thing
Handled correctly, change is not a threat — it’s a value signal. It’s a way of keeping the project aligned with real-world needs, not just sticking rigidly to an outdated plan. A stakeholder refining their requirements may improve final usability. A market-driven scope shift may create new revenue opportunities. A discovered technical capability may shorten delivery timelines.
Good change happens when the environment shifts and the project responds instead of resists. It protects relevance. It reflects agility. And it often increases stakeholder satisfaction — not by adding work, but by delivering more of what matters.
PMI favors this mindset: a change that increases value is worth exploring. But it must still pass through a process — not just be accepted informally.
Why Change Can Be Harmful
Despite its benefits, change becomes harmful when it’s not managed with care. Uncontrolled change leads directly to the most common project problems: Schedule Slippage, cost overruns, loss of scope clarity, and stakeholder confusion.
This happens when changes are implemented without analysis, approval, or communication. When one stakeholder pushes through a requirement midstream without consulting the team. When a developer makes updates before understanding the impact. Or when the change process is bypassed entirely in a rush to satisfy short-term demands.
PMI flags these behaviors on the exam as indicators of misalignment and poor governance. You won’t be asked whether change is good or bad — but you will be tested on whether it was handled correctly.
How PMI Defines Change Management
Change management is not a single document or role. It’s a set of structured activities that ensure all proposed changes are captured, assessed, approved, and implemented in a way that protects the project’s integrity.
A change doesn’t become “managed” just because it’s discussed. PMI expects you to follow a disciplined process, typically along these lines:
- Identification and logging — the change is recognized and formally recorded using a change request and entered in the change log.
- Impact analysis — the potential effects on cost, time, scope, quality, risk, and resources are examined.
- Review and decision — the Change Control Board (or authorized entity) evaluates and either approves, rejects, or defers the change.
- Implementation — no change is applied until it is formally approved, and adjustments are reflected in the updated baselines.
On the exam, questions that skip this order — or implement before approval — are nearly always distractors. PMI prioritizes transparency, traceability, and accountability over speed or convenience.
The Role of Governance and Configuration
To understand change fully, it helps to see it within the broader landscape of project governance. Change control is not isolated; it intersects with configuration management — the system for ensuring that product versions, documents, and deliverables are consistently tracked and verified.
PMI separates change control (deciding if something should change) from configuration control (tracking what has changed and ensuring it’s correct). Both exist to protect project consistency.
Changes that affect deliverables — like a design update or a version upgrade — must pass through both systems to ensure the final output matches the revised requirements.
Explore more in Range (Epstein, 2019) in References.
Where Change and Leadership Intersect
Change isn’t just about control — it’s about communication. High-performing project managers don’t wait for change to become a crisis. They create visibility around uncertainty, open conversations about impacts, and invite cross-functional input before decisions are made.
This includes surfacing hidden risks tied to changes, clarifying who will be affected, and protecting Project Scope from becoming bloated by well-intended requests. It also includes advocating for change when it’s the right move — even if it’s politically risky.
Change is not just a technical layer of process — it’s a leadership behavior.
Questions Worth Asking
When you understand the foundations of change, you begin to uncover deeper lines of inquiry:
- How do I recognize when a suggestion is actually a change request?
- What tools help me track changes across baselines?
- When is stakeholder pushback a change in disguise?
- How do configuration and change control reinforce each other?
- What’s the cost of accepting change informally, even when it seems harmless?
- How can Agile teams manage change without formal CCBs?
Let these questions drive further exploration — in the Glossary, in your courseware, or in practice exam reviews. PMI won’t ask you to recite a definition — but it will expect you to think like a project manager when change shows up.