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.
In short
Requirements change because people describe their work in general terms until they use real screens with real data. Testing exposes missing steps, unclear rules and needs nobody mentioned. A fixed price suits work whose requirements are already stable. When the requirements will keep emerging as people use the software, a monthly engagement with a fixed budget and an agreed priority order handles that learning with less friction, as long as someone on your side owns the priorities.
The scope is written, reviewed and approved. Everyone agrees on what the software should do. Development starts.
Then real users start testing, and the list grows. It is easy to read this as poor planning by someone. Usually, it is something else: people only fully understand what they need once they see it working.
This article explains why that happens, and why the way you pay for development makes it easier or harder to deal with.
A scope document records what everyone understood at the time. It is written by people describing their work from memory, in general terms, before any of it exists on screen.
That description is honest, but it is incomplete in predictable ways. People describe the usual case, not the exceptions. They describe their own step, not the hand-off to the next team. And they describe how the process is meant to work, which is not always how it actually runs.
None of this shows until the software meets real work.
Once people use a working version with real data, three kinds of requirement tend to appear.
Missing workflows. The approval step was in the scope. What happens when the approver is on leave was not. Neither was the record that has to be corrected after it is approved.
Unclear business rules. “Discounts apply to members” sounded clear. Then someone asks whether that includes expired members, members who joined this week, or orders placed by staff on a member’s behalf. Each answer changes how the software behaves.
Operational needs nobody raised. Finance needs a month-end export in a particular format. Branches need to see only their own records. The warehouse works on a tablet with patchy coverage. These come from people who were not in the room when the scope was agreed.
These are not changes of mind. They are the business learning what it needs, and the software is the first time anyone could see it.
Most businesses only fully understand what they need once they start using the software. So why force them to predict everything before development begins?
A fixed price is priced against an agreed scope. That protects both sides. You know what you will pay, and the team knows what it has committed to deliver.
When a genuine new requirement appears, it is outside that agreement, so it becomes a change: a description, a quotation, an approval and often a new date. That process is fair, and on a project where a handful of changes come up, it works well.
It works less well when the learning is most of the work. If every round of testing produces several new requirements, each one goes through quotation and approval before anyone builds it. Work waits for decisions. Discussions about what the original scope “really” meant start to take up time that should go into the software. And a team asked to fix a final price for requirements that are still moving can only protect itself by adding contingency or by reading the scope narrowly. Neither helps you.
The problem in that situation is not fixed pricing. It is asking for a fixed final price and date while the requirements are still being discovered.
In a monthly engagement, the budget is fixed and the order of work is not. You agree a priority order with the team, and the team works through it.
When testing turns up a missing workflow, it goes into the backlog and is ranked against everything else. If it matters more than the next planned item, it moves ahead of it. Nobody needs a new quotation to start, because the cost each month is already known.
That changes the conversation. Instead of “is this in scope?”, the question becomes “is this more important than what we planned next?” That is a business decision, and it is yours to make.
Our Managed Delivery works this way, from RM13,000 a month, with no minimum term. For a single live system with a growing list of changes, System Improvement does the same at a smaller scale.
A fixed price makes sense, and is often the better choice, when:
| Your situation | Usually fits better |
|---|---|
| Requirements are settled and the end point is clear | Fixed scope |
| The direction is clear but the detail will emerge as people use it | Monthly |
| Some parts are settled and others are still being worked out | Fixed scope for the settled parts, monthly for the rest |
We offer both. A Custom Project is priced against an agreed scope, and it is the right choice for work that fits the first row.
A monthly engagement buys steady capacity, not unlimited development. Adding to the backlog does not add capacity. It changes the order in which things get done, and something else waits longer.
That only works when someone on your side owns three things:
Without that owner, a monthly engagement can drift as easily as a fixed project can stall. With one, your business can keep learning as the software is built, without losing control of cost or priorities.
If you are planning a project and expect requirements to keep emerging, say so in your first conversation with any developer. It should change what they recommend. What happens when requirements change halfway through? covers how individual changes are agreed, and what to prepare before asking for a quotation helps you work out which parts of your scope are already settled.
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
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.
Rosaan Ramasamy · · 3 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
