Change Request

How it flows

Four steps: submission, impact assessment, approval or rejection, incorporation. When "add three admin report screens" arrives, it does not slide into the schedule — its impact on scope, schedule, and cost gets assessed first. Three extra weeks of development, one more week of testing, a two-week slip of the launch: those figures go to the decision maker along with the request. Approved, the change is incorporated — and where it touches a baseline, the affected baseline is updated with it; rejected, the record remains. Either way, the decision leaves a trace — that is the point. The assessment's output is not a thick document but a decidable choice: one page showing what accepting costs and what rejecting forfeits is enough.

Why it matters

What sinks projects is rarely one big change; it is the accumulation of small ones that seep in without process. Scope creep is not an event but the running total of "sure, we can just do that." A CR is not a device for blocking change — it is a device for making change's cost visible, so the requester decides with the price in full view — that is all change control does. Scope slipped in on a verbal agreement returns at acceptance as a dispute between "it is not in the contract" and "you said you would."

Common misconceptions

Treating CR as bureaucracy is the common one. The weight of the process should scale with the change: a half-day change needs a one-line record and a single approver, not a committee. Another: change control over scope and schedule only makes sense against a baseline. The baseline is what defines what counts as a scope or schedule change — so in that domain, the first step of change control is baseline approval, not process design.