Writing RFP specifications vendors cannot game

Many software tenders end the same way. Every bid says “Complied” against every line, the lowest bid wins, and a year later the department has a system that meets the document but not the need. Usually nobody cheated. The specification simply allowed more than one reading, and the cheapest reading won.

How specifications get gamed

• Vague words. “User-friendly”, “robust”, “should support reports” can be claimed by any product.
• Checklist compliance. A long feature list invites a column of “Complied” with no way to verify it before award.
• Generic demonstrations. Vendors show their best screens, not your process.
• Undefined scope, priced low. If the scope is loose, the lowest bid is often the narrowest reading, recovered later through change requests.

Principle 1: Specify the work, not just features

Describe what the system must do in your terms: the processes (who does what, in what order), the business rules (eligibility, calculations, approvals), the main records and their fields, the number of users by role, the expected volumes, and the languages. A vendor can game a feature list. It is much harder to game a process map with rules and volumes attached.

Principle 2: Make every requirement testable

For each requirement, write how you will check it. “The system shall be user-friendly” becomes something like: “After a one-hour orientation, a first-time clerk enters a complete application without help, in the time agreed in the acceptance criteria.” The exact numbers are yours to set; what matters is that a requirement either passes or fails, and both sides know how it will be tested.

Principle 3: Ask for evidence, not promises

During technical evaluation, give shortlisted bidders a scripted scenario and a small set of your own sample data, and ask them to run it live. Score what you see: did the rules give the right results, did the screens follow the process, did the reports match? A scenario demonstration tells you more than a hundred pages of compliance statements.

Principle 4: Keep ownership of the design, the data and the exit

• The department owns its data, with export in open, documented formats at any time.
• The data model, business rules and interfaces are documented and handed over, not held as the vendor’s secret.
• Source code ownership, or an escrow arrangement, is settled in the contract.
• A transition clause says how the system moves to a new vendor or to the department at the end of the contract.

Principle 5: Weight evaluation for fit, and keep it fair

Give real weight to the scenario demonstration and to the quality of the proposed design, not only to certificates and turnover. At the same time, avoid criteria that only one vendor can meet; a specification should describe your need, not a product. Always work within the procurement rules that apply to your organisation.

Principle 6: Describe the data you already have

Most new systems start with old records: registers, spreadsheets, an earlier database. If the RFP does not describe them, migration becomes a surprise cost or a rushed job. List the existing sources, roughly how many records each holds, their condition, and who will clean them. Then state who is responsible for migration, how it will be checked, and what counts as complete.

Principle 7: Plan for change before it happens

Policies will change during the contract. Agree in the RFP how changes are requested, estimated and priced, for example through a rate card, and keep a signed baseline of the scope, so change requests are measured against something fixed.

Before you publish the RFP

1. Is every process, rule and volume described in our terms?
2. Does every requirement say how it will be tested?
3. Is there a scripted scenario and sample data for the demonstration?
4. Are data ownership, documentation, code and exit covered in the contract terms?
5. Could more than one capable vendor meet every criterion?
6. Are existing records, their condition and migration responsibility described?
7. Is there a priced way to handle change?

Neodeus prepares technical specifications, evaluation criteria and demonstration scenarios for technology tenders, and can act as design authority once a vendor is selected, so the system that is built matches the one that was specified.