Software Procurement: Why the Tender Process Is Broken

I've seen software procurement from both sides. As a consultant running the process. As a vendor receiving the RFP. And as a problem-solver called in to clean up afterwards.

My honest take: for everyone involved, a software tender is usually a massive waste of time.

What actually happens during a software tender

You define requirements. Select potential vendors. Send out the RFP. Set timelines — for questions, answers, presentations. Then you wait. Responses arrive in completely different formats. You cluster, sort, compare wildly inconsistent pricing. There are meetings about the results of those meetings. You build a shortlist. Vendor presentations. A decision — or not. Then negotiation.

By the time you're done, months have passed. The original problem has probably gotten worse.

And what do you get at the end? Usually SAP. Or a custom build. Because someone knew someone. Because it was comfortable. Because a decision just had to be made.

What happens on the vendor side — nobody tells you this

The smart vendors — often exactly the ones with the best solutions — don't respond at all. Why would they? Answering an RFP properly costs days, sometimes weeks. For a statistical chance that approaches zero.

The vendors who do respond are often the ones who have to fight for every single deal. The ones pushing an on-premise solution that hasn't had a real update since 2012. They invest time because they have to — not because they have the best solution for you.

And as soon as an external consultant is running the tender? Every alarm bell goes off. Experienced vendors know: they already know who's going to win this. The RFP is a formality.

The dirty secret of software procurement

Many companies launch a tender hoping that one of the vendors — smart enough and naive enough to invest serious effort into the response — will teach them what they actually need.

The tender as a free consulting process at the vendors' expense. That sounds harsh — but I've seen it happen more times than I can count.

The real problem: it's almost never the tool

Here's the biggest misunderstanding. The tool is rarely the problem. The decision-making processes are the problem. The workflows. The way projects get approached.

Many problems can be solved without new software at all. And the probability that the same problems will resurface in the new tool — sometimes even worse — is almost guaranteed. It starts with the mindset: we buy a new tool, everything gets better.

It won't. Not automatically.

What you should do instead

Before you launch the next software tender — let someone with a genuine problem-solving mindset look at your actual problem.

Not someone who wants to sell you a solution. Someone who will tell you whether you need a new solution at all.

Sometimes the answer is: no. Sometimes it's: yes, but not what you had in mind. Sometimes it's: your problem is somewhere else entirely.

You won't get that answer from a tender process. You only get it when someone actually looks.

If you're facing a software decision right now and you're not sure you're on the right track — get in touch. Before you start the tender, not after.

— Robert