An RFP produces comparable proposals when it describes the process the software must support, names the systems it must integrate with, states the compliance controls, and says who will own the result. An RFP that lists features instead produces proposals priced against different assumptions, which cannot be compared on anything except the number at the bottom.
We respond to a lot of these. The good ones are rare and obvious.
Describe the process, not the features
"User can upload a document" tells a supplier nothing about effort. Describe what actually happens: who uploads it, what it arrives as, what has to be extracted, what happens when it is malformed, who fixes it, and what the downstream system expects.
The exceptions are where the work is. An RFP that describes only the happy path will get quotes for only the happy path, and the difference becomes change requests once you have signed.
Name every system it must touch
For each one, say whether it has an API, whether you have credentials, and who owns it internally. Integrations are usually the largest single driver of effort, and a system without an API costs several times more to connect and stays more fragile afterwards.
This one section changes estimates more than any other.
State the compliance position
Audit logging, data residency, retention, access review, encryption, and who certifies you. These are engineering work, and a supplier who does not know about them will either omit them from the price or discover them late.
Say who owns and runs it afterwards
Three quite different projects hide behind the same feature list:
- We build it, you run it — needs documentation and handover built in
- We build it and run it — needs monitoring, on-call and a support agreement
- We work alongside your team — needs your conventions and your review process
Suppliers price these differently and correctly. Not saying which you want is the single most common reason proposals are incomparable.
Ask for the exclusions
Require every response to state what it deliberately does not include. This is the most useful question in an RFP and almost nobody asks it. The answers reveal what each supplier assumed, and the differences between those assumptions are usually where your risk is.
What to ask beyond scope
- Who is technically accountable, by name
- Where the code lives during the engagement
- Test coverage, deployment process, monitoring, restore testing
- What happens if a key person leaves
- One project that went badly and what changed afterwards
What to leave out
A pre-decided architecture, unless you have a real constraint. Specifying microservices or a particular database in the RFP removes the supplier's ability to tell you something you did not know, which is much of what you are buying.
A fixed deadline with fixed scope and no priority order. If both are fixed and the estimate does not fit, something gives — usually testing. Say which parts matter most instead.
Weighted scoring on rate. It rewards the supplier who assumed least, which is the opposite of what you want.
The shortest useful version
If a full RFP is too much, a one-page brief with the process described, the integrations listed, the compliance position stated and the ownership question answered will get you better proposals than most twenty-page documents. Length is not the variable that matters.
- procurement
- rfp
- scoping
- vendor-selection