Discovery & delivery
What should software discovery deliver? A worked example
A concrete example of the decisions, scope and evidence you should receive before approving development.
Software discovery should leave you with a decision you can act on: what to build or buy, what the first release includes, how you will accept it, what remains uncertain and what the next commitment requires. A list of features alone is not enough.
Illustrative example: a nonprofit request portal. Use it to evaluate a proposed discovery scope or prepare your own brief. Agree the deliverables, fee and schedule with your supplier before the assessment begins.
1. A brief that names the problem and owner
Problem: requests arrive by email and spreadsheet. Staff cannot reliably tell which requests are awaiting information, assigned or complete.
People: applicants submit and track their own requests; coordinators review and assign them; a program owner decides which policy and workflow changes are acceptable.
First-release decision: can a small portal replace the shared request tracker without making staff maintain two competing records?
Evidence to collect: an approved sample of requests, the current status definitions, common exceptions and a walkthrough with the people doing the work. Use synthetic or redacted records until access and data-handling arrangements are agreed.
Success measure: record the existing time from receipt to assignment and the number of requests requiring manual status clarification. Agree the measurement method and observation period before setting a target. Use the baseline to evaluate the new workflow after release.
2. A first release with a clear boundary
| Include in the first release | Leave for a separate decision |
|---|---|
| Applicant sign-in, request submission and own-request status | Public anonymous submissions |
| Staff queue, assignment and agreed status transitions | Multiple program-specific approval chains |
| Email confirmation and a visible failure state for staff | SMS notifications and campaigns |
| Import of agreed active records, with reconciliation | Historical attachments and full archive migration |
| Role checks, essential activity history and staff handover | AI classification, a mobile app and advanced reporting |
Describe the complete journey: an applicant submits, a coordinator assigns, staff request missing information, and the applicant responds before closure. Record who may reopen a request and what happens when a coordinator leaves. Those exceptions belong in the scope decision.
3. A comparison of realistic options
| Option to investigate | Demonstration required | Uncertainty to resolve |
|---|---|---|
| Configure an existing service-management product | Complete the request journey with applicant and staff roles | Can applicants see only their own records, and can the organization export what it needs? |
| Integrate existing forms and staff tools | Follow a request across systems, including an update that fails | Which system owns status, and how are duplicates and failed updates reconciled? |
| Build a custom portal | Review the critical screens, access model and a small technical experiment | Are distinctive workflow needs worth the ongoing ownership and maintenance? |
The decision record should name the preferred option, the evidence behind it and what would change the recommendation. In this example, the next step is to demonstrate permissions and export in an existing product before deciding whether custom development is needed.
4. Acceptance checks with observable results
Use examples that someone other than the developer can run. Agree the expected result, test data, evidence and decision owner.
| Situation | Expected result | Evidence to retain |
|---|---|---|
| Applicant A opens Applicant B’s request URL | Access is denied without exposing the request’s contents | Result for the direct URL and any related attachment |
| An applicant submits the form twice | The agreed duplicate-handling rule is applied and explained | Resulting records and user feedback |
| Email delivery fails after submission | The request remains recorded; staff can see the failure and follow the agreed recovery process | Request record, notification state and recovery result |
| A staff member loses access | That account can no longer open protected records | Session and direct-link checks |
| Active records are imported | Source and destination counts reconcile, with exceptions documented | Reconciliation report and sampled records |
| A staff member uses a keyboard to process a request | The agreed journey can be completed with visible focus and usable errors | Journey notes and unresolved accessibility issues |
Expand these sample checks to reflect the sensitivity of the data, the needs of the audience and the project’s operating requirements. Agree any specialist security or accessibility review separately.
5. A delivery proposal with visible assumptions
The estimate should reference the agreed scope and split discovery, implementation, migration, third-party charges, support and specific uncertainty. State the currency, what is excluded, who authorizes changes and when an unresolved assumption will be checked.
For example, importing active records depends on a stable identifier and a usable export. If the sample lacks either, record the investigation or cleanup as a separate decision before committing to the import budget. Make the allowance and its assumptions visible in the estimate.
Use the software budget worksheet with actual supplier amounts. The budget guide explains how to compare proposals on the same scope.
6. Your team’s work at each stage
| Stage | Your team supplies or decides | Delivery team prepares |
|---|---|---|
| Before discovery | Decision owner, current workflow, approved sample records, constraints and budget boundary | Access request, proposed assessment scope and required participants |
| During discovery | Staff walkthroughs, policy answers and review of the proposed journey | Options, findings, scope boundary and unresolved questions |
| Before a build decision | Approval of priorities, acceptance checks and operating responsibilities | Written proposal, dependencies, estimate assumptions and release approach |
| Before launch | Named operators, account owners and acceptance decisions | Test evidence, migration results, release checklist and handover materials |
Agree the participants and review time in the proposal. Record how delayed access or unanswered policy questions will affect the schedule, and name the person responsible for resolving them.
7. Handover and the decision to proceed
Specify who controls the domain, hosting, repositories and vendor accounts. Include setup and release instructions, backup and restore responsibilities, monitoring, support escalation and a record of known limitations. Intellectual-property rights, licences and transfer terms belong in the agreement; possession of a repository does not settle those terms.
Download the software handover checklist (.txt). Fill in the owner, evidence and acceptance date for each item. Have a future operator use the instructions instead of relying only on a developer’s demonstration.
At the end of discovery, choose explicitly: proceed with the agreed release, reduce scope, investigate a remaining uncertainty, use an existing product or stop. A useful discovery engagement can recommend any of these outcomes.
Discuss a discovery assessment with RapidIteration. Bring the decision you need to make, the people affected and an example of the work that is difficult today.