Executive Takeaway: Traditional RFTs built around long requirements spreadsheets often lead to higher costs, fewer quality vendor responses and poorer outcomes in software procurement, particularly for SaaS solutions.
If you are still using a traditional RFT with a spreadsheet of thousands of requirements, there is a good chance you are making it harder for the right vendors to respond.
I spoke to a vendor yesterday, this time in the CRM space, and they told me they no longer respond to software RFTs where the client sends a giant spreadsheet and expects them to complete it line by line.
It is not the first time I have heard this. In fact, it’s happening more often, and it is one of the main reasons I push back on traditional RFT processes built around long lists of detailed requirements.
Why this traditional approach is failing
Many clients and consultants still take the old approach. They find a requirements list online or increasingly ask AI to generate one, modify it slightly and then send it to the market as if it reflects what they actually need.
Vendors are becoming increasingly frustrated by this checklist process, especially when it has little relevance to a Software as a Service (SaaS) solution. And the good vendors, the ones with plenty of work, are often the first to walk away.
That can actually reduce competition, because the organisations best placed to deliver the work may decide the RFT is not worth the effort.
In my experience, many of these spreadsheets are full of requirements that are vague, open to interpretation, or copied from somewhere else.
Vendors often do their best to respond, but much of the detail is still guesswork. That becomes a risk later when there are disagreements about what it means.
What has changed in software procurement
I have worked in the IT industry in all roles (i.e. buyer, customer and vendor partner) for more than 20 years. When I first started doing procurements, we were buying and delivering heavily customised systems that sat on servers in the client’s building.
At that time, you had no choice. You had to design the solution in detail and document everything through long lists of requirements.
Today, most software is cloud-based. The goal is no longer to design every feature from scratch. It is to choose a system that is already fit for purpose for around 85% to 90% of your needs, then focus on the few things that are genuinely unique.
If anything, the challenge now is usually to avoid over-customising.
Why long requirements spreadsheets lead to poor pricing
When clients insist on sending out thousands of requirements, they often create the wrong impression in the market.
Vendors assume the organisation wants a highly customised solution, even if that wasn’t the intention. That usually leads to higher prices, more contingency, and sometimes no response at all.
I’ve worked with several clients after they originally went to market this way and found themselves with sticker shock. They were asking for a Rolls-Royce when they only had a Kia budget.
The problem wasn’t just the budget. It was that they didn’t understand how requirements gathering has changed. They ended up describing something far more complex than they actually needed, and probably still had gaps in their list.
Why you can end up paying twice
There is another problem with doing this level of detail during procurement. After you select the vendor or implementation partner, you will usually go through a detailed design phase with them anyway.
That is the point where workflows are unpacked properly, decisions are tested, data fields are considered, and the solution is designed in context.
So, if you pay someone to create that level of detail as part of the procurement process, there is a good chance you are paying for it twice.
What I do instead
I focus on the 10% to 15% that is genuinely different from the out-of-the-box solution. That is what a vendor needs to understand to price the work properly.
How does your organisation operate differently from others like you? What special workflows, compliance needs, service models, or reporting requirements will create extra effort compared to the average implementation?
That is where the real value sits. Vendors can usually estimate a standard implementation for your sector. What they can’t price properly is the part you haven’t explained, or the part hidden inside a generic spreadsheet.
So, I spend more time describing the unique processes, the information flows, and the exceptions that matter. Yes, there are still some baseline requirements that can be checked off. But that should not be the centrepiece of the procurement process.
A better way to run a software RFT
If you want a more realistic response from the market, better pricing, and a solution that is genuinely fit for purpose, you need a more modern procurement approach.
For most SaaS and cloud systems, that means spending less time on thousands of generic requirements and more time explaining the few things that are truly unique about your organisation.
That is the information vendors actually need. It is also far more likely to get you a meaningful response from more vendors.
I help associations with software investment decisions regularly. If you need some help, let me know.
P.S. If you found this article helpful, you might want to read these too:
Tammy Ven Dange is a former charity CEO, Association President, Not for Profit Board Member and IT Executive. Today, she helps NFPs with strategic IT decisions, especially around major investments and risk mitigation.