6 Reasons to Skip the HRIS RFP When Purchasing HR and Payroll Software

I am going to get straight to the point in this blog: I am passionately opposed to using an RFP to buy any kind of software, SaaS solution or technology. Unless you are legally required to do so by state or federal law or contractually obliged to by some other means, RFP’s are an antiquated and obsolete process. And they were never intended to be used for the purchase of technology. While they may be good for buying bulk paper for your company or purchasing lawn care maintenance for your City; trying to purchase technology through an RFP is a near-impossible task—for both you and the vendor. Let’s look at my top HRIS RFP pitfalls and reasons for skipping the HRIS RFP.

HRIS RFP Pitfalls

1. Many modern, cloud-based HRIS software systems are very configurable. Meaning, you can ‘configure’ the systems to make it do what you want or need it to do. HR systems today simply have a high degree of flexibility. For all the ‘black or white’ questions on your RFP (i.e. questions requesting a “yes” or “no” response) regarding specific functional capabilities, most vendors will simply answer “yes” because their solution can be configured to accommodate and satisfy the request. The real question, however, is not if they can or cannot meet a functional requirement, but what level of effort is required to fulfill that functional capability. Don’t be surprised to see your entire requirements matrix answered with a “Yes, Meets Requirement”. The bottom line is the devil is always in the details.
2. Requirements. Unfortunately, requirements will not be ‘fully’ defined at this early stage of acquiring any HR software. This is not for a lack of trying to document the requirements up front, but simply that getting into the details is not an easy process. Consider all the opinions, needs and wants of the various team members (e.g. executives, department leaders, the various HR team members, etc.) and each of these having different priorities. Not to mention, that typically what an organization thinks they want and need initially, often changes or is adjusted as your team goes through product demonstrations, and more importantly, through the implementation scoping sessions, learning as you become more knowledgeable about solutions, best practices and possibilities for process improvements. It is my opinion that you simply cannot define all your requirements and processes in an RFP upfront—they will change as you learn about each vendor’s product and implementation methodology.
3. Price. The vendor should be able to give you an accurate estimate for its application’s annual subscription costs, but when it comes to implementation and training fees—the vendor simply cannot get to the level of detail needed from an RFP. Plus, as noted in item #2 above, the vendor knows your requirements will change as you go through the evaluation process and therefore knows implementation costs are a bit of a moving target. If you require the total first year investment costs in your RFP, you should expect that all you’ll be getting is an educated guess at best.
4. References. References are important, but at the right time. Any respectable vendor must align the information you need to garner from a reference with appropriate and specific clients. At the RFP stage, the vendor simply doesn’t know this information yet and I’d venture to say that neither does the person asking for the reference. If the vendor is any good at what they do, you will not be getting references until much later in the evaluation process.
5. Time. It takes a significant amount of effort to create, distribute, collect, evaluate and score an RFP. In my experience, the RFP process is not going to be completed any faster than 8 weeks, which I would argue is time that could be better spent with follow-up demonstrations, dialogue with the vendor’s VP of Professional Services and/or assigned project manager, conversations with the VP of Customer Support, or reviewing 3rd party testimonial sites (e.g. TrustRadius, G2 Crowd, Capterra, etc.).
6. The RFP itself. In over 20 years of selling, I’ve seen more RFP’s than I care to admit. And the RFPs always fall into one of two categories. First, the RFP is a boilerplate document downloaded from some popular website and is used almost as-is. To be honest, these RFPs are the lesser of two evils because I could at least copy/paste from previous RFP responses and move on. The second type is more open-ended and clearly written with the assistance of a specific vendor (or consultant) to place a certain vendor and their application in the best light possible. And let’s face it, any company other than the chosen vendor and solution for the tailored RFP is nothing more than column fodder. In either case, is this really the intent of the RFP in the first place? Couldn’t, and shouldn’t, your time and the vendor’s time be better spent working towards obtaining the best solution for your organization?

For what it is worth, I am seeing some movement on the vendor side of the RFP process to simply not respond to or decline to participate in any RFP process. And I truly hope this trend gains the traction it deserves. It is well documented in today’s era of buying technology, two-thirds of the sales process has been completed by the buyer before they ever reach out to a vendor. Information is readily available online and buyers are extremely smart and capable. Engage vendors and have meaningful fact-finding sessions, product demonstrations and professional services scoping conversations. These events will be far more valuable to you as a buyer than an RFP ever could do. My personal recommendation, not just because I am passionately opposed to the RFP, but because I sincerely believe it is in your best interest to skip the HRIS RFP. I know you will have a much better evaluation and buying experience without it.

Feel free to contact us for a better HR technology buying experience.