Organisations often write a deliberately loose requirements document, reasoning that it invites suppliers to propose creative approaches. What it actually does is select for suppliers comfortable quoting on incomplete information — which is not the same population as suppliers who will deliver well. The careful ones either decline or price in the uncertainty, so you end up choosing between an optimistic number from someone guessing and a defensive number from someone hedging, with no basis to compare them.
The most useful thing a brief can contain is the problem rather than the solution. A specification listing screens and features invites suppliers to price the list, and the list is usually wrong in ways nobody has discovered yet. A document explaining what the business is trying to achieve, who the users are, what they do today, what goes wrong and what success would look like, lets a competent supplier propose something better than you asked for. It also reveals which suppliers understood the problem, which is the thing you are really trying to find out.
Constraints belong in the brief, stated plainly. The budget range, or at least its order of magnitude. The deadline and what drives it. Systems that must be integrated with. Regulatory obligations. Technology the organisation will not adopt and why. Withholding the budget in the belief that it produces keener pricing mostly produces proposals aimed at the wrong scale, and three rounds of rescoping. Naming a range gets you three proposals you can actually compare.
Say what exists today, honestly. The current system and its state. What data will need migrating and what condition it is in. Who inside your organisation will be available, for how much of their time, and who can make a decision. Projects far more often stall on client-side availability and decision-making than on supplier capability, and a supplier who knows the constraint can plan for it while one who discovers it in month two cannot.
Ask questions that differentiate. What would you build first and why. What is the biggest risk in this project and how would you reduce it. Tell us about a project of yours that went badly and what you changed afterwards. Who specifically would work on this and what else are they committed to. Those answers separate firms meaningfully. A request to list your technologies and your years in business does not, because every respondent looks the same on it.
Then give suppliers enough time and access to answer properly — a call with someone who knows the domain, and two weeks rather than four days. The quality of proposals you receive is largely a function of the quality of the brief and the access you allowed. A rushed, vague process produces poor proposals, and the organisation then concludes that suppliers are unreliable, when what it actually observed was its own brief reflected back at it.
