Change Control

A client asks a software team to add a feature halfway through a project, and the request might be valuable but could change the launch date and budget, so change control makes that tradeoff visible before developers start the extra work. The Association for Project Management defines change control around requests to change an approved baseline, describing capturing and evaluating requests, then approving, rejecting or deferring them.

The plan is updated if a change is approved. First define the baseline: agreed scope, delivery date, budget, service level or technical configuration, because without a known starting point people cannot tell whether a request is a new change or work already promised.

Describe the proposed change in plain terms, covering who requested it, why, what would be different and what happens if nothing changes. A vague request such as 'make it faster' needs a measurable target before it can be costed.

Estimate impact across the whole project, since a new feature may need design, testing, documentation, training and support, and the coding effort alone is not the full cost. Consider dependencies, because a schedule change may affect another team, customer launch or regulatory deadline, and a change that saves one group time can create risk elsewhere.

Assign decision rights too: a project manager may approve a small change within agreed tolerance, while a major budget increase may need sponsor or customer approval, so record the actual authority rather than letting the loudest stakeholder decide. A change log stores the request, impact assessment, decision, owner and implementation status, but it is not the approval itself, so a row saying 'approved' should link to the decision or person with authority.

If a change is approved, update scope, schedule, budget and communication while preserving a record of the old commitment for comparison; if it is rejected, explain why and what remains in scope; if it is deferred, set a review trigger or date. Silence is not a clear decision, especially when work can begin informally.

Control should be proportionate: a minor copy correction may not require a formal board meeting, while a major architecture change should not be accepted by chat alone, so set thresholds based on impact and reversibility. Urgent changes such as a security fix or safety hazard can use a defined emergency route with a documented decision and follow-up review, which is better than pretending the normal multi-day board can always meet first.

Change control also applies to live systems, where a proposed release should include test evidence, deployment timing, a rollback plan and authorisation suited to the risk. A useful measure is the ratio of approved change costs to the original budget: if approved added costs total $150,000 on a $1,000,000 baseline, the illustrative ratio is 15%, though this does not show net cost if changes also remove work or create savings.

Use both gross additions and net approved budget effect where needed, because a sequence of offsetting changes may leave the same total but alter quality and risk. Do not let a supplier do extra work without agreed commercial terms, use the contract's change-order route for price and scope, and ask whether the combined changes still support the original business case.