A Custom Software Project Discovery Checklist

A useful software brief explains what people need to accomplish, where the current process breaks down and how the business will recognize a better result. It gives an engineering team enough context to challenge the proposed solution and estimate a meaningful release.

This custom software project discovery checklist is for operations leaders planning internal applications, customer portals or integrations across a manufacturing, distribution or B2B service business. Use it as a worksheet before comparing proposals. Existing evidence counts: you do not need to buy a separate discovery engagement if the important inputs are already clear.

Start with a workflow, an owner and a decision

Describe the job in plain language. “Turn an approved quote into a reviewed order” is easier to evaluate than “digitally transform order management.” Name the person accountable for that outcome and the people who do the work today.

Ask those users to show a normal case and a difficult one. Include the spreadsheet, phone call or inbox that sits between formal systems. A manager’s process diagram and a coordinator’s actual working day can reveal different requirements.

The UK Government’s discovery guidance similarly emphasizes understanding users, constraints and the wider process before deciding what to build. We recommend applying that principle without importing a government delivery process wholesale. GOV.UK discovery guidance.

Fill in this project discovery worksheet

Keep the first version short. Link to evidence where it exists, and mark unknowns with a named person who can answer them.

The worksheet should expose disagreements. If sales and finance define an approved customer differently, record both definitions and resolve the rule with the owner. Otherwise, an engineering estimate may silently assume the wrong behavior.

Bring examples that can become acceptance tests

Use synthetic or appropriately redacted examples for early conversations. Show the fields, decisions and expected output without sharing passwords, private customer records or production credentials.

For a hypothetical distributor’s quote-to-order release, the examples might be:

• Standard order: an approved quote creates one draft order with matching quantities and agreed prices, ready for staff review.
• Changed price: a difference between the quote and current pricing holds the order for a named approver rather than silently substituting a value.
• Repeated submission: submitting the same approved quote again does not create another order.
• Unavailable system: the transfer remains visible as pending or failed, with a defined retry or manual recovery path.

These are proposed acceptance examples, not a complete specification. Add the cases that matter to your business, including who can view or change a record. Specify the agreed processing delay and what the user should see while waiting.

Identify dependencies before they become schedule surprises

For each connected system, record the account owner, available interface, required subscription and test access. Ask the vendor to confirm uncertain capabilities. A connector shown in a marketplace may still need configuration or may cover only part of your workflow.

Assign an authoritative system for each important record or field. Decide how identifiers match, who resolves conflicting updates and whether historical data belongs in the first release. Include migration reconciliation and a fallback if the new process cannot be used at launch.

Make security work explicit: access roles, sensitive fields, credential handling, dependency updates and the route for reporting a suspected issue. NIST’s Secure Software Development Framework provides shared terminology that software purchasers and suppliers can use for these conversations. Use it to ask how responsibilities will be handled in your project. NIST SSDF 1.1.

Define a release your team can accept and operate

List deliverables separately from outcomes. A deployed interface, connector, source repository, test evidence and operating guide are deliverables. Reduced waiting time is an outcome to measure against an established baseline; shipping the interface does not prove it happened.

Agree on the review period, reviewer and acceptance examples before development. Define how a defect differs from a new requirement, who can authorize changes and how changes affect cost or dates. If vendor feasibility remains unknown, price that investigation separately from the dependent implementation.

For ongoing operation, specify who owns hosting and vendor accounts, who receives alerts, and who performs updates. Record source-delivery terms, third-party licenses, backup and restore responsibilities, and the handoff needed if another team takes over. Set support capacity and response expectations that the named delivery team can actually provide.

Turn the brief into a project decision

A complete brief can support a direct implementation proposal. A partial brief should identify the particular questions that need investigation, rather than trigger an open-ended discovery phase. Sometimes the evidence will favor configuring an existing product or improving an integration; our build, buy or integrate guide helps compare those routes.

Modern Labyrinth’s engineering work includes applications, connected systems and the release and handoff planning around them. Bring the workflow, the systems involved and the decision you need to make. That is enough to start a useful conversation.