The ‘Shalt Nots’ of GRC Implementations

In the current business climate—with unprecedented regulatory risk, complexity, and security threats—companies of all sizes rely heavily on governance, risk, and compliance software. In a perfect world, these solutions help an organization transition from manual processes to state-of-the-art controls, and provide insight into a firm’s risk profile and compliance needs.

Alas, it is not a perfect world.

There is no shortage of vendors and products. Choosing the wrong one can be disastrous. Just as problematic, however, is pairing a poor implementation strategy with even the best of solutions.

What’s at stake? Missteps can lead to employee revolts, cost overruns, delays, and ineffective controls where you can least afford them should regulators come knocking at your door.

We asked GRC experts to weigh in on what the most common implementation mistakes are.

They “boil the ocean.” With an approved budget in hand and a GRC implementation plan garnering top-level support, there may be an understandable urge to act quickly and comprehensively to make every dollar count. An overly ambitious approach, however, can prove counter-productive.

“Once they make the decision to invest in technology, they go overboard. They get funding and decide, ‘let’s do everything,’ from risk to compliance automation and incident response,” says Torsten George, global marketing executive for GRC software company Agiliance. Bringing too many functionalities online with too broad a user rollout are common mistakes that lead to an unfocused process and plenty of chaos. “That often backfires,” he says. “Do it step by step and don’t bite off more than you can chew.”

They don’t fully appreciate their needs. You may think you know what is needed from the new technology, but are those goals realistic?

“When people try to implement or update risk management within the organization, they often believe that the tool should adjust to their existing procedures and the processes that are already in place,” George says. “They are not necessarily seeing an opportunity to review their existing processes, evaluate if they are efficient or not, and tailor [the GRC implementation] toward best practices. Try not to be static and think the tool needs to adjust to your procedures.”

They take an “ivory tower” approach. “The people tasked with implementing risk management software often keep that responsibility to themselves and don’t want to bring anybody in too early,” George says. Unilateral decision making can be a crisis in waiting.

Early on, even in the vendor selection process, as many stakeholders as possible should be part of the process. “You want to get their buy-in early,” he says. “We have seen situations where a centralized decision was made, the tool was implemented, and you had end users who spent half their career creating spreadsheets, and implementing special formulas into these spreadsheets, that they had to throw out the window.”

Keeping in the loop those who will ultimately use the new tools will help quell internal opposition. “When you are implementing a GRC system, it might be the first time the organization has ever gone down this road,” adds Mitch Kraskin, CEO of Compliance Science, a provider of GRC solutions. “You might be asking stakeholders to do certain things they have never done before, such as attestations and certifications. Figure out how to get buy-in before you push it out so they don’t have an adverse reaction. You want them to be collaborative, understand why you are doing it, and why it is a benefit to the organization.”

“You are going to step into landmines you didn’t realize were there and want get them out of the way early. Make it manageable. You are going to find things you missed, no matter how good your project management team is.”
Mitch Kraskin, CEO, Compliance Science

Engaged with the process, a small group of early adopters “can become your fan club,” Kraskin says, suggesting that those GRC cheerleaders include employees who are respected by their peers and carry clout. This will “tamp down any adverse reactions to new technology, particularly those things that are part of a cultural shift.”

Another reason to have a manageable roll-out and employee buy-in is that problems will emerge and the company must be positioned to deal with them. “You are going to step into landmines you didn’t realize were there and want get them out of the way early,” Kraskin says. “Make it manageable. You are going to find things you missed, no matter how good your project management team is.”

They reduce workforce. A particular GRC vendor may boast of the many cost savings and efficiencies their wares can create. In fact, that pitch may focus on how the company can reap additional savings once now-unnecessary staff is trimmed from payroll. Think long and hard before pink-slipping all those mid-level clerical employees who grew accustomed to manual or semi-manual processes.

Kraskin suggests that these employees may bring considerable value to the company post-implementation. “You are going to end up saying, ‘Gee, I want people on my team who can do that work at a higher level using the system,” he says. “You may be able to get those people to go from paper shuffling to providing truly valuable analytical work under the new platform.”

A standard mistake is focusing almost exclusively on technology and process and not considering how people fit into the framework.

THE HEADACHE PILL OF GRC

What constitutes an effective GRC implementation? What are the common elements of both success stories and worst-case scenarios? Those questions guided recent research (“GRC Vendor Implementation Success Strategies, “Contributors to GRC Implementation Success: Avoiding the Worst-Case Scenario”) by David Houlihan, principal analyst at Blue Hill Research.
The studies looked at new GRC projects at large enterprises with a median annual revenue of approximately $3.5 billion and median employee count of approximately 5,700 employees. Typically, “best-case” implementations: took three to four months; cost between $75,000 to $180,000; had high end-user satisfaction; placed an emphasis on business objectives and needs; focused planning on process change required; conducted an assessment of value at the conclusion of each stage; emphasized scalability; balanced both out-of-the-box and configurable capabilities; and restricted the scope to immediate needs.
Worst-case implementations saw organizations give relatively little consideration to future business objectives. They were also reactive, responding to upcoming regulatory change, increased agency enforcement, or high-profile exposures or breaches suffered by peers. “This posture can limit the value provided or the shelf life of the solution as point needs dissipate or change over time,” Houlihan wrote.
Sub-par executions also involved attempts to implement most or all of the desired functionality at once, or to roll out the solution to users in one effort. “Big bang approaches are not necessarily harmful, in and of themselves,” the study says. “However, when these approaches are also accompanied by lack of attention to underlying business needs or enterprise IT considerations, the consequence will be an unfocused and chaotic process.”
Discussing the reports, Houlihan has advice for GRC vendors: “They don’t have to sell the world. They can sell a smaller story of implementation.”
“This isn’t necessarily an organizational transformation story; it is an analgesic. It is headache relief,” is how he describes most successful GRC efforts. Accept new capabilities for what they are: a toolset, not necessarily disruptive or life-changing technology.
“Do all the right things with enterprise technology, but lower the expectations and nail it to something that is tangible,” Houlihan says. “Talk about the business objectives. Why do we want this? Why do we want compliance to be more efficient? What is our risk tolerance? Where do we see pressure from regulators coming from? GRC should direct those things and the underlying business practices.”
—Joe Mont

Large organizations, when confronted by crisis, will often react by “throwing a whole bunch of technology at the problem and spending a bunch of money to hire outside consultants,“ says Henry Balani, head of Innovation at Accuity, a financial services consultancy. “They certainly don’t focus on the people. You have consultants come in, do their thing, and guess what? Six months later everything falls apart again. In order to have a successful GRC program you need to have people on board who are part of the organization. There is always a resistance to having outsiders coming in to tell you what to do when, after they leave, you are left holding the bag.“

They overdo customization. A challenge that goes hand-in-hand with any GRC implementation or upgrade is how much to rely on a vendor’s out-of-the-box solution, versus the need for customization to better mesh with business needs.

“If you go with lots of customization, you are creating a very rigid framework. Later on, if your business changes and you want to adjust for them, it will be costly and time consuming,” George says, recommending that the focus needs to instead be on configuration, without touching the underlying coding as much as possible.

A careful evaluation of the embedded best practices, templates, and data models included with an out-of-the box product may, in fact, show that your unique challenges aren’t that unusual or unheard of after all.

They don’t evaluate specific data needs. GRC should never be a one-size-fits-all solution, and specific data needs cannot be an afterthought. Companies cannot underestimate the importance of understanding what is unique about their needs and understand the nature of their data.

“The first step is self-realization. A lot of firms start with a view of an ideal program that doesn’t take into account that the hand they are dealt is one of data fragmentation, the complexity of new and legacy systems, and disparate workforces relying on ‘bring your own device’ and ‘bring your own cloud’ solutions,” says Harald Collet, global head of Bloomberg Vault. “If your GRC program doesn’t take into account the status quo and tries to turn the clock back, you end up with an end-user revolt on your hands.”

Collet sees merit in piecemeal implementations, rather than attempting too much, too fast. “For smaller firms, an across-the-board approach might be fine because you only deal with hundreds of employees and have integrated business units,” he says. “In a firm that has gone through an amalgamation of divestitures and acquisitions, and has a large workforce, the complexity of the business means it may be much wiser to pick a single thing and build on that success over time.”

Start with a single policy against a single group of employees, he suggests. This will help the firm avoid the risk of being mired in the process creating taxonomies and overly complicated surveillance review policies. Creating separate “buckets” of employees, regulated and unregulated, allows the roll-out to apply policies in a less granular way initially, adding that specificity over time as false positives and the exceptions needed under a specific policy are better understood.

The worst case scenario that may unfold without such an approach: hundreds of policies, each with a thousand or more exceptions a day. “You will be in a very bad place and may need to dial back your entire program,” Collet says.

They overlook synergies. A lack of central coordination allows opportunities for synergies to be completely missed. With similar regulatory initiatives emerging in various countries, a company benefits from breaking down communication silos.

“In the United States you may have a compliance officer implementing a system for trade reconstruction under the Dodd-Frank Act. Meanwhile, in London, a different compliance team in a different line of business is implementing an identical solution for trade reconstruction under the MiFID 2 law [for Europe’s capital markets],” Collet says. “Sometimes, because they are not communicating, it is only through outside parties or a consultancy that they realize they can connect the dots.” Until that realization, “cost and operating synergies, and a better risk posture, are lost because you are not communicating internally at the firm.”