MethodRequirementsPrototypeBusiness software
Software project scoping: steps, workshops, deliverables and how long it takes
10 min read
Scoping a software project is the phase that comes before development. In a few days or a few weeks, it turns an intention ("we need a tool to track field interventions") into written decisions: why this software, for whom, with which rules, connected to what, what goes into the first version and what waits. It runs as interviews and workshops with a decision-maker, future users and the development team, and it ends with concrete deliverables: a scope summary, user journeys, a prototype, a prioritised backlog and an estimate.
Agencies call it many things: discovery phase, inception, scoping sprint, project definition. The label matters less than the result. Good scoping is not measured by the thickness of the document. It is measured by the number of questions settled before anyone writes production code.
Scoping, requirements, prototype: who does what
The three terms get mixed up. They answer different questions.
| Item | Main question | Form | Who produces it |
|---|---|---|---|
| Scoping | Why, for whom, and what first? | Workshops and a scope summary | Client and vendor together |
| Requirements document | What exactly must the software do? | Detailed written document | The client, often with help |
| Prototype | What will it look like, is the flow right? | Clickable screens | The vendor, validated by real users |
Scoping is the process; the requirements document and the prototype are two of its possible outputs. For an internal tool, a validated prototype plus a list of business rules often does the job better than a long specification. Our guide to writing a software requirements document explains when the full document is still worth writing.
The seven questions scoping must answer
Scoping is done when each of these questions has a written answer, even a provisional one.
- What problem are we solving, and how will we know it is solved? A measurable goal: less double data entry, a shorter processing time, fewer invoicing errors.
- Who is it for? The user roles, their context (office, field, mobile) and how comfortable they are with software.
- Which business rules? Approval chains, calculations, statuses, and above all their exceptions.
- Which existing systems? ERP, accounting, CRM, email, spreadsheets: what the new software reads, what it writes, and which system remains the source of truth for each piece of data.
- Under which constraints? Personal data, security, hosting location, accessibility, sector rules.
- What comes first? The scope of version one, and an explicit list of what is left out.
- How much, by when, and who decides? A budget range, a deadline and a named person who settles trade-offs.
Question six is the one that saves the most money. Our article on what to build first in an MVP helps you draw that line.
How scoping runs, step by step
The format changes with the size of the project, but the same stages come back almost every time.
1. The kickoff interview
A meeting with the decision-maker and the process owner. It sets the context, the goal, the budget range and the deadline, and it produces two lists: the people to talk to and the material to gather (data exports, document templates, screenshots of the current tools). What comes out is a list of open questions that will guide the rest of the phase.
2. Watching the work
This is the step most often skipped, and the one with the best return. An hour spent watching someone do the job teaches more than a day of meetings: the side spreadsheet nobody mentioned, the Friday afternoon re-keying, the workaround everyone uses. A few short interviews with future users are usually enough.
3. The scoping workshops
Short working sessions, each on one topic:
- the journey workshop: walk through, step by step, what each role does, from the trigger to the outcome;
- the rules workshop: for each step, the conditions, calculations, special cases and possible errors;
- the data and integrations workshop: where each piece of information comes from, where it has to go, and in which format;
- the prioritisation workshop: sort every need into must have, later, or nice to have, then draw the version one line. The MoSCoW method is a common way to run it.
An effective workshop has a written objective, a facilitator and a note taker. It ends with the list of decisions made and the questions still open, each with an owner.
4. The technical inventory
In parallel, the development team examines what already exists: the APIs of the systems to connect, the quality of the data to migrate, hosting and security constraints. This is where you discover the ERP without an API, or the export that strips accented characters. Our article on integrating a custom application with an existing ERP lists what to check.
5. The prototype
Decisions made in workshops become screens. A clickable prototype shown to users surfaces what no meeting notes reveal: a missing field, a useless screen, a sequence of steps that does not match how the work is really done. One or two iterations are usually enough to stabilise the main journeys.
6. The playback
A final session presents the deliverables to the decision-maker, who approves the version one scope, the estimate and the plan, or asks for more trade-offs. Scoping ends with a decision: go, adjust, or stop.
Who takes part, and in what role
| Participant | Role in scoping | What happens if they are missing |
|---|---|---|
| Decision-maker (owner, director) | Sets the goal, settles trade-offs | Decisions stay pending |
| Process owner | Knows the process and its exceptions | Business rules are incomplete |
| Future users | Describe the real work, test the prototype | The software fits a theoretical process |
| Owner of the existing systems | Knows the access rights, exports and APIs | Integrations are estimated by guesswork |
| Product lead (vendor) | Facilitates, writes things down, prototypes | Workshops turn into meetings |
| Developer (vendor) | Assesses feasibility and technical risk | The estimate rests on assumptions |
Two remarks. The decision-maker does not need to sit through every workshop, but must be reachable and decide quickly. And scoping run without a single future user almost always produces software the team works around.
The deliverables of a scoping phase
At the end, you should hold:
- a scope summary (some call it a project charter or vision document): context, measurable goal, scope and exclusions, people, constraints, risks, budget range and target dates;
- user journeys for each role;
- the list of business rules, exceptions included;
- an inventory of integrations and data to migrate, with the source of truth for each data set;
- a prototype validated by users;
- a prioritised backlog, with the version one line drawn;
- an estimate as a range, with its assumptions written down;
- a high-level plan with approval milestones;
- a risk log and the questions still open.
These deliverables are what a vendor needs to write a credible statement of work (SOW), whether the contract ends up fixed price or time and materials.
On constraints, one point deserves attention at this stage. Article 25 of the GDPR requires data protection by design and by default, and the UK GDPR keeps the same rule. Scoping is the right moment to list the personal data the software will process, how long it is kept and which role can see what. Our GDPR checklist for a business application walks through it.
How long scoping takes
Duration depends less on technology than on two factors: how wide the scope is, and how available the people who decide are. As a rough guide:
| Type of project | Appropriate depth of scoping |
|---|---|
| Simple internal tool, one or two user roles | A few days of conversations and a prototype |
| Business application with integrations | A series of workshops, a technical inventory, an iterated prototype |
| Customer-facing product (SaaS, client portal) | Several weeks, with user interviews and prototype testing |
Scoping that keeps growing without producing decisions is a signal: either the decision-maker is not available, or the goal is not shared. Better to find out during scoping than halfway through development.
Free or paid scoping?
Both exist. Light scoping folded into the pre-sales conversation suits projects with a clear scope. A paid discovery phase makes sense when the rules are many, the integrations uncertain or the users spread across sites: it ties up several people for several days.
Either way, check three things before you start:
- Can another team read the deliverables? Scoping is only worth something if it remains usable without its author.
- Who owns them? Rights over documents, mockups and prototypes are defined case by case in the contract: read the clause.
- Which decision will it support? Scoping must end in an estimate you can act on. Our guide on how to estimate a software project explains how to read one.
The most common scoping mistakes
- Scoping the solution instead of the problem. Arriving with a feature list hides the fact that part of the need could be met another way, sometimes without any development.
- Forgetting the exceptions. The general case fits in one sentence; the exceptions drive the cost. A rules workshop that finds none has not dug deep enough.
- Leaving users out. Scoping between managers and a vendor describes the process as people imagine it, not as it is practised.
- Excluding nothing. A scope summary with no exclusion list leaves the door open to every unspoken expectation, which is how scope creep starts.
- Confusing completeness with precision. A hundred page document does not replace ten clear decisions.
- Letting scoping go stale. A scope approved and then shelved for months must be reviewed before development starts.
When heavy scoping is a waste
Not every project needs a series of workshops. For a simple tool, used by one team, with a stable and well understood process, one in-depth interview followed by a prototype is enough: each extra week of scoping costs more than the mistake it prevents. At the other end, for a new product whose right features nobody knows yet, no amount of scoping replaces putting something in front of real users. Scope a short first version, ship it, measure, then scope the next one.
Signs that scoping worked
- The decision-maker can explain the goal and how it will be measured in two sentences.
- Users recognise their own work in the prototype journeys.
- The exclusion list exists and has been approved.
- Every integration has been checked, not just named.
- The estimate is a range, and its assumptions are written down.
- The remaining open questions each have an owner and a date.
Where to start
- Write one page: the problem, the users, the tools in place, the budget range and the deadline.
- Name a decision-maker who has time to decide.
- Gather real examples: exports, documents, screenshots.
- Make the need visible as early as possible.
For that last step, we build a free visual prototype, presented on a video call within 5 working days of a first scoping conversation: you see your journeys as screens before committing to anything. Our article see your software before you pay for it explains what the prototype contains, and what it does not replace.