Changes are normal. Here is how they are handled on a fixed-scope project, when requirements arrive a piece at a time, and how to spot a scope that is turning into a moving target.
In short
Changes are normal. What matters is that they are agreed, not assumed. On a fixed-scope project, a change is discussed and agreed in writing, including its effect on the work, the timing and the price. If requirements will keep arriving as you learn, an ongoing engagement with an agreed priority queue usually fits better than a fixed scope.
Almost every software project changes after it starts. The business sees the first working version and realises something it could not see on paper. A customer asks for something. A process turns out to work differently from how it was described. None of that is a failure.
What goes wrong is not the change itself. It is a change that one side thinks is included and the other side thinks is extra. This article is about keeping those two views the same.
Requirements change for good reasons. People describe their work in general terms until they see real screens with real data. Unusual cases only show up when the software meets real work. And the business itself moves on while the work is happening.
So the useful question is not “how do we stop requirements changing?” It is “how do we agree changes quickly, without derailing the work already in progress?” The answer depends on the kind of engagement.
A Custom Project, from RM30,000, is priced against an agreed scope: the deliverables, phases, dependencies and responsibilities. That scope is the reference for the whole project.
When something new comes up, we discuss it and agree it in writing, including what it does to the current work, the timing and the payment. We do not treat extra scope as automatically included, and we do not quietly absorb it either. Both would leave someone with a surprise later.
The same principle applies to smaller fixed pieces of work. A Fix Sprint moves one clear problem towards an agreed result. Unrelated issues, new features and unlimited changes after the result is reviewed are separate conversations.
Some businesses know the direction but not the detail. The detail arrives as each part is used and the next step becomes clear. Forcing that into a fixed scope usually means a long argument about what the original scope “really” meant.
For this kind of work, an ongoing engagement is a better fit. With System Improvement, changes, reports, workflows and integrations move through an agreed priority queue. The queue can change when both sides agree the change and its effect on current work, dependencies and timing. For a larger body of work, Managed Delivery does the same around a bigger backlog.
In both, the queue matters more than the list. A list of everything you might want is not a plan. An agreed order, with the active item clearly defined, is.
Changes move quickly when four things are clear:
When any of these is missing, the change is not ready yet, however urgent it feels.
When we see these signs, we pause and re-agree the active priority rather than carrying on. Work stops moving when scope, approval or acceptance has no owner, and it is better to say so early than to discover it at the invoice.
If you are about to start a project and expect the requirements to change, tell us early. It changes which engagement we recommend. Extra developers or a team that owns the result? explains the difference between ongoing and fixed-scope work in more detail.
Founder and Managing Director, Antdragon
Rosaan started Antdragon in 2020 to be the team that stays accountable once software goes live, and works with business owners on the systems they rely on every day.
Filed under Scope and changes
Most businesses only fully understand what they need once people start using the software. Why that happens, and how the way you pay for development makes it easier or harder to handle.
Rosaan Ramasamy · · 5 min read
A worksheet for the records, owners, access, errors, reconciliation and real-world tests behind a business system integration.
Rosaan Ramasamy · · 2 min read
A copyable brief that helps a software team understand users, workflows, priorities, constraints, dependencies and how you will accept the work.
Rosaan Ramasamy · · 2 min read
