Despite great strides in governance, risk and compliance (GRC) software, it’s unlikely we will ever see a single plug-and-play software solution that satisfies all the demands of multidisciplinary GRC. Instead, GRC leaders who want to make real, practical strides toward a multidisciplinary GRC environment that encourages broad participation and delivers measurable ROI need to take a well-thought-out, iterative approach.
This approach will likely include multiple technologies. It should also include buy-in from all the key assurance stakeholders, as well as a balanced approach to defining and managing the scope and program elements and developing a common GRC language across the organization.
The following program realities and suggestions are based on my experience with hundreds of GRC program assessments and technology implementations.
First, let’s accept that multidisciplinary GRC is difficult. If your organization is like most, your assurance groups already have their own processes in place. If you try to impose a monolithic, top-down GRC solution on all these groups, you will likely meet with frustration, resistance and eventual non-compliance. This isn’t surprising, because there’s a good chance that a preconfigured technology chosen by a single team won’t easily align with the methodologies that various groups use. Gaining feedback from multiple groups may be a bit more time consuming, but with the right approach, it will lead to a better outcome.
Before starting anything, it is imperative to get strong executive sponsorship. This is the only way to ensure funding for what will be a long-term project, get the necessary buy-in from the various assurance groups and maintain the high-profile status the project needs to survive inevitable challenges. Getting executive buy-in should be followed by stakeholder buy-in, including from the lines of business, which are crucial for successfully operationalizing the program.
Understanding and defining the scope of your GRC program is an important part of determining which stakeholders should be involved. Consider who the consumers, providers and users of GRC information are. The end users of your GRC system will likely weigh in more heavily than consumers and providers of GRC data.
Still, though, your GRC implementation may be dependent on accessing information from providers of data (e.g., regulations from your legal group) or delivering data to other consumers (e.g., a list of issues to a central analytics team). Only with the support of all the key stakeholders can you build a program that strikes the all-important balance between consistency and rationalization across the company on one side and support for unique stakeholder requirements on the other. Just as important, groups that have input on a decision are more likely to embrace the result, even if it isn’t always ideal.
Another key to overcoming the inherent messiness of developing a multidisciplinary GRC program is the creation of a strong program management organization. This is different than a purely operational-based project management organization. A project manager, who typically lacks subject-matter expertise, will struggle to support each group’s wants, leading to paralysis. Only a program manager capable of understanding and rationalizing the various stakeholder requirements can construct a harmonized approach that balances unique demands with corporate-level goals.
A successful multidisciplinary GRC also requires developing a common language across the various taxonomies that different assurance groups use for their risks and controls. If you distinguish between these taxonomies and the actual content – which is often more similar in nature than the specific language suggests – you can work toward a standards-based model that allows different risks and controls to be linked back to a set of standards that support global objectives. One key here is that content is king! Perfecting a framework without reviewing real data is a recipe for paralysis. Put together a sound conceptual framework. Get data from applicable stakeholders. And refine your framework.
It’s also important, however, not to make 100 percent rationalization of language a prerequisite of a technology implementation. Instead, take an iterative approach. Start by rationalizing risk/control sets as much as possible prior to implementation, but don’t let yourself get bogged down. And be sure to perform a thorough analysis of the available content. This is the only way to create a useful taxonomy that can be successfully rationalized over time. Then move forward and let your teams work with the actual data, allowing effective rationalization to evolve.
Only after moving through this process should you fully configure the system, and even then, allow the taxonomy to evolve over time to fit the current needs of the organization. Planning for dynamic change versus hoping for a static model is the only way to work toward a multidisciplinary GRC environment that can be maintained over time.
The final key element of a successful approach to multidisciplinary GRC is scope management – that is, getting the right balance between over-engineering the solution on the one hand and understanding the minimal, critical-path elements on the other. For example, if you over-specify reporting requirements up-front, you may be wasting a lot of time – many of those reports will go unused, and new requirements will arise. Instead, specify only the most important reports at the outset, then add more reports over time.
The key to this approach is defining a minimal viable product that identifies the program elements that must be deployed immediately and aligns these elements with your internal delivery capabilities. This way, you can create a supportable roadmap that reduces implementation conflicts, allows for proper budgeting and timing, enables the reporting of successful milestones, and lets the implementation team respond to feedback in order to make the multidisciplinary GRC program even better.
The above suggestions and approaches will enable organizations to work iteratively through the inherently messy process of developing a successful, rationalized multidisciplinary GRC program that can evolve over time. With executive buy-in, a thoughtful approach to scope management, a common language and a strong program manager, a multidisciplinary GRC program can achieve the right balance between the corporate-level desire for consistency and the operational-level need for flexibility.
