Every material change request asks leadership to recommit money, time, capacity and risk to a different future than the one previously approved.
A change request may arrive as a technical modification, an additional feature or a revised date. The form asks for description, impact and approval. This makes change appear procedural. Yet the decision is often strategic: should the organisation direct more scarce resources to this initiative, reduce another commitment, accept a new risk or abandon part of the original value proposition?
When change control is treated as document administration, approvals accumulate without a coherent view of the investment. When it is treated as capital allocation, leaders compare value, consequence and opportunity cost before authority is exercised.
The purpose is not to resist change. It is to ensure the organisation changes deliberately.
The Strategic Context
No serious project remains untouched by new information. Designs mature. Markets move. Regulations change. Suppliers fail. Users learn what they need. Risks become issues. A plan that never changes may reflect stability, but it may also reflect a team that has stopped learning.
Control begins with a credible baseline and defined decision rights. It then provides a disciplined route for evaluating proposed deviations. US Department of Energy guidance on baseline control recognises that project baselines can change while emphasising thresholds, approval authority and preservation of a stable basis for performance measurement.
This balance matters. If the baseline changes too easily, poor performance disappears into replanning. If it never changes, reporting becomes detached from the authorised future.
What Leaders Commonly Misread
The first misreading is that all change is scope creep. Unauthorised expansion is a control failure, but an approved change may increase value, reduce lifecycle cost, address safety or respond to evidence that invalidates the original plan.
The second is that small changes are harmless. A request may be inexpensive in isolation but significant when combined with dozens of others. It may also affect an interface, create a new configuration, consume testing capacity or delay a dependent benefit.
The third is that approval completes the decision. An approved change has no operational meaning until affected requirements, designs, contracts, schedules, budgets, risks, procedures and acceptance criteria are updated consistently.
The fourth is that rebaselining repairs variance. Rebaselining should reflect an authorised change in the plan or a formally governed reset—not erase the evidence that the previous commitment was missed.
Reframing the Issue
Change control should answer three connected questions.
- Investment question: Is the changed future worth its incremental commitment?
- System question: What else changes because this element changes?
- Control question: How will the authorised decision be reflected, communicated and measured?
This reframing moves the conversation beyond “Can the project afford it?” A project may have contingency and still make a poor investment. Conversely, a high-value change may deserve funding even when it exceeds the project’s existing tolerance.
Related article: Scope Is an Investment Boundary, Not a Requirements List
Distinguish Correction, Change and Enhancement
Leaders should first identify what kind of request is being made.
Correction: The agreed requirement has not been met. The question is normally how responsibility, warranty and recovery will be handled.
Controlled change: The authorised requirement, design, method or timing is being altered in response to new information or a new decision.
Enhancement: Additional capability or value is proposed beyond the approved boundary.
These categories have different commercial and governance consequences. Labelling a defect as an enhancement may transfer cost unfairly. Labelling an enhancement as a clarification can allow scope to expand without a conscious investment decision.
The distinction also clarifies gold plating. A supplier or internal team may add functionality with good intentions, but unapproved additions can create training, support, cybersecurity, validation or warranty obligations. More product is not automatically more value.
Evaluate the Whole-System Impact
The visible cost of a change is often only the beginning. A disciplined assessment considers:
- design and engineering effort;
- procurement and contract effects;
- schedule logic and critical-path movement;
- testing, assurance and regulatory approval;
- operating procedures, training and maintenance;
- data, documentation and configuration updates;
- dependencies with other projects; and
- benefits delayed, increased or put at risk.
A hypothetical healthcare program may approve a seemingly modest change to a digital triage workflow. Development cost may be limited, but the change could alter clinical protocols, training, privacy assessment, reporting and workforce adoption. The investment decision must reflect the system, not only the software estimate.
Make Opportunity Cost Visible
Change boards commonly compare incremental cost with remaining contingency. That is necessary but incomplete. The relevant question is what the organisation cannot do if it approves the request.
The change may consume the only available commissioning engineer, extend use of a leased facility, delay revenue, or absorb executive attention needed for another program. These consequences may sit outside the project budget.
For material changes, the decision paper should therefore state:
- value expected from approval;
- value or obligation protected by rejection;
- resources displaced elsewhere;
- reversibility of the decision;
- latest responsible decision date; and
- conditions that must be true for the change to succeed.
This turns a change log into an investment record.
Configuration Management Completes the Decision
Change control decides. Configuration management preserves the integrity of what was decided.
Once approved, the organisation needs one coherent version of requirements, drawings, software, contracts, schedules, procedures and acceptance evidence. If the design changes but the work instruction does not, approval has not produced control. It has produced inconsistency.
This is especially important in engineering, defence, healthcare and regulated environments, where the wrong revision can create safety, quality or compliance consequences. Documentation is not separate from the product system; it is part of the operating configuration.
Decision Framework
| Criterion | Decision question |
|---|---|
| Strategic value | Does the change strengthen the intended outcome or address a material threat? |
| Full impact | Have lifecycle, interface, assurance and adoption consequences been assessed? |
| Opportunity cost | What other work, benefit or option will be displaced? |
| Risk | Does the change reduce one risk while creating another? |
| Reversibility | Can the decision be tested, staged or reversed? |
| Authority | Is the decision within delegated tolerance or does it require escalation? |
| Configuration | Can every affected controlled item be updated and verified? |
The decision should result in approval, conditional approval, deferral, rejection or a request for evidence. “Approved subject to working out the details” is often an unrecognised transfer of risk to the delivery team.
From Strategy to Execution
Immediate action: Define change categories, decision thresholds and required impact fields. Stop routing every request through the same level of governance.
Medium-term capability: Integrate change records with scope, WBS, schedule, cost, risk, contract and configuration systems. Measure cumulative impact, not only individual approvals.
Long-term positioning: Use change data to improve portfolio decisions. Repeated changes may expose weak discovery, unstable strategy, poor stakeholder engagement or a capability gap that should be addressed systemically.
Related article: The Work Breakdown Structure Is a Control Architecture
Signals to Monitor
- “Clarifications” repeatedly add effort or capability.
- Approved changes are absent from drawings, procedures or acceptance tests.
- Contingency is treated as an available spending target.
- Rebaselining improves status without a corresponding authorised change.
- Individual requests appear small while cumulative effect is unknown.
- The same type of change recurs across multiple projects.
- Change approval is delayed until the decision is no longer reversible.
Questions for the Leadership Team
- What future are we choosing by approving this change?
- What is the full lifecycle commitment—not merely the implementation cost?
- Which other initiative or benefit will lose capacity?
- Is this a correction, controlled change or enhancement?
- What evidence would justify deferring or rejecting it?
- How will we prove that every affected configuration item was updated?
Closing Perspective
Change control is often the point where strategy meets reality. New evidence reveals that the original path is incomplete, unaffordable or no longer desirable. The leadership task is neither to defend the baseline at all costs nor to approve every attractive addition.
It is to make the next allocation of capital and capacity consciously—and then preserve the integrity of that decision throughout the system.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.