Practical guide / How to scope a custom software project
Scope the first useful release.
A good software brief describes the work and the decisions around it. It leaves room to choose the right interface after the team has agreed on users, records, and boundaries.
When to use this
Start with the decision in front of you.
Use this when an internal app or customer portal seems necessary but the requested feature list keeps growing before anyone has tested the core workflow.
Decision steps
A practical sequence.
- 01
Choose one job and its users
Name who starts the process, who reviews it, and who receives the result. Describe the action each person must be able to complete in the first release.
- 02
Define records and permissions
List the fields that matter, where they come from, who may view or change them, and how mistakes are corrected. Avoid collecting data just because a form can hold it.
- 03
Write the exceptional paths
Include missing information, rejected approvals, duplicates, unavailable connections, and requests that need human judgment. These cases often determine the real complexity.
- 04
Agree acceptance and ownership
Choose realistic test cases, a launch handoff, and responsibilities for hosting, support, and future changes. Separate later ideas from the first release.
Illustrative scenario, not a client case study
See the decision in context.
Staff ask for a customer portal because approval emails are difficult to track.
Decision to test. A first release might allow staff to submit a request, let the authorized approver accept or return it, and show the status. Customer login could wait until the internal path is proven useful.
First action. Write three representative requests, including one that fails the normal path, before estimating the build.
Take to your team
Questions worth answering.
- 01What must a user finish in the first release?
- 02Which data and permissions are essential?
- 03What happens when an approval or integration fails?