Why software projects fail at requirements, and how to stop scope creep

Developers are good at building what they are asked for. The trouble is that what they are asked for is often not what the business needs, and nobody finds out until the software is in front of the people who have to use it.

Where requirements go wrong

The stated problem is not the real one. The first request is usually a solution (“we need a portal”) rather than a problem (“customers phone us five times to find out where their order is”). Build the solution as stated and you may solve nothing.

The people who do the work were not asked. Requirements gathered from managers describe how the process is supposed to run. The people doing it know how it actually runs — the exceptions, the workarounds, the spreadsheet beside the official system. That gap is where projects go wrong.

Requirements are written to be approved, not tested. “The system shall be intuitive and efficient” will be approved by everyone and can be verified by no one.

Nothing is out of scope. Without a written list of what the system will not do, every stakeholder assumes their own priorities are included.

The data was an afterthought. What the system holds, who owns each record and how it moves between systems are decided late, by developers, without the business in the room.

Scope creep is a symptom

Scope creep is usually described as stakeholders asking for more. More often it is the project discovering what it should have known at the start. Each “new” request is a requirement that existed all along but was never written down.

That is why the cure is not refusing changes. It is writing the scope down precisely enough that a change is visible as a change — and then deciding about it deliberately.

When requirements keep changing

Some change is legitimate. Markets move, regulations change, and building software teaches people what they actually want. The useful distinction is between discovery — learning something genuinely new — and drift, where scope expands because it was never bounded.

Handle both the same way: write the change down, say what it costs in time and money, say what it displaces, and get a decision from someone who owns the budget. Changes priced and agreed are healthy. Changes absorbed silently are how projects end up late with nobody able to explain why.

What actually prevents it

1. Watch the work being done before writing anything. Interviews alone miss the workarounds.
2. Write the as-is process as well as the to-be. The current process is evidence.
3. Separate software changes from people changes. Some problems are process problems, and saying so saves money.
4. Give every requirement acceptance criteria, so it can be tested and its completion is not a matter of opinion.
5. Write the out-of-scope list and have the people who asked for those things see it.
6. Walk the specification back through the stakeholders and get it agreed before the build begins.
7. Put change control in writing: every change described, priced and approved.

Our guide on how to write a functional design document shows how these fit into a single document.

Who should do this work

There are three common arrangements, each with a different failure mode:

• The developers write the requirements. Fast, but developers naturally specify what is convenient to build, and the business questions go unasked.
• A consultancy writes them, a separate team builds. Thorough, but whether the specification is buildable at the price is no one’s problem until the build starts.
• An internal business analyst writes them. Good when the capacity exists; often it does not, or the analyst is pulled between too many projects.

The arrangement we offer is the analyst who writes the specification leading the engineers who build from it, so the specification has to be buildable and the build has to match it. The analysis can also be bought on its own — see requirements analysis.