December 5th, 2018 • posted by Aravo • Reading Time: 6 minutes

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:

• Some vendors will always say yes. In Dave’s experience, most RFPs focus on features and functions, and vendors will almost always check off all of the tick boxes. As webinar co-presenter Michael Rasmussen of GRC 20/20 Research pointed out, buyers need to dig deeper to validate these claims. A vendor may feel justified in saying that they have a feature, but:
  • Is it a feature available now or on the road map?
  • Is it out-of-the-box or custom?
  • Is it currently being used in production by other organizations?

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.

• The “shielding” process limits collaboration. Many organizations limit interactions with vendors during the RFP process with a goal of preventing any preferential treatment. While fairness and objectivity are worthwhile goals, this policy may prevent a shared understanding of the actual problem. It also underestimates how important it is for buyers to develop a relationship with their potential vendor-of-choice. During the webinar, Michael emphasized that organizations must clearly define what they are trying to accomplish, but the questions in an RFP may not be sufficient to communicate that.

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.

• A new RFP is unlikely to change the outcome. For those who have already gone through the RFP process, and found that their selected vendor could not meet their requirements, it’s likely that essentially the same set of vendors will be responding to a new RFP for a TPRM solution. Though all vendors will likely have made some technical updates, can a new set of questions be expected to uncover major new differentiators that weren’t identified in the past?

In most of Aravo’s “boomerang” situations, there is no subsequent RFP process. Instead, subsequent evaluations, focused on solving more specific use-case-based outcomes (based on real-world experience with the previously selected vendor) are more effective the second time around.

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:

• Can users navigate it? Usability is a key feature for all software and critical for user adoption. To achieve a mature, federated TPRM strategy, the solution must be accessible to a variety of users from the occasional business buyer to a third party using the self-service portal to the power user. The best way to test usability is to provide hands-on opportunities to users across various stakeholder roles.
• Is it responsive? What happens when a vendor’s risk profile changes? What if there is a weather-related or political incident that impacts a geographical region? It’s important to understand how the system will identify these changes, how users will be made aware, and how quickly that will happen. The ability to infuse this type of intelligence into your program will likely make (or break) the success of a TPRM program.
• Can changes be made easily? Change is inevitable, whether it’s the board’s risk appetite, internal processes, or external requirements like new regulations. A vendor should be able to demonstrate in real time how changes can be made to the system and how the organization can be vendor independent in making reasonable changes itself. This ensures that the solution remains fresh and has the agility to adapt to new risks without delays or dependence on the vendor, which often result in additional, unpredicted costs.

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:

• Make changes – The solution will likely include existing assessments, workflows, and other capabilities based on standards and best practices. During an evaluation, users should experiment with making changes that would reflect potential internal use cases, such as adding or deleting questions in an assessment, modifying the approval workflow, or changing the weight assigned to individual risks. This will instill confidence that the solution can provide the agility the organization needs to meet ongoing demands and challenges.
• Build something in real time – Standard functionality can be great, but it can also be limiting, and additions to a rigid system can be expensive and time-consuming if an organization has to rely on the vendor for everything. Within the PoC, users should experiment with building something on their own, such as a secondary questionnaire or a workflow.
• Test integrations – Without content and context, a TPRM solution can’t really provide a holistic view of risk. The evaluation team should test for themselves how content (such as a variety of third-party data sources) can be added to the overall risk profile in the context of real-world problems they are trying to solve and how that content is updated, either when the data itself changes or new content sources are added.

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.