Thriving in the GRC Trenches

3 Multidisciplinary Lessons Learned

GRC leaders shouldn’t expect to find an off-the-shelf GRC solution that truly meets their needs. Instead, they should focus on adopting a balanced, iterative approach, likely one involving a variety of technology schemes that include practical, best-practice steps to encourage multiple assurance stakeholders to recognize their shared goals and frameworks while also supporting the unique needs of each group.

Organizations reviewing marketing materials and selecting governance, risk and compliance (GRC) solutions often come away with the impression that they can use plug-and-play technology to manage their multidisciplinary GRC program. However, although many strong technologies are available for GRC, “out-of-the box GRC” simply does not exist. Even single-discipline solutions need some configuration to meet client-specific requirements.

Add to this the complexity of multiple groups and typical GRC program fragmentation, and it becomes essential to avoid holding out hope that a single turnkey solution will do everything required. Instead, GRC leaders should focus on adopting a balanced, iterative approach, likely one involving a variety of technology schemes that include practical, best-practice steps to encourage multiple assurance stakeholders to recognize their shared goals and frameworks while also supporting the unique needs of each group.

Having participated in or supported hundreds of GRC implementations, we have found that a successful multidisciplinary GRC implementation starts with heeding the following three program realities:

1. It’s Difficult – But Definitely Achievable

By their nature, assurance groups have their own processes in place, typically based on how they have successfully run their groups for years or how they did so at other organizations. Some organizations seek to eliminate this natural complexity by imposing a monolithic, top-down GRC solution on all assurance groups. This approach, however, is fraught with peril. A technology can only support a program; it is not the program itself. A good motto to heed is “Methodology first, technology second.”

Besides, there is no guarantee that the technology a single team or the IT function chooses will align with the methodologies the various assurance groups use, especially if the solution is initially over-configured. When an unwieldy, over-configured technology is imposed on an assurance group, the group will tend to ignore or work around the technology or implement it in a way that undercuts its effectiveness.

It is far better to accept that satisfying the needs of multiple assurance groups will be inherently messy and difficult, but that there are effective ways to approach and work through this quagmire. First, ensure strong executive sponsorship. A multidisciplinary GRC program may be deemed essential, but that does not guarantee a sufficient long-term investment of money and resources. Further, without strong sponsorship from the C-suite, it will be more difficult to obtain buy-in from the various assurance groups, and overall, the program will not be able to maintain the high organizational profile it must have to progress through the inevitable challenges.

Next, obtain buy-in from all key stakeholders, including the lines of business (LOBs). Ultimately, GRC efforts involve the assurance and audit functions working well with the LOBs to manage risk, but the LOBs are extremely busy executing their day-to-day activities. Thus, obtaining their buy-in to the approach – and to the level of effort required to manage both the business and operational risks – is crucial.

When multiple stakeholders feed into, update and build a GRC program, it becomes possible to strike a balance between consistency and rationalization across the company on the one side and support for unique stakeholder requirements on the other. Further, when all the groups know they have been represented, they are more likely to accept some imperfection for the greater good, instead of simply ignoring or working around the solution out of frustration.

Finally, develop a strong program management organization (PMO). An operational-based PMO simply is not enough. There must also be a strong program manager. Too often, multidisciplinary projects are given a project manager responsible for managing tasks instead of a program manager with the appropriate subject-matter expertise to understand and rationalize multi-stakeholder requirements and then construct a harmonized corporate approach.

With only a project manager, paralysis tends to ensue as the project team struggles to support every group requirement – or the team pushes ahead, creating unrationalized clutter. Only a strong program manager with the necessary expertise will be able to achieve the balance between unique stakeholder requirements and corporate-level goals.

2. A Common Language Is Key

Assurance groups tend to have their own taxonomies for their risks and controls, creating a multidisciplinary Tower of Babel. By distinguishing between these taxonomies and the actual content, which is often similar among different groups, organizations can develop a standards-based model that allows underlying risks and controls, regardless of whether they’re named differently among different groups, to be linked back to a set of standards that support enterprise objectives.

This model allows stakeholder groups to build out relevant, specific risks and controls while still being able to report back into these enterprise standards. Notably, creating this model requires an iterative approach, which also allows the supporting technology to work toward rationalization over time instead of making 100 percent rationalization a prerequisite of a technology implementation. Certainly, rationalizing risk/control sets as much as possible prior to implementation can eliminate some rework, but it should never be allowed to create paralysis. The key, once again, is striking the right balance.

Many organizations spend far too much time up front trying to work out a single taxonomy, only to become hung up on abstractions, including word choice to describe common elements, data relationships, data models, etc. While it is critical to think through the taxonomy before embarking on the GRC effort to avoid a spaghetti implementation, it is equally critical to move quickly beyond the abstractions and let teams roll up their sleeves and get to the actual data. Too often, organizations attempt to perfect a taxonomy before building out their content set. However, the latter can inform the former, as analyzing patterns in the content set leads to reciprocal insights with respect to the taxonomy.

The initial strategy should be to develop a preliminary taxonomy, analyze actual data and then adjust the taxonomy. Only then should the system be configured. Even with this, the taxonomy should be allowed to evolve over time, establishing the most appropriate fit for the current requirements of the organization. Some rework is fine if it means the organization can make solid progress toward a unified, multidisciplinary approach. Definitely start with a plan and with a good foundational taxonomy that has broad-level buy-in. However, don’t let perfection of this taxonomy paralyze efforts to develop the requisite content needed to initialize the GRC program and implementation.

3. Scope Management Is Essential

To get on the road to a successful multidisciplinary GRC system, organizations must establish the right balance between ensuring critical path elements are in place on the one hand, and over-engineering the solution on the other. For example, while it is essential to design the GRC system with an eye toward the desired output, over-specifying reporting requirements up front can be a waste of time, as some of the reports will likely go unused, while new requirements will certainly arise. The goal is to be able to accomplish the most important tasks – such as being able to issue the most critical reports – right away, then improve the implementation over time.

Similarly, watch out for automating business rules where the exception becomes the rule. Once again, it’s about the data. The less data the organization has with which to initialize the system, the less confident it should feel about imposing validation rules, system calculations or business rules that may become invalid once patterns in the actual data are analyzed. However, if the organization has substantive data or, better yet, experience from a legacy system that has created growing challenges, then automation can definitely drive efficiency.

Start by defining what constitutes the minimal viable product (MVP). This is essential because it will dictate the critical-path elements that must be deployed immediately. Many organizations struggle to implement enterprise GRC not because the systems can’t handle it, but because there is no defined roadmap for onboarding new disciplines. And because there is no defined roadmap, schedules are not aligned with IT configuration windows so that one group’s configurations do not adversely impact another’s, once again leading to project paralysis.

Starting with an MVP approach not only prevents paralysis, but also leads to a better end product. By budgeting properly for the required follow-on investments in the GRC effort, the organization will be able to respond to feedback along the way to develop approaches that make the GRC program more efficient while also producing more useful information.

Balance Is the Key

In each lesson learned, the key is to strike a balance between the needs of each assurance group and the organization as a whole. By ensuring representation from all groups while working iteratively toward a common language, a PMO led by a strong program manager can navigate complexity, keep the top-line goals of the organization always in sight, accommodate individual groups as necessary and maintain the goodwill of all the stakeholders. This way, over time, a successful, rationalized multidisciplinary GRC program can evolve.