Define custom software scope: turn a wish list into a usable first release

Choose a result a user can recognise

Begin with a task somebody genuinely needs to finish. For the maintenance company, that is not “have a dashboard”, but assign a complete enquiry to an available employee and retrieve the agreed arrangement later. Identify the information needed and how the responsible person can establish that the assignment was actually stored rather than merely displayed on screen.

Walk through a current example before drawing solutions. Ask where staff wait, supplement information or continue outside the application. Distinguish a desired result from habits that need not necessarily survive. This investigation may make the first release smaller than initially imagined while giving it a clearer purpose and a more useful relationship to the work performed each day.

GOV.UK Service Manual: How the discovery phase works ↗

Include roles and boundaries in the assignment

Identify who starts, reviews and completes the task. A customer, planner and engineer may use the same request with different responsibilities. Describe the necessary information and operations for each role. “Everyone can log in” is not an access requirement; a planner might assign work while an engineer should update only their own jobs and see a narrower set of records.

Include an excluded case. An engineer should not gain access to another branch’s enquiry by changing an address or identifier. You need not select a complete technical implementation during the first discussion. You do need agreement that the boundary belongs to the required behaviour and will be checked during acceptance, alongside the successful path used by an authorised employee.

Describe states instead of screens alone

A request might be received, incomplete, reviewed, scheduled and completed. Discuss what each state means and who may cause a transition. “Scheduled” and “confirmed to the customer” can represent different events. A single colour in an overview must not silently combine business meanings that staff later need to investigate separately when explaining progress to a customer.

Work through a change after scheduling. Does the earlier agreement remain visible, does a new proposal appear, or is the existing plan immediately replaced? Identify information that becomes outdated as a result. A small state model helps prevent a simple-looking interface from leaving staff to repeatedly guess which business meaning applies to the value that has been stored.

A scope becomes testable when the first release has explicit scenarios to pass: Accept custom software: assess complete tasks and agreed boundaries.

Limit information to what the task needs

Inventory information required by the first workflow and identify its source. A customer address might come from existing administration, while a work instruction originates in the new application. Distinguish information that is displayed, edited or retained historically. This often exposes a term being used for several different types of information without those differences being acknowledged in the proposed screens.

Use fictional records to discover missing meaning. What happens with an unknown customer reference, a changed address or two locations sharing a name? Record the decision before treating import as an easy technical step. Limiting information keeps scope understandable, but should not remove references, provenance or review information needed to explain what the application has done in actual operation.

Place exceptions alongside the normal path

Choose exceptions that materially affect the design: missing input, a withdrawn enquiry, an unavailable application or simultaneous changes. Describe the desired behaviour as clearly as the ordinary task. Should work stop, wait or go to a person for review? Who receives an understandable notification, and what reference allows that person to find the affected case and decide what happens next?

You need not implement every imaginable exception beforehand. Distinguish cases supported in the first release, situations covered by an agreed manual route and uncertainty requiring investigation. An explicit temporary working method is easier to assess than silently assuming users will somehow solve problems once the application is live. The manual route should name an owner and preserve enough information for later reconciliation.

Separate discovery from executable work

Some requests depend on unconfirmed capabilities. A vendor might need to enable API access, or an existing database may be poorly documented. Frame a small investigation with a concrete output: a demonstrated exchange, usable export or list of blocking limitations. Agree who provides information and access and when the next decision will be made on the evidence obtained.

Do not hide that uncertainty inside a fixed promise for the entire build. A proposal can contain confirmed implementation and a distinct investigation step. Explain which choices change if an assumption proves false. The maintenance company might initially export records manually rather than making an unproven real-time integration a dependency for every part of its first release. That boundary keeps progress proportionate to evidence.

Make acceptance criteria observable

For each important task, state what someone should be able to establish. A request is stored under a stable reference, an unauthorised user cannot access it, and a failed handover remains visibly unresolved. Add normal input and an exception case. This produces stronger criteria than words such as usable, fast or fully integrated without any description of the expected outcome.

Agree who reviews results and where evidence is retained. A project owner can assess the business outcome while a technical operator checks a recovery exercise. Keep measurable indicators distinct from chosen objectives; Google SRE explains that principle for services. The actual threshold must follow your own usage and responsibilities, rather than being presented as a universal technical standard for every project.

Google SRE: Service Level Objectives ↗

Identify work deliberately left for later

Make exclusions as concrete as included work. The fictional first release could handle incoming maintenance requests while automatic invoicing, stock control and multiple planning regions remain later possibilities. Explain the work staff continue to perform meanwhile. Otherwise an exclusion may look precise in a proposal while leaving the operating process impractical for the people expected to use it.

Check whether a known later need already affects an important boundary. A second branch need not be implemented immediately, but may require organisation-specific data separation. Investigate that boundary deliberately. This is not a reason to build every future feature now. It helps prevent a small first step from unnecessarily obstructing a necessary next step that is already understood by the project team.

Use scope to assess changes

A change becomes understandable when original and proposed behaviour are compared. Which user receives another operation, what information is created and which rules change? Include effects on testing and maintenance. An additional field might alter selection, authorisation, exports and documentation even when its interface is small. Describe those consequences before deciding that a request is merely a cosmetic adjustment.

Keep the agreed initial scope, decisions and trial cases with a recognisable version. Give new wishes a decision of their own: implement, investigate or defer. Project size then remains more than a discussion about hours. You retain visibility over the result being purchased, its assumptions and the operating responsibility that remains once the first version becomes available to the organisation.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Custom software development ↗
• Customer portal development ↗

Questions about this topic

Continue with a related question