How should a team respond to a requirement change mid-project?

Classify it, state its cost against the work already done, and make the decision explicit rather than absorbing it. The response that causes damage is the silent yes, because it moves the cost from a conversation into the schedule where nobody can see it until the deadline arrives.

What is the difference between a clarification and a change?

A clarification resolves something the original specification left ambiguous, and the work was always owed since the requirement could not have been met without deciding it. A change replaces a decision that was made and built against. Charging for clarifications damages trust and absorbing reversals for free damages the schedule, so telling them apart is the first step.

How do you price a mid-build requirement change?

Price it against the checks it affects: how many existing automated checks it invalidates, how many new ones it requires, and what implementation those checks imply. This gives both parties a concrete unit to discuss instead of an argument from memory about what a sentence in the original document was supposed to mean.

Why is absorbing small changes dangerous?

Because each one is genuinely small and the cost is cumulative and invisible. A team that quietly takes on eleven small changes has moved the deadline without anybody deciding to, and when the project is late there is no single week to point at, which makes the conversation about the delay much harder than it needed to be.

What is a change budget?

It is an agreed allowance for change, stated up front, expressed in time or money or a number of change events. It works because it makes change an expected part of the project rather than an exception requiring negotiation each time, which removes most of the awkwardness and keeps the accounting visible on both sides.

When should a change be refused rather than priced?

When it invalidates work that is not yet finished, because the cost is highest while something is half built. Also when it contradicts a decision the architecture rests on, when it arrives so late that accepting it puts the release date at risk without that being said out loud, and when nobody can explain what problem it solves. Refusal here usually means deferring to the next phase rather than never.

What happens to the specification when requirements change?

It gets updated, or it gets explicitly retired. A specification that silently stops matching the build is worse than having none, because people continue to cite it in good faith and disputes turn into two parties quoting different versions of a document each believes is current.

Who should approve a requirement change?

One named person on each side with the authority to accept the cost. Change control fails most often not because the process is wrong but because approval is diffuse, so a change gets verbally agreed by somebody who was not empowered to agree it and nobody finds out until the invoice or the delay.

How do agile methods handle this differently?

Agile methods expect change and handle it by re-prioritising within a fixed capacity, so accepting something new means something else leaves the iteration. That is a mechanism for making the trade visible, and it fails in the same way as any other when the new work is added without anything coming out, which is the common case in practice.

Does AI-generated code make requirement changes cheaper?

It makes re-implementation cheaper and leaves everything else roughly where it was. Deciding what correct means, updating the checks, re-testing the affected paths and re-establishing agreement are the expensive parts, and they are unchanged. A change that is mostly re-typing is now much cheaper, and a change that invalidates a decision the system is built around is not.

What to do when requirements change mid-build: Reveneau

Requirements change on every project that has ever been run. This is not a failure of planning, and a process that treats it as one will simply be routed around.

The damage does not come from the change. It comes from what a capable, willing team does with it by default, which is to absorb it quietly.

The silent yes

Here is the shape of it. Week five. Someone senior on the client side, in the middle of a demo, says: while you're in there, could it also handle the case where a customer has two accounts?

The team says yes. Not because they are pushovers. Because the request is reasonable, because it genuinely is small, because saying yes takes four seconds and explaining the cost takes twenty minutes and feels like an accusation, and because everyone in the room wants the meeting to go well.

Nothing is written down. No date moves. Repeat this eleven times over two months.

The project is then late, and nobody can identify the week it went wrong, because it never went wrong in any particular week. The conversation that follows is much worse than eleven small conversations would have been, and it is worse in a specific way: it is now about competence and good faith rather than about scope, because there is no shared record showing otherwise.

Almost every scope dispute we have seen traces back to this pattern rather than to anyone behaving badly. Why scope creep happens and how to stop it covers the organisational version; this piece is about the mechanics of handling a single change well.

Classify before pricing

Three categories, and conflating them is where both sides start behaving unreasonably.

A clarification resolves something the original specification left open. "When two users have the same email, which one receives the notification?" was never answered, and the requirement could not have been delivered without answering it. This work was always owed. Charging for it is how vendors acquire a reputation for nickel-and-diming, and it is deserved when they do.

A reversal replaces a decision that was already made and built against. The client chose single-currency in week two and now wants multi-currency. This is real work, and it is more expensive than the same requirement stated in week two would have been, because it includes undoing.

An addition is a genuinely new requirement that does not contradict anything. It is the easiest of the three to price and, in practice, the least common.

Most change requests are a mixture, and separating them is the first useful move. It also tends to defuse the conversation, because a client who is told "half of this is clarification, which we owe you, and half is a reversal, which costs" hears somebody being fair rather than somebody negotiating.

Price against the checks

If the project is specified as automated checks rather than as prose, pricing a change becomes mechanical.

A change affects the check set in three ways. It invalidates existing checks, which now assert something the client no longer wants. It requires new checks for behaviour that was not previously specified. And it implies implementation work to make the new set pass.

"This change invalidates six existing checks, requires four new ones, and touches the export path and the reconciliation job" is a sentence both sides can examine. Neither party has to trust the other's memory or estimate. The alternative, which is the industry norm, is two people arguing from recollection about what a paragraph written in July meant, where the outcome depends mostly on who is more willing to strain the relationship.

This is the practical payoff of the approach described in how to write an acceptance test a machine can run. The checks are a quality mechanism and also the shared, unambiguous record of what was agreed, and that second job turns out to matter most during a disagreement.

What actually got cheaper

A fair question: does generated code make this less of a problem?

Partly, and it is worth being precise about which part. Re-implementation got much cheaper. A change that is mostly re-typing, where the requirement is clear and the structure holds, is now a fraction of what it was. That is a real reduction and it should show up in what the client pays.

What did not change is everything around it. Deciding what the new correct behaviour is. Updating the checks. Re-testing the paths the change touches. Confirming the change does not contradict a decision three other features rest on. Re-establishing agreement between people.

So the shape of change cost has shifted rather than shrunk uniformly. Changes that are mostly typing are cheap now. Changes that invalidate a decision the system is built around cost roughly what they always did, because the expensive part was never the typing.

The timing that costs most

Not the latest change. The one that lands on work currently half finished.

A change to something not yet started costs the difference between the old plan and the new one. A change to something finished, tested and shipped costs the modification. A change to something in progress costs both: the partial work is discarded or reworked, and the person doing it has to reload a mental model that no longer applies.

This gives a scheduling rule worth following. When a change arrives for work already in flight, the default is to finish the current piece and apply the change immediately after, rather than redirecting mid-stream. It feels wasteful. It is usually cheaper, and the finished intermediate state is something you can test, ship, and roll back.

Keep the specification true, or kill it

A specification that has quietly stopped matching the build is worse than no specification, because people still cite it in good faith.

Two workable options after any accepted change. Update the document, with a dated note saying what changed and why. Or declare it superseded and name what is authoritative now, usually the check suite.

What must not happen is the third thing, which is what happens by default: the document stays in the shared drive, unchanged, gradually diverging, until month four when two parties are quoting different paragraphs of what each believes is the current specification. Half the disputes we see at this stage are exactly that, and nobody in them is lying.

A change budget, agreed at the start

The mechanism that removes most of the friction is to agree up front that change will happen and to allocate for it.

State it in the terms that suit the engagement: a number of days, a percentage of the budget, or a count of change events per phase. What matters is that change becomes an expected, accounted-for part of the project rather than an exception requiring an awkward negotiation each time.

Two effects follow, and the second is the more valuable. Change requests stop being confrontations, because there is a pot they come out of and nobody has to argue about whether change is legitimate. And the pot is visible, so when it is two-thirds spent in week four, both sides can see that, and the conversation about the remainder happens while there is still room to have it.

The four questions worth asking on any change

What problem does this solve? Surprisingly often, nobody can answer. Requests get generated by a meeting rather than by a need, and asking the question kills a reasonable proportion of them at no cost.

What does it cost, specifically? In checks invalidated, checks added, and paths retested. Not in feelings about size.

What comes out? If the date is fixed, accepting something new means something else leaves. Naming what leaves is the whole discipline, and it is the step that gets skipped.

Who is deciding? One named person on each side who can accept the cost. Change control fails far more often from diffuse approval than from a bad process: something gets verbally agreed by whoever was in the room, and nobody discovers they were not empowered to agree it until the invoice arrives.

The goal was never to prevent change, which is neither possible nor desirable. It is to make the cost visible at the moment it is incurred, while there is still room to decide differently.

Sources

2025 DORA report announcement, Google Cloud: drawn from roughly 5,000 respondents; AI adoption relates positively to throughput and negatively to delivery stability, amplifying a team's existing practices rather than replacing them.
METR, early-2025 study of experienced open-source developers: 16 developers took 19 percent longer across 246 tasks with AI tools while believing afterwards they had been 20 percent faster, which is why change cost deserves measurement rather than intuition.