How to scope a software project
Every project I scope goes through the same discipline, whether it's a one-person startup or a platform for a £1bn corporate. There's no secret to it, just work that has to be done properly and in the right order:
- Start with the business problem, not the feature list. What actually changes for the business if this project works? If nobody can answer that, no feature list will save it.
- Find every user and walk their journeys. Not just the customers: the admin staff, the finance team, the person who has to fix things at 5pm on a Friday.
- Ask the awkward questions early. Where does the data live now, and what state is it really in? What has to integrate with what? Who can say no to this project, and have they said yes?
- Write the requirements down, numbered and evidenced. Every requirement traceable to a reason. Vague hopes become specific, testable statements.
- Phase it honestly. What belongs in version one, and what feels essential but genuinely isn't. Most projects that fail were trying to build phase three first.
- Only then put costs and timelines on it. Numbers written before the thinking are guesses, and guessed numbers are the single biggest reason software projects go wrong.
That last point is the whole game. I won't price or schedule anything until the analysis has been done, and I don't believe anyone else should either.
What you get: one document, written to be built from
The deliverable is a full written specification. Depending on the project it covers:
- The business goals, in plain English, agreed before any design happens
- Every type of user and their journeys through the system
- Functional requirements, numbered and evidenced, in enough detail to build from directly
- Data: what exists, what needs migrating, what the system must record
- Integrations with the systems you already run
- The non-negotiables: security, performance, accessibility
- Risks and unknowns, flagged honestly rather than buried
- Phasing: a version one worth shipping, and a roadmap for the rest
The specification is yours. Take it to any team, use it to gather accurate costings, put it in front of your board or your investors. Clients have used my specifications to win funding, to get sign-off, and then to get the thing built without the nasty surprises that usually turn up halfway through.
How it works
-
A half-day workshop
Around Leeds or on a call, with the people who actually know the business. We get the idea out of heads and onto the wall, and it's genuinely good fun.
-
The analysis
I talk to the people involved, dig into your data and systems, and ask the awkward questions while they're still cheap to answer.
-
The specification
Written over two to six weeks depending on the size of the thing, with drafts shared as we go and a proper walkthrough at the end.
-
The handover
All for a fee we fix up front. Then build with any team you like. If you want me to stay involved while it's delivered, that's delivery assurance.
Where this has worked
I've been doing this for twenty-five years. The biggest specification I've signed off was around £12m: a platform serving two and a half thousand schools, scoped through a month of daily requirements sessions in Sydney. The smallest have been one-person startups with an idea and a deadline. The job is the same at both ends: understand the business properly before anyone builds anything.
The format has survived contact with real money. Specifications I've written have been used to secure funding, to get board sign-off, and to brief teams who built from them without me in the room.
When you don't need this
Honestly: if you're testing a small idea, a ready-made product already fits, or a week of prototyping would answer the question faster than a document, just build the thing. Scoping earns its keep when being wrong is expensive: real money, real data, other people's time, a board or a funder to answer to.
If the cost of being wrong is a week and a bit of pride, you don't need me yet. Come back when it's bigger.
Common questions
Do I need a business analyst before building software?
If being wrong would be expensive, yes. The test I give people is this: could you write down what the software must do, who uses it, and how you'll know it worked, in enough detail that two different suppliers would quote for the same thing? If you can't yet, the analysis hasn't been done, and someone will end up doing it in the middle of the build at many times the price. If your project is small and easy to reverse, skip the analyst and just build it.
How long does scoping and specification take?
Two to six weeks for most projects, starting with a half-day workshop. Small, well-contained ideas sit at the short end; platforms with lots of users, data and integrations sit at the long end. You see drafts as we go, not a big reveal at the end.
How much does scoping and specification cost?
A fixed fee, agreed before the work starts and sized after the workshop, so you always know what you're committing to. As a rule of thumb it's a small fraction of the build cost, and it tends to pay for itself twice over: suppliers quote accurately instead of padding for uncertainty, and you avoid the mid-build changes that are where budgets really go.
Can a development team build straight from the specification?
Yes, and that's the test of a good one. Everything is numbered, evidenced and written so that a team can pick it up without me in the room, and teams have. You own the document outright and can take it to any developer, agency or in-house team. If you want me to stay involved while it's built, that's delivery assurance, and it's a separate, honest decision rather than a lock-in.
What if the analysis says the project isn't worth building?
Then I'll tell you, with the evidence, and you'll have spent a fraction of the build cost to find out. I have no build to sell and nothing waiting on your yes, which is what lets me give you the honest answer. Sometimes the analysis points at a smaller, cheaper version that is worth building, and that's usually the best outcome of all.
How is this different from a development agency's discovery phase?
Independence. A discovery phase run by the people who will build the project tends to discover a project shaped like their team and their platform. I don't build, I don't resell anything and I don't keep developers on a bench, so the specification describes what your business needs, not what someone needs to sell you. Good agencies genuinely like building from it, because clear requirements make their job easier too.
Do you only work in Leeds?
I'm based in Leeds and workshops are lovely in person around Yorkshire, but most of the work happens in documents and calls, so the practice works with businesses anywhere.