Turn a software idea into a useful project brief

An idea such as a customer portal names a solution, not the reason to fund it. A useful brief explains who struggles, what happens today, and which decision the next investment should support. It should leave room for a smaller intervention when software is not the best answer.

Describe the problem before the product

GOV.UK discovery guidance recommends challenging a predefined solution and reframing it as a problem before research begins.[1] Apply that principle to a commercial brief. Describe a recent operational event, the people involved, and the consequence of the current process.

Separate observed evidence from stakeholder interpretation. A sample of support requests can show repeated questions. It does not establish that every customer wants a portal. List what the sample covers and what remains unknown.

Define the first useful boundary

Name the start and end of the workflow under consideration. Explain which users, locations, data, and existing systems fall inside that boundary. State exclusions with equal care. A phrase such as integration included is not enough to compare proposals.

Describe desired behavior rather than screens. Identify who can submit, review, correct, and close a request. Include failure handling and ownership. Keep business constraints separate from preferences about technology so vendors can propose alternatives.

Hypothetical example: a repair intake service

A hypothetical equipment distributor wants an app for repair requests. The brief instead asks how branch staff can submit complete repair information without repeated calls. It includes intake and status visibility but excludes technician scheduling and spare-parts purchasing.

The buyer attaches anonymized examples of incomplete requests. A trial of a revised intake form becomes an option alongside custom software. No reduction in calls is claimed. The next decision depends on whether staff can provide the required information reliably.

Review the brief as a purchasing tool

Use this checklist before asking suppliers for a proposal. It turns vague expectations into questions that different teams can answer consistently.

• Identify one accountable business sponsor and one operational contact.
• Attach representative evidence with sensitive details removed.
• Define the workflow boundary and explicitly excluded activities.
• List required interfaces, access restrictions, and unresolved dependencies.
• Specify what evidence permits a proceed, revise, or stop decision.

Keep uncertainty visible in estimates

A concise brief cannot resolve every rule or technical dependency. More detail also costs time and can become outdated. Request an estimate range with named assumptions rather than forcing precision from incomplete information.

End with the next decision, its owner, and the questions that could change it. Treat the brief as a controlled starting point for discussion, not a guarantee that scope and cost cannot change.