When bids come back and none of them can be compared to the others, the solicitation caused it. Either it described the desired solution instead of the problem, or it left out the information vendors needed to price accurately — so each one guessed differently.
Describe outcomes, not implementations
The most common failure is a requirements list transcribed from one vendor's feature page. It produces two bad outcomes: it narrows the field to that vendor, and it invites a protest from the others.
Instead of: "System shall provide a configurable dashboard with drag-and-drop widgets."
Write: "Supervisors must be able to see current case status across their team without running a report, and adjust what is displayed without vendor assistance."
The second describes what you need. It permits several legitimate solutions and lets vendors compete on how well they meet it.
The eight sections that make bids comparable
- Background and current state. What exists now, how many users, what volume. Vendors price risk; unknowns get priced high.
- Scope, with explicit exclusions. What is not included matters as much as what is. Say who handles data cleansing, training, and change management.
- Functional requirements as outcomes, each one testable. If you cannot describe how you would verify it at acceptance, rewrite it.
- Technical constraints. Systems it must integrate with, and whether those have APIs. Hosting requirements, data residency, identity provider. This section prevents more overruns than any other.
- Security and accessibility. The framework that applies, the authorization path expected, and a requirement for an accessibility conformance report. Ask for these with the bid, not after selection.
- Data. Volume, formats, quality, and who is responsible for cleansing. If you have not profiled it, say so — vendors will price the uncertainty either way, and honesty gets you closer to a real number.
- Deliverables and acceptance criteria. What gets handed over, and what test decides each item is done.
- Support and transition. Warranty period, ongoing support expectations, and what happens at contract end — including data export and documentation.
What to leave open on purpose
Do not specify the technology stack unless you have a genuine constraint, such as staff who must maintain it. Prescribing a language or framework narrows competition without improving the outcome, and it transfers a technical decision from the people best placed to make it.
Likewise, avoid specifying the exact interface. Say what the user must accomplish and let vendors show you how.
The two sections buyers most often omit
Data quality. Every vendor will assume something different about the state of your records, and the assumptions will differ by a factor of three in effort. A short honest paragraph — record counts, known gaps, how many systems it lives in — makes bids comparable in a way nothing else does.
Decision-making. Name who has authority to answer questions during the project and how quickly. Slow decisions are the most common cause of overrun, and vendors who have been burned will price for it silently unless you address it.
How to evaluate what comes back
Publish the evaluation criteria and weightings in the solicitation. Then apply them as written.
Beyond price, weight: relevant experience with your kind of entity; the named individuals who will do the work; whether their questions during the Q&A period showed genuine understanding; and what they identified as risky. A vendor who flags a real problem in your requirements is demonstrating competence, not being difficult.
Before you publish
Have someone technical who is not writing it read it and try to price it. Every question they cannot answer is a question a vendor will either ask in the Q&A period — costing you a week — or silently guess at, costing you comparability.
For the wider process this sits inside, see how agencies actually buy software. If the purchase involves AI, the additional clauses worth adding are in procuring AI through a contract vehicle, and vehicle selection is covered under contract vehicles.
Drafting one now? We are happy to review a draft before it goes out.