What You’ll Learn in This Post
- The two distinct meanings of change management in project management — and why confusing them causes real problems
- How the change control process works — from change request through impact assessment to formal approval
- What a change request form must contain and how a change log keeps the project audit trail intact
- The ADKAR model and Kotter’s 8-Step framework for managing organizational change
- The most common reasons change management fails — and how experienced PMs prevent each one
- Real-world change management examples across banking, construction, retail, IT, and healthcare
Change management in project management refers to two related but distinct disciplines that every project manager must understand and apply. The first is project change control — the formal process that governs how changes to scope, schedule, cost, or quality are requested, assessed, approved, and tracked within a project. Organizational change management is the second discipline — ensuring that the people affected by a project’s outcome actually adopt and sustain the new ways of working, systems, or structures the project delivers. Both matter. Neither works without the other.
Specifically, in this post we cover both definitions in full, walk through the change control process step by step, explain the change request form and change log, introduce the ADKAR model for organizational change, examine why change management fails, and provide real-world examples across five industries.
What Is Change Management in Project Management?
Change management in project management sits at the intersection of two professional disciplines — project delivery and people leadership — and the term means something different depending on which context it is used in. Understanding the distinction is essential, because the tools, processes, and skills required for each are fundamentally different.
“A comprehensive, cyclic, and structured approach for transitioning individuals, groups, and organizations from a current state to a future state with intended business benefits.”
— A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute (PMI)
Change management in project management means two things in practice. Within the project itself, it is the process that prevents unauthorized changes from quietly expanding scope, shifting the schedule, or burning through budget without a formal decision. For the people and organization the project affects, it is the structured effort to ensure that when the project delivers something new — a system, a process, a structure — people actually use it as intended rather than reverting to the old way within three months of go-live.
The PMP exam uses the term “Integrated Change Control” — a specific PMBOK process that ensures all change requests are reviewed, all impacts are assessed across scope, schedule, cost, and quality, and all approved changes are formally incorporated into the project management plan and baselines. Importantly, remember that the project manager does not have unilateral authority to approve changes that affect the project baseline — those decisions belong to the Change Control Board (CCB) or project sponsor, depending on the governance structure defined in the project charter.
The Change Control Process — Step by Step
The change control process — a core element of change management in project management — is the structured sequence that every requested change to a project must pass through before it is implemented. Without this process, changes accumulate informally — picked up in conversations, absorbed by the team without assessment, and delivered without a corresponding update to the baseline. The result is a project whose actual scope, schedule, and cost bear no resemblance to the approved plan by Week 8 of a 20-week delivery. Consequently, establishing the change control process during project initiation — before the first change request arrives — is non-negotiable.
Change Request Submitted
Any stakeholder — sponsor, business owner, end user, or team member — may submit a change request. All requests must be submitted in writing using the project’s standard change request form, not verbally or via email without a formal log entry. The PM’s responsibility at this stage is to ensure every request is captured — regardless of whether it seems significant — because small, informal changes are how scope creep begins. A numbered change request ID is assigned immediately on submission so the request can be tracked through the process.
Impact Assessment Conducted
Before any decision is made, the PM and relevant subject matter experts assess the impact of the proposed change across all four constraint dimensions: scope, schedule, cost, and quality. This assessment is the most critical step in the process — it transforms a vague request into a concrete decision. Additionally, the assessment should identify any dependencies the change creates or disrupts, any risks introduced by implementing or rejecting the change, and any effect on previously approved deliverables or baselines.
Change Control Board Reviews and Decides
The completed impact assessment is presented to the Change Control Board (CCB) — or the project sponsor if no formal CCB exists — along with the PM’s recommendation. After reviewing the request, impact, and options, the CCB makes one of three decisions: approve, reject, or defer. Critically, deferred changes are not abandoned — they are held for a future decision when more information is available or when the project’s constraint situation changes. All three decision outcomes are recorded in the change log.
Approved Changes Are Baselined
When a change is approved, the project management plan, schedule, budget, and scope baseline are formally updated to reflect the change before implementation begins. This step is routinely skipped under delivery pressure — teams implement approved changes but forget to update the baseline, which means the project’s performance measurement is now based on a plan that no longer reflects reality. Consequently, every approved change must trigger a baseline update as a mandatory action, not an optional administrative task.
Change Is Implemented and Closed
The approved change is implemented according to the updated plan. Upon completion, the PM confirms that the change has been delivered as specified, updates the change log with the implementation date and outcome, and formally closes the change request. Furthermore, any lessons from the change — particularly if the impact assessment proved inaccurate or if the change revealed a gap in the requirements process — should be captured in the project’s lessons learned log for future reference.
The Change Request Form and Change Log
The change request form and the change log are the two foundational documents of project change control. Together, they create the audit trail that lets any stakeholder — or auditor — see exactly what was requested, what was decided, who made the decision, and what it cost the project in scope, time, or money. Without both, there is no defensible record of how the project evolved from its original baseline.
What a Change Request Form Must Contain
| Field | What to Record | Why It Matters |
|---|---|---|
| Change ID | Unique reference number assigned on submission | Enables tracking across the log, email chains, and meeting minutes |
| Requested by | Name, role, and date of the person submitting the request | Establishes accountability and provides context for the request’s origin |
| Change description | Clear description of what is being requested and the reason for the request | Prevents ambiguity during impact assessment and CCB review |
| Impact on scope | What new work is added, what existing work is modified or removed | Drives the scope baseline update if approved |
| Impact on schedule | Number of days added or saved; effect on milestones and deadlines | Drives the schedule baseline update if approved |
| Impact on cost | Additional budget required or savings generated | Drives the cost baseline update if approved |
| Risk assessment | New risks introduced by implementing or rejecting the change | Ensures the CCB understands the full risk picture before deciding |
| Decision | Approved / Rejected / Deferred — with the decision-maker’s name and date | Creates the formal audit record of who authorized the change |
Tracking change requests in email threads or meeting minutes is a reliable path to a disputed project baseline. A dedicated change log gives every request a numbered entry, a decision status, and a cost-to-date impact summary that the PM can report to the sponsor at any status meeting. Download our free Project Plan Template — it includes a pre-formatted change log alongside the risk register, issue log, and RAID log so all four tracking tools are in one place from day one.
Organizational Change Management — ADKAR and Kotter
The organizational dimension of change management in project management — often abbreviated as OCM — is the discipline of helping people move from a current state to a new one. Projects that deliver new systems, processes, structures, or behaviors without investing in OCM frequently achieve technical success and business failure: the deliverable is built, deployed, and then quietly abandoned or worked around because the people expected to use it were never truly ready to do so.
The ADKAR Model
Developed by Prosci, ADKAR is the most widely used individual change management framework in organizational and project contexts. It describes the five building blocks a person needs to successfully adopt a change — and it is sequential, meaning each stage must be achieved before the next is possible. Consequently, diagnosing which stage is missing tells the PM exactly where to intervene rather than defaulting to blanket communication campaigns or repeat training.
In practice, most project-related change failures can be traced back to a specific ADKAR gap. Specifically, a CRM system that users bypass likely has a Desire or Ability gap — users understand the change exists (Awareness) but either do not want it or cannot use it effectively. A new process that staff follow for 6 weeks then quietly abandon likely has a Reinforcement gap — the behavior was adopted initially but not embedded into management accountability or system incentives. Identifying which ADKAR stage is failing allows the change manager to target the right intervention rather than defaulting to “more training” as the universal solution.
Kotter’s 8-Step Model
Where ADKAR focuses on the individual, Kotter’s 8-Step Model addresses the organizational level — the leadership actions required to drive large-scale change successfully. The eight steps are: Create Urgency, Build a Guiding Coalition, Form a Strategic Vision, Enlist a Volunteer Army, Enable Action by Removing Barriers, Generate Short-Term Wins, Sustain Acceleration, and Institute Change. While Kotter’s model is more commonly applied to enterprise-level transformation programs than individual projects, understanding it helps PMs communicate the importance of leadership engagement and early wins in gaining and sustaining stakeholder support. In practice, even mid-size project PMs benefit from applying Kotter’s first two steps — creating urgency and securing a visible guiding coalition — well before go-live to build the organizational momentum the ADKAR Desire stage depends on.
Why Change Management Fails — 6 Root Causes
Change management in project management fails in predictable ways. Understanding these root causes allows PMs to build preventive measures into the project plan before the failure patterns emerge — because by the time the symptoms are visible, the window for easy intervention has usually passed.
In my experience, the single most common change management failure I encounter is not a broken process — it is a process that exists on paper but gets bypassed under delivery pressure. A sponsor calls the PM on a Friday afternoon and asks for a “small tweak.” The PM says yes verbally. The team implements it Monday. No change request. No impact assessment. No baseline update. Do this three times on a single project and you have created a culture where the change control process is optional — and by Week 12, nobody is using it. The PM must therefore enforce the process consistently from the very first change request, regardless of how minor the request appears — because process credibility, once lost, is extremely difficult to rebuild mid-project.
Change Management in Project Management — Examples Across Five Industries
Change management in project management takes a different form depending on whether the challenge is project change control, organizational change management, or both. The examples below illustrate how each type presents in real project environments and what the PM’s response looks like when it is handled well. Note particularly that the failure examples are not edge cases — they are the most common patterns encountered across industries.
| Industry | Project Type | Change Management Challenge | Type | Outcome |
|---|---|---|---|---|
| 🏦 Banking | Core banking platform replacement | Sponsor requested 14 scope additions over 16 weeks — each framed as “minor.” Without a formal change control process, cumulative schedule impact was 11 weeks and budget impact was $430,000 before the PM surfaced the issue | Project Change Control failure | Formal CCB established in Week 4 with a $50,000 approval threshold. All prior informal changes documented retroactively. Baseline renegotiated with sponsor. |
| 🏥 Healthcare | Electronic prescribing system rollout | Physicians resisted the new system at go-live — preferring to verbally dictate prescriptions to nurses who then entered them, bypassing the system entirely | Organizational Change Management (ADKAR Desire gap) | Physician champion program launched 8 weeks pre-go-live. Compliance tracked and reported to department heads. Adoption reached 91% within 60 days of go-live. |
| 🏗️ Construction | Commercial office fit-out | Client requested 7 design changes between Week 3 and Week 9, each submitted verbally on site visits. PM lacked a formal change request process and absorbed changes informally | Project Change Control failure | Formal variation order process introduced in Week 10. Each change priced, documented, and client-signed before work began. Avoided dispute at final account stage. |
| 💻 IT / Software | CRM platform implementation | Sales team continued using spreadsheets 3 months post-go-live, citing the CRM as “too complicated for daily use” | Organizational Change Management (ADKAR Ability gap) | Role-based training delivered in Week 2 post-go-live. Power users identified in each team as peer support contacts. Manager reporting dashboards built in the CRM to incentivize data entry. Adoption reached 84% within 45 days. |
| 🏪 Retail | New warehouse management system | Operations director approved the project scope in Week 1, then requested a real-time inventory dashboard in Week 7 — a significant technical addition estimated at $85,000 and 3 weeks of additional development | Project Change Control — formal process handled correctly | Change request raised same day. Impact assessment delivered within 48 hours. CCB approved with budget increase and 2-week timeline extension. Baseline updated before development started. |
On a core banking platform replacement for a regional US bank, the project launched with a clearly defined scope baseline and a 28-week delivery timeline. By Week 9, the IT steering committee had informally requested six enhancements — additional reporting views, a mobile banking integration, and an enhanced fraud alert module — each framed as “just a small addition” in steering committee minutes. None had gone through a formal change request process. The project manager, under pressure to maintain positive relationships with the committee, had absorbed each request into the team’s backlog without a formal impact assessment or baseline update.
By Week 14, the development team reported they were 6 weeks behind schedule. When the PM conducted a retroactive change impact analysis, the six informal additions accounted for 5.2 weeks of the overrun and $218,000 in unplanned labor costs. As a result, the PM presented the full picture to the bank’s CTO — including the audit trail of informal approvals in steering committee minutes — and proposed two options: formally approve the additional scope with a revised budget and timeline, or descope three of the six additions and recover 3 weeks. The CTO chose the second option. Subsequently, a formal CCB with a $25,000 approval threshold was established the following week. No further informal additions were absorbed for the remainder of the project. The lesson, learned at significant cost, was that the change control process must be enforced from Week 1 — not introduced as a corrective measure in Week 14.
How to Apply Change Management in Your Project
Effective change management in project management requires deliberate setup before the first change request arrives and consistent discipline throughout delivery. The framework below covers both project change control and organizational change management — because the strongest project outcomes come from applying both simultaneously, not treating them as separate workstreams.
Define the Change Control Process in the Project Charter
Before the project begins, document the change control process in the project charter or project management plan. Specifically, define: who can submit change requests, who has authority to approve changes at each cost threshold, how impact assessments will be conducted and by whom, and what the turnaround time commitment is from submission to decision. This information must be communicated to all stakeholders at the project kickoff meeting — not distributed quietly as an attachment to the charter that nobody reads.
Set Up the Change Log from Day One
The change log — a numbered register of every change request, its impact assessment, decision, and implementation status — must be created and shared with the project team and sponsor before the first change request arrives. A change log that is created reactively, after informal changes have already been absorbed, is a damage assessment tool, not a management tool. Furthermore, use our free Project Plan Template, which includes the change log as a dedicated sheet pre-formatted for immediate use alongside the risk register and issue log.
Conduct a Stakeholder Assessment for Organizational Change
For projects that deliver changes affecting how people work, conduct a structured stakeholder assessment during the planning phase to identify who will be affected, how significantly, and what their likely initial attitude toward the change will be. This assessment feeds directly into the ADKAR framework — identifying which stakeholder groups are at risk of Awareness, Desire, Knowledge, Ability, or Reinforcement gaps. Additionally, it identifies the organizational change champions — respected peers and managers — whose visible support will ultimately carry more weight with affected staff than any formal communication from the project team.
Enforce the Process — Every Single Time
The change control process has zero value if it is applied selectively. Every change request — regardless of how minor it appears, how senior the requestor is, or how much delivery pressure exists — must pass through the formal process before implementation. However, the process does not need to be slow: a well-designed change control framework can assess, decide, and baseline a straightforward low-cost change within 24–48 hours. The PM’s job is to make the process fast enough that bypassing it offers no practical advantage.
Plan for Reinforcement Beyond Go-Live
Organizational change management does not end at go-live — it enters its most critical phase. The Reinforcement stage of ADKAR requires that the new behaviors, processes, and systems are embedded into the organization’s management structure, performance metrics, and daily accountability routines before the project team disbands. Furthermore, a post-implementation review at 30, 60, and 90 days post-go-live is the most effective mechanism for identifying adoption gaps early enough to intervene before reversion patterns become permanent. Build this review cadence into the project plan before closure, with a named business owner responsible for monitoring and reporting adoption metrics.
🎯 Key Takeaways — The 90-Second Summary
