Change Request

Origin & evolution

Formal change control predates software project management; it grew out of configuration management in aerospace and defence, where an uncontrolled change to a baselined design could ground an aircraft. The Project Management Institute carried the practice into general project management and named its mechanism the change control board. In the PMBOK Guide, a change request is "a formal proposal to modify any document, deliverable, or baseline," handled inside the Perform Integrated Change Control process.

PRINCE2 frames the same mechanism differently: a change request is one of three issue types (alongside off-specifications📋SpecificationFoundationsA canonical open standard or specification that primitives and products conform toView reference → and general problems or concerns), all processed through a single issue and change control procedure. Where PMBOK places a change control board at the centre, PRINCE2 may delegate change authority to a smaller body—or to the project manager up to a financial threshold set by the project board—and reserves a discrete change budget to fund approved modifications without cannibalising the main plan. The structural logic is the same: every request is captured, evaluated against the baseline, and disposed of as a recorded decision before any work moves.

The control board is the human half of the mechanism. A change control board is a formally chartered group that reviews each request and approves, defers, or rejects it, then ensures an approved change is reflected across every affected plan so the baselines stay consistent. The word integrated matters: a scope change that does not also adjust schedule and budget is the definition of the failure mode the process exists to prevent.

That failure mode has a name. Scope creep is the uncontrolled growth of scope without matching adjustments to time, cost, and resources. The change request is the antidote because it makes the adjustment mandatory and recorded. Managed change and scope creep are the same act of adding work; the only difference is whether it passed through the gate.

How it works in practice

A platform team has a signed-off scope for a reporting module. A sales lead asks, mid-build, for one more chart, "just a small one." Without change control, the engineer adds it, the release🚢ReleaseProduct SpecificationA shipped version of the productView reference → slips two days, and nobody can later explain where the two days went.

With change control, the ask becomes a written request: the chart, its estimate of three engineer-days, and its effect on the milestone⛳MilestoneProgram ManagementA key date or achievementView reference →. The board, a product lead and an engineering lead meeting weekly, sees that three days breaches the milestone, and chooses. They either approve it and move the date, approve it and drop a lower-value item, or defer it to the next release. The decision is logged against the request. Six small "just one more" asks that would have quietly cost a fortnight are now six visible line items, each with an owner and a verdict.

Change request vs. its neighbours

• Decision: A decision is the ruling the board reaches; the change request is the proposal that triggered it. One request yields one decision, and recording both separately means you can audit what was asked as well as what was chosen.
• Deliverable: A deliverable is the agreed output a change request might add to, remove from, or redefine. The request acts on the deliverable's baseline; it is the controlled doorway through which a deliverable's definition is allowed to move.
• Scope creep: Scope creep is what happens in the absence of change requests, the same added work routed around the gate instead of through it. The presence of a logged request is precisely the line between managed change and creep.

In the graph

In the Unified Product Graph, a change request sits in the delivery region as a control node attached to the work it governs. Its canonical edge is program_changed_via_change_requestProgramchanged viaChange Requesthierarchy, binding the request to the program whose baseline it modifies and giving the program a queryable record of every sanctioned deviation from plan. Because the request is a first-class node rather than a comment buried in a status update, the graph can show the full chain from a proposed modification to its approving decision to the deliverable that ended up reshaped, which is the audit trail that distinguishes a controlled program from one that merely drifted.