How to write a useful software project brief

Write two or three sentences about what fails today and who feels the effect. A sales team might copy information between two systems and be unsure which record is correct after an order changes. That gives a development team more to work with than a request for a new dashboard: it exposes the data, responsibilities and first useful test. Add how often the situation occurs and what it costs in time, errors or missed opportunities. Label an estimate as an estimate when no measurement exists.

Explain what should be different for a specific person after the project. Who enters information, who approves it and who handles an exception? Describe one ordinary path and one failure path. Separate the outcome you need from your idea for implementing it. This lets you compare an extension, an integration and a new product against the same objective. You need not select technology in advance; if an existing contract or environment dictates it, state that constraint.

List the systems involved and the owner of each important piece of data. For each transfer, note who may read, who may change and what happens when the other system does not answer. For payments, distinguish a received request from a confirmed result. For a CRM, identify who resolves conflicting records. For AI, decide whether it may only recommend or may take action. Include example inputs without real personal information and mark data that must never be sent to public tools.

Write constraints as facts that influence design: existing software, licences, contractual interfaces, user roles, languages, field work, availability and internal policies. Do not hide unknowns. Add an owner and a date for checking each one. In a regulated setting, identify who will assess legal and security obligations; a generic supplier proposal cannot establish duties for your particular product. Record dependencies on other teams and any deadline with a real business reason.

Choose one important user journey that can be completed end to end. State what success looks like, how a failure becomes visible and who accepts the result. A first release can omit some roles, reports and automation, but it cannot ignore identity, sensitive data, basic recovery or outage behavior when those are critical to the chosen journey. A small pilot or technical experiment may be the right first stage if one unknown could invalidate the larger plan.

Name three signals that would demonstrate improvement. Examples include fewer manual copies, shorter resolution time, fewer mismatched records or completion of a user task. For each signal, note the current baseline or a way to establish it. Avoid promising a percentage gain without evidence. Ask what the team could show after the first month and how that result would change the next decision. This turns a vague ambition into a testable proposal.

An initial message needs six items: problem and impact, main users, current process and systems, significant constraints, one expected first journey and a person who can make decisions. Mention existing material that can be shared safely. Do not send passwords, confidential customer records or production exports. Mark unknown questions plainly. A useful brief enables a focused conversation; it does not pretend that every design choice has already been made.

Ask the prospective team to propose a first verification stage, the input they need from you, how they estimate and how they hand work over. Discuss changes in scope, failure cases and operating responsibility. Price and schedule only become meaningful against an agreed scope and known dependencies; a generic guide cannot provide an honest fixed figure. End the meeting with named owners for missing facts, a concrete next deliverable and the criterion for continuing.