A change request is a small project decision with a big paper trail: what was asked, whether it is really new work, what it costs, who agreed and what changed as a result. This free scope change request checklist takes one request from the moment someone asks to the point where the plan, budget and invoice reflect it. It is written for project managers, agency account and delivery leads, consultancies and internal PMOs. One question at the start shows the client change order phase for work done for an external client, and a threshold question during the decision shows the sponsor or change board review only when the change is bigger than the project manager is allowed to approve alone.
The same request can become either a scope change or scope creep. The difference is what happens next. PMI’s PMBOK® Guide defines scope creep as “the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.” A scope change is the controlled version: the extra work is described, its impact is assessed, someone with the authority to do so agrees it, and the schedule, budget and contract move with it.
PMI calls that discipline integrated change control: reviewing every change request, approving or rejecting it, managing the changes to deliverables, plans and project documents, and communicating the decision. On larger projects a change control board, a formally chartered group, reviews and approves, defers or rejects the bigger changes. On a small agency project the “board” may be the account lead and the client’s marketing director on a call. The steps are the same either way.
Neither of these is IT change management, even though the vocabulary overlaps. IT change management controls changes to live systems, such as a server patch or a firewall rule, through requests for change and a change advisory board. If that is the process you need, use the IT Change Management Process Checklist instead, and see CheckFlow for change management.
Seven phases run from logging the request to invoicing the change. Phase 5 appears only when the change exceeds the project manager’s approval threshold, and Phase 6 appears only when the work is for an external client.
Answer the scope question first. It decides whether the client change order phase appears.
If the request is not a scope change, record why, tell the requester and close the checklist here.
The threshold question here decides whether Phase 5 appears.
Shown only when the change exceeds the project manager’s approval threshold.
Shown only when the scope answer is that the work is for an external client.
Most slow or contested change decisions come from one missing agreement: who is allowed to approve what. Set the thresholds when the project starts, in the charter, the project initiation document or the contract, so nobody negotiates authority in the middle of a disagreement about scope. The figures below are examples only. Set your own to match your budgets, your contingency and the way your organisation delegates authority.
| Impact of the change | Project manager decides | Sponsor decides | Change board or steering group decides |
|---|---|---|---|
| Cost | Example: covered by remaining contingency and under 2% of budget | Example: 2% to 10% of budget, or needs new money | Example: over 10% of budget, or changes the business case |
| Schedule | No change to any external milestone | Moves an external milestone by up to two weeks | Moves the go-live or contract completion date |
| Scope | Swaps like-for-like items inside a deliverable | Adds or removes a deliverable | Changes the project’s objectives or benefits |
| Risk and quality | No new high-rated risk; acceptance criteria unchanged | Adds a high-rated risk or changes acceptance criteria | Affects safety, regulatory compliance or another project |
| Contract (client work) | No change to price or terms | Change order within the account lead’s pricing authority | Changes contract terms, liability or the overall fee |
Use the highest level any row reaches. A change that costs little but moves the go-live date goes to the board. Count changes cumulatively as well: five small changes that each stay under the project manager’s limit can add up to one the sponsor should have seen, so review the running total in the change log at every steering or status meeting.
Keep the assessment proportionate. A two-hour copy change needs a line in the change log and an email confirming the cost. A new integration needs the full impact assessment. The checklist is the same; the depth of each answer is not.
The decision is an approval step that holds the checklist until the sponsor or account lead answers, so the plan, the change order and the invoice only move once someone with authority has agreed. The approval is recorded beside the assessment it was based on.
Conditional logic shows the change board review only for changes above the threshold, and the change order steps only for client work. Small changes stay quick, and big ones cannot skip the review.
Agree the change process and the thresholds before the work starts, in the Project Kickoff Checklist, and keep the change log with the rest of the project record using the Project Management Documentation Checklist. A change big enough to alter the benefits needs the Business Case Checklist run again, and the Project Closeout Checklist reconciles every approved change before the project closes.
Running change requests across several projects or clients? CheckFlow for approvals routes each decision to the right person, and CheckFlow for change management covers the IT side when a project change also touches live systems.
A scope change request is a formal record that someone wants the project to deliver something different from what was agreed: more, less or something else. It names who asked, what they want and why, and it starts the process of assessing the impact and deciding. Logging it is not agreeing to it. The request only becomes part of the project once someone with the authority to do so approves it and the plan, budget and, for client work, the contract are updated.
Scope creep is uncontrolled; a scope change is controlled. PMI defines scope creep as the uncontrolled expansion of product or project scope without adjustments to time, cost and resources. The extra work itself can be identical. If it is logged, costed, approved and reflected in the schedule and budget, it is a scope change. If it is agreed in a meeting and simply absorbed, it is creep, and it usually surfaces later as an overrun nobody can explain.
Whoever the project’s agreed thresholds say, based on the size of the impact. Small changes covered by contingency are usually the project manager’s call, larger ones go to the sponsor, and changes that move the go-live date or alter the business case go to a change control board or steering group. For client work the client must also agree, normally by signing a change order. Set the thresholds at the start of the project, not during the first disagreement.
Enough for someone else to make the decision without a meeting: a reference number, the requester, the date, a description of the change and the reason for it, how urgent it is, the requirement or SOW section it affects, the estimated effect on effort, schedule, cost, resources, risk and quality, the options considered, a recommendation, the decision with the decision-maker’s name and date, and, for client work, the price and the signed change order.
Log every one of them, however small, and review the running total. A change that takes an hour is easy to agree informally, but ten of them are more than a week of work nobody budgeted for. Keeping a cumulative total in the change log, and setting a threshold for the total as well as for each change, lets the project manager say yes to small requests quickly while the sponsor still sees the pattern.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
