I sat through a vendor selection last year that took five months. Five months of demos, reference calls, scoring spreadsheets, and steering committee meetings. The outcome? The company picked the vendor their VP of Engineering had wanted from day one. Everyone involved knew it by month two. Nobody said anything because the process had to run its course.
This is not an unusual story. It might be the default story.
The standard vendor selection process at most mid-to-large companies follows a script that hasn’t changed since the early 2000s. Someone senior decides the organisation needs a new platform – a CRM, a data warehouse, an ERP module, whatever. Procurement drafts an RFP with 300 to 400 line items that nobody will read carefully, least of all the vendors responding to it. Four or five vendors get invited to present. They fly in, set up identical-looking PowerPoint decks, and spend 90 minutes showing you exactly what you want to see. An evaluation committee scores everything on a weighted spreadsheet. And three months later, you pick the vendor whose sales team built the strongest internal relationships.
Meanwhile, the engineers and analysts who will actually use the tool daily had minimal input. Maybe they got to attend one demo. Maybe they submitted a few requirements that got folded into page 14 of the RFP.
There’s a better way to do this. It requires fewer meetings, less theatre, and a willingness to make decisions faster than your procurement team is comfortable with.
Start With Outcomes, Not Product Categories
The first mistake happens before any vendor is contacted. Someone frames the need as a product category: “We need a cloud data warehouse” or “We need a customer data platform.” That framing immediately narrows your thinking to whatever Gartner or Forrester says belongs in that box.
Instead, write down what needs to be true in 12 months. Not features. Outcomes.
“We need to process 10x the data volume without hiring additional data engineers” is an outcome. “We need sub-second query performance on datasets over 500GB” is an outcome. “We need marketing to self-serve campaign analytics without filing tickets” is an outcome. These statements give you something to actually evaluate against. They also open the door to solutions you might not have considered – maybe you don’t need a new platform at all, maybe you need to re-architect what you have.
I’ve seen teams spend four months evaluating data platforms when the real problem was a badly designed ETL pipeline. The new platform would have inherited the same mess. Outcomes-first thinking catches that early.
Three Vendors. That’s It.
Your shortlist should have three vendors on it. Not five. Not seven. Three.
Every vendor you add to the evaluation creates work. Each one needs demos scheduled, questions answered, security reviews completed, and reference calls made. Your team – the people doing the evaluating – have day jobs. They can’t spend half their week comparing platforms. When you ask them to evaluate seven options, one of two things happens: they do a shallow job on all seven, or they do a deep job on two and phone it in on the rest.
Getting to three requires doing your homework upfront. Spend a week reading analyst reports, talking to peers at similar companies, and checking the ThoughtWorks Technology Radar for what’s gaining traction. By the end of that week, you should know which three vendors are worth a serious look. If you can’t narrow it to three, you don’t understand the problem well enough yet.
Proof of Concept Over PowerPoint
Demos are theatre. Every vendor demo you’ve ever seen was rehearsed, optimised, and running on a dataset specifically designed to make the product look fast and elegant. The demo environment bears roughly the same relationship to production as a show home bears to actual daily living.
A two-week proof of concept with your actual data, run by your actual engineers, will tell you more than six months of slide decks ever could.
Structure the PoC around your outcome statements. If one of your outcomes is “sub-second queries on 500GB datasets,” load 500GB of your real data and run your real queries. If an outcome is “marketing self-serves analytics,” put two marketers in front of the tool for a week and see what happens. No vendor support during the PoC beyond initial setup. You want to know what it’s like when the sales engineer isn’t sitting next to you.
Yes, this takes effort. Yes, it requires the vendor to give you a trial environment. Any vendor who won’t provide one is telling you something important about how they’ll behave as a partner.
Total Cost of Ownership Will Surprise You
The license fee on the proposal is maybe 40% of what you’ll actually spend in year one. Maybe.
Implementation costs are the obvious addition, but they’re consistently underestimated. The vendor says 8 weeks; plan for 16. The systems integrator quotes $200K; budget $350K. This isn’t cynicism – it’s pattern recognition from watching dozens of these implementations.
Then there’s migration. Getting your data out of the old system and into the new one is almost always harder than anyone expects. Schema differences, data quality issues that only surface during migration, integrations that need to be rebuilt – it adds up. Training is another hidden cost. Not just the formal training sessions, but the 3-6 months of reduced productivity while your team learns the new system. And ongoing maintenance: someone has to manage upgrades, monitor performance, handle vendor communications, and maintain integrations as other systems change around it.
Build a total cost of ownership model that covers three years. Include every category: license, implementation, migration, training, integration development, ongoing maintenance, and internal staff time. Then add 25% contingency, because you will have forgotten something. For a thorough look at how technology costs compound, especially when technical debt enters the picture, that 25% buffer starts to look conservative.
Reference Checks: Skip the Vendor’s List
Every vendor will give you three reference customers. Those customers were chosen because they’re happy, they have a good relationship with the account manager, and they’ve agreed to take calls. Talking to them is fine but almost useless for decision-making.
What you actually want is to find companies similar to yours – similar size, similar industry, similar use case – who use the tool, and contact them directly. LinkedIn makes this straightforward. Search for the vendor name plus a relevant job title, and you’ll find people who work with the product daily. Send them a message. Most people are surprisingly willing to share their honest experience.
Ask specific questions. “How was the implementation – did it hit the timeline they quoted?” “What’s the biggest limitation you’ve hit?” “If you were starting over, would you choose this vendor again?” The answers to that last question are the most revealing. A pause before “yes” tells you as much as an outright “no.”
Managing the Politics
Vendor selection is a political process wrapped in a technical process. Acknowledging that fact doesn’t make you cynical – it makes you effective.
Someone on your team will have a favourite vendor from the start. Maybe they used it at a previous company. Maybe they’ve been talking to the sales rep for months. Maybe they genuinely believe it’s the best option and they’re right. Regardless, if that person’s preferred vendor doesn’t win the evaluation, you have a management problem on your hands.
The person who championed the losing vendor will be difficult for six months afterwards. They’ll point out every flaw in the chosen tool. They’ll bring up their preferred option in meetings. They’ll say “I told you so” at the first sign of trouble. This is human nature, and pretending it won’t happen is naive.
Manage it proactively. Give everyone a genuine voice in the evaluation. Make the criteria and scoring transparent. When the decision is made, have a direct conversation with the people on the losing side: “I know this wasn’t your first choice. I need you to commit to making this work. What do you need from me to get there?”
For organisations where board-level technology investment decisions go sideways, the political dimension is almost always the root cause, not the technology itself.
A Faster Timeline
Here’s what a good vendor selection looks like in practice:
- Week 1-2: Define outcomes. Write 5-8 outcome statements. Get stakeholder sign-off on these, not on vendors.
- Week 2-3: Research and shortlist. Desk research, peer conversations, analyst reports. Narrow to three vendors.
- Week 3-4: Structured demos. Not the vendor’s standard pitch – give them your outcome statements and ask them to show how they’d address each one.
- Week 5-6: Proof of concept with the top two. Real data, real users, no vendor hand-holding.
- Week 7: Reference checks, TCO modelling, final scoring.
- Week 8: Decision and negotiation.
Eight weeks. Not six months. The Gartner vendor management framework provides useful structural scaffolding, but you don’t need to follow every step of a formal methodology to make a sound decision.
Will procurement push back on this timeline? Probably. Will some stakeholders complain they didn’t get enough input? Maybe. But eight weeks of focused evaluation produces a better outcome than six months of diffuse evaluation every single time. The longer the process runs, the more it gets captured by vendor sales tactics, internal politics, and simple fatigue.
What This Means for Technology Leaders
If you’re a CTO or technology leader running a vendor selection this year, take an honest look at your process. Count the hours your team will spend on it. Multiply by their loaded cost. That number is the real price of your evaluation methodology. If it’s a six-month process involving 30 people, you might be spending $500K in internal time to make a $200K software decision.
The companies that move fast on technology decisions have an edge. Not because they’re reckless, but because they’ve learned that the cost of a slightly imperfect decision made quickly is almost always lower than the cost of a perfect decision made slowly. The tool you pick matters less than how fast you implement it and how well you adopt it.
Speed isn’t about cutting corners. It’s about cutting the parts of the process that don’t actually improve the decision.
Ben is a full-time data leadership professional and a part-time blogger.
When he’s not writing articles for Data Driven Daily, Ben is a Head of Data Strategy at a large financial institution.
He has over 14 years’ experience in Banking and Financial Services, during which he has led large data engineering and business intelligence teams, managed cloud migration programs, and spearheaded regulatory change initiatives.