Most scope fights I have seen on client projects did not start with a big request. They started with a small one, accepted in a chat message ("sure, I'll try"), and nobody wrote down what it moved. Three weeks later the deadline has drifted and neither side can say which request caused it.
The fix is boring and it works: every change after kickoff goes on a one-page change request with a number. Here are the seven fields we put on that page, from the developer side of the table.
The seven fields
1. What changes, in screen terms. Not "improve search", but "add a date-range filter to the order list; picking a start and end date shows only orders in between." Test: ask someone new to describe the finished screen from your sentence.
2. Why (one line). "At month end the manager only wants last month's orders but has to scroll the whole list." Knowing the purpose is what lets you, the developer, say "there is a cheaper way."
3. What it touches. Screens modified, queries modified, new screens, data-structure changes, integrations. This is where "it's just one field" turns into "that's a migration" — say it before work starts, not halfway.
4. Effect on schedule, in dates. "Interim demo moves 2 days; final delivery unchanged." Send the updated overall schedule with the same CR number, so schedule versions line up with requests.
5. Effect on cost, with a basis. Not an amount pulled from the air — the basis (workload, agreed rate) and a reference to the quote. "To be discussed" is not an answer; don't start on it.
6. What gets dropped or deferred. If the client wants the date and budget unchanged, something else moves. Put the trade on the same page: "Admin Excel export moves to phase two." Check it isn't something they marked as core.
7. Who approves, and how. Both contacts reply "proceed" by email (or sign the doc). Work starts after that, not before. Number, date, approver name.
A filled-in (made-up) example
| Field | Entry |
|---|---|
| Number / date | CR-003 · requested by client contact |
| Change | Date-range filter on the order list |
| Purpose | See only last month's orders at month end |
| Impact | Order list screen, order query. No new screens, no schema change |
| Schedule | Interim demo +2 days; final delivery unchanged |
| Cost | Extra; basis = 1 screen + 1 query change, amount per attached quote |
| Trade-off | Admin Excel export deferred to phase two |
| Approval | Starts after both contacts approve by email |
Not everything needs a CR
Sort first. If something agreed in the requirements doesn't work, that's a defect — you fix it, no CR. Wording and color tweaks inside an agreed screen usually go in a batch. A new behavior, a new screen, or anything that touches data or integrations gets a number. Where exactly the line sits depends on your contract wording, so agree on the sorting rule at kickoff, not during the first argument.
What I like about this as a developer: it turns "the client keeps adding stuff" into a list you can both point at. Saying yes gets cheaper because every yes has a price tag and a date next to it.
The full guide (with the sorting table and how each field fails if you skip it) is here: How to write a change request. It's general information, not legal advice.
How do you handle mid-project requests — a numbered doc, tickets, or just a running chat thread?
Top comments (1)
Field 6 is the one I'd underline twice. Most "small" asks feel free because nobody names what they push out, and once the trade is on the page the client often decides they don't need it after all.
To answer your question: a numbered running log, not a doc per change. One line per request: date, what they asked in their own words, bug or change, and the reply I sent. Bugs get fixed and noted, changes get a number and wait for a "go". The chat thread stays where requests arrive, but nothing gets worked on until it has a line in the log.
Two small habits that made it stick:
Agree on sorting at kickoff too. The first argument is a bad time to decide what counts as a defect.