The sections every software project scope needs, from the problem and what's out of scope to running costs and who owns the code, so nobody is surprised later.
Most software projects that go wrong don’t fail on the code. They fail because two people had different pictures of what was being built. A short written scope, agreed before any work starts, is the cheapest way to make sure everyone has the same picture.
It doesn’t need to be long. A good scope fits on a few pages, and each section answers a question someone will otherwise ask halfway through the project.
The problem, in plain words
Describe what isn’t working today and who it affects. “Staff spend Monday mornings copying figures between three spreadsheets” is more useful than “build a reporting platform”. A clear problem lets you judge every later decision against it.
Who will use it
List the groups of people who’ll use the system and what each needs to do. Staff, managers, customers and administrators usually need different things, and they often need different permissions.
What’s included, and what isn’t
The “not included” list matters as much as the “included” one. If integrating with your finance system, migrating old data or building a mobile app isn’t part of this project, say so. It prevents arguments and gives you a ready list for the next phase.
How you’ll know it’s done
Write acceptance criteria you can check: “A manager can approve a request from their phone” rather than “the approval process works well”. These become the tests at the end of the project.
Milestones you can see
Break the work into stages that each end with something you can try, not just a progress report. Seeing working software early is the best way to catch misunderstandings while they’re still cheap to fix.
Risks, named early
Every project has unknowns: an old system nobody has documentation for, a supplier whose cooperation you need, data that may not be as clean as hoped. Naming them up front, with what you’ll do if they bite, is a sign of an honest plan.
The cost of building it and of running it
The build price is only part of the cost. Include hosting, licences, support and updates for the first year, so the budget holder sees the full picture before deciding.
Who owns what at the end
Agree that the code, the cloud accounts and the documentation belong to you. If you ever change supplier, you should be able to hand everything over without asking permission.
Support after launch
Say what happens after go-live: who fixes problems, how quickly, and what’s covered. Even a simple line such as “fixes for the first three months are included” avoids awkward conversations later.
If you’re planning a project and want help writing the scope, get in touch. We write one for every project before any work begins.