How to write a government software RFP that gets good responses

A request for proposals is the one document in a procurement that every credible vendor reads closely and every mediocre one games. Written well, it filters the field to the vendors who actually fit and gives your evaluation committee the evidence to defend its choice. Written badly — as most are — it produces a stack of interchangeable, boilerplate responses, a low-bid award to whoever priced the ambiguity most aggressively, and a project that unravels the moment the real requirements surface. This is a cross-cutting playbook: it applies whether you are buying permitting, ERP, a CIS, or asset management, because the failure patterns are the same across every category.

The core mistake is writing the RFP to be procurement-defensible rather than answerable. A document that exists to survive a protest, not to describe what you need, gets you vendors who are good at responding to documents that exist to survive protests. That is not the skill you are buying.

Specify problems and outcomes, not a vendor's feature list

The single most damaging thing a buyer can do is copy requirements out of a vendor's marketing sheet or let a friendly vendor 'help' draft the spec. A vendor-authored specification is a sole-source award wearing the costume of a competition: it describes one product so precisely that only that product can clear it, and every other bidder either no-bids or pads the price to cover the risk of a spec they can tell was written for someone else. If a requirement reads like a datasheet — a named feature, an oddly specific number, a capability only one vendor markets — strike it and rewrite it as the outcome you actually need.

State requirements as problems to solve and outcomes to achieve, and let vendors propose how. 'The system must let non-technical staff configure a new permit-type workflow without a vendor change order' is a requirement. 'The system must have a drag-and-drop workflow designer with conditional branching' is a feature you copied from a brochure — and it quietly disqualifies a vendor who solves the same problem a different way.

Separate must-haves from wish-lists, ruthlessly

The 200-line requirements matrix where every row is 'mandatory' is the most common self-inflicted wound in government procurement. When everything is required, nothing is prioritized, and the evaluation collapses into a checkbox-counting exercise that a thin product with a good proposal-writing team wins over a strong product that answered honestly. It also inflates price across the board, because vendors quote to the maximal reading of an over-specified document.

Sort every requirement into two buckets before the RFP goes out: true gates (a vendor who cannot meet this is disqualified, full stop) and scored criteria (better is better, but its absence is not fatal). Keep the gate list short enough that a healthy number of credible vendors can clear it — if only one vendor passes your gates, your gates are a spec someone wrote for that vendor, not a description of your need. Everything else belongs in the scored tier, where the weighting does the discriminating.

Publish the evaluation weighting inside the RFP

Tell vendors how you will score them, in the RFP itself. A weighted rubric — fit-to-workflow, implementation and references, total cost over a multi-year horizon, integration and data portability, vendor viability — signals a serious buyer and pulls better responses, because good vendors invest effort where they can see it will be read. Weighting also protects the committee from itself: it prevents the post-demo drift where a charismatic presentation retroactively becomes the most important criterion.

Be deliberate about the cost weight. Scoring price too heavily invites the stripped-scope low bid that defers implementation, training, and data migration into change orders you will pay for later; the companion piece on total cost of ownership is where that trap is dissected. Score cost against a like-for-like scope you define, over a multi-year window that includes the renewal escalator, not against first-year license alone.

Make the demo a scripted scenario, not a sales pitch

A vendor's canned demo is a highlight reel of their strongest features against their happiest data. It tells you almost nothing about fit. Replace it with scripted scenarios you write and every finalist runs against the same script, scored by the same people on the same rubric: intake a real transaction, route it through the reviews your organization actually performs, hit a failure and recover from it, pull the report a supervisor genuinely needs. You learn more from watching a vendor configure one real workflow live — and from what they stumble over — than from an hour of slides.

Reserve part of the demo for the unscripted. Ask the vendor to make a change you did not warn them about, using their own configuration tools, in front of you. Whether that takes five minutes or 'we'll have to get back to you' is one of the most honest signals in the entire process about who owns configuration after go-live.

Require references you can actually use — and check them yourself

Ask for references at your size band and complexity, doing the work you do, live on the current version of the product — not a flagship account three times your size running a heavily customized deployment. Vague reference requirements get you a vendor's three happiest customers; specific ones get you peers whose experience actually predicts yours. Better still, find your own references from public award records rather than relying only on the vendor's curated list; the reference-check playbook covers how to run those calls so they surface the truth instead of a testimonial.

Finally, write the RFP so the contract terms that matter are decided during competition, not after award when your leverage is gone. Ask for the renewal escalator, the data-export and exit terms, the implementation scope and acceptance criteria, and the support model as part of the response. A vendor's willingness to commit to those in writing, while they are still competing, tells you how the relationship will feel once you have signed and the competition is over.