- About Us
- Request Demo
The RFP has long been accepted as an “objective” way to conduct vendor selection for purchases ranging from hard goods to complex services. Its often lengthy list of feature/function-oriented questions is considered a means to level the playing field between vendors while demonstrating adequate due diligence. But is it necessarily the best way to buy third-party risk management (TPRM) technology?
Ironically, that was the question posed by Dave Rusher, SVP of product strategy and alliances at Aravo during last week’s webinar on “Best Practices for Third-Party Management RFPs,” which explored the critical capabilities and considerations for selecting TPRM vendors. Based on his more than two decades of experience in enterprise software and participation in hundreds of RFP processes, Dave observed that RFPs don’t always help risk management professionals evaluate the aspects of a solution that are most likely to lead to successful results.
“About 50-60% of new clients I engage with are what I call ‘boomerang clients,’” Dave reports. Most of these organizations considered Aravo in their evaluation of TPRM vendors, yet selected an alternative. Now they find themselves involved in another RFP process and are reviewing the market again because the selected vendor failed to meet the organization’s needs. After extensive internal resource and financial investment, they find themselves back where they started, and their organizations are no further ahead in understanding potential exposure from third-party relationships. Why would such a large number of organizations find themselves in this position if RFPs were the most effective way of identifying the best provider?
The Weaknesses of RFPs
Dave’s observation may be particularly frustrating for those who’ve spent countless hours researching, writing, and collecting the desired requirements for a TPRM solution. However, an unsuccessful RFP outcome may not be a reflection of the quality of the effort, but weaknesses in the process itself when it comes to evaluating enterprise technology. Are there common pitfalls that contribute to this failure rate? Dave points out several reasons why traditional RFP processes results may fall short, particularly in the TPRM space:
The general tendency for some RFP respondents to answer everything in the affirmative can result in the perception that all of the proposals are relatively equal and lead to decisions based on price, which doesn’t always represent the total cost of ownership or the unique needs of the organization.
For instance, Dave says, a deeper dive conversation may make it clear that the issue isn’t a technical one, but a process one, or that the problem of risk is being considered too narrowly. By creating distance between the buyer and the vendor, the “quiet period” prevents the organization from being able to take advantage of consultative vendor expertise derived from experience with other clients and result in mismatched expectations.
Experience matters and, ultimately, contributes to success or failure. Regardless of features and functions, it’s important that organizations establish a trusting relationship with one another. By preventing potential vendors with the opportunity to consult with business stakeholders to address the primary concerns for achieving success within their program, organizations make it harder to establish shared vision about the outcome. They are also missing an opportunity for buyers to understand first hand what a potential relationship with that vendor would be like and the level of expertise they have to offer.
What’s Missing from the Typical RFP
An RFP can ask vendors to verify that they have a solution that will encompass the full TPRM life cycle: registration, qualification, contracting, onboarding, maintenance and renewal, and offboarding. But some features that are critical to success are harder to evaluate via questionnaire and have to be evaluated in real life – not through a canned demo. For these, buyers and users need to be able to determine the following:
PoC > RFP
If RFPs aren’t ideal, what is the alternative for making an informed decision? As the saying goes, there’s no substitute for experience. A proof-of-concept (PoC) and/or a hands-on pilot based on the organization’s specific, defined workflows and use cases is a much more effective way to evaluate usability, responsiveness, and agility. Whether a standard out-of-the-box solution or a PoC with greater custom configuration, a hands-on pilot allows users to test drive TPRM technology, much as one would assess the handling and maneuverability of a new car. Dave specifically recommends that potential buyers put TPRM technology through the following courses:
A scorecard based on this kind of experiential PoC can provide greater confidence that the vendor can, in fact, deliver on the features and functions as well as the user experience that can meet current and future expectations for a TPRM solution. Even if corporate policy forces a TPRM purchase through an RFP process, buyers should consider incorporating a PoC or other hands-on evaluation into the creation of the vendor shortlist or the final evaluation to increase the likelihood of success.
Dave’s comments on the shortcomings of RFPs and more insight into criteria for evaluating TPRM vendors is available in the on-demand webinar: Best Practices for Third-Party Management RFPs. Industry analysts specializing in TPRM, such as Michael Rasmussen, are also valuable resources for helping organization refine their requirements and criteria for vendor selection that reflects their needs and priorities.