Manage and Control Changes
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
Imagine launching a satellite into low Earth orbit. The initial trajectory—the baseline—is calculated with exacting precision. Yet, once in motion, atmospheric drag, gravitational anomalies, and solar radiation exert their influence. If the flight director ignores these forces, the satellite drifts into the void. Conversely, if every engineer is permitted to unilaterally fire the thrusters whenever they notice a variance, the result is equally chaotic. Managing project change requires the same rigorous balance. It is not about building an impenetrable fortress against alterations, but rather establishing a deliberate, systematic mechanism to evaluate, approve, and integrate necessary course corrections without destabilizing the entire endeavor.
In project management, this systematic mechanism is called the Perform Integrated Change Control process, which is a critical component of the Project Integration Management knowledge area. Think of Integration Management as the central nervous system of your project; it ensures that a tweak to the schedule does not inadvertently blow up the budget or introduce catastrophic risk.
To govern this, we rely on the change management plan. This foundational document removes ambiguity by explicitly defining the procedure for submitting, evaluating, and approving project change requests.
At the center of this process is the concept of a baseline. A project baseline is the approved version of a work product—be it the schedule, budget, or scope. It represents the yardstick against which all performance is measured. Because it is the foundational truth of your project, a project baseline can be changed only through formal change control procedures.
The real world is messy, and changes can originate from anywhere. Any project stakeholder may submit a formal change request to the project. This includes the end-user testing a software prototype, the structural engineer on a construction site, or the CEO responding to market shifts.
However, we must strictly separate hallway chatter from actionable data. If a stakeholder catches you in the elevator and asks for a "minor tweak" to a deliverable, you must enforce a cardinal rule of project management: a verbal change request must be documented in writing before the change request can be processed. Writing it down forces clarity, defines the scope of the request, and injects the request into the formal control system.
Change requests generally fall into one of three specific categories:
| Type of Change Request | What it Does | Real-World Example |
|---|---|---|
| Corrective Action | A change request intended to realign the performance of project work with the project management plan. | A team is falling behind schedule, so they request authorization to work weekend overtime to catch up. |
| Preventive Action | A change request intended to ensure the future performance of the project work aligns with the project management plan. | Upgrading a server's cooling system before the summer months to prevent anticipated thermal throttling. |
| Defect Repair | A change request to modify a nonconforming product component. | Rewriting a block of code that failed quality assurance testing because it caused the application to crash. |
When a formal, written change request lands on your desk, you do not simply rubber-stamp it based on how good it sounds. You must act as an investigator. The project manager evaluates the impact of every change request on the overall project constraints. You are looking for the ripple effects.
For every single proposed change, the project manager must:
- Assess the impact of a proposed change on the project schedule. (Will this delay the launch?)
- Assess the impact of a proposed change on the project budget. (Will this require an extra $50,000 in raw materials?)
- Assess the impact of a proposed change on project risks. (Does adopting this new technology introduce untested security vulnerabilities?)
- Assess the impact of a proposed change on project quality requirements. (Will rushing this feature degrade the user experience?)
Alongside the high-level constraints, you must also trace the physical realities of the product. This is where the configuration management system comes in. While change control focuses on project documents and baselines, a configuration management system tracks changes to both the physical characteristics and the functional requirements of the project deliverables. If an engineer wants to change a 10mm bolt to a 12mm bolt, the configuration management system ensures that every subsequent diagram, safety manual, and procurement order reflects that specific physical change.
One of the most common pitfalls for a project manager is the hero complex—believing you possess the authority to authorize any change that makes sense to you. This is false. The project manager cannot unilaterally approve changes that affect the established project baselines.
Because baselines represent the fundamental agreement between the project team and the business, changes to project baselines can only be approved through the Perform Integrated Change Control process.
So, who holds the gavel? In formal predictive environments, that responsibility falls to the Change Control Board (CCB).
Change Control Board (CCB): A formally chartered group responsible for reviewing changes to the project.
The CCB is not an advisory committee; it is a decision-making body. A Change Control Board has the authority to:
- Approve proposed project changes.
- Reject proposed project changes.
- Defer proposed project changes (often requesting more data or waiting for a more strategic time to implement).
Occasionally, a change is so massive—perhaps requiring an additional $2 million in funding, or a pivot in corporate strategy—that even the CCB lacks the jurisdiction to decide. In these instances, the project sponsor is typically the final escalation point for change requests that exceed the authority of the Change Control Board.
The Change Log
The central nervous system of this communication is the change log, which tracks the current status of all submitted change requests. The project manager uses the change log to communicate the current status of proposed changes to project stakeholders.
Transparency is mandatory. Whether the news is good or bad, the project manager must communicate the approval of a change request AND the rejection of a change request to the relevant stakeholders. Furthermore, stakeholders don't just need to know that a change was approved; they need to know what it costs. Therefore, the project manager must inform stakeholders about the schedule impact and the cost impact of an approved change.
Updating the Baselines
An approved change alters the DNA of the project, meaning the project's documentation must immediately reflect the new reality.
- The project manager must update the project management plan to reflect approved change requests.
- The project schedule baseline must be updated following the approval of a schedule-altering change request.
- The project cost baseline must be updated following the approval of a cost-altering change request.
- The project scope statement must be updated if an approved change request alters the project scope.
- Crucially, a work breakdown structure (WBS) must be updated when a change request adds new deliverables to the project scope.
The Rule of Implementation
Until the paperwork is signed and the baselines are updated, the project team must hold the line. Only approved change requests can be implemented by the project team. To prevent unauthorized scope creep or "gold plating," the rule is absolute: a project team member cannot implement a change request before receiving formal approval.
The rigorous CCB framework we just explored is typical of traditional, predictive (Waterfall) projects. But what happens when we shift the paradigm toward Agile, where changing requirements are literally welcomed late in development?
The Agile Approach to Change
In Agile methodologies, the heavy bureaucratic machinery of a CCB is intentionally dismantled to allow for rapid adaptation. Here, the Product Owner manages project changes by reprioritizing items in the product backlog.
If a stakeholder has a brilliant new idea midway through the project, they don't fill out a rigid change request form for a board to review. Instead, new requirements are incorporated into the product backlog. The Product Owner evaluates the business value of that new requirement and places it appropriately in the queue. Because of this, execution-level changes bypass the formal Change Control Board process.
However, Agile is not anarchy; it simply places its boundaries elsewhere. While the overall backlog is fluid, the immediate work is strictly protected. Agile teams typically freeze changes to the sprint backlog once a sprint begins. This allows the team to focus purely on execution during the iteration without the whiplash of mid-sprint pivots.
The Hybrid Reality
Many modern organizations exist in a gray area, utilizing a Hybrid methodology that blends predictive governance with agile execution. In these environments, you must segregate your change control strategy by altitude:
- Strategic project changes often require formal Change Control Board approval. (e.g., "We are pivoting the software's architecture from an on-premise model to a cloud-based SaaS model.")
- Operational execution-level changes are often managed dynamically via the product backlog. (e.g., "Based on user feedback from Sprint 2, let's change the layout of the user dashboard in Sprint 3.")
Mastering the Perform Integrated Change Control process is ultimately about mastering momentum. Whether you are leading a predictive defense contract overseen by a rigid CCB, an agile software build guided by a Product Owner, or a hybrid of the two, your job remains the same: ensure that every change is evaluated, documented, and aligned with the ultimate goals of the endeavor.