Start with the problem, not the feature list
The most common mistake is copying a vendor’s feature sheet and turning it into requirements. That is exactly the bias: only that vendor meets all of them, and in exactly that way.
Write requirements in terms of capability and outcome:
The system shall include an asset management module with a five-level hierarchy tree.
The system shall let users organize assets by site, building, floor and unit, and view the work history at any of those levels.
The structure that works
- Context. How many assets, how many technicians, how many jobs a year and which systems are already in place. Without this, bids cannot be compared.
- Functional requirements, in three groups: mandatory (not meeting one disqualifies), scored (they earn points) and desirable (they break ties).
- Technical and security requirements: hosting, data protection, integrations, API and data export.
- Services: implementation, migration, training and support, with the required service levels.
- Scoring criteria, with their weights, published.
Be honest about the mandatory ones. Every one you add reduces competition, and some reduce it to a single vendor.
Scoring criteria
This is where everything gets decided. A reasonable split for management software:
| Criterion | Weight |
|---|---|
| Functional fit | 35% |
| Total cost over four years: license, implementation and support | 30% |
| Implementation and migration plan | 15% |
| Support and service levels | 10% |
| Experience with similar projects | 10% |
The key is total cost over four years, not the license price. It stops the vendor who discounts the license and charges three times as much for implementation from winning.
The clauses you must include
- Data ownership and portability. Full export, in a standard format, at no cost and within a committed time. It is the clause that protects you most and the one most often forgotten.
- Exit terms. What happens at the end: export deadline, support during the transition and certified deletion.
- Data protection. A data processing agreement, the list of subprocessors, where the data is stored and breach notification.
- Service levels with a measurement method, not just a percentage.
- Pricing for add-ons during the contract term. If it is not set, add-ons will cost whatever the vendor says once you can no longer switch.
How to avoid bias
- Talk to the market before the tender if you are a public agency, for example with a request for information. It is usually allowed and avoids impossible requirements. In Spain, public procurement law provides a formal preliminary market consultation for this.
- Do not name brands or specific technologies, unless interoperability justifies it.
- Ask for a demo with your own data, not a slide presentation. It is a very effective filter.
- Talk to companies that use each product, chosen by you, not from a list the vendor gives you.
- Review your mandatory requirements. If only one vendor meets them, either the requirement is truly critical or you copied their brochure.
The three questions that filter the most
- “Show it to me on screen, right now,” whenever you hear “that can be configured.”
- “Is a company using this today, or is it planned?”
- “Can I talk to a company of a similar size to mine?”
A good RFP is one where, reading it, you cannot guess who will win. If you can guess when you finish yours, review it: either there is bias, or a requirement is not as essential as you thought.
Last updated: