How to Use a Project Change Request Form: A Practical Guide
A change request form is how a project handles the inevitable moment when someone asks for something different from what was agreed. “Can we add a loyalty-points feature?” “The client wants the launch moved up two weeks.” Without a formal process, these requests get agreed in corridors and the project quietly doubles in size. The form makes every change visible, costed, and decided on purpose.
When to Use This
Use it from the day the project plan is signed until the project closes. Any request that changes the agreed scope, budget, timeline, or deliverables goes through this process, no matter how small it sounds. “Just add one more report” is never just one more report. The form applies to changes requested by the client, the sponsor, team members, or anyone else. What it does not cover: fixing mistakes in the original work (that is rework, not a change) and trivial tweaks the team can absorb without impact (use judgement, but document them).
How to Fill It Out
Section 1: Change description. Describe exactly what is being requested and who asked for it. “Requested by: James Okafor, Sales Director, 12 May 2027. Request: add a gift-wrapping option to the checkout page, including a £3.95 charge and a gift-message field.” Be precise enough that someone reading it in six months understands what was asked. Attach any supporting emails or mockups.
Section 2: Reason and business justification. Explain why the change is wanted and what value it adds. “Gift wrapping was the most-requested feature in the customer survey (34% of respondents) and competitors offer it.” A change with no justification is a whim; the justification lets the sponsor weigh the benefit against the cost. If the requester cannot explain the business reason, the change is probably not worth making.
Section 3: Impact assessment. This is the heart of the form. The project manager assesses the impact on scope (what new work is needed), schedule (how many days does it add, be specific: “adds 6 working days to the build phase”), budget (exact cost: “£2,800, 3 days of developer time plus testing”), and risks (what new risks does this introduce). Get estimates from the people who will do the work, not guesses. An honest impact assessment is what turns “just a small change” into a real decision.
Section 4: Options and recommendation. List the realistic options: approve the change as requested, approve a reduced version, defer it to a later phase, or reject it. Include the project manager’s recommendation with reasons. “Recommendation: defer to Phase 2. The feature is valuable but adds £2,800 and delays launch by a week; Phase 2 is scheduled for September and already includes checkout improvements.” Recommendations make the sponsor’s decision faster and better informed.
Section 5: Decision. Record the decision, who made it, and the date: “Approved by Maria Chen (sponsor), 15 May 2027, with launch moved from 30 June to 7 July.” Also record rejections: a rejected change should be logged, not deleted, so the same request does not resurface in July as if it were never discussed. If the decision is “defer,” note where it was deferred to.
Section 6: Implementation. If approved, note the updated plan references: which tasks were added, the new dates, the revised budget figure. “Plan updated: tasks CR-004a/b added; budget revised to £62,800; milestone 4 moved to 7 July. Charter updated and re-signed.” A change is not finished when it is approved, it is finished when the plan reflects it.
Common Mistakes
1. Skipping the form for “small” changes. The five small changes nobody recorded are what blow up the budget. Every change that affects scope, time, or cost goes through the form, no exceptions, no matter how senior the person asking. The discipline feels bureaucratic until the first time a £15,000 overrun traces back to corridor conversations.
2. Assessing impact without the people doing the work. A project manager guessing “that should take a day” is how changes get under-costed. Always get the estimate from the person who will do the work. Developers, designers, and contractors know their effort; managers know their optimism.
3. Approving changes without adjusting the plan. A change approved but never reflected in the schedule, budget, or task list creates two versions of reality: the official plan and the real project. Update everything the same week the change is approved, and re-communicate the new dates to the whole team.
4. No record of rejected changes. Rejected requests have a habit of returning. Log every request and its outcome, including rejections with the reason. “Rejected 20 May: out of scope for Phase 1; reconsider for Phase 2.” When the request comes back, you have the history instead of re-arguing it from scratch.
Who Needs to Sign Off
The project manager completes the impact assessment and makes the recommendation. The sponsor approves or rejects, they own the budget and the dates, so the decision is theirs. For changes above a threshold (say, £5,000 or two weeks of schedule), the sponsor may need to consult finance or the steering group; set this threshold in the project plan. The requester is informed of the decision either way, silence breeds repeat requests.
How Often to Review and Update
Process each change request within five working days, slow decisions stall the project as surely as bad ones. Review the change log monthly with the sponsor: how many changes, total cost and schedule impact, and whether the pattern suggests the original scope was wrong. At project close, the log becomes part of the lessons-learned review, ten change requests for “extra reports” means the next project’s scope should include reporting from the start.
Download the free Project Change Request Form.