Everything is now a change request

Stop arguing about whether the latest change request is reasonable. Take the last 10, put each into one of three buckets, and count. The distribution tells you which of three quite different problems you have, and each one has a different response — one of which is to change your own behaviour rather than the supplier's.

This takes about an hour and it works even when the relationship has already gone tense, because it is a claim about a documented set of requests rather than about anyone's good faith.

The three buckets

The test for each bucket is deliberately narrow. Apply it to the brief as written, not to what everyone remembers agreeing in the room.

Most disputes collapse at this point, because the second bucket turns out to be nearly empty. Genuine new requirements are rarer than either side believes; what feels like scope growth is usually one of the other two, and they are opposites.

Reading the distribution

The first row is the one people mean when they complain. It is worth being precise about what has happened: nothing in the brief was misread. A firm that intends to win on price knows that a brief has gaps, prices the brief literally, and treats every gap as billable later. That is a coherent commercial strategy and it is not fraud. It is also why two quotes for one brief can differ by multiples without either being wrong — the divergence is covered in why two quotes for one brief differ by multiples.

The diagnostic signal is what is being charged for, not how much. A supplier billing fairly for genuinely new work and one billing for everything it chose not to mention produce identical invoices and opposite conclusions.

The requirements that always fall between the lines

The same items land in bucket one on almost every project, because briefs describe features and these are not features. If your change requests are concentrated here, you now know what the exclusions list would have said.

• Environments. Staging, seeded test data, and a way to reset it. Priced as 1 environment, needed as 3.
• Migration and backfill. Moving 6 years of history out of Excel, reconciling it, and running both systems in parallel. Almost never in a brief that says "replace the spreadsheet".
• Access control. SSO via SAML or OIDC, roles, and an audit log of who saw what. Cheap to design in, expensive to retrofit.
• Security evidence. Questionnaire responses, penetration-test remediation, and the reading of an audit report — where buyers routinely assume coverage that is not there, as set out in what an attestation report attests to.
• Non-happy paths. Retries, partial failures, reconciliation, and the runbook for when the integration stops at 02:00.
• Accessibility and device matrix. Which WCAG conformance level, which screen readers, which minimum Android and Safari versions. Unstated means unpriced.
• Observability. Logging, alerting, and the dashboard someone will need on a Sunday. Regularly the first thing cut and the first thing missed.

On an AI build there is a fifth category that almost nobody scopes: the machinery that keeps model behaviour stable. A prompt change alters system behaviour while no application code moves, so unless it was agreed at signature that prompt and model changes pass a regression gate, that work arrives later as a change request — the mechanism is described in making a prompt change fail the build. Eval sets, human review queues and a fallback path when the model provider degrades belong in the same conversation, and are part of what we scope explicitly in AI agents and automation work.

When you are the source

The third bucket is the one nobody wants to find, and it is common. Its signature is specific: the change requests are small, frequent, and mostly reversals. A field is added in sprint 4 and removed in sprint 6. An approval step is inserted after a stakeholder sees the demo. A workflow is reworked because 2 departments never agreed how it should run and the supplier was left to guess. Pull the change log out of Jira and sort by title similarity — the reversals cluster.

That is not scope creep. It is a decision being taken late, by a supplier, on your behalf, and then taken again properly. The cost is real but the cause is internal, and no amount of contractual pressure will fix it.

Preventing it at the next signature

1. Ask what the proposal excludes, in writing, before signing. This one question does more than any contract clause. A supplier that answers with a specific list is telling you it read the brief; a supplier that answers "nothing, it is all included" has either not read it or is planning to bill for the gaps.
2. Fix the scorecard weighting before you read any proposal. Otherwise the cheapest bid quietly rewrites the criteria around itself — the mechanism, and the disqualifiers that sit outside the score, are in a scorecard finance and engineering can both sign.
3. Price the between-the-lines list explicitly. Send the seven items above to every bidder and require a line against each. Bids then become comparable, which is the actual objective.
4. Define done for one representative feature. Not the whole system. One feature, described to the level of tests, error states and who signs it off, which reveals more about a supplier's definition of complete than a hundred pages of requirements.
5. Weigh the track record honestly. A firm without a long history is not automatically riskier here, but you need different evidence from it — the ranking is in assessing a firm with no decade of history.

For AI work specifically, the scoping questions that produce a defensible boundary — what the system is allowed to decide, what happens when it is unsure, and what evidence counts as working — are set out in scoping an AI project.

What to do mid-project

You cannot re-tender a half-built system without paying twice, so the realistic move is to convert an open-ended arrangement into a bounded one. Agree the remaining scope as a fixed list with a definition of done per item, accept that some bucket-one work is now sunk, and put the exclusions question to the supplier for the remainder rather than for the past. Arguing about the first 10 change requests is a worse use of the relationship than fixing the next 30.

One thing to check while you are in the records: a rise in change requests often coincides with a change in who is doing the work, because a team that did not scope the build does not recognise what the brief implied. If both are happening, see the engineers who pitched are not the engineers committing. The surrounding decisions live in deciding what to build and who builds it, in the library.

• scoping
• vendor management
• contracts
• delivery