Rethinking the RFP: How to address the vendor-practitioner power imbalance during HR tech procurement

For even the most procurement prone HR leaders, hearing the letters ‘RFP’ will bring back rising feelings of frustration. Requests for proposals (RFPs) are a perpetual point of friction in the HR technology acquisition process that is already fraught with difficulties, from shrinking budgets to stakeholder buy-in.

This has to change. Having a deeper understanding of the RFP process can help HR leaders secure the technology they believe will best help the organization achieve its people-driven and business-driven objectives. William Tincup joins HRD for another Decoding HR Tech Q&A to reveal RFP best practices that can help HR leaders save time, avoid piling up HR technical debt, and emerge from a procurement cycle with confidence in their purchase.

1. What steps can HR leaders take to ensure they select the right software?

William Tincup: You’re trying not to waste money on problems that don’t exist. Recruiting software has such good marketing that practitioners will fall in love with it, without thinking about their own company, people, or users.

First, get everyone involved. As a leader, you might not even be logging into the software you’re buying, so make a selection that other people will use. Secondly, it should solve a real problem. Often, a problem in onboarding, for example, could be solved with a process or policy rather than software, so you have to find the underlying problem. Then, does the software shed new light on the problem? Does it solve it uniquely or better than anything else you can think of? And is your team on board with this change?

2. What are the best practices for HR leaders during the RFP process?

William Tincup: A lot of RFPs are built by vendors. It’s like how a lot of legislation in America is written by lobbyists before it’s modified. Very rarely does a practitioner sit down and write out all the things they need the software to do. The vendor gives the practitioner the RFP who then tweaks it. The vendor inherently writes the RFP in their favor. It skews towards their strengths.

The way to overcome this is to hire a consulting firm that doesn’t make money from any of the vendors. This type of firm can be objective. Or, write the RFPs in-house. I’ve seen companies, especially mid and larger companies, that have built beautiful RFPs, from the ground up with no help. They don’t use anyone else’s template because it’s based on another company’s needs.

3. Should HR leaders evaluate a vendor’s stability and future potential?

William Tincup: No company is truly stable. We believe the bigger companies are somehow more stable but that’s a misnomer. Ten, fifteen, or twenty years ago, if your vendor discontinued the software or went under, it would be a huge cause for concern. But now, software moves so fast. If you’re not looking to replace your software every two years, you’re doing something wrong. In turn, stability becomes less important.

Stability now forces us away from truly innovative start-ups. Keep in mind a smaller vendor that is traditionally less stable will bend over backward for a big-name organization, whereas you’re just another logo to a larger and traditionally more stable vendor. Obviously, each case is different and there are pros and cons in every scenario. But how can you even determine stability? From a balance sheet? It doesn’t tell you how they treat their customers.

4. How can they make the RFP process more efficient while still ensuring they select the right vendor?

William Tincup: It goes back to my first point. Have everyone in the room when you build them. Everyone has to agree on each line. It could be as simple as asking for a show of hands in agreement on Row X.

The software will have a bunch of exciting features that aren’t critical and don’t belong on the RFP. So, you need a clear agreement on features that are critical. To go on the RFP, or not, there must be 100% agreement. If it’s not unanimous, hammer it out until there is consensus.

5. What potential contractual pitfalls should HR leaders be cautious of?

William Tincup: There’s good news and bad news. SaaS contracts these days are much better than the on-premise contracts of yesteryear. It’s not a question of whether you own your data, the transferability of historic data into new applications, and so on. But software companies have an advantage over practitioners. They write these contracts every day. They know the ins and outs of every single one of their contracts.

As practitioners, we might negotiate one or two software deals a year. We’re not as skilled at the finer points of negotiation. So, look for your legal counsel to provide plenty of support, and make sure they know how to negotiate software contracts. I’d also advise pushing for a break clause after 90 days if it isn’t working out, from either side, be it vendor or practitioner.

I’d also push for those shorter contracts. In a longer contract, you might get a cost break. But you don’t truly know the chemistry of the team or the technology. It also incentivizes faster onboarding to get people up and running. Finally, it places a clear incentive for ongoing support and innovation. In a longer contract, they might treat you terribly for several years and only make an effort in the last six months before the contract renews. It motivates them to support you throughout and to consistently innovate to keep you from looking elsewhere at the end of the two years.