How to Scope a Custom Software Project

Write the first-release boundary

Name the users, permitted actions, required information and completion state. Include correction and failure paths. Then state exclusions plainly so “not now” does not become an invisible assumption.

• Included: the complete core journey, its necessary controls and support route.
• Excluded: optional channels, roles, integrations or reports that will wait.
• Assumed: facts that are not yet verified, with an owner and a decision date.
• Dependent: access, data, approvals or supplier work required for delivery.

Use the feature prioritisation guide to separate a viable first release from a collection of desirable features. A deliberately manual step still needs a named owner and realistic capacity.

Replace vague requirements with acceptance examples

“Easy to use” and “secure” are goals, not sufficient acceptance instructions. Describe observable behaviour, including the conditions under which an action must fail.

Hypothetical scope example: an invited customer submits a service request. Required fields are validated, the customer receives a reference and authorised staff can review it. Another customer's account cannot retrieve the request by changing its identifier. A repeated submission does not create an unnoticed duplicate.

Agree who signs off each example and which environment and data will be used. Necessary accessibility, performance, recovery and privacy requirements belong in the scope. Define measurable thresholds with the team for the actual context rather than copying generic promises.

Give every dependency an owner

For each integration, record the system, required operation, available documentation, test access and system owner's approval. An available API does not establish that every required action is supported or permitted.

For data, record source ownership, expected format, quality checks and the treatment of incomplete records. For business decisions, name the person authorised to resolve conflicting rules. This prevents an unresolved policy question from appearing later as a coding delay.

Use the ERP and CRM application guide to examine system boundaries. If you are changing an existing application, add the migration and recovery evidence from the legacy modernisation guide.

Estimate the defined work with the team

Ask for an estimate that identifies included delivery work, assumptions, uncertainty and ongoing operating responsibilities. Include testing, data preparation, deployment, training and support handover where needed. Cost and duration depend on the verified scope and dependencies; agree them with the people doing the work.

AI-assisted development can help with implementation tasks, but it does not remove business decisions, access approvals or acceptance testing. Ask which tasks may benefit and how output will be reviewed. Do not assume a tool automatically produces a fixed discount or launch date.

Keep a short, living scope record

When a new request arrives, record the problem it solves, whether the existing outcome fails without it and its effect on cost, timing and risk. Choose to include it, exchange it for other work, investigate it or defer it. Have the accountable owner approve the decision.

Before starting, share a compact brief containing the outcome, users, boundary, acceptance examples, dependencies, exclusions and decision owners. Before release, use the MVP checklist to verify the agreed work. The MVP and product development service provides the wider delivery context.

Prepare the decisions around your scope

Use the development partner selection guide to assess proposals, the discovery workshop guide to plan unresolved questions and the integration preparation checklist to establish system readiness. For customer-facing work, start with a client portal brief.

Questions

Frequently asked questions