Change Request: Definition, Contents and Approval Path
A change request is a formal proposal to alter approved scope, schedule, cost or quality, submitted with an assessment of its impact. It records what is being asked for, why, what it costs in money and time, what it affects, and who approved or rejected it. Its purpose is to make change a decision rather than a drift.
What a change request contains
| Field | Purpose |
|---|---|
| Reference and date | So the request can be cited in minutes and in the plan |
| Raised by | The requester, and the function they represent |
| Description | What is being asked for, in enough detail to be estimated |
| Rationale | Why it is needed now, and what happens if it is not done |
| Scope impact | What is added, removed or altered against the baseline |
| Cost impact | Effort, licence, vendor and run-cost consequences |
| Schedule impact | Effect on milestones, including whether a committed date moves |
| Risk and quality impact | New risks introduced, testing implications, technical debt accepted |
| Options | Approve, reject, defer, or approve a reduced version |
| Decision | Outcome, decision maker, date, and any conditions attached |
How it is used
A request moves through a fixed path: raised, logged, assessed, decided, and then either implemented and baselined or closed as rejected. The assessment step is the one with all the value in it. A request presented without cost and schedule impact cannot be decided, only agreed to, and agreement without impact is how scope grows quietly.
Thresholds determine who decides. Small changes inside tolerance are usually settled by the project manager; anything affecting a committed date, the budget envelope or contracted scope goes to the board or steering committee. Those thresholds belong in the governance design rather than being negotiated per request — see programme governance. Where the volume is high enough, a standing change control board takes the decisions instead.
Keeping the impact attached to the request is a tooling question. The change request log holds the assessment on the same line as the request, so approvals are decisions rather than nods. Where cost impact is material, the same figures have to land in the budget forecast, which is what the budget and vendor tracker carries as forecast at completion. Approved changes then need to be visible in reporting; the project status report guide covers where they sit in the weekly view.
Where it goes wrong
- Verbal approval. A change agreed in a corridor and never logged reappears at closure as an unexplained overspend.
- Impact assessed after approval. The decision has already been taken; the assessment becomes paperwork justifying it.
- No baseline to change against. Where scope was never written down precisely, every request becomes an argument about whether it is a change at all.
- Cumulative effect invisible. Twelve small approved changes each cost three days. Nobody added them up.
- Rejected requests deleted. The log is more useful with them in. Rejections get raised again, and the record shortens the second conversation.
- Defect logged as change. Fixing something that was in scope and does not work is not a change. Blurring this shifts cost to the wrong party.
Related terms
Change control board — the body that decides requests where volume justifies a standing forum. Baseline — the approved position a request is assessed against. Scope creep — what happens where requests bypass the process. Project charter — the document that defines the scope being changed. Exception report — raised where the change puts the project outside tolerance.
Questions
Who approves a change request?
It depends on the threshold. Small changes within tolerance are usually approved by the project manager; changes to committed dates, budget or contracted scope go to the board, steering committee or change control board.
What is the difference between a change request and a defect?
A defect is agreed scope that does not work, and fixing it is not a change. A change request alters what was agreed. The distinction matters most on fixed-price contracts, where it determines who pays.
Does every change need a written request?
Every change to baselined scope, cost or committed dates does. Day-to-day decisions inside the project manager's tolerance do not, which is why the tolerance has to be written down.
What happens to rejected change requests?
They stay in the log with the rejection reason and date. Rejected items get raised again, often by different people, and the record makes the second conversation shorter.