How to Write a Project Brief That Gets Serious Quotes

The scene is always the same. You write to three suppliers: “We need a management system for our company, could you send us a quote?” Two weeks later you have three numbers that look nothing alike, and no way of telling which of the three understood what you actually need.

The temptation is to assume someone is inflating the price. Usually that's not it: each of them pictured a different project, because the request left room to picture one.

The good news is that this gets fixed on your side, in half a day of work, and it takes no technical knowledge at all.

Whoever receives a generic request has two options. They can imagine the smallest project those words could mean — and quote a low price that will collapse in the first meeting. Or they can imagine everything a company like yours might need, and quote a high price that gets their proposal discarded unread.

Neither is dishonest. They are two different ways of handling the uncertainty you handed over. The more precise the request, the less uncertainty there is to cover, and the more the numbers you receive become comparable with one another.

The problem, not the solution. Not “we need a CRM”, but “we lose enquiries because they arrive through three different channels and nobody knows who answers”. A problem described well leaves the supplier room to propose the simplest solution, which sometimes costs a tenth of what you had in mind.

Who will use it, and to do what. Three people in an office and forty field agents are not the same project, even if the screens look similar. Write down the roles and what each one does on a typical day.

The numbers you already have. Orders per month, customers on file, documents per year. They tell a supplier whether we are talking about a thousand rows or two million: it changes everything, and it changes the price.

What already exists and has to stay. The accounting system, the invoicing software, the e-commerce site, the spreadsheets you have used for years. Every system that must keep working is a constraint, and constraints discovered halfway through are the ones that blow up the schedule.

The budget, at least as an order of magnitude. This is the part that scares people most, and it is the one that saves everyone the most time. You don't need a precise figure: you need to say whether the project is worth five thousand or fifty thousand. With an order of magnitude in hand, a serious supplier will tell you what fits inside it and what doesn't — which is exactly the information you were after.

When you need it, and why then. “By March” says nothing. “By March because the season starts and from April we can't take anyone off the floor” says everything, and lets someone propose a phased plan instead of one monolithic block.

You don't need to write a thirty-page document: two well-written pages are worth more. You don't need to specify technologies — writing “we want it built in WordPress” narrows the solutions before anyone has checked whether that is the right call, and that judgement is the job of the person answering you.

Above all, you don't need a specification stuffed with features copied from other software. A list of a hundred items doesn't make the request more precise: it makes it more expensive, because every item has to be priced, including the ones you never actually needed.

Given a request like that, a serious supplier won't just send you a number. They will send questions back — an excellent sign, because it means they read it. Then they will send a proposal describing what they will do, what they won't, how long it takes and on what assumptions.

When three proposals arrive written that way, comparing them becomes ordinary work. I covered which differences between two quotes are legitimate, and which are warning signs, in Why Two Quotes for the Same App Can Be Worlds Apart.