There are far too many accounts of failed GRC projects, particularly in moving to a new system or evolving an existing platform to streamline and modernize governance. The idea of simply adding a GRC module to a large enterprise software system is enticing, but these are often the cases with the highest rate of a project being jettisoned. Even despite best intentions and a “failure is not an option” posture, GRC implementations can be unwieldy and notoriously difficult. Although there are many causes for unsuccessful GRC projects, there are four reasons that are most common and predominant. Knowing these in advance may make all the difference between success and a back-to-the-drawing board “plan B” or “plan C.”

Leveraging Existing Technology

The first reason stems from the notion that extending a general platform is advantageous because a company can deal with an incumbent preferred vendor to gain GRC as an incremental add-on. Large workflow, ERP and financial systems often offer a GRC module, sometimes for little additional initial cost. One-stop shopping and keeping to a preferred vendor has been an attraction since at least the dominance of IBM in the earlier days of computing, and later with large software vendors, such as Oracle and SAP. Today, the attraction is still strong, perhaps even influenced by personal shopping habits, such as the mentality of buying everything from Amazon.

The perceived benefits of adding to monolithic enterprise software and one-stop shopping include having a trusted vendor, eliminating the need to qualify a new vendor, incurring a smaller incremental cost, having personnel already familiar with using the platform and having security and IT teams already familiar with operating and protecting it. While some of these factors are true, some are rarely reality. User familiarity with a platform and knowing some of the universal functionality does not translate into knowing how to use an added GRC module. For the most part, learning a GRC module isn’t much different than learning a standalone GRC solution. In some cases, it may be more difficult since one may struggle with how to make a generalized function meet specific needs. Lower cost may seem attractive, but often, companies end up paying more for an added module than for a bespoke GRC system. The low or no-cost introductory period for a module will give way to higher-priced licensing over time, usually beginning in the second year.

The Hidden Cost Factor

A second major reason for abandoned or failed GRC projects is a combination of rigidity and hidden costs. A lack of flexibility either creates the need to find or create modifications to the application or requires additional procedural work on the part of a GRC team. The related hidden costs include customizations, workarounds, and consulting to make a more generalized GRC module accommodate an organization’s true needs. This expense cannot be overstated. The costs and difficulty can often be as extreme as what one would go through in making a square peg fit into a round hole.

Lack of Automation

A third major reason for GRC project failure is a lack of automation and streamlining to reduce workloads on GRC teams. An inability of the GRC solution to automatically ingest laws, rules and regulations and create policies rather than fully relying on manual processes is a prime example. It is increasingly more difficult for organizations to keep current with the number of new and changed laws and regulations while also typically being understaffed and overworked. With the advances of AI and GPT-3 in particular, not having this automated capability will prove an increasing disadvantage, until it finally becomes untenable. In addition, the lack of a robust content library for legal conventions, templates or reports, or the lack of ability to easily integrate with regulatory content sources, put organizations at a disadvantage and require considerably more work from their practitioners.

The Turnover Factor and Organizational Adoption

A fourth cause of failure is when a GRC solution does not fit the needs and workstyles of the organization or is too difficult to use. One common aspect of this is when the solution is made by one CISO or compliance officer who may not stay in their job for long and it becomes inherited by a person’s replacement. If the GRC solution is inherently incapable of meeting the requirements and expectations of the next CISO or compliance officer, it may ultimately be abandoned in favor of something else, particularly if the implementation occurs during the transition from one executive to the next. Having a flexible, purpose-built GRC solution that can accommodate various work styles, priorities, team composition and other factors can obviate the need to switch to some other solution.

GRC projects fail far too often. How failure can be avoided or turned around without unsustainable heroism by a few and the excessive expenditure of time, resources and money should be thoroughly considered. Organizations should actively plan for success rather than tacitly succumb to failure.

Image source: Mahdi Bafande (Unsplash license) https://unsplash.com/photos/2HW1I7sMbs8