Change Control in PMBOK 8: Assess First, Then Implement

A change rarely arrives labelled as one. It turns up as a sentence at the end of a meeting. While the team is in that part of the system anyway, could they also add the second reporting currency. The person asking can see one small piece of work. They cannot see the eleven things attached to it, and at that moment neither can anybody else in the room.

Two familiar failures follow. In the first, the answer comes before the analysis. Someone says yes because the request sounds modest, or no because the baseline has started to feel like something to defend. In the second, the change is approved properly, by the right people, in the right forum, and then almost nothing moves. The schedule still shows the old sequence, the supplier is still building to the previous specification, and three testers carry on working to acceptance criteria that no longer apply.

The useful way to hold this is as two connected pieces of work with a decision sitting between them. Assessment establishes what the change would do to the project's objectives and to the value the project exists to create. Implementation makes the approved change real in the plans, the agreements and the working understanding of everyone affected. The PMBOK® Guide Eighth Edition treats these as one process, Section 2.1.6, Assess and Implement Changes, within the Governance Performance Domain, which is a helpful reminder that neither half achieves much on its own.

Working out what the change really touches

The first question is whether the request is a change at all. Some requests are clarifications of a requirement that was already agreed and simply written loosely. Some are defects that the supplier or the team is already obliged to put right. Some are genuinely new or altered scope. Treating all three the same way either buries the process in trivia or quietly lets new work in without anyone deciding to accept it, and the second is more expensive than the first.

Once a request is confirmed as a change, the assessment has to reach further than effort and cost. Effort is the easy part and rarely the part that hurts. The harder work is sequence and dependency, because a change to one component can move a date that has been promised elsewhere. Resources are usually already committed to something, so a change that takes two weeks of a specialist's time is also a change to whatever that specialist was going to do. Risk exposure shifts, both through new risks and through existing responses that were designed around the old approach. Acceptance criteria, test material, training, contractual obligations, regulatory evidence and the benefits the project was funded to deliver may all need revisiting. Second-order effects are where assessments most often fall short, and they are almost never visible to the person making the request.

A good assessment also considers timing and the cost of doing nothing. Some changes are better taken in a later release, when the disruption is lower and more is known. Some become much more expensive the longer they wait, because work is being built on the assumption they will not happen. Declining a change permanently and deferring it deliberately are different answers, and stakeholders deserve to know which one they have received.

Proportion matters throughout. A change worth three days of work does not deserve a fortnight of analysis, and a change that alters a regulatory commitment deserves considerably more scrutiny than the effort figure suggests. Deciding how much assessment a request warrants is itself a judgement, and it is one that governance should support rather than replace with a single mandatory form.

Deciding at the right level

Change decisions go wrong most often because authority was never settled while everyone was calm. Thresholds, tolerances and decision rights belong in the governance arrangements agreed at the start of the project or the phase, so that the question in front of the project manager is which route applies rather than who might be willing to take responsibility for this one.

With that in place, a great deal can be decided close to the work. A project manager operating inside an agreed tolerance for cost, schedule and scope can accept or decline changes within it, provided the decision is visible. A change that breaches a threshold, alters a contractual position, affects another project or changes what the sponsor promised the organisation belongs at sponsor or board level, and sending it there is ordinary practice rather than an admission of difficulty. What should be avoided is escalation triggered by discomfort, where a decision well within the project manager's authority is passed upwards because the requester is senior or persistent.

Preparing the decision is usually more valuable than making it. The people with the authority to approve a significant change rarely have the detail to assess it, and they are not served by a summary that lists impacts without weighing them. They need the realistic options, including the option of doing nothing, the consequences of each, the risks that would be accepted, and a recommendation the project manager is willing to stand behind.

Whatever is decided, record the decision, the reasoning and the authority behind it, and communicate rejections as carefully as approvals. Rationale that is never written down is reconstructed from memory three months later, usually by someone who disagreed at the time.

An approved change is the middle of the work

Approval changes nothing by itself. Implementation is the work of moving the change into every place the project holds its commitments: the schedule and its dependencies, the budget and any reserve drawn on, the scope structure or backlog, requirements and traceability, acceptance criteria and test material, the risk register, the resource plan, and any supplier agreement that needs a formal variation. It also has to reach the people doing the work, which is the step most often left to chance.

A worked situation makes the gap visible. A manufacturer is replacing its production scheduling system, with the first phase covering one plant. The operations director asks for a second plant to be brought into phase one, since the configuration will largely be the same. The assessment finds that the configuration genuinely is similar, that the additional effort is modest, and that the real impact sits elsewhere: the second plant runs a different shift pattern, which changes the cutover window, which collides with a planned maintenance shutdown. The sponsor approves the change with a revised cutover date and additional contingency. Four weeks later the integration team is still working to the original cutover weekend, because the change was recorded in the decision log and the revised plan, and nobody told the three engineers whose weekend it was.

That is an implementation failure, not a decision failure, and it is the more common of the two. Closing it out means confirming that the change has actually landed. Someone should be able to point at the updated plan, the amended agreement, the revised criteria and the people working to them. Where a change alters how a delivered thing will be used or supported, the check belongs partly in the operational environment rather than entirely in the project's own records.

The same discipline where scope is meant to evolve

Adaptive delivery is sometimes described as though change control does not apply, which misreads what a backlog is. Reordering a backlog, refining a story or dropping a low-value item in favour of something better is normal managed scope, handled by the product owner inside the boundaries already agreed. No change process is needed because no external commitment has moved.

The boundary is what has been committed outside the team. A funding envelope, a contracted outcome, a regulatory date, a release the business has announced to customers, an interface another programme is depending on: changes to these need assessment and a decision at the level that owns them, whether the delivery approach is predictive, adaptive or hybrid. Hybrid work makes this explicit rather than difficult, provided someone has decided in advance which parts of the project run under which rule and where the two meet. Leaving that undefined produces the worst of both, with iterative teams surprised by change boards and governance surprised by scope that moved months ago.

For a PMP candidate, this is the judgement the exam is interested in. The 2026 PMP Examination Content Outline places managing and controlling changes in the Business Environment domain, covering the execution of change control, communicating the status of proposed changes, implementing approved ones and updating documentation, and predictive, adaptive and hybrid approaches appear throughout all three domains rather than being separated out. A scenario will usually be asking what a competent project manager notices and does first, not which form to complete. Working through a structured programme such as Omega's PMP® Exam Preparation gives you the chance to practise separating assessment from decision while nothing is at stake, which is the only comfortable time to learn it.

On a live project the payoff is quieter. Teams stop treating change as an argument to be won, stakeholders find out early what their request would really cost, and the plan keeps describing the project that is actually being delivered. That last one is worth the effort on its own.

Andre Malowney

Interested in going further?

Change requests are where governance either earns its place or becomes an obstacle, and the reasoning behind a proportionate assessment is much easier to build before a live request is sitting in front of you. Omega's PMP® Exam Preparation works through change assessment, decision authority and implementation follow-through across predictive, adaptive and hybrid delivery.

Assess and Implement Changes sits in the Governance Performance Domain of the PMBOK® Guide Eighth Edition, alongside the planning, monitoring and closure processes it depends on.

Ad · Amazon affiliate link.

References

A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What's the Difference?
A092: How Projects Create Value Through Governance
A093: Choosing a Project Governance Model
A094: Governance Metrics That Actually Tell You Something

PMP and PMBOK are registered marks of the Project Management Institute, Inc.