Software discovery: what you should get from it

Bring the people who do the work

A manager may know the intended process while staff know the workarounds. Include both. If customers will use the system, collect their questions or observe a representative task with permission. Discovery based only on the owner's wish list can miss the friction that matters.

Prepare a recent example from beginning to end, using anonymised records. Show the emails, spreadsheets and approvals involved rather than relying on a memory of the ideal workflow.

Map the normal route and the exceptions

Start with the trigger: a new request, a completed job or an approaching renewal. Identify the owner of each step and the condition that allows it to move forward. Then examine rejections, cancellations, missing data and duplicate requests.

Mark each unknown explicitly. If the project depends on a third-party system accepting an update, test that capability early rather than assuming it exists.

Ask for tangible outputs

Avoid discovery that just produces more slides

A workshop is not automatically valuable because many people attended. Ask what uncertainty it removed. If a supplier knew nothing about your existing tools beforehand and still recommends the same package afterwards, request the evidence behind that recommendation.

A useful outcome might be that your current software already supports the required workflow. That can save more than discovery costs and is a legitimate reason to stop.

Decide the next step

Review the outputs with the operational owner. Are the proposed benefits measurable? Are critical dependencies tested? Is the first release small enough to evaluate? If not, commission only the missing investigation, not the entire build.

Agree whether the discovery documents can be used with another supplier. That gives you a practical deliverable and avoids treating discovery as a deposit whose value disappears if you choose not to proceed.