Writing a Technology RFP That Gets You the Right System
A strong RFP is the single best predictor of a successful technology project. Here's what separates the RFPs that work from the ones that don't.
Replacing a records system, CAD, jail management system or ERP is one of the largest investments many agencies make, and the system you choose will likely be with you for a decade or more. Yet many projects that struggle can trace their problems back to the very beginning: a request for proposals that didn’t clearly describe what the organization actually needed.
Here’s what we’ve learned about writing RFPs that lead to the right system, on terms that protect you.
Start with needs, not a wish list
Before writing a single requirement, take time to understand how work really gets done today. Talk to the people who use the current system every day, not just managers. Map the key workflows, identify the workarounds people rely on, and note the reports and integrations other departments depend on.
That needs assessment becomes the foundation of everything that follows. It also helps you separate what’s essential from what’s merely nice to have.
Write requirements vendors can actually respond to
Good requirements are specific, testable and tied to how you work. Compare these two:
- “The system must be user-friendly.”
- “Patrol officers must be able to complete and submit a standard incident report from an in-vehicle laptop, including attachments, without returning to the station.”
The second tells vendors exactly what you need and gives your evaluation team something they can verify in a demonstration. A few other tips:
- Prioritize. Mark requirements as mandatory, important or desirable so vendors understand what matters most.
- Describe outcomes, not products. Avoid writing requirements around one vendor’s features, which limits competition.
- Don’t forget the unglamorous parts. Data conversion, interfaces, training, hosting, security, support and service levels often determine success more than features do.
- Include compliance up front. If the system will touch criminal justice information, CJIS Security Policy requirements belong in the RFP, not in a contract amendment.
Plan the evaluation before you release the RFP
Decide how proposals will be scored and who will score them before responses arrive. Weight criteria to reflect your priorities, and require scripted demonstrations based on your real scenarios rather than a vendor’s standard sales presentation. Reference checks with agencies of similar size and complexity are invaluable.
Negotiate the contract like you’ll live with it, because you will
The best time to secure fair terms is before you sign. Pay close attention to implementation milestones tied to payment, acceptance testing, data ownership and data return at the end of the contract, support response times, and how future price increases are handled.
Stay involved through implementation
An RFP is a promise. Implementation is where you find out if it’s kept. Someone on your side should track the vendor’s commitments, manage scope changes and make sure what was proposed is what gets delivered.
How GTEL can help
We guide agencies through the entire procurement lifecycle: needs assessment, requirements, RFP or RFI development, vendor identification, proposal evaluation, contract negotiation and implementation oversight. Talk to us before your next major purchase.
