When GRC (related) RFPs Crash and Fail

Written by The GRC Pundit

Published on2024-06-04Updated on2024-06-04Discussion1 Comment on When GRC (related) RFPs Crash and Fail

Yesterday, I was in a hurry. I had a family medical appointment and needed to get back to the office. I got to our apartment, hopped on my bicycle, and took off for a five-block ride to the office. Intent on getting to my destination, I failed to be present where I was at the moment. My bike tire got caught in the light-rail tram tracks (The Hop in Milwaukee) and threw me. I skidded across the pavement and now have a bruised and banged-up body (but nothing broken or serious).

This is the second time those tram tracks have taken me for a spill, but have caused much greater hurt to others. My wife and I were walking and helped a young lady who needed to get to the emergency room as she was seriously injured a few years back. Two of my adult sons separately saw nasty bike accidents last week on those tracks. Even the lady at the bar in the public market shared her stories with me last night of people who have taken a spill on bikes from those train tracks.

Of course, this got me to thinking about the number of GRC-related RFPs I have interacted on that also have ended up in ‘crashes.’ Sometimes during the RFP, other times a year or two later. Too often from the same issues across RFPs that fail to pay attention to the details.

I work on A LOT of GRC-related RFPs. By related, I mean they are in a broad array of GRC domains and functionality. Some are for a broad enterprise GRC platform; others are focused on a specific aspect, like the array of third-party governance/risk management RFPs I am currently or regulatory change management RFPs I am currently interacting on. There are currently 14 RFPS of various GRC scopes with which I am interacting on in the United Kingdom (I am in the United Kingdom helping with several of these as well as other engagements from June 11th to 28th, if you are in the UK and want to get a pint, coffee, or have me stop by the office in London . . . let me know). Looking at my inquiries and engagements, there are 31 RFPs across Europe that I have interacted with recently (in addition to the UK ones). Two-thirds are in the DACH and Nordic regions, and then BENELUX is the next busiest. And 8 across North America. Several more in the Middle East and across Asia Pacific.

For some of these, my involvement is deep in establishing requirements and being an advisor throughout the process. For others, it is just a quick conversation where they want my perspective on who they are evaluating/considering. Sometimes, I get engaged at the beginning of the RFP in building a business case, and other times, I am asked for my perspective when they are down to the final 3.

I can point to highly successful GRC-related RFPs where the organization is extremely happy with the selection and implementation (I am happy to provide references and introductions where appropriate). Sadly, I can point to RFPs that have been wrecked and crashed, which have led to people losing their jobs and the projects failing (sometimes from not following my advice).

Like riding a bike, you need to know where you are starting from, what your destination is, and be present in evaluating what is around you as you progress through your GRC-related RFP.

GRC-related RFPs fail when:

• You blindly listen to analyst opinions. Yes, I am an analyst (and would think you should listen to my opinion). The analyst industry is a mess right now. Too often, some analyst firms have commoditized their research and fail to deliver objective value. In one firm’s last three reports comparing solutions, I have seen them rank one vendor as a leader in Enterprise GRC Platforms. This solution did not have a publicly available enterprise/operational risk management module at the release of these three reports. How can you be a leader in GRC without a risk management module? Too many analyst firms do not want to have live demos and do not want to work with the solution themselves in a sandbox. Instead, they want video demos submitted. Really??? That opens the doors to a lot of fiction. They also do not want to talk directly to client references but want to do web surveys. This is not market research where you can get into stories and ask hard questions (see below).
• You fail to test the product. I have seen people lose their jobs for choosing the wrong solution. They listen to the marketing and sales pitches, fail to dive deep into the product capabilities, and seek client references for similar implementations (size and industry). I remember one RFP where I advised them against the solution they chose. They were twitter-paited with the vision and story of marketing and sales. Additionally, the major analyst firms told them to select it. I told them NOT TO. I simply stated that there was no way that the solution they chose could support the complexity of their program. I was right. They came back less than two years later and said they wish they had listened to me and that they were back in RFP. The sad thing is that there are several that story fits.
• You blindly believe the RFP submissions. Solution providers realize that if they say yes to everything in an RFP, their chances of making the cut to the finalists and doing the live demos and POCs are much improved. Too often, the answers in RFPs are misleading and false. The functionality does not exist, or the solution provider believes they can build it on delivery. I have come into RFPs that have failed, and in reviewing them, I asked about the solutions I thought would be the ideal fit and found they were discredited as they did not answer the RFP as positively as the one that won the RFP (who misrepresented their capabilities in the RFP). I have even caught solution providers demoing competitor capabilities in RFPs; capabilities they did not have.
• You do not investigate what is meant by “no-code” solutions. Organizations want solutions that are easy to deploy and maintain and do not break on upgrades because of all the heavy customization. They desire agile solutions, what I call Agile GRC (GRC 4.0). So the world has moved to the marketing terms ‘low-code’ and ‘no-code,’ but these are not to be accepted blindly. Some low-code solutions are still very high-code solutions. And no-code means different things. I know no-code GRC solutions that are truly no-code but are also not agile or adaptable. They have a beautiful interface but can not be adapted to the organization’s GRC processes; the organization has to adjust its processes to how the solution was designed. However, there are no-code GRC solutions that are extremely agile and configurable to the organization’s needs. Careful understanding and inquiry are needed to determine the agility and configurability of so-called no-code GRC solutions.
• You fail to check client references adequately. Client references are challenging. Too often, the client reference is the decision maker that only has great things to say about how wise they were to choose this product over others. Those same decision-makers often speak on the solution’s webinars and conferences. They do not like to say negative things about the product. I ask them hard questions, like where the product has failed and where it has undelivered. They are hesitant to answer. I ask them the same question differently: what functionality/feature do they want to see delivered in the next release of the solution? They are more ready to answer this question, but what they are telling me is that it is not delivering today and is frustrating them. I then ask to speak to individuals on their team down in the weeds using the solution. I often get very different perspectives and views from those in the trenches when utilizing the solution. This is another example of why the client reference surveys of some analyst firms do not work; you cannot explore the truth and fiction.
• You fail to define strategy and process and think technology solves the problem. Technology is an enabler and delivers significant value, but only when there is a clear understanding of the strategy and process. I get frustrated when an organization calls me and says they just purchased GRC please come in and tell us how to do GRC. That is putting the cart before the horse. A clear understanding of strategy, process, and objectives should come before an RFP.
• You fail to understand your current and future state with a business case. To succeed in any GRC process (whether broad or focused), a clear and compelling business case is required. Organizations need to define their current state and process, what it is costing them, their ideal future state and the value/return it brings, and their roadmap to get to that future state involving strategy, process, information, and technology. Everything should be clearly documented and measured, empowering the RFP and selection process. When I work on business cases, I build them around the value angles of efficiency (time saved, money saved), effectiveness, resilience, and agility.
• You give preference to a solution already deployed or that one department wants. This happens time and time again. The organization has a broad vision of what it wants to achieve. Still, it either tries to do it with an existing solution being used that does not have the capabilities to deliver on the vision or goes with a solution that one department (such as IT with ITSM) desires that does not fit the broader vision. Too often, I see IT stepping in and saying it will only be this one solution they are using for other purposes when it is not always a good fit for the organization’s vision and requirements.
• You try to do everything in one GRC solution/platform. While I firmly believe there can be a core GRC platform to bring things together (as long as it is the right platform that meets the requirements), this does not mean this solution is the only solution. There is a place for best-of-breed GRC solutions that go deep in IT/cyber-risk, third-party risk, regulatory change, and other areas. A GRC strategy should be more about GRC architecture and not trying to force fit everything into one platform that does not do everything well but does do some things well.

Take heed of these cautions to maintain situational awareness and deliver on a successful GRC-related RFP. In other words, do not end up in a crash like I did on my bicycle.

I can go on and on, happy to chat about these and more on how to approach GRC-related RFPs. I have been in this space for 31 years, and 24 of those as an analyst. I was a top analyst and VP at Forrester Research for seven years and have been independent, competing against the big analyst firms for 17 years as a boutique. I can claim to have the longest history evaluating GRC-related solutions as I was the first to use the acronym GRC, model the GRC market, and compare solutions going back to February 2002.