Part 1 of The Solicitation Author's Handbook. The work that happens before drafting decides whether your RFP attracts strong responses or three copy-paste bids.
This is Part 1 of The Solicitation Author’s Handbook, an eight-part series for people in offices of government who write solicitations. Most procurement content is written for vendors who want to win your contract. This series is written for you, the person who has to author the document, defend the process, and live with the result. It is vendor-neutral by design: nothing in it favors any bidder, including GovSoft. It is educational material, not legal advice; procurement law varies by jurisdiction, so treat your procurement code and counsel as the final word.
Before drafting begins, the agency should agree on the operational problem, the measurable outcome it expects, and the constraints that cannot change. This short needs assessment keeps the document from becoming a negotiation among stakeholders and gives vendors a clear result to propose against.
The discipline that prevents this costs two meetings and a memo. Before anyone drafts, write down three things in plain language: the problem as experienced by the people who have it, the outcome that would count as success twelve months after go-live, and the constraints that are genuinely non-negotiable. If your team cannot agree on those three paragraphs, you are not ready to write requirements, and no requirement you write will fix that.
Describe the current operational failure and desired outcome without naming a product architecture or feature set. This gives vendors room to propose different responsive approaches and helps the agency compare solutions against the problem instead of a prematurely selected design.
For example, “We need a cloud-based permitting platform with a configurable workflow engine” is not a problem. It is a solution someone has already chosen, and it forecloses every answer that does not look like it. The problem underneath might be “permit applications take 40 days to process, applicants cannot see status, and staff re-enter the same data three times.” Stated that way, the field of possible answers opens up, and so does your leverage as a buyer.
A useful test: could a vendor read your problem statement and disagree with your presumed approach while still proposing something responsive? If not, you have specified a solution, and you will receive quotes for it rather than proposals against your problem.
Consult the program staff who experience the problem, the IT team that must operate and secure the solution, finance, legal or procurement counsel, and the leaders accountable for the outcome. Each group holds requirements the others may not know, so early consultation prevents late surprises.
Write down who was consulted and when. That record does double duty: it improves the document, and it becomes part of the administrative file that shows the process was sound.
Use a documented process that offers the same information and access to every participant. Agencies can combine requests for information, sources sought notices, scripted demonstrations, published research, and peer-agency interviews to understand available approaches without allowing one vendor to shape the requirements.
The standard instruments, from lightest to heaviest:
Whatever you use, the rules are the same: offer the same information and access to every participant, document what you learned, and never let one vendor draft your requirements. If a vendor hands you a “sample RFP,” understand it for what it is, a document engineered so that only its author scores well.
Experienced vendors look for an operational problem, measurable outcomes, credible funding, and a realistic timeline. These signals show that an agency understands the purchase and can evaluate proposals consistently. When they are missing, qualified vendors may decide that responding is not worth the cost or uncertainty.
That is the quiet economics of this series: the effort you invest before writing is repaid in the quality of what arrives after you publish.
An RFP pre-drafting checklist should confirm the problem, measurable outcome, stakeholder consultation, market capacity, funding authority, and evaluation team. Before opening the template, the agency should be able to answer yes to each of these:
In Part 2, we take up the first structural decision on the document itself: choosing the right solicitation vehicle, and why the difference between an RFI, an RFQ, and an RFP is really a statement about how much you know.
The Solicitation Author’s Handbook is published by GovSoft as a public resource for offices of government. It is educational information, not legal advice.
