A technology RFP can include dozens of requirements, detailed SLAs and a formal evaluation process — and still end with proposals that are not genuinely comparable. The problem rarely starts at the decision stage. It usually began much earlier.
There is a recurring moment in many technology sourcing processes.
The proposals arrive.
They all appear to respond to the RFP.
They all meet a large share of the requirements.
They all present an apparently credible solution.
And yet comparison becomes difficult.
One proposal includes services that another presents as optional. One vendor assumes a particular usage volume; another uses different assumptions. Licensing models are not directly comparable. SLAs use different definitions. Implementation, migration, support or evolution costs are distributed in different ways.
In the end, the organisation has several technically valid proposals — but not a sufficiently robust basis for making the decision.
This is not simply an evaluation problem.
It is often a problem in the design of the RFP itself.
A complete RFP is not necessarily a comparable RFP
It is easy to associate quality with detail.
More requirements.
More pages.
More questions.
More appendices.
But a lengthy RFP can still leave open precisely the issues that will need to be compared later.
For example:
- Which requirements are genuinely critical and which are simply desirable?
- How should a partial response be treated?
- Which economic assumptions should be common to every vendor?
- Which costs must be presented separately?
- How will risk, technology dependency and ability to evolve be assessed?
- How much weight will each decision dimension carry?
If these rules are not clear before going to market, each vendor will tend to respond according to its own commercial and technical logic.
The greater the freedom of interpretation, the lower the comparability.
The decision starts before the shortlist
One of the most common mistakes in a selection process is to treat the evaluation model as a later stage.
First, the RFP is defined.
Then proposals are received.
Only then does the organisation decide how to compare them.
The sequence should be almost the reverse.
Before issuing the RFP, the organisation should be able to answer:
That question forces the decision model to be structured in advance.
It does not mean choosing the vendor before the process begins.
It means defining transparently what will distinguish a suitable proposal from a less suitable one.
Without that structure, the assessment tends to become a combination of interpretations, late negotiations and weightings adjusted after the proposals are already known.
That is precisely where independence starts to weaken.
Five dimensions that determine whether proposals will be genuinely comparable
1. Requirements: not everything should carry the same weight
A long list of requirements is not, by itself, a sound decision model.
If every requirement is treated as equally important, the process may favour the solution with the largest feature set — not necessarily the one that best addresses the business problem.
The organisation should distinguish between:
- mandatory requirements;
- requirements that are critical for differentiation;
- desirable requirements;
- future capabilities;
- items that are out of scope.
The question is not simply whether a solution “has” a particular capability.
It is how much that capability matters to the decision.
2. Evaluation criteria: impartiality starts before scoring
The evaluation model should be defined before proposals are received.
Functionality, architecture, implementation, security, operations, experience, cost, risk and ability to evolve may carry different weights depending on the context.
The weighting should reflect the organisation’s strategy — not the structure of a particular vendor’s proposal.
When the criteria are only refined after the responses are known, the risk increases that the evaluation adapts to the solutions instead of assessing the solutions against the need.
3. SLAs: the same metric can mean different things
“99.9% availability” looks comparable.
It is not always.
The organisation needs to understand:
- the measurement period;
- which exclusions are allowed;
- how scheduled maintenance is treated;
- the definition of unavailability;
- how service credits or penalties are calculated;
- which services are actually covered.
Without common definitions, two vendors can present the same number while making materially different commitments.
The same principle applies to response times, resolution times, continuity, support and capacity.
4. TCO: price is not total cost
Comparing only the amount shown on the first page of a commercial proposal can lead to the wrong decision.
The real cost may include:
- licensing;
- implementation;
- migration;
- integration;
- infrastructure;
- professional services;
- training;
- support;
- evolution;
- volume growth;
- future exit or transition.
Vendors may also use different time horizons and growth assumptions.
To compare proposals on an economically sustainable basis, those assumptions need to be normalised.
The relevant question is not only: How much does this solution cost?
It is: How much will this decision cost across the lifecycle that matters to the organisation?
5. Risk and dependencies: what is not in the price still matters
Two proposals may look similar from a functional and financial perspective while creating very different levels of risk.
One may depend heavily on proprietary components.
Another may require capabilities the organisation does not have.
One may create a high degree of vendor dependency.
Another may introduce significant integration complexity.
The assessment should therefore include factors such as:
- technology dependencies;
- required internal capabilities;
- implementation risk;
- contractual flexibility;
- ability to evolve;
- ease of transition;
- vendor concentration.
Without this dimension, the process may optimise the initial price while increasing future risk.
Normalising does not mean eliminating differences
The objective of a good RFP is not to force every vendor to submit identical proposals.
That would be counterproductive.
Vendor innovation, experience and different approaches are part of the value of going to market.
Normalising means creating enough common structure to distinguish real differences from differences in presentation.
For example:
| Without normalisation | With a comparable basis |
|---|---|
| Each vendor presents pricing using its own structure | All vendors respond to common economic assumptions |
| SLAs use vendor-specific definitions | Metrics and measurement rules are predefined |
| Requirements are treated as one undifferentiated list | Criticality and priority are explicit |
| Evaluation is largely qualitative | Criteria and weightings are defined in advance |
| Risk is discussed at the end | Risk is integrated into the evaluation model |
The objective is not to reduce the richness of the proposals.
It is to make the differences between them visible and relevant to the decision.
When comparison is difficult, negotiation also loses quality
An RFP with weak comparability does not only damage the selection process.
It also reduces the quality of the negotiation.
If the organisation cannot explain clearly why one proposal is stronger across other dimensions, price tends to receive excessive weight.
And when proposals use very different financial or contractual structures, negotiation becomes harder to conduct with discipline.
A comparable basis improves negotiation because it makes the following clearer:
- the strengths and weaknesses of each solution;
- the critical elements that need to be protected;
- deviations from the expected model;
- acceptable concessions;
- the economic impact of each change.
The organisation starts negotiating against criteria, not simply against positions.
A defensible process leaves a decision trail
The quality of a technology selection should not be measured only at the moment the choice is made.
Months or years later, someone may ask:
A robust decision should be explainable.
Which criteria were used?
Which alternatives were considered?
Which risks were identified?
Which trade-offs were accepted?
Which economic assumptions supported the decision?
Which exceptions were approved?
This traceability becomes particularly important when the decision involves significant investment, multiple internal stakeholders, technology risk or executive exposure.
A good RFP process should not merely arrive at a choice.
It should make it possible to explain why that choice was rational and defensible.
Before launching the next RFP, five questions
Before sending the document to the market, it is worth testing whether the organisation can answer these questions:
- Do we know which criteria will actually determine the selection?
- Will every vendor respond to the same economic and operational assumptions?
- Are the SLAs and requirements defined objectively enough to be compared?
- Are risk, dependencies and ability to evolve part of the assessment?
- Will we be able to justify the final decision without reconstructing the rationale afterwards?
If any of these answers is “no”, the evaluation problem is probably already being created before the proposals arrive.
The best RFP is not the one that generates more responses. It is the one that enables a better decision.
A technology sourcing process should not be assessed only by the quality of the document or by the number of proposals received.
The real test comes when it is time to compare.
Are the alternatives comparable?
Are the trade-offs visible?
Are the costs economically equivalent?
Are the risks explicit?
Can the decision be explained and defended?
When these conditions are in place, the choice becomes clearer and the negotiation more disciplined.
When they are not, the organisation can end up with a technically complete RFP — and a weak decision.
At aiteris, RFP Drive structures sourcing and selection processes around clear criteria, comparability, impartiality and traceability, helping organisations accelerate the decision without reducing rigour.
Frequently asked questions
What makes two RFP proposals genuinely comparable?
It is not enough for them to respond to the same requirements. They need sufficiently consistent economic assumptions, service definitions, evaluation criteria and response structures to support an objective comparison.
When should the RFP evaluation model be defined?
Before the RFP is issued to the market. Defining criteria and weightings after proposals have been received increases the risk that the assessment is influenced by the vendors’ responses.
Is the lowest price necessarily the best proposal?
No. Price should be assessed in the context of TCO, risk, implementation capability, dependencies, flexibility and expected business value.
Why should risk be included in the evaluation model?
Because two solutions that look similar in functionality and price can create very different levels of dependency, operational complexity, implementation risk and future ability to evolve.
How do you make a sourcing decision defensible?
By defining requirements, criteria, weightings and assumptions in advance; documenting the assessment; making trade-offs explicit; and preserving traceability on why one alternative was selected.
FROM PROPOSALS TO A DEFENSIBLE DECISION
Structure your next technology RFP with RFP Drive
RFP Drive helps structure requirements, SLAs and evaluation models to improve comparability, impartiality and economic value in technology sourcing processes.
accelerating what matters.
