Change requests: how to keep them from wrecking the budget
Every project meets 'can we also'. How change requests are handled so the price stays fixed and the good ideas still get built.
The short answer
Every project reaches the moment someone says “can we also”. A change request is anything not in the written scope, and it is neither a problem nor a trick. It is a decision: build it now for an agreed price, build it later, or not at all. The rule that keeps a fixed price fixed is that nothing outside the scope is built until it has been described, priced and agreed, in writing, however small. Everything else follows from that rule.
The process
- Describe it. One paragraph: what the change is, why it is wanted, what it replaces or adds.
- Price and time it. A fixed price and the effect on the schedule, in writing. Sometimes the price is zero and the effect is nothing; it is still written down.
- Decide. Now, later, or no. “Later” goes on the parked list with a date to revisit.
- Update the scope. If approved, the change becomes part of the scope, with the new price and date. The document stays true.
- Build it as agreed. Not before.
What it looks like from each side
| Situation | Without the process | With the process |
|---|---|---|
| The client asks for an extra page | Built quietly; appears on the final invoice, or something else is cut to fit | Described, priced, decided; scope updated |
| The supplier spots an improvement | Done unasked and billed, or done unasked and absorbed by cutting corners elsewhere | Proposed with a price; client decides |
| Ten small extras over a project | A dispute at the end about what was included | Ten small decisions, each visible |
| A great idea mid-build | Derails the schedule | Parked for phase two with a date |
The template
A change request does not need a system. It needs the same six lines every time, so that two people can agree in writing in ten minutes. Copy this, fill it in, and keep it with the scope document.
Change request
Project: [project or package name]
Date: [date]
Requested by: [name]
1. What changes [one paragraph: what it is, why it is wanted, what it replaces or adds]
2. Effect on price [fixed amount, or "none"]
3. Effect on timing [days added, or "none"]
4. Decision [now / later / no] Decided on: [date]
5. If later [date to revisit]
6. Scope updated [yes, with the new price and date / not applicable]The two lines that make it work are 2 and 3. A change with no price and no date effect is still written down as such, because the value of the record is that nothing moves without both sides seeing it. Our terms require the same thing in one sentence: changes to scope need written agreement and may affect pricing and timeline.
Use it in both directions. A supplier proposing a change fills in the same six lines. If the request came from the supplier’s own estimate being wrong, that belongs on line 1 rather than in a conversation.
The parked list
The good ideas discovered during the build arrive as change requests. The parked list is where they go: described, roughly sized, with a date to revisit, usually after launch when real use shows which of them matter. It keeps the ideas, protects the schedule, and produces the scope for phase two with no extra effort.
What this means for you
Insist on a written scope with exclusions, agree the change process before the project starts, and use the parked list generously. Then say “can we also” as often as you like: each one becomes a decision you make with the price in front of you, the fixed price stays fixed, and the good ideas are waiting, dated, when the build is done.
Frequently asked questions
Isn't a change request just the supplier trying to charge more?
Only if the scope was vague enough that the change should have been in it. With a clear scope, a change request is what protects you: it makes the extra visible and lets you decide, instead of it appearing on the final invoice or being quietly cut from elsewhere to fit.
What about tiny changes?
Tiny changes inside the scope, a word, a colour, a rearranged section, are normal iteration and part of the price. Tiny changes outside the scope, a new page, a new integration, add up; ten of them are a phase. Describe, price, agree, even when the price is small or zero.
How do we avoid change requests in the first place?
A written scope with exclusions, clickable designs before code so changes happen where they are cheap, and a parked list from day one. A change request is a discovered need; the process makes discovering them cheap instead of expensive.