Change Control: Assess and Approve Before You Implement

Most of the changes that wreck projects do not come through the door but through the window: a small request in a corridor, a verbal approval, execution the same day. Nobody objects, because each change on its own is reasonable. Three months later the team discovers the schedule has slipped and the budget is over, and nobody can say exactly when. Change control is not deliberate slowness but a mechanism that makes the impact of each request visible before it is committed to. The Eighth Edition adds an important timing constraint: changes are not formally controlled until baselines are established.

Definition and Foundation

A change request is a formal proposal to modify a document, deliverable, or baseline, and it may be initiated internally or externally to the project. Four elements surround it in the Eighth Edition:

• The change management plan — a component of the project management plan that establishes the change control board, also known as a steering committee, documents the extent of its authority, describes how the change control system will be implemented, and sets out the board's roles and responsibilities.
• The configuration management plan — it should specify which project artifacts are subject to configuration control. Changes to those artifacts require a formal change request.
• The change log — a comprehensive list of changes submitted during the project, including the current status of each. The disposition of all change requests is recorded there as a project document update.
• The change control board (CCB) — a formally established group responsible for reviewing, evaluating, approving, deferring, or rejecting changes, and for documenting and communicating those decisions.

The Eighth Edition sets the timing threshold plainly: in predictive approaches, changes are not formally controlled until baselines are established. Once the project has a baseline, all changes should go through a formal process to assess and implement them.

And the type of change request management applied depends on the scope of the project, its complexity, the contract requirements, and the development approach being used. The change route is not one template imposed on every project but something tailored to context. A small project under a flexible contract does not need what a construction project under a fixed-price contract needs, and imposing the second on the first obstructs without return.

How It Works in Practice

From request to decision

Although changes can be initiated verbally, they should be documented in writing and entered into the change or configuration management system. Change requests should typically include information on the estimated schedule and cost impacts before they can be approved. If a request impacts a project baseline, integrated change control measures should follow a formal process to assess and implement those changes. Each documented change request should be approved, deferred, or rejected by a designated person — such as the project sponsor or project manager — as specified in the project management plan or organizational procedures.

Request types and decision outcomes

The Eighth Edition presents the change route as a flow: a request enters as a corrective action, a preventive action, a defect repair, or an update; it passes through an impact analysis covering scope, finance, schedule, resources, stakeholders, and risk; and a decision issues as one of four — approved, rejected, deferred, or more information. That fourth one matters, because it breaks the common binary: not every request is answered with a yes or a no.

The board's role and the manager's conduct while waiting

When applicable, a change control board or project board may be involved. While awaiting the board's decision, project managers should continually execute planned tasks while also analyzing the impact and risks related to accepting or rejecting the proposed changes, to minimize negative impacts. This is where many go wrong: waiting does not mean stopping. Suspending work while a decision is pending adds a delay nobody asked for and charges the project for a decision not yet made. What the manager owes that window is double work: executing what is planned, and preparing the impact analysis the board needs in order to decide.

After approval

Approved change requests may require new or updated cost estimates, schedule adjustments, resource requirements, and risk assessments. They may also require updates to components of the project management plan and to project documents. The stated inputs to Assess and Implement Changes include the change and configuration management plans, the scope, schedule, and cost baselines, the basis of estimates, the change log, the requirements traceability matrix, the risk report, and work performance reports. Its tools include alternative analysis, cost-benefit analysis, voting, autocratic decision-making, and multicriteria decision analysis.

On the Exam

The 2026 ECO places change in Domain III, Business Environment, under Task 3 — manage and control changes — with four stated enablers: execute the change control process; communicate the status of proposed changes; implement approved changes to the project; and update project documentation to reflect changes. Related to it is Task 8, evaluate external business environment changes, through its enabler on assessing the impact on project scope or backlog.

The dominant pattern is a scenario presenting a request and asking for the next step. Four keys settle most of it:

• A verbal request, however small → documented and entered into the system, then assessed for impact.
• No baseline established yet → in predictive approaches there is no formal control at that point.
• The team is awaiting the board's decision → it continues executing planned tasks and analyzing impact.
• A team working from a backlog → the request becomes a backlog item and goes to no board.

What deceives is that the options offer "implement it because it is small" or "because the customer asked," both of which skip the requirement to estimate schedule and cost impact before approval. So does an option that halts work while awaiting the board. And so does a third that imposes a change control board on an agile project, ignoring that the type of change management applied depends on the development approach in use.

Detailed Mistakes

Approving before estimating schedule and cost impact

The guide requires that change requests typically include information on estimated schedule and cost impacts before they can be approved. Approving without that estimate turns the decision into a gamble: the board agrees to something whose price it does not know and then discovers it in a performance report a month later. The estimate is not bureaucracy; it is the information the decision rests on. That is why tools such as cost-benefit analysis and alternative analysis appear among the process's techniques: the decision is built on a comparison, not an impression.

Reducing the decision to approve or reject

The change flow in the Eighth Edition shows four outcomes: approved, rejected, deferred, and more information. Collapsing them into two pushes the board toward a hasty decision when information is incomplete — rejecting a legitimate request for being unclear, or approving one whose impact is not yet understood.

Neglecting the change log

The change log is a comprehensive list of changes submitted during the project with their current status, and the disposition of every request is recorded in it. Neglecting it costs the project one irreplaceable trace: why the project became what it is. When a budget overrun is reviewed, the difference between a live log and a neglected one is the difference between an answer in minutes and an investigation lasting days. Worse, the log is a stated input to Assess and Implement Changes, so neglecting it weakens the process itself and not only the documentation.

Where It Does Not Apply

In adaptive approaches, managing project changes typically involves backlog management rather than a formal change request process. Changes are continuously assessed and prioritized throughout the iterative development cycle. When a stakeholder proposes a change, it is recorded as a product backlog item and added to the backlog. Although these are not formally termed change requests, an impact analysis is still conducted to evaluate the change's effect and set its priority. There is typically no formal approval process: assigning a change a lower priority essentially means it is deferred, while choosing not to add it to the backlog, or removing an existing one, means it is rejected. The difference is not whether discipline exists but what form it takes — transplanting a control board onto an agile team adds a layer the model does not ask for, and dropping impact analysis in the name of agility deletes the part the model deliberately kept.