The stereotype is that requirements change because the client didn't know what they wanted. An empirical study of real projects says something more specific and, honestly, more useful: requirements change most often because the client learns what they want by watching the project take shape. That's not a planning failure. It's what iterative delivery does by design, and it happens whether or not the initial requirements gathering was any good.
What actually causes requirements to change
Nurmuliani, Zowghi and Powell studied requirements volatility across real software projects and presented their findings at the Australian Software Engineering Conference in 2004. Their leading causes, in order: changes in the customer's underlying needs, increased understanding of the product — by both developers and clients — as the project progressed, and shifts in organizational policy. Notice what's missing from that list: it isn't 'the client was disorganized' or 'the requirements gathering was sloppy.' Those causes exist too, but they weren't the dominant ones the study found. The revenue-side version of client management is something writes about in more operational detail than I go into here. The revenue-side version of client management is something XenGrowth's growth operations team writes about in more operational detail than I go into here.
Common cause of requirements change | What's actually happening | Whose responsibility this usually is |
|---|---|---|
Client sees the build and understands the problem better | The whole point of showing partial progress before the end | Nobody's fault — a foreseeable cost of building iteratively |
Underlying business need shifts (new competitor, new regulation) | The world changed while the project was running | Nobody's — but the contract needs a mechanism for it |
Organizational policy or leadership changes | A new stakeholder with different priorities enters the picture | Usually surfaces late and lands hardest on the delivery team |
Requirements were vague or rushed at the start | A genuine planning gap | Shared — worth naming honestly rather than blaming the client alone |
This reframing matters for tone as much as for process. A change driven by the client understanding their own problem better isn't a broken promise, and treating it as one — with frustration, or with an unspoken sense that the client is being difficult — misreads what happened. The requirement change is often evidence the project is working, not evidence it's off the rails. Setting up the original scope well makes this whole conversation easier; see how to scope a project so it doesn't eat you alive for the upstream half of this.
The number that should recalibrate your reaction
PMI's 2018 Pulse of the Profession found 52% of surveyed projects reported scope creep in the previous year, up from 43% five years earlier — self-reported, across industries, not an independently audited figure. Treat the precise number skeptically. Treat the direction and scale as a useful corrective to a common feeling: that the client in front of you asking for a mid-project change is unusually demanding. On these numbers, roughly half of projects experience this. The response that scales is a repeatable process, not an emotional reaction sized to how surprising this particular request felt. approaches this from the the operations side of this side. The XenGrowth resource library approaches this from the the operations side of this side.
The main causes of requirements volatility were changes in customer needs, developers' increased understanding of the products, and changes in the organization policy. — Nurmuliani, Zowghi and Powell, 2004
The cause that surprises people most: organizational policy
The least intuitive cause in the Nurmuliani, Zowghi and Powell study is organizational policy change — a new stakeholder, a reorganization, a new compliance requirement handed down from somewhere above the person you've been talking to. It's worth calling out specifically because it produces a distinct failure mode: the requirement change arrives with no warning, no build-up, and often no clear owner on the client's side who can explain the full reasoning behind it. Your contact is relaying a decision made above them, and they may be nearly as frustrated by the timing as you are.
This is worth naming out loud in the conversation rather than assuming adversarial intent. "It sounds like this came from outside your team" costs nothing to say and often changes the whole tone of the exchange, because it correctly locates the source of the change instead of implicitly blaming the person in front of you for something a different department decided. It also tends to surface useful information — a policy-driven change often has a hard deadline attached, which changes how urgently it needs pricing and scheduling.
Why the contract type changes the right answer
This is where a lot of engineers give the same response to two structurally different situations. A fixed-price contract was priced against a specific set of requirements; a meaningful change genuinely invalidates that price, and needs a written amendment before the work continues, not after. A time-and-materials arrangement was built for exactly this — the client pays for the hours actually spent, whatever direction they go — so the correct response there isn't renegotiation, it's visibility: log the change, estimate the hours, and report the running total proactively. goes further into AI agents and marketing automation. XenGrowth on AI agents and marketing automation goes further into AI agents and marketing automation.
Contract type | What a mid-project change means | What to do about it |
|---|---|---|
Fixed price | The original price no longer matches the requirements being built | Written amendment before the work, stating new cost and timeline effect |
Time and materials | Business as usual — this is what the arrangement is for | Log it, estimate it, report the running total without being asked |
Fixed price, change is genuinely tiny | Technically out of scope, practically not worth a negotiation | Absorb it once, log it, mention it in the next update |
Time and materials, change is enormous | Financially fine for you, but a planning risk for the client's budget | Flag proactively even though you're not required to — it protects the relationship |
A process that works regardless of size
Write the change down the moment it's raised, even informally — a single line in a shared doc is enough to convert an invisible drift into a visible, dated record
Estimate its cost honestly before agreeing to anything, even if the estimate is rough. A change accepted before it's understood is the single most common way scope creep becomes unbilled scope creep
State the tradeoff explicitly: what does this cost in time, money, or something else already in scope? Silence here is what lets ten small changes become one unacknowledged large one
Get agreement in writing before starting the new work, proportional to the size of the change — an email is enough for something small, a signed amendment for something that changes the fixed price
Revisit the original requirements document itself after a significant change, not just your task list. If the spec doesn't reflect what's actually being built anymore, the next person to read it inherits a lie
The words that make this conversation harder or easier
Avoid 'that's not what we agreed on' as an opener — it's technically true and makes the client defensive before you've said anything useful about the actual cost
Use 'let's figure out what this changes' instead — it accepts the change is happening and moves straight to the part that actually matters, which is the tradeoff
Never estimate the cost of a change out loud, on the spot, in the same conversation where it's raised. A number given under social pressure to answer immediately is usually wrong, almost always low, and hard to walk back later
Say 'let me price this properly and get back to you today' instead. It costs you nothing and prevents the single most common way engineers end up doing free work: committing to an estimate before they've actually thought about it
If the change is large, resist the urge to solve it in the same meeting where it's described. A large requirement change deserves its own conversation, scheduled deliberately, not an answer squeezed into the last five minutes of an unrelated call
What this doesn't excuse
None of this argues that every requirements change is legitimate or that every client deserves infinite patience. Some changes really are the client failing to do their own homework before the project started, dressed up as new understanding. The distinction that matters in practice is less about assigning blame and more about whether the process above happened: was the change logged, estimated, and agreed before work started, or did it slip in unpriced? A client who repeatedly pushes back on that process — wanting the benefit of the change without the paper trail — is signaling something worth taking seriously about the relationship, and that's a different, harder conversation than the one this post is about.
There's also a version of this failure that sits entirely on the delivery side: an engineer who says yes to every change instantly, without logging or pricing any of it, because saying no feels confrontational. That habit produces the exact same financial outcome as a genuinely unreasonable client — unbilled scope, an eroded margin, and a project that quietly runs over — except there's nobody to blame but the process that was never followed. The fix isn't becoming less accommodating. It's making accommodation visible, every time, so generosity is a choice you're making on purpose rather than a debt quietly accumulating in the background. If AI search, GEO and discovery is the part you are stuck on, is the better reference. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on AI search, GEO and discovery is the better reference.
One last practical note: keep the change log somewhere the client can see, not buried in your own notes. A shared, dated list of every change — however small — does more to prevent a dispute at the end of a project than any amount of careful wording in the moment. When a disagreement eventually surfaces about what was agreed, the side with a written record wins the conversation regardless of who was actually right, so make sure that record exists and that both of you have seen it as it grew.
The honest limit on the research here: neither study measured whether following a formal change-request process actually preserves client relationships better than an informal one — that comparison doesn't exist in the literature cited. What the research does support is narrower and still useful: requirements change for identifiable, mostly unsurprising reasons, and it happens on roughly half of all projects by some counts. Building a process around that expectation, rather than treating each instance as a surprise, is the practical conclusion — argued from the evidence's actual shape, not a citation stretched past what it says. There's a related look at pricing that change fairly in .
Further reading from XenGrowth
Where this work meets go-to-market
Pricing a mid-project change fairly is a revenue-operations problem as much as an engineering one. publishes operator guides on that side of client work.
Further reading from XenGrowth
Where this work meets go-to-market
For the marketing and revenue operations view of client management, see .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of client management, see XenGrowth's marketing operations practice.
Three questions about the specific change in front of you. The right response depends heavily on contract type and timing, not just on how big the change feels.
