Ask anyone who has commissioned a software project that ran over time and budget, and the explanation rarely involves the developers writing bad code. It usually involves a decision that was never actually made: an assumption both sides carried into the project without saying it out loud, surfacing three months in as a disagreement about what was supposed to be built.
Key Takeaways
- Most software project overruns trace back to scope gaps agreed vaguely at the start, not to development quality.
- A scope document is only useful if it states what’s explicitly excluded, not just what’s included.
- Change is normal in software projects; the failure isn’t scope changing, it’s changing without anyone formally agreeing to the new cost or timeline.
- Scoping conversations that only happen once, at the start, miss the requirements that only become clear once stakeholders see something real.
- The clearest sign of a well-scoped project is that both sides could independently describe what “done” looks like in the same terms.
Business owners commissioning software for the first time often assume scoping is a formality, a document to sign before the “real work” of building begins. In practice, the quality of that early conversation determines more about whether a project finishes on budget than almost anything that happens during development itself.
What scope documents usually get wrong
Most disputes over a software project don’t come from ambiguity about what was included. They come from what was never explicitly excluded. A scope that lists features to be built but never states what’s out of bounds leaves room for both sides to assume differently, and that gap surfaces exactly when it’s most expensive to resolve, midway through a build, when changing course costs far more than agreeing the boundary would have at the start.
The Association for Project Management’s guidance on scope in project delivery, reflecting the framework set out in its 2019 Body of Knowledge, treats explicit boundaries, not just deliverables, as the core of a usable scope document. A well-written scope should let someone unfamiliar with the project read it and describe, in the same terms as the team building it, what will and won’t exist when the project is finished.
A project manager and developer reviewing a project plan document
Change isn’t the problem, undocumented change is
A persistent myth in software scoping is that a good scope prevents change. It doesn’t, and trying to make it do so usually backfires, since requirements genuinely do shift as stakeholders see working software for the first time and realise what they actually need. This is precisely the spirit of the Agile Manifesto, published in 2001, which treats responding to change as more valuable than following a fixed plan. GOV.UK’s guidance on agile delivery for public services builds this expectation in directly, treating evolving requirements as the normal condition of a software project rather than a failure of the original plan.
The actual failure mode isn’t scope changing. It’s scope changing informally, a feature quietly added because it seemed reasonable in the moment, without anyone agreeing what that does to the timeline or the cost. Twenty small, reasonable additions made this way add up to a project that’s meaningfully different from the one that was originally priced, without either side quite noticing it happening.
A scope document that never gets revisited after the kickoff meeting was written for a project that no longer exists by the time it finishes.
Scoping is a conversation, not a document
Harvard Business Review’s 2011 research on IT project risk, drawn from a sample of 1,471 IT projects, has long pointed to a pattern where the projects that run into serious trouble are disproportionately the ones where scope was fixed once, early, and never structurally revisited as new information emerged. Treating scoping as a single upfront event, rather than a conversation that continues through the project at defined checkpoints, is a large part of why estimates drift so far from delivery.
Software built well tends to treat scoping as ongoing rather than a gate passed once. A platform Arch built for NHS radiology communications, for instance, involved scope conversations that continued through delivery as clinical stakeholders across different trusts clarified requirements that weren’t fully knowable until the working system was in front of them. Building that structure into a project from the outset, regular checkpoints where scope is explicitly reconfirmed rather than assumed, is what keeps a shifting understanding of requirements from turning into an uncontrolled budget.
A whiteboard covered with sticky notes outlining a project roadmap
What a well-scoped project actually looks like
The clearest test of a scope document isn’t how detailed it is. It’s whether the client and the development team, asked separately what “done” means, would describe the same thing. Agile Alliance’s introduction to iterative delivery frames this shared understanding, not a fixed specification, as the actual goal of good scoping: not eliminating uncertainty, which isn’t possible, but making sure both sides are working from the same picture of it as the project moves forward.
For a business commissioning software, the practical version of this is asking, at the scoping stage, not just what will be built but what explicitly won’t be, and agreeing upfront how new requirements that emerge mid-project will be priced and timed rather than absorbed silently. That single habit prevents more overruns than any amount of upfront detail in the original document.
It’s also worth asking a prospective development partner how they handle scope conversations once a project is underway, not just how thoroughly they document it at the start. A team with a defined process for revisiting scope at set milestones is telling a business something useful about how disagreements later in the project will actually get resolved, long before either side needs to find out the hard way.
That answer tends to be revealing in itself. A team that describes scope purely in terms of a signed document usually hasn’t run a project complicated enough to need anything more. One that can describe how it handles the moment a stakeholder asks for something reasonable but unbudgeted, calmly, with a defined process rather than an awkward silence, has almost certainly been through that exact conversation before and learned from it.
Frequently Asked Questions
What’s the difference between scope and requirements?
Requirements describe what the software needs to do; scope describes the boundary of what’s being delivered, including what’s explicitly excluded. A detailed requirements list without a clear boundary still leaves room for disagreement about what’s actually included in the project.
Why do software projects go over budget even with a scope document in place?
Usually because the scope document only covered what was included at the start, not what was excluded, and because requirement changes during the project were absorbed informally rather than formally repriced. The overrun is rarely one dramatic change; it’s an accumulation of small, undocumented ones.
Should a scope document be fixed once the project starts?
No. Requirements shift as stakeholders see working software, and a scope that’s never revisited stops reflecting the project it was written for. Good practice treats scoping as a conversation with defined checkpoints, not a single document signed at the outset.
How detailed should a project scope be?
Detailed enough that the client and the development team could each independently describe what “done” looks like and arrive at the same answer. Detail for its own sake matters less than shared understanding of the boundary.
Who should be involved in scoping a software project?
Anyone whose requirements will meaningfully shape the build, not just the person commissioning it. Projects with multiple stakeholder groups, different departments or user types, need scoping conversations that surface conflicting assumptions before development starts, not after.
