A software project brief describes the problem, the people affected and what success looks like. It is not a feature list. One page that a stranger can follow beats twenty pages nobody finishes.
Every software quote is a reaction to what the supplier thinks you asked for. A vague brief gets a vague quote, and two suppliers can read the same sentence and price two different projects. That is why quotes for the same job often look so far apart.
Seven headings that cover almost everything
1. The problem. Describe what is slow, risky, expensive or impossible today. Write about the situation, not the solution. "Our team re-types orders from emails into three systems, and mistakes reach customers" is a problem. "We need an order portal" is a solution that may or may not fit.
2. Who it is for. List the groups who will use it or be affected: staff, customers, suppliers, managers. Say roughly how many there are and what each needs to do. External users usually mean more design, security and support work than internal ones.
3. What success looks like. Say how you will know it worked, using something you can observe: fewer manual steps, faster turnaround, fewer errors. Avoid targets you cannot measure or have not measured before.
4. What it must do first. List the few things the first release must do for the project to be worth it. Everything else goes on a "later" list. This is the most useful step for controlling cost.
5. What it connects to. Name the systems it has to work with (accounting, a shop, a CRM, a spreadsheet, a payment provider) and what you know about each. Integrations are often where estimates go wrong, because they depend on systems you do not control.
6. Constraints. Budget range or at least a ceiling, a date that cannot move and why, legal duties such as handling personal data under UK GDPR, technology you must or must not use, and who approves decisions. If you do not know the budget, say so.
7. What is out of scope. State what you are not asking for, for example "no mobile app in the first release" or "no data migration from the old system". It feels unnecessary until a disagreement starts.
What to leave out
- Detailed screen designs, unless you already have them.
- A specific technology, unless there is a real reason. Ask for a recommendation instead.
- Every possible feature. A long list hides the important items.
- Confidential material you would not share with an unsuccessful bidder.
Is the brief ready?
Give it to someone who has not been involved and ask them to explain it back. If they cannot say what problem is being solved and for whom, rewrite it. Then check: does it say what you want to be true afterwards and not only what you want built? Would two suppliers price roughly the same project from it? Does it say what is fixed and what is open? Does it say who decides on your side?
If you cannot finish the headings yet, that is normal. You may know the problem but not the solution, and a short discovery stage exists for exactly that.
The full guide, with FAQs, is on the Cognivise blog. If you are planning a build, see custom software development.
Top comments (0)