Learning from others: Improve the chances of a successful GRC implementation

Eileen A Fahey, CFA Chief Risk Officer, Fitch Group

Software implementation projects are always operationally challenging and financially scrutinized. Most organizations have experiences of both successful and unsuccessful implementations and the latter are often highlighted as cautionary tales for better oversight and due diligence on future projects. Implementations of GRC software often span across first, second and third lines of defense of operational controls. As such, the breadth of a GRC implementation makes it one of the more challenging and high profile within a firm. This increases the pressure to deliver a timely and successful implementation with executive management acceptance and goodwill.

The goal of this article is to share a few tips to increase the likelihood of a successful GRC implementation. Each corporate GRC implementation will have different challenges. It is not a step by step guide but instead discusses several aspects to avoid some common frustrations. We hope to increase the likelihood of success by understanding the journey of others.

There are certain elements of consistency for the selection and implementation phases which aid in the decision-making. They include:

• defined and dedicated internal resources

• plans which include similar documentation approaches, agreed milestones, periodic stakeholder meetings, and measures of success.

These guide the way to an overall successful implementation. Communication and engagement with stakeholders and partners are key throughout as is the understanding that it will be a lot of hard work and that not everything will go right!

The Selection Phase: Define the Key Attributes

Ideally, key stakeholders will identify the need and outcomes intended from the application to aid the selection of the optimal GRC system. A successful GRC system allows independent risk functions such as compliance, risk and audit functions to use common risk, controls, testing libraries and consistent reporting within the organizational hierarchy. Occasional users are often more important to the success such as auditees responding to an audit issue or line management completing a risk control self-assessment. They will need clarity and easy user interfaces. Finally, data and reporting will be used by all levels of management. Virtually the whole organization has a vested interest in a successful implementation of a value adding GRC system.

There are external product selection tools and research that can help determine which type of GRC application is appropriate. It is helpful to develop initial relationships with a number of GRC vendors to develop an understanding of the market, the product and whether the service will match expectations. A high-level demonstration of the product to the project sponsor/ manager allows an early decision as to which products will or will not work for the organisation. For example, some organizations will want an ‘off the shelf’ package rather than a product that will require considerable customization. The latter is likely to be more expensive and require more resource which may be appropriate for large or complex companies. It is a good idea to speak with a number of customers and review external research around the products and their implementation. There are excellent information sources that provide invaluable insight on vendors and implementations (both successful and unsuccessful).

Key Stakeholders Invited to Participate

A small number of products can then be selected for demonstration to all key stakeholders. The vendor should take the time to understand the expectations for the demonstration and tailor the demonstration for the executive audience. In addition to daily GRC users, other department heads should remain engaged such as senior heads from Operations, Finance and IT. These department heads will likely be occasional users but are often the most critical of a system that might be too difficult to use.

While counter intuitive, senior/executive skeptics of the GRC journey should also be included in the demonstrations. There will be less opposition to an investment approval if naysayers can be convinced of the value early in the project proposals. GRC vendors should be well versed in hearing and responding to dissenting comments and should have solutions based on years of experience.

IT engagement is critical to evaluate the technological quality, service and reliability of the product together with the prospects for a smooth integration with other applications and within the broader corporate IT environment. IT resources will also likely be involved in many phases of the implementation process.

Following vendor presentations, stakeholders should independently select those products for more detailed due diligence. As noted earlier, including the stakeholders in this stage of vendor selection creates buy in and commitment to both the value of moving forward with a GRC system and the selected GRC product.

The small number of selected vendors should provide detailed functional demonstrations and preferably test cases of the most critical aspects of the systems to control departments. The ability to see how the GRC system is able to replicate and improve existing manual processes is a key point such as the completion of a Risk Control Self-Assessment. The vendor should be able to create an instance of the application which can use the company’s example data to demonstrate its functionality. With each stage of the selection process, the number of vendors should be reduced – it is likely by this stage there are two or three preferred vendors remaining.

Sand Box Testing

The next stage for preferred vendors is most often testing the GRC application and parallel discussions with the vendor around contracts including service level agreements and costs.

• The vendor should be requested to provide a ‘sand box’ – effectively a mockup of the application in a separate IT environment. The sand box should encompass the key elements of the product features.

• As noted above, the demonstration should include the most important functions of the system for your firm. This helps the selection of the optimal GRC system. And, will help prioritize, identify customization requirements and set expectations for the practicality of the system. This will also provide awareness of the key elements that stakeholders can’t live without, the ease of that function and potentially identify dependencies across applications.

• Either example or real data could be used in this environment and the vendor should upload this data to the sand box. Depending on the nature of the data, it is likely that a Non-Disclosure Agreement is in place before this stage to protect both parties.

o A small number of line managers from each of the control departments will use the sand box to test the functionality of the system and in particular test that manual processes can be replicated by the application. It is likely the vendor will need to provide real time support to help new users with the application.

o The availability and quality of the GRC vendor’s support at this critical stage may enable the company to take a view on the likely support and capability of the vendor post acquisition.

Each organization needs to consider the most practical way forward with the decision of customization. While ‘off the shelf’ is the simplest and likely cheapest, companies need to asses s expectations of a system that works for them rather than them changing how they work to accommodate the system. Customization will be more expensive and impact future upgrade capabilities. Most organizations are likely to require some customization to tailor the product to their needs.

During sandbox evaluations, commercial terms need to be discussed and proposed. There is wide variance between vendors on both the costs of the product and the potential costs for implementation. Some vendors will be able to provide a full project management service (in conjunction with company resource). Others may not or alternatively suggest a potential implementation partner (such as an accounting firm).

Seek External Input from current and past users.

In parallel, request the vendor to provide customer references. References selected should be as close to the company’s profile as possible. Discussing the GRC product with current customers will provide real life experience of the product, implementation challenges, the value (or not) of customization, unexpected costs and how the vendor performs once the deal is finalized.

Ideally, buyers will speak with a customer who had an unsuccessful experience – the lessons learned and their challenges could be of critical importance on the decision to go ahead or to adopt a different strategy. Most of the larger GRC vendors either host their own conferences and/or participate in broader GRC conferences. As a potential customer, you should attend these events where happy and sometimes disgruntled customers will provide you with additional commentary on their GRC journey.

Contracts and Service Level Agreements should be reviewed and approved by business managers, the legal department, procurement, IT including security reviews as necessary, inclusion in disaster recovery, and efficiency of the system. Final decisions will be made by the investment committee, finance committee and other considerations.

Service Level Agreements (SLA)

Carefully construct SLAs to include expectations such as delivery timelines, in house or offshore resource provisions, implementation training and system specifications and monitoring. Escalation procedures must be included to ensure appropriate attention is provided and available from the Vendor. Some key elements of an SLA include:

• Maintenance annex modifications during the project as adjustments are made.
• Schedule of payments that match implementation phases and include certification;
• Verification of completed testing;
• Escalation procedures;
• Up time requirements;
• A break out clause.

Once all agreements are signed and decisions made, it is time to enter the implementation phase. Implementations should start small, then scale after initial success. User Acceptance Testing (UAT) should be included in implementation plans. The creation of incremental milestones will limit internal resource commitments until the program is running as expected. This might isolate and identify system issues sooner. Many systems are modular and best considered in increments rather than an all or nothing implementation. Finding hiccups in one module will reduce implementation time for others as test phases can iron out bugs for others.

Initial testing should identify whether workflows such as those for acknowledgements and approvals, flow easily for the occasional or infrequent user.

Finally, the system will need socialization and 100% adoption by primary intended users. The training of super users can ease adoption with experts able to support minor implementation pains. Implement and use the software for at least 12 months to understand system functionality and judge system benefits. Keep abreast of vendor enhancements but don’t seek upgrades until implementation is complete and there is broad acceptance of the system.