Here’s how this usually goes. You write an RFP to keep procurement happy. You list a pile of features, ask for some certifications, and request the lowest price. A few months later the “winning” bid is late, over budget, and doing the wrong thing beautifully.
This isn’t bad luck, it’s the base rate. The Standish Group’s long-running CHAOS research finds only about a third of software projects fully succeed, while roughly half land late, over budget, or under scope (InfoQ). And the bigger the budget, the worse the odds: McKinsey, with Oxford, studied more than 5,400 large IT projects and found they run 45% over budget and deliver 56% less value than predicted (McKinsey). A sharper RFP is the cheapest place to bend those numbers in your favour.
The problem isn’t you. It’s the RFP. A vague one rewards whoever has the slickest proposal-writing team, not the best engineers. Ask a fuzzy question, get back five confident documents that all sound identical. Now go ahead and tell them apart.
So let me show you how to write one that actually works.
Start with the problem. Not the solution.
Open with what you’re trying to achieve and the constraints you’re stuck with. How many users. How much data. What it has to plug into. Which rules you answer to, like PDPL, the NCA’s controls, or your sector’s regulator. Then let vendors tell you how. The moment you over-specify the solution, you kill the better ideas and invite box-ticking.
Make every requirement testable.
“The system must be scalable” means nothing. Nobody can score it. Try this instead: “must handle 5,000 users at once, under 300ms, with proof from a real deployment.” Now a vendor can prove it, and you can check it.
Ask for evidence, not adjectives.
Anyone can call themselves world-class. Make them show you. A real architecture. A named project at similar scale that you can actually phone up. The CVs of the engineers who’ll do the work, not the partner who appears at kickoff and is never seen again. And ask the awkward question: how do you handle the thing that always breaks? Data migration. Change requests. The integration nobody scoped.
Decide your scoring before you read a single proposal.
This one matters more than people think. Agree on your weights now, while you’re calm and nobody’s in the room selling to you. Once the glossy decks land, you’ve lost. You’ll just reward whoever presented last. Here’s a sensible place to start.
Move the numbers to fit your situation. The whole point is that you set them first.
Don’t confuse price with cost.
The cheapest bid is almost never the cheapest system. Put the full picture into your score: licensing, integration, support, and what it’d cost to rip your data back out if the thing fails. (I go deep on this in total cost of ownership.)
Do all this and something nice happens. The RFP starts doing your filtering for you. Serious vendors spot a serious buyer and raise their game. The ones who planned to coast can’t hide behind buzzwords anymore.
Want an RFP that gets you the right answer, not the best sales pitch? We write and score technical RFPs as an independent party. We don’t resell software and we take zero vendor commissions, so the only thing we’re optimizing for is your outcome. Book a free 30-minute review and we’ll pressure-test your RFP before it goes out, or help you score the bids already sitting on your desk.
Sources
- InfoQ, Standish Group CHAOS report summary
- McKinsey, Delivering large-scale IT projects on time, on budget, and on value