Scope Change Request Checklist Template

Answer the scope question first. It decides whether the client change order phase appears.

• Name the project manager, sponsor and account lead — later tasks are assigned from these fields; on internal projects the project manager can also be the account lead
• Answer the scope question — is this work for an external client
• Record who asked, what they want and why — in the requester’s words, with the date, where it was asked and any deadline they gave
• Give the request a reference in the change log — one number used in every email, estimate, task and invoice line about it
• Ask how urgent it is and what happens if it waits — a deadline with a consequence is urgent; one without is a preference
• Tell the team not to start the work yet — nothing gets built on a verbal yes before the decision

If the request is not a scope change, record why, tell the requester and close the checklist here.

• Compare the request with the SOW, charter or backlog — quote the requirement, deliverable or acceptance criterion it would change
• Rule out a defect — work that fails an agreed requirement is fixed under the original scope, not charged as a change
• Rule out a clarification — an answer to an ambiguous requirement that adds no work needs a decision note, not a change
• Check whether it is already covered — by contingency, an allowance, a time and materials budget or an assumption in the estimate
• Record the classification and the reason — scope change, defect, clarification or already in scope, and tell the requester which

• Define the change precisely — what is added, removed or altered, and what is explicitly not included
• Estimate effort and schedule impact with the people doing the work — including the effect on milestones and the critical path
• Cost the change — labour, third-party costs and licences, and how much contingency it would use
• Assess the effect on resources, risk and quality — who is pulled off what, new risks, and any acceptance criteria or tests that change
• Check dependencies outside the project — other teams, suppliers, contracts or later phases the change touches

The threshold question here decides whether Phase 5 appears.

• Set out the options — accept, defer to a later phase or release, reject, or accept with a trade-off
• Look for a trade-off before adding time or money — something that could come out of scope, or a date that could move, to absorb the change
• Write a one-page recommendation — the request, the impact, the options and the one you recommend, with reasons
• Check the change against the approval thresholds — answer whether it exceeds the project manager’s delegated authority on cost, time or scope
• Record your decision if it is within your authority — and attach the recommendation it was based on

Shown only when the change exceeds the project manager’s approval threshold.

• Send the recommendation to the sponsor or change board — with the impact assessment attached, before the meeting, not at it
• Present the change and record the questions asked — with any condition the decision depends on, such as a launch date holding
• Confirm the decision against the board’s terms of reference — very large changes may need the steering group or a revised business case
• Sponsor approval of the change decision — the checklist stops here until the sponsor approves the recommended decision

Shown only when the scope answer is that the work is for an external client.

• Price the change under the contract’s change terms — rate card, fixed fee or time and materials, as the contract sets out
• Draft the change order or contract variation — scope, price, schedule effect, assumptions and which clauses or SOW sections it amends
• Account lead approval of the change order — price, margin and terms checked before anything goes to the client
• Send the change order and agree a response date — and explain what happens to the schedule if the answer is late
• File the client’s signed change order — work starts when it is back, unless the contract allows otherwise

• Record the final decision in the change log — accepted, deferred, rejected or traded off, who decided and on what date
• Update the plan, budget and backlog — rebaseline dates and cost; deferred items go into the later phase’s backlog
• Update the RAID log and the requirements — new risks, assumptions, issues, dependencies and acceptance criteria
• Tell the requester, the team and stakeholders — what changed, what did not, and any new dates
• Track the work under the change reference — tag tasks and time so actual effort can be compared with the estimate
• Invoice the change or record it against the budget — as the change order says, and note any variance for the next estimate