Ask a room full of executives why their last software project went over budget and you will hear a version of the same answer: scope creep. Requirements grew. The build kept expanding. What was quoted in March bore little resemblance to what shipped in November.
It is worth being precise about what actually happened, because the usual diagnosis is wrong, and the wrong diagnosis produces the wrong cure.
Most scope creep is not change. It is discovery.
There are two different things that get filed under the same label.
Genuine change is when the business itself moves. A regulation lands mid-project. An acquisition changes the org chart. A competitor forces a decision. The requirement did not exist when the project started, and now it does. This is real, it is nobody's fault, and it needs a process.
Discovery is different. The requirement existed the whole time. Nobody wrote it down, because nobody was asked the question that would have surfaced it. It stayed invisible until a half-built screen made its absence obvious. That is not the client changing their mind — that is a requirements process that stopped too early.
In our experience, the large majority of what gets called scope creep is discovery, not change. Which means it was preventable, and preventing it is the vendor's job.
This distinction matters commercially. Change is a legitimate reason for a project to cost more. Discovery is a legitimate reason to ask why the vendor did not find it during the phase they were paid to find it.
Where requirements actually go missing
Requirements rarely disappear in the obvious places. The core workflow — the reason for the project — usually gets captured well. What gets missed is consistent, and it is nearly always one of these.
| What gets missed | Why it goes unrecorded |
|---|---|
| The exception cases | Stakeholders describe how the process works, not the fifteen percent of the time it doesn't. The rush order, the split shipment, the customer with two accounts, the correction after month-end close. |
| The person who wasn't in the room | Requirements are gathered from managers. The work is done by the people they manage. The gap between how a process is described and how it is performed is where projects die. |
| Everything prefaced with "obviously" | Assumptions shared by everyone in the room are never stated aloud, which means they never reach the people who weren't in it. |
| The integration nobody owns | Every system touches another system. The seams belong to no single department, so no single department speaks for them. |
| The manual workaround | Someone has a spreadsheet. Someone re-keys data every Friday. These are load-bearing parts of the operation that appear on no process map. |
| What "done" means | The hardest one. Without agreed success criteria there is no objective way to say the project is finished — only opinions about whether it feels finished. |
How we approach it
XOR Services runs a disciplined three-phase engagement built on a four-step methodology we call CADD — Collect, Analyze, Design, Deliver. The point of the structure is simple: move the discovery forward, so it happens during the phase designed to absorb it rather than during the phase where it costs the most.
Collect — before anything is designed
We sit down with your team and work through the operation as it is actually performed. That means talking to the people doing the work, not only the people describing it. It means walking the exceptions deliberately rather than waiting for them to surface. It means asking what the spreadsheets are for, what gets re-keyed, what everyone works around, and what happens on the bad days rather than the normal ones.
We also collect what already exists — current systems, data structures, integration points, reports people depend on — because a new application almost never lands in empty space.
Analyze — reconcile before you build
Collected requirements always contain contradictions. Two departments describe the same process differently. A stated rule conflicts with observed practice. A requested feature duplicates something that already exists elsewhere.
Analysis is where those get resolved, on paper, while resolving them is cheap. It is also where gaps get named: the questions nobody has answered yet, flagged explicitly rather than quietly assumed. An unanswered question that is written down is a manageable risk. The same question unwritten becomes a change order in month four.
This phase produces the thing that governs everything after it: measurable success criteria. Not "the portal should be fast" but a stated target. Not "reporting should be accurate" but a defined reconciliation. Criteria written so that at the end, whether they were met is a matter of testing rather than debate.
Design — and your signature on it
You review and approve the full design before we build. Screens, data model, integrations, workflows, success criteria — the whole thing, in writing, signed off.
The sign-off is the mechanism that makes the rest work. It converts a shared understanding, which decays and diverges the moment the meeting ends, into a document both parties are bound to. It protects you, because we can be held to exactly what you approved. It protects us equally, because the standard is written down rather than remembered.
It also creates a genuine decision point. If the design is not what you wanted, the moment to discover that is while it is still a document — not after the build is underway and the cost of changing direction has multiplied.
Deliver — tested against the criteria you approved
We build to the signed design, then run user acceptance testing against the same measurable criteria that were agreed in the Analyze phase.
That last part is what makes UAT meaningful rather than ceremonial. On most projects, acceptance testing is a demo — the vendor shows what they built, everyone nods, and problems surface after go-live. When the criteria were fixed before a line of code was written, UAT stops being a presentation and becomes a verification: here is what you specified, here is the evidence it does that.
Because the design is signed and the criteria are fixed, we can also commit to fixed-cost delivery against it. That commitment is only possible because of the work that came before — you cannot price a project honestly if you do not know what it contains.
What happens when something genuinely changes
None of this means a project is frozen. Businesses move, and a methodology that cannot absorb real change is a liability rather than a discipline.
When a genuine change arrives, it is handled openly: what it affects, what it costs, what it does to the timeline, decided by you before any work starts. That is a change, priced and approved as one.
What it is not is a surprise line on an invoice, or a quiet expansion nobody discussed. The difference between a well-run project and a runaway one is rarely the amount of change. It is whether each change was a decision or an accident.
What you have at handoff
- A signed design describing what was built, matching what was actually delivered.
- Success criteria, and the test results demonstrating they were met.
- Documentation of the system, its data, and its integration points — yours to keep.
- A record of every change, what it cost, and who approved it.
- An application your people recognize, because they were part of defining it.
That last one is quietly the most valuable. Adoption problems are usually requirements problems wearing a different hat. Software built with the people who use it does not need to be sold to them afterward.
The trade we are making
We spend more time before the build than most firms do. That is a deliberate trade, and worth being upfront about: the requirements phase feels slower, and to a client eager to see progress it can feel like delay.
The return on it is that the build is faster, the estimate holds, and the thing that ships is the thing that was described. Rework is the most expensive activity in software development, and nearly all of it traces back to a requirement that was never captured.
Any competent firm can write code. The differentiator is whether they knew what to write before they started.
If you are scoping an application and want to see what a signed-off engagement looks like in practice, get in touch — or read more about how we handle application development and what past engagements delivered.