Software change request process for fixed-price projects

A fair software change request process has three steps. You ask for the change in writing. The team sends back a time and cost estimate before anyone touches the code. Nothing gets built until you approve that estimate. That's the rule we work to at EK Ra Sunya, and it's the rule we'd tell you to insist on from any vendor, because a fixed price without it protects nobody.

Changes aren't a sign the project is going wrong. They're a sign people are using what's being built.

Why do changes happen on a project that was fully specified?

Because nobody knows exactly what they need until they see it working. You write "staff can approve leave requests" in the scope. Then you click through the first build and realise your branch managers approve, but head office has to see everything above three days. That rule was always true in your business. It just never made it into the document.

The software industry stopped pretending otherwise a long time ago. One of the principles behind the Agile Manifesto is to "welcome changing requirements, even late in development." The GOV.UK Service Manual tells government teams that what they treat as high priority should change as the service develops.

So the useful question isn't how to stop changes. It's what happens when one arrives.

Why does a fixed price without a change rule fail both sides?

A fixed price is a promise to build a defined thing for a defined amount. When the thing stops being defined, one of two bad outcomes follows.

The vendor absorbs it. Small changes pile up, nobody says anything, and the team quietly starts cutting corners elsewhere to stay inside the price. Testing gets thinner. Documentation disappears. You pay for that later.

Or the argument comes late. Halfway through, the vendor says the last ten requests were out of scope and sends a bill. You say they were "obviously" included. Now you're negotiating with the people holding your half-built software, which is the weakest position a client can be in.

Both are scope creep on a fixed price project, and both start the same way: changes made by phone, in meetings, or in a chat thread, with no record of what was agreed and no number attached. A written change rule doesn't make the project more expensive. It makes the cost visible at the point where you can still say no.

We made the same argument from the buying side in how to read a software development quote. A cheap quote with no change process is often the dearest one by the end.

What should a change request contain?

You don't need a form, but you do need it in writing: an email is fine. A good request answers four things.

1. What you want, described as behaviour. "When a leave request is longer than three days, send it to head office after the branch manager approves" beats "fix the leave approval".
2. Why you want it. The reason often points to a simpler build. Sometimes the team can solve the real problem with a report instead of a new workflow.
3. Who it affects. Which users, which screens, which existing data.
4. How urgent it is. Before launch, after launch, or "whenever the next batch goes".

If you wrote a good requirements document at the start, a change request is just a new line for it. Our post on what to prepare before asking for a quote covers the same habits.

What should the estimate tell you?

The estimate is where a change request either protects you or doesn't. A one-line reply saying "can do, extra cost" isn't an estimate. Look for these:

The estimate should show	Why it matters
What will be built, in the team's words	Confirms they understood the request, not a different one
Time and cost of the change	The two numbers you're actually approving
Effect on the launch date	A change that costs little but pushes launch back may not be worth it
What else it touches	Reports, permissions, mobile app, existing records
What it won't include	Stops the change itself from creeping

Then approval means one thing: you agreed to that estimate, clearly and on record, and the team can start. A passing "sounds good" in a meeting is worth confirming by email. We would rather ask twice than build something you didn't sign off. If you decline, nothing gets built. The request stays in the log in case you want it later.

Is it a bug or a change?

This is where most disputes start, so settle the rule early.

A bug is when the software doesn't do what the agreed scope says it should. The scope says the invoice shows VAT on its own line, and it doesn't. That's a defect, and on a fair fixed-price contract fixing it is part of what you already paid for.

A change is when the software does what the scope says, but the scope was wrong or incomplete. The invoice shows VAT correctly, but you've now decided you also want each line split by branch. Nothing is broken. You want something new.

The grey cases are where the scope was vague. Here the Scrum Guide has a useful idea even if your project doesn't run on Scrum: a "Definition of Done", a formal description of the state the work must be in before it counts as finished. The guide says an item that doesn't meet the Definition of Done can't be released. Agree yours at the start. "Done" might mean it works on the screens listed, it handles the error cases in the document, and it passes the test cases you were shown. With that written down, most bug-or-change arguments answer themselves.

When it's still unclear, say so in your request. A good team will tell you which side they think it falls on and why, before any estimate.

How should you handle lots of small changes?

Batch them. Five tiny requests sent on five different days mean five estimates, five approvals, and five interruptions to the team's planned work. The same five sent as one list on Friday can be estimated together, and can cost less as a group because they touch the same screens.

The Scrum Guide describes the Product Backlog as "an emergent, ordered list" of what the product needs. You can keep a client-side version of that without any tool: a shared sheet of requests, each marked must-have before launch, should-have, or can wait. The GOV.UK manual uses the same idea with its MoSCoW labels, including a "will not have" list the team has agreed not to do. That last column is underrated. Writing down what you've decided against stops the same idea coming back every week.

Two practical habits help:

• Separate launch from later. Most changes raised during testing can ship in a release after launch. Moving them there protects your date.
• Keep one person as the approver. If three people on your side can approve changes, the team will get three conflicting instructions. Name one person.

Frequently asked questions

Does a change request always cost extra?

Not always. Some changes swap one piece of work for another of similar size, and the estimate may show no added cost. The point of the estimate is that you know before anything is built, whatever the answer is.

Can I make changes after the app or system is live?

Yes, and that's normal. After launch the same three steps apply: written request, estimate, approval. If your app is on the Play Store or App Store, check whose account it's published under, because that affects who can release the update (we explain why in who owns your app store accounts).

What if I disagree with the estimate?

Ask what drives it. Often a smaller version of the change, or a different approach, does most of the job for much less. You can also decline it. Nothing is built until you approve.

Is a fixed price still a good idea if changes are expected?

For a well-defined first version, yes. It gives you a known cost for the core build. The fixed price covers the agreed scope. The change process covers everything you learn after that.

Starting a fixed-price project with us

Our business solutions team builds custom business systems, and every change on those projects goes through these three steps. If you're about to sign a project, with us or anyone else, and want a second look at how changes will be handled, send us what you have.