.webp)
Five hundred and thirty one (531). The number of HR Tech RFP responses that crossed my desk as a writer, editor, manager or sponsor in the 3 years leading up to April 2020.
If you've ever prepared one RFP response you'll understand the level of effort, detail and preparation that goes into delivering just a single submission, it is taxing. If you’ve ever reviewed RFP responses, you’ll be familiar with the challenging and sometimes frustrating process of trying to break apart responses to enable that elusive “apples to apples” comparison of vendor capability, it’s not easy.
If you haven’t done either, but are about to ask your team to buy via an RFP then read on in particular, I want to outline how you specifically as an executive can safeguard your organization from a costly misstep, supercharge team engagement, and ultimately lay the foundation for breakout success with your new technology.
(and if your boss is the one asking, why not grab this article and show it to them)
The Problem... and the Solution.
Having been on both sides of the procurement table, and seeing in a three year period more RFP structures, styles and approaches than most professional buyers see in their careers, I’ve often wondered if in the final analysis each group actually gets from the process what they were looking for. Having canvassed opinion, unfortunately often the answer is “no”.
A common response is also “we made an ok first filter, but really just had to start over with the main contenders at the demo round”, or perhaps worse “the vendor we liked best bombed, and then we had to tweak the process to get them back in”.
On the flip side, ask any experienced software consultant for war stories and they’ll likely be able to detail an extensive boulevard of broken dreams when it comes to organizations choosing a less than ideal option for their needs.
As a business leader (or team) entering a new procurement process this should ring some alarm bells. But there is a solution….
I want to make an argument of why it’s important, if not critical at the RFP stage to be thorough in preparing, open to share and up front about your needs, and what business outcomes the vendor needs to help you achieve.
I call this RADICAL CANDOR, and it can transform everything.
It might sound simple, you might even think you’re doing it, but 531 times to the rodeo tell me otherwise (I would estimate less than 5% do a good job). On the other hand you might think it is unnecessary or even dangerous to share this level of detail at such an “early” stage. I believe it is actually the complete opposite.
Let me break down why.
Seeing Your Blind Spot
So what is the point of the RFP process anyway?
For you, the HR leader, the objective is mostly likely to determine who are the likely contenders to meet the needs of your organization. It is the structured, objective (and defensible) evaluation of your options. An RFP can also act as a check and balance to ensure fair competition, a tool to ensure you obtain the best possible price, and can be used as protection to ensure what vendors tell you they will deliver is written down someplace to avoid a “gotcha” moment down the track. But for the most part it is, and should be, about fit.
In spite of this, eight out of ten HR Tech RFP requests from top firms, even with world class procurement groups, lack meaningful information about the actual business challenges the organization is looking to solve. Instead they are limited to a set of largely (or completely) generic questions on functional wants, a smattering of generic service and support questions and perhaps a general question on company “vision”.
This is so common most vendors maintain a library of standard responses to these questions and can even answer the majority with little or no human intervention at all (yes, there is software that does this for you).
Inevitably taking this approach leads to one, some, or all of the following to happen:
Every vendor answers “yes” to every question you have asked
The supporting comments are limited, potentially off topic and don’t really allow you to discern the concrete differences between vendors (who is better or worse)
The grading system of “standard”, “configuration”, “custom”, “roadmap” and “not available” functionality (or your equivalent) is interpreted differently by each vendor and even used to their advantage (see point 1 above)
The final scoring schema, while it looked good on paper, doesn’t yield the vendor you feel is actually best qualified to deliver you and your organization to success
None of these are ideal outcomes.
You might argue that the RFP is just a first filter and you’ll be able to better establish fit and cover the details in later demos and meetings, however, likely you won't have the time to see a demo from every shortlisted vendor showing every element you asked about (and need) as included in the RFP documentation.
At best you’ll be limited to a handful of key business flows out of the dozens that happen in a real organization, or a limited set of hundreds of functionalities that would represent everything you need in a solution. Suddenly all of those “yes” responses and vague comments leave you a massive blind spot.
By kicking the details down the road you have reduced your level of certainty about a vendor’s ability to meet your needs, and forced your time poor operational and procurement teams to work on faith that the vendor will deliver.
Instead, why not give the vendor a chance to frame their offering in the context of your business problem in writing, when everyone has time and a chance to review it?
"Makes sense. But without RADICAL CANDOR it is impossible, and it starts with you."
While a vendor may have a theory on how they can help you, faced with uncertainty about specific objectives they will offer “bland”. The risk of missing the mark is too high, and while they might have a general theory on how they can help, every business (including yours) is unique. The idea that the right vendor will just “know” what you want is definitely not an acid test to depend on.
As a leader you have two key superpowers in this scenario, the ability to give your team permission to talk about real business challenges and objectives at RFP, and the ability to distil your vision down so it can be part of the process.
Without doing these two things, the chances of significant success are limited.
Difficulty increases, time commitment increases, frustration increases and ultimately risk increases.
On the flip side, if given a strong brief of your needs and desired business outcomes the vendor doesn’t or can't articulate how what they offer fits, there is a reasonable chance:
They haven’t had significant past exposure to your specific scenario (limited past experience)
They don't have functionality to meet the need so they keep it generic
They are not truly invested in this opportunity (indicator of marginal fit or potentially limited resources in the back end to support you as a customer)
Not leveraging provided information to tailor answers to your needs isn't necessarily a disqualifier (there may be a good reason like a short response turnaround time), but it’s something to pay attention to. Those that care will ensure they take the time to actually explain in writing how they can help.
(and if you don’t want to leave it to chance, ask vendors to specifically write to your needs within your request)
But What About Best Practice?
It is common that you might not know exactly what you want, and so it would seem logical to keep the RFP generic and let the vendors take the lead. You’re planning to completely revamp or scrap your old outdated system anyway right, so why not just adopt a “best practices” feature set to ensure you’re competitive?
In reality, while you may be hamstrung by the limitations of your current system, the fundamentals of your approach, and what you are trying to achieve as a department or a business transcends the technology. To truly win (or transform) you need to innovate with cutting edge practice, underpinned by technology.
"No technology can overcome a bad process."
While it might seem you’re buying a “tool” or a “platform” within which to work, in reality what you are buying is a delivery capability.
Functionality needs to be there, but all of the functionality in the world doesn’t matter if it doesn’t fit your use case. In fact, what is more likely to determine success, particularly with core systems is how well the technology is configured to match your needs.
Why? Configurability allows you to ensure the process is coherent, logical and aligned with the way you work, and most importantly can drive activity towards your business objectives. This drives outcomes, adoption and ultimately rip roaring success.
If you don’t tell the vendor what your business objectives are, they won’t be able to tell you how their system can drive activity towards them. Instead they will be forced to simply show you their “best functionality” or a “happy path” process, which may or may not be useful (cue sighs and irritation from those in the business who just wasted 2 hours in a demo).
Likewise, remember those “killer features” and generic “best practice tactics” are being sold to your competitors too, at best they represent a short term advantage.
Configurability is only part of the picture too. Implementation and Account services are essential to ensure your system meets your needs. It cannot be understated the value in having someone with domain expertise translating your desired approach into a system and then supporting you with ongoing enhancements.
Through RADICAL CANDOR you are allowing the cream to rise to the top across all of these topics.
Don’t get me wrong, I’m not arguing against asking vendors what their best practices approach or innovative functionality looks like for calibration or to establish your wish list, that can be very helpful, but there is so much more value in that process when everyone knows what you want to achieve.
Overcoming FOMO
Finally, perhaps the fear is that if you're too specific no vendor will meet your needs, and you’ll be stuck with no options and nobody willing to service you, let’s call this a sort of procurement FOMO (Fear of Missing Out).
First up, no software vendor will offer absolutely everything you want exactly the way you want it, it is important to understand like any purchase you’ll always be making some compromises. The seller knows this and will always put forward their best alternative for your situation (further details to come in part 2 of this blog series).
The more you focus on your wants (rather than a generic feature set) the more likely you are to unearth your perfect match. There is no sense in being shy. Or as I like to say:
“If you don’t ask for a monkey, you don’t get a monkey.”
If you have unique needs and there are indeed big gaps in all options at least you know where you stand. You can then decide to compromise, stick with what you’ve got, canvas for more options or potentially up your budget to get the system you want (larger vendors offer more configuration options, and even beyond that there is almost always a vendor willing to do custom work). In most cases, even being very specific about your needs, there will be at least one viable option on the table.
And if you don’t get that monkey, it might be for the best anyway.
In Conclusion
Summing up, by being thorough in preparing, open to share and up front about your specific needs and business objectives, you will maximise your chances of successfully identifying the vendors who are most likely to be a fit.
By using radical candor, you will limit your blind spots in the demo round, reduce risk, and identify vendors who offer a delivery capability to drive you towards your objectives. It is critical to look beyond functionality alone, and to the ability to configure to your needs supported by the right implementation and account expertise.
Finally, as a leader you are uniquely positioned to make this happen. Your team at the coal face may have an idea of the problems at hand and the overall priorities, but only you can really distil them down to what matters and provide the permission to make them part of the process.
Now, I can hear you saying “that is all well and good, but by being so honest aren’t I leaving myself and my organization open to being catfished, coerced or conned?”.
Not necessarily. In Part 2 I go on to discuss the risks and realities, and the “hidden” ways radical candor can actually help to root out the pretenders, and reveal who the real enemy actually is (and no, it’s not the procurement department).
And finally, “great pitch, but how do I actually do it….?”
Not to fear, I’ll cover my top trick and approach in Part 2 as well.
(Starting your process now and can’t afford to wait? No problem, contact me here and I’ll give you a sneak peak to get you going)
Comments