Informal requirements changes: the work nobody wrote down

Published 22 October 2026

Informal requirements changes are changes that are agreed and built without going through the change process: a tweak agreed on a call, a “small” screen change, a favour to keep a client happy. Research on a real project found them everywhere, and most of them were not mistakes — they were deliberate. What makes them expensive is that nobody can see them later: they are not billed, not tested against anything, and not in the requirements. Below are what the research found, where informal changes come from, what they cost, how to handle them without banning them, and why they matter more when an AI coding agent builds from the written requirements.

As we were billing them on a cost-basis, I hadn’t been diligent with documenting all the change requests. […] So I essentially had to dig through all my emails, notes and whatever else I could find and start writing down all the changes they had requested throughout the project.

— r/projectmanagement, in a thread titled “Document everything.... seriously”, 2019

What the research found

Waqar Hussain, Didar Zowghi, Tony Clear, Stephen MacDonell and Kelly Blincoe studied requirements change at a software vendor with an offshore team over ten months, from February 2013 to January 2014. They interviewed the development manager, team leads, developers and the quality assurance manager, and the company’s CEO, who also acted as a proxy for the client; they also read the project’s change logs, which held around a hundred change requests (Managing Requirements Change the Informal Way: When Saying ‘No’ is Not an Option, IEEE Requirements Engineering conference, 2016).

The company had a formal change process. The study found a second one beside it: “Yet we observed that ‘informal requirements changes’ (InfRc) were pervasive and unavoidable.” The authors define them as “those changes that bypass most of the controls imposed by formal change management processes (e.g. formal review and change impact analysis) and get implemented in the resulting system.”

The records showed it. The company’s policy required every requirement to be recorded in a requirements workbook, “however only ninety five requirements (estimated to be 20% of the total) were noted in the RM workbook.” And “six out of the eight participants reported that they did not have enough time to update the design documents with all the changes.”

Where informal changes come from

The study names the sources, in the participants’ words:

A client who changes things all the time. “So almost every second or third day the requirements are changed.” And the client did not see them as changes: “He [proxy client] does not even consider those as requirements change…he says there is no harm in tweaking the UI.”
Changes that seem too small for a form. “So if it is one to four hours’ work, we tend to accommodate it.”
Screen changes. “The changes which come within UI, we do not consider them changes at all… the changes to the workflow are a part of the change management process.”
Goodwill. “Change requests made by the client (considered low in impact), especially during elicitation and design phases were often implemented without any cost to the client. This was meant to establish good client relationship and to retain the client.”

Practitioners describe the same channels. A request that arrives in a chat: one developer’s question on Stack Exchange describes a business advisor who “talks in the evening with my boss for hour or two on windows messenger”, after which the changes arrive by email the next day (Software Engineering Stack Exchange, 2012). A request that grows: stakeholders “begin asking the tech team for changes or alterations that seem minor at first, but before long, pile up into what would amount to a major change request had you seen it first” (r/projectmanagement, 2018).

What informal changes cost

The study lists the consequences on the project it followed: “added pressure on the team to meet deadlines, extra time and (uncompensated) effort, delay in release dates, misunderstanding and conflicts among the team members, problems in change understanding, confusion during testing and lack of requirements traceability.” Its conclusion calls informal change “an under reported and variably managed project dimension of hidden work which demands suitable buffers to accommodate such activities in development projects.”

The other cost comes later, in a dispute. One freelancer starting a thread about scope creep: “there’s no written agreed upon scope (only by phone), big mistake” (r/webdev, 2023). One Hacker News commenter remembers a client “claiming I had ‘told him to do X & Y’ on a phone meeting 6 months prior” (Hacker News, 2019). Another’s rule: “Never allow the scope of a project to be changed based on a conversation or a phone call, anything that could get you sued needs to be in writing” (Hacker News, 2014).

Informal changes vs scope creep

They overlap, but they are not the same. Scope creep is work added without anyone deciding what it costs. An informal change can be a deliberate decision — the study’s vendor chose to absorb small changes to keep a client — that simply was never written down. The decision may be right. The record is what is missing: the next tester does not know the rule changed, the next developer reads the old requirement, and at the end of the project nobody can show how much was given away.

How to handle informal changes

Banning them does not work; the study calls them unavoidable. Making them visible does:

Write it down the same day, in one line to the client: what was asked, what you will do. “‘If it’s not documented it didn’t happen’ is an effective phrase to live by when dealing with clients, even the nice ones” (Hacker News, 2020). For sign-off itself: “Always get a paper chain - which is an email signoff. Never rely on a verbal signoff” (r/businessanalysis, 2025).
Keep the threshold, add the record. The study’s team accommodated work of a few hours without a form. That is a sensible fast path, as long as each one still gets a line in the change log.
Mark goodwill as free, not invisible. A change done at no charge is logged as “no charge”, so the client — and the next estimate — can see what was given.
Agree a buffer up front. The study’s “suitable buffers” can be a tweak allowance in the statement of work: so many small changes, then change requests.
Update the requirement, not only the code. Otherwise the next person reads the old rule — see how to track changes to requirements.
Review the list with the client at each milestone: everything added since the start, free or paid, against the agreed version. The full process for the changes that do go through it is in requirements change management.

Informal changes and AI coding agents

A developer who was on the call carries the change in their head and builds it. An AI coding agent was not on the call. It builds from what is written — the spec, the ticket, the acceptance criteria — and a change that lives only in a conversation never reaches it. One commenter, in a thread on requirements engineering and AI coding agents:

You hand a vague story to a good engineer and they quietly resolve fifty ambiguities you never wrote down, using context, hallway conversations, and the ability to ask “wait, did you mean X or Y” mid-build.

And on the agent: “An AI agent does not fill those gaps. It resolves them, but it resolves them by guessing, confidently, in whatever direction its training biases it” (r/businessanalysis, 2026). With an agent in the loop, an unwritten change is not just an unbilled one; it is one the next build will undo. More on that gap in spec drift.

Where Specroot fits

This is the problem Specroot works on: every change to the agreed requirements recorded with the decision behind it — including the small ones agreed on a call — so that what was agreed and what is written stay the same thing. Specroot for agencies and consultancies.