A technical RFP is a filter, and a vague one filters for the wrong thing: the vendor with the best proposal writers, not the best engineers. This post covers the three jobs a good RFP has to do, a worked example, and the traps that turn a careful procurement into an expensive one.
Here’s how it usually goes. You list a pile of features, ask for some certifications, and request the lowest price. Five confident documents come back that all sound identical. A few months later the “winning” bid is late, over budget, and doing the wrong thing beautifully.
That isn’t bad luck, it’s the base rate. The Standish Group’s CHAOS research finds that roughly 31% of projects succeed, about 50% are “challenged” (late, over budget, or under scope), and about 19% fail outright (InfoQ, 2015). The bigger the budget, the worse the odds: McKinsey and Oxford studied more than 5,400 IT projects and found the large ones run on average 45% over budget and deliver 56% less value than predicted (McKinsey, 2012). Much of that damage is decided in the document that chose the vendor.
The three jobs an RFP has to do
Strip away the procurement templates and an RFP only has to do three things. Do all three and it filters vendors for you. Skip one and the filtering happens in the sales meeting instead.
flowchart TD A(["A technical RFP"]) --> B(["1. State the problem, not the solution"]) A --> C(["2. Make every requirement testable"]) A --> D(["3. Fix the scoring before bids arrive"]) B --> B2(["Skip it: vendors sell their product, not your outcome"]) C --> C2(["Skip it: five identical 'yes' answers you can't tell apart"]) D --> D2(["Skip it: whoever presented last wins"])
Job one: write the problem, then let vendors propose the how
Open with what you’re trying to achieve and the constraints you’re stuck with. Not a feature list. A problem statement an engineer could argue with.
- The outcome. “Cut order-to-dispatch from three days to one” is a problem. “A warehouse system with mobile scanning” is a solution you’ve already picked, possibly the wrong one.
- The scale. Users, transactions a day, data today and in three years. Vendors size their architecture and price on this. Leave it out and every bid is guessing.
- The integrations. Name the systems it must talk to: your ERP, your bank, ZATCA e-invoicing. Name the ones with no API. That list is where projects die.
- The rules you answer to. PDPL took effect on 14 September 2023 with SDAIA as regulator, and cross-border transfers are governed by Article 29 and SDAIA’s Transfer Regulations (Morgan Lewis, 2024). So say where personal data may be hosted and whether it may leave the country. If you fall under the NCA’s Essential Cybersecurity Controls, list the controls the vendor inherits. A bank names SAMA; a hospital names NPHIES.
- The constraints. Budget range, the go-live date that actually matters, and what you can’t change: the data center, the identity provider, the incumbent.
Then stop. Let vendors tell you how. Over-specify the solution and you kill the better ideas and invite box-ticking. If you’re a government entity the tender goes out through Etimad in a fixed format, but nothing stops you putting a real problem statement in the technical annex.
Job two: make every requirement testable
“The system must be scalable” means nothing. Nobody can score it, so every vendor writes “yes.” Try this instead: “must handle 5,000 concurrent users with page loads under 300ms, demonstrated on a named production deployment we can reference.” Now a vendor can prove it and you can check it. The test for every line: would two evaluators, working separately, give it the same score?
- Replace adjectives with conditions. “Secure” becomes “encrypts data at rest and in transit, supports SSO with our identity provider, and passed an independent penetration test in the last 12 months.”
- Name the actual interface. “Posts journal entries to SAP via the standard BAPI, with a documented error queue.” The vendor who has done it will say so in detail.
- Split mandatory from scored. A mandatory requirement is a gate: fail it and the bid is out, whatever the price. In-Kingdom data residency, a required certification, a hard go-live date. Everything else gets a weighted score. Mixing the two is how a cheap bid that fails a legal requirement gets shortlisted.
- Ask for evidence, not adjectives. An architecture diagram for your case. A named project at similar scale with a reference you can phone. The CVs of the engineers who’ll do the work, not the partner who appears at kickoff and vanishes. And the awkward questions: how do you handle data migration, and how do you price change requests?
Job three: set the scoring before the first proposal lands
Agree your weights now, while you’re calm and nobody is in the room selling to you. Once the demos start, you’ve lost. You’ll reward whoever presented last.
Move the numbers to fit your situation; a bank pushes risk higher. The point is that you set them first, publish them in the RFP, and have each evaluator score independently before anyone compares notes. The mechanics are in our framework for scoring software proposals.
One more rule: price is a score, not the score. The cheapest bid is almost never the cheapest system. Score total cost over five years: license, implementation, integration, support, internal staff, and what it costs to get your data back out. We go deep on this in the hidden costs of enterprise software.
A worked example: three bids for one system
Say you’re a distributor replacing a warehouse system across four sites. The numbers are made up to show the shape.
Three bids come back. Vendor A quotes SAR 900,000, the lowest. Vendor B quotes SAR 1.4 million. Vendor C quotes SAR 1.9 million with a well-known logo. On price alone, A wins.
Now apply the RFP. A fails a mandatory gate: their platform is hosted outside the Kingdom and their data-residency answer was “we can look into it.” They’re out before scoring starts. On technical fit, B beats C: their architecture was drawn for your four sites, their reference was a distributor your size, and the engineer named on the bid was on the reference call. C’s bid was polished but generic.
On cost, C’s license was lower, but their change-request rates were higher and their contract made data export a paid engagement, so B’s five-year total came in below C’s. B wins on a scoresheet you can show the board, and the reason you didn’t pick the cheapest bid was written down before anyone asked. None of it needed a bigger budget, just a better document.
Where RFPs go wrong
We see the same five failure modes in most tenders we’re asked to rescue.
- Copying a vendor’s template. If a vendor “helped” draft your requirements, the RFP specifies their product. Every competitor sees it on page one and bids to lose.
- Two hundred requirements, none testable. Long RFPs feel rigorous. In practice vendors answer “compliant” to everything and the decision falls back to price.
- Scoring after reading. Weights decided after the demos are rationalization, not evaluation, and the award can’t be defended if challenged.
- Lowest price wins. A five-year system bought on year-one price usually means the thinnest implementation team and the highest change-request rate.
- No exit clause. If the RFP doesn’t require a documented data export and a defined handover, the vendor owns your data in practice. Lock-in is set at signing, not at renewal. The contract terms that keep your options open are in avoiding vendor lock-in in government IT.
The honest catch: a good RFP takes longer to write, usually three to six weeks in our experience, and some vendors will decline the extra work. That’s the filter operating.
How to start: one RFP, done properly
The pattern that works is boring and reliable. Pick one procurement that matters. Write the problem statement first and have the person who’ll live with the system sign it off. Turn the requirements into tests, split mandatory from scored, set the weights. Only then open the door to vendors. Run the evaluation as written, and keep the scoresheets.
Then measure: did the project land within budget and date, and would the scoresheet have predicted the winner? If yes, that RFP is your template for the next tender. If no, you’ve learned which requirement you missed, cheaply. An independent read of the document before it goes out is what our technology assessment and due diligence practice is for.
Is there an RFP on your desk you’re not sure will get you the right vendor? SDCG writes and scores technical RFPs as an independent party, with zero vendor commissions. Book a free 30-minute review and we’ll pressure-test your RFP before it goes out, or help you score the bids already in.