Three weeks into a project, a message arrives: "While you are at it, could the report also show last year's figures?" It sounds like an hour of work. The developer says "sure", the client is pleased, and nothing is written down. A month later there are eleven such requests, the delivery date has moved and nobody agrees what was in the original price.
Changes during a project are normal. People learn things as the work progresses. The problem is not the change itself but a change with no price, no agreement and no new date. This article describes a short routine for the middle of a project, whether you are the client or the supplier.
What counts as a change
A change is anything that adds, removes or alters what was agreed at the start. A new field, a different export format, an extra user group, a removed feature and a request to move the deadline all count. If you are unsure, compare the request with the written scope. If it is not in the scope, or it works differently, it is a change.
If the original scope was never written down, fix that first. A one-page proposal with scope, price and timeline gives you something to compare against. Without it, every discussion is about memory.
Step 1: Say what it means before doing it
Do not start the work to "see how long it takes". Answer three questions in writing, in a few lines:
- What exactly changes? Describe it in one or two sentences, using the client's own words where possible.
- What does it cost? An amount or a clear estimate with a range, and whether it is a one-off or recurring cost.
- What does it do to the schedule? Either "no effect", or a new date, or "this replaces item X".
Small changes can be priced from a simple rule, such as an hourly rate agreed at the start. Larger ones need a short estimate. If you cannot price it yet, say so and give a date when you will, rather than guessing under pressure.
Step 2: Offer the options
A change rarely has only one answer. Typically there are three:
- Add it and accept the extra cost and the later date.
- Swap it for something of similar size that was planned and is now less important.
- Postpone it to a second phase, with a note in the backlog.
Often the swap is the best choice for a fixed deadline. Putting the three options side by side also moves the conversation from "yes or no" to "what matters most", which is easier for both sides.
Step 3: Get a yes in writing
The person who pays, or who has authority over the budget, should answer. A reply from the colleague who made the request is not enough if they do not control the money. An email is fine. The answer should be clear: "Yes, option 1, at the stated price, with the new date of 14 November."
Silence is not agreement. If nobody answers within a few days, ask once more, and do not begin the work. This protects both sides: the client knows what they are paying for, and the supplier is not asked to defend an undocumented promise later. In a commercial contract, payment terms and extras should be clear in writing, and GOV.UK explains what applies to late commercial payments when a contract is silent on them.
Step 4: Update the schedule in the same message
The most common failure is agreeing the price and forgetting the date. Put the new date in the same email as the approval, and update the plan everyone looks at. If the change pushes out other items, list them. A schedule that is not updated becomes a source of disappointment, because the old date still looks official.
If the date cannot move, the swap option is usually the only honest one. Say this plainly: "If the deadline stays, something else has to leave."
Step 5: Keep a one-line log
Keep a simple list, one line per change: date, short description, price, effect on the date, who approved. A shared spreadsheet is enough. The log is useful in three ways: the final invoice matches it, a status meeting can see the total effect at a glance, and the next project can use it to estimate how much change to expect.
Look at the log every few weeks. If changes are frequent, the cause is usually earlier: the first brief was unclear, or the users were not involved. The log shows this pattern. Our article on deciding what a tool should not do describes a way to reduce it from the start. For work after launch, the rules are slightly different; see handling change requests after launch.
When the change is urgent
Sometimes a change cannot wait, for example a legal requirement or an error in the original brief. Even then, send the three lines first, by phone call if needed, and confirm by email within the day. A fast process is still a written one. Mark the log entry as urgent so you can see later how often it happened.
What about small changes
Do not ask for a signed document for a five-minute fix. Agree a small allowance at the start, for example a few hours that the supplier can use for minor adjustments, and track it in the same log. When the allowance is used up, the normal routine starts. This keeps goodwill while the budget stays visible.
What to do this week
- Take a project in progress and list the requests made since the start. How many were priced and approved in writing?
- Write the three-line message template: what changes, what it costs, what it does to the date.
- Agree who can approve changes on the client side and who on the supplier side.
- Start the one-line change log, even if it begins with changes already made.
Sources
- GOV.UK, Late commercial payments: interest and debt recovery: what applies to payment terms when a contract does not state them.