The short version
Scoping comes down to six pieces of work, in this order:
- Agree the business problem you're solving and what changes if you solve it.
- Find every user, not just the obvious ones, and walk through their day.
- Ask the awkward questions about data, integrations and authority while they're cheap to answer.
- Write the requirements down, numbered, specific and traceable to a reason.
- Split the project into honest phases, with a version one that can ship on its own.
- Only then put costs and timelines on it.
The order matters more than any single step. Nearly every failed project I've been brought into broke the order somewhere, and it's usually the same place: a number was written down before the thinking that should have produced it.
Step 1: agree what the project is actually for
Before anyone talks about features, write one paragraph in plain English saying what the business problem is, what will be different if the project works, and how you'll measure the difference. Then get the person who owns the budget to read it and agree to it in writing.
This sounds too obvious to bother with, and it's the most valuable hour in the whole process. When a feature argument breaks out three months later, and one will, that paragraph is the referee.
A test for whether yours is any good: would a stranger reading it understand why the business is spending the money? "We need a new portal" fails that test. "Our staff retype every order from email into the accounts system, which takes two days a week and causes most of our invoicing errors" passes it, and notice it hasn't mentioned software yet. The best goal paragraphs describe the problem so clearly that the solution has room to be something cheaper than you expected.
Step 2: find every user and walk their journeys
Customers are the easy part. The users who sink projects are the ones nobody thought to ask: the admin team who will live in the system eight hours a day, the finance person who needs it to agree with the accounts, whoever gets the phone call when something breaks at five o'clock on a Friday.
List every type of person who will touch the system. Then walk each journey end to end with the actual people, asking where their information comes from, what they do to it, and where it has to go next. Their manager's description of the job is not the job, and the gap between the two is exactly where mid-build surprises come from. Every gap you find at this stage is a change request that never gets raised.
Step 3: ask the awkward questions while they're cheap
Every project has questions that cost a conversation now or a fortune later. These are the ones I always ask:
- Where does the data live today, and what state is it really in? Almost every project moves or connects existing data, and almost every business overestimates how clean theirs is. Open the actual spreadsheets and look, don't take anyone's word for it.
- What does this have to integrate with, and are those connections real? "It has an API" covers everything from a documented, supported interface to a CSV export a man called Steve runs on Tuesdays. Find out which one you have before anybody prices the integration.
- Who can say no to this project, and have they actually said yes? IT, legal, compliance, a parent company, sometimes a big customer. A veto that arrives three months into a build is one of the most expensive things that can happen to a project, and it was nearly always available for free at the start.
- Which constraints are real? Deadlines come in two kinds: tied to something genuine like a contract or a season, or invented to create urgency. Budgets are the same. You can plan around either, but only if you know which you're looking at.
Step 4: write the requirements down properly
This is the step most projects skip past, and it's where the value is. A requirement is written down, numbered, specific enough to test, and traceable to a reason.
"The system should be easy to use" is a hope. "R14: a trained member of staff can process a standard order in under two minutes without leaving the screen" is a requirement. You can build to it, you can quote against it, and after launch you can check whether it came true.
Numbering sounds bureaucratic and turns out to be the thing that keeps meetings sane, because people can argue about R37 instead of talking past each other about "the ordering stuff". Alongside the requirements, keep two more lists: decisions made, with who made them and why, and things explicitly out of scope. The out-of-scope list saves more arguments than anything else in the document. "We agreed in March not to do that in phase one" lands very differently when it's written down.
Step 5: phase it honestly
Everything feels essential while you're describing the finished vision, and almost none of it is. For each requirement, ask whether the business could genuinely launch and get value without it. The difference between a version one that ships and a project that quietly dies is usually a year of features that could have waited.
A good version one is small enough to ship, complete enough to do real work, and useful enough that people would complain if you turned it off. Everything else goes into a phased roadmap where it stays visible without holding the launch hostage. Most of the failed projects I've looked at were attempting phase three first.
Step 6: only now talk about cost and time
Any number produced before the steps above is a guess. Guessed numbers are the single biggest reason software projects go wrong, because they get written into budgets, promised upwards, and then defended long after everyone involved knows they were fiction.
Once a specification exists, pricing changes character. Suppliers can quote against numbered requirements instead of padding for uncertainty, you can compare quotes because everyone is pricing the same thing, and when one quote comes back wildly different from the rest, you can find out why. That conversation is sometimes the most useful part of the whole exercise.
Briefing a development team from it
With the scope done, briefing an agency or a development team stops being a dark art. Send the goal paragraph, the journeys, the numbered requirements and the phasing, then ask every supplier for two things: a price for phase one, and what they would challenge or change. The second answer tells you more than the price. Good teams push back somewhere, because they know their terrain better than you do. A supplier with no questions at all either hasn't read it or is saving the argument for later, on your money.
Can you do this yourself?
Often, yes. The method needs discipline more than it needs me: write the paragraph, talk to the real users, ask the awkward questions, number the requirements, phase honestly, and keep the numbers until last. If the project is small and being wrong would be survivable, run it yourself and spend the saving on the build.
Independence earns its keep when the numbers are big enough to hurt, when the politics need an outsider who can ask blunt questions of senior people, or when nobody inside has the time to do it properly, which is the honest reason most of my work exists. If that's where you are, scoping and specification is the first of the three things I do, and I'll tell you for nothing whether your project actually needs it.
Common questions
How long does it take to scope a software project?
Two to six weeks for most business projects, if someone is actually driving it. Small, well-contained ideas sit at the short end, platforms with lots of users and integrations at the long end. If it has been running for three months with nothing written down, it has stopped being scoping and turned into drift.
What is the difference between scoping and a specification?
Scoping is the investigation: the problem, the users, the constraints, the awkward questions. The specification is the document that comes out of it. You need both, because analysis that never gets written down evaporates, and a specification written without the analysis behind it is fiction with numbering.
Who should scope a software project?
Someone with enough time to do it properly, enough standing to ask senior people awkward questions, and no stake in what the answer turns out to be. That can absolutely be someone inside the business. The reason it's often an outside job is the last part: it's hard to tell your own boss that the project they announced isn't worth building.
What should a software specification include?
The business goal in plain English, every user type and their journeys, numbered functional requirements each traced to a reason, the data picture including what needs migrating, integrations, the non-negotiables such as security and accessibility, the risks stated honestly, and phasing. The test of the whole document is that two different suppliers would read it and quote for the same thing.
How much does scoping cost?
Done in-house it mostly costs attention: a few weeks of somebody's focus, which is real but budgetable. Done professionally it's typically a small fraction of the build cost, and it tends to pay for itself in the quotes alone, because suppliers price uncertainty into every vague requirement and there's a lot less padding to pay for when the requirements are specific.
How do I know when scoping is finished?
When new conversations stop changing the shape of the project and only add detail to it. The practical test is whether two different suppliers could quote for the same thing from what you've written. If big new requirements are still appearing every week, keep going.