Change Control

Definition

Change Control is the formal, documented process through which any proposed alteration to the project baseline — scope, schedule, cost, quality, or risk — is identified, evaluated, approved or rejected, and (if approved) incorporated. It is the immune system of the project: without it, baselines degrade silently, variance reporting becomes meaningless, and disputes accumulate until they explode.

Change control is not bureaucracy. It is the mechanism that distinguishes a managed project from a series of accidents. The cost of running a change-control process is roughly 0.5–1% of project value; the cost of not running one is typically 5–20% in disputed change orders, claims, and rework.

History

Formal change control emerged from U.S. defence procurement in the 1960s, where cost-plus contracts on Polaris and Apollo produced uncontrolled scope growth. The C/SCSC criteria (1967) required a Configuration Management process; PMI's PMBOK codified Integrated Change Control in 1987; ISO 10007 and ISO 21502 carry the modern definitions. In software, change control evolved through configuration management (CVS, SVN, Git) and request-for-change processes in ITIL.

Principles

• One change board, one log, one approval path. Multiple channels guarantee leakage.
• No change without impact analysis. Cost, schedule, scope, quality, risk — all five must be evaluated before approval.
• No work without approval. Pre-approval work is the most common cause of claim disputes.
• Re-baseline only for material change. Trivial changes update forecasts; material changes update the baseline. Mixing the two corrupts variance reporting.
• Closed-loop. Every approved change must be reflected in the schedule, the cost forecast, the risk register, and the document control system. A change approved but not propagated is a change pending failure.

The Change-Control Lifecycle

1. Identify — any stakeholder raises a change request via the controlled channel.
2. Log — assigned a unique ID, owner, originator, date, and provisional category (scope, schedule, cost, quality, risk).
3. Impact analysis — multi-disciplinary review producing quantified cost, schedule, scope, quality, and risk impact.
4. Recommendation — by the change manager or project controls lead.
5. Decision — by the change control board (CCB), with authority level matching the change magnitude.
6. Communication — approved or rejected; reasons recorded; affected parties notified.
7. Implementation — propagation through schedule, cost forecast, risk register, drawings, procedures.
8. Verification — confirmation that the propagation actually happened.
9. Closure — change marked closed only after verification.

Change Categories

• Internal scope clarification — no net change in deliverable, often no cost impact.
• Owner-directed change — client requests an addition or modification.
• Constructive change — actions that effectively constitute a change without being formally directed; a common source of dispute.
• Force majeure / external — regulatory change, weather, geopolitical events.
• Design-development change — emerging engineering details that exceed the contract basis.

Real-World Construction Example

On a 400-bed hospital project, the owner asked the contractor to "consider adding a second helipad" during a routine site visit. The contractor's site team began preliminary structural calculations without a change request. Three weeks later, when the owner formally requested the helipad with a request to "use what you've already done," the contractor's pre-approval work was unbilled and unrecoverable. The lesson — documented and inserted into the company's standard procedure — was that no engineering effort over four labour-hours could be initiated on an owner suggestion without a logged change request, even if the owner later promised to pay. The discipline cost a few hours of awkward conversation; the alternative cost the contractor USD 180,000 over the next year.

Real-World IT / Agile Example

A SaaS team accepted "small" customer requests through Slack throughout an 8-week milestone. By week 6, the cumulative effect was 23 unbudgeted features and a 4-week slip. The team introduced a one-page change request template, a weekly 30-minute change board, and a clear rule: any request requiring more than 4 engineer-hours goes through the board. Velocity stabilised within three sprints. The agile equivalent of change control is not absent — it is just lighter in tooling. The discipline is identical.

Project Controls Perspective

Controls teams sit at the centre of change control. They run the change log, perform or coordinate the impact analysis, recommend the disposition, and verify propagation after approval. Three controls metrics matter: change-request ageing (open requests by days outstanding), cumulative approved change as a percentage of original baseline (a leading indicator of programme stability), and change-approval-to-propagation lag (the time between board approval and actual schedule/cost update). Lags greater than two weeks predict variance drift.

Common Mistakes

• Verbal directives accepted as authorisation — the single largest source of construction disputes.
• Change requests with cost impact but no schedule or risk impact analysis (or vice versa).
• Approval without re-baseline, leaving variance reporting meaningless.
• Approved changes not propagated into all controls systems — the change is real but invisible.
• "Small" changes bypassing the board, individually trivial but cumulatively destructive.
• Change board with delegation rules that do not match the project size — micro-management at executive level, or rubber-stamping at site level.

Expert Tips

• Set delegation thresholds in writing at project kick-off. Anything below USD X or N days, site team approves; above, project director; above, sponsor.
• Run the change board weekly, not monthly. Monthly cadence accumulates pre-approval work and disputes.
• Quantify everything. "Significant impact" is not a quantity; "USD 240,000 and 11 days" is.
• Separate forecast updates from baseline updates. Update the forecast monthly; update the baseline only when material change accumulates.
• Audit propagation quarterly. Pull ten approved changes at random and verify they are reflected in schedule, cost, and document control.

Key Takeaways

• Change control protects the baseline; without it, variance reporting is fiction.
• One log, one board, one approval path, five impact dimensions.
• No pre-approval work, no verbal directives, no propagation gaps.
• Constructive change is the silent killer — name it to manage it.
• 0.5–1% process cost prevents 5–20% claim and rework exposure.

Related Concepts

Change Control interlocks with Scope Management, Risk Management, Baseline Schedule, Cost Control, and Lessons Learned. Change request templates and CCB charters are at PMMilestone.org.