Why briefs fail
A brief that lists features without context produces proposals that cannot be compared, because each supplier has silently made different assumptions about everything the brief left out.
The purpose of a brief is not to specify the system. It is to give suppliers enough context to propose something sensible and to ask good questions.
Lead with the problem
Start with what is not working now, for whom, and what it costs. This is the part suppliers most need and most often do not get.
A brief that opens with the problem lets a good supplier tell you that part of your requested solution is unnecessary — which is exactly the advice you are paying for and cannot receive if you only describe features.
State the constraints honestly
Deadlines that are real and why. Systems that cannot be replaced. Regulatory requirements. Internal capacity. A team that is already committed elsewhere.
Constraints are not weaknesses to hide during procurement. They are the information that separates a deliverable plan from an attractive one.
- Hard dates, and what makes them hard
- Systems that must be integrated with or preserved
- Compliance or data-residency obligations
- Internal people available, and how much of their time
- Anything that has already been tried and did not work
Give a budget range
Withholding budget in the hope of a lower quote is the most common false economy in software procurement. Without a range, suppliers guess, and you receive proposals that are not comparable and frequently not viable.
A range lets a supplier tell you honestly whether the scope fits, and to propose a sensible first phase if it does not. If a supplier's proposal simply expands to fill whatever number you state, that itself is useful information.
Define success in numbers
"Better user experience" cannot be delivered or verified. "Reduce application abandonment from forty percent to under twenty-five" can be, and it also tells a supplier where to focus.
If a target cannot be stated numerically, state the decision it should enable instead. Both are better than an adjective.
List the integrations
The systems a project must connect to affect the estimate more than the feature list does, and they are the most common omission from a brief.
For each one, say what it is, whether it has an API, who owns it internally, and whether you have working access today. "We think there is an API" is an honest and useful answer.
Say what you have decided and what is open
Marking which decisions are already made — and which are genuinely open — prevents suppliers from wasting proposal effort re-litigating settled questions, and stops them assuming that everything is fixed.
Where a decision is already made and you are not certain about it, say so. A supplier that disagrees with a reasoned position is far more useful than one that quietly builds what it was told.
Explain how you will decide
Tell suppliers what you are evaluating on, who is involved, and by when. Serious suppliers put real effort into proposals and will invest more where the process is clear.
It also improves what you receive: a supplier who knows you are weighting long-term maintainability will address it, rather than optimising the headline price.