THANK YOU FOR SUBSCRIBING
Software implementations are operationally challenging and financially scrutinized. Definitions of success vary widely. Implementing GRC software spans 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 article shares a few tips to reduce pain points to improve the likelihood of a successful implementation. It is by no means a step by step guide but highlights some aspects which result in common frustrations.
Elements of consistency in the selection and implementation phases aid in decision-making. They include:
• defined and dedicated internal resources sized to meet project skills and implementation deadlines
• planning and documentation of implementation phases to include milestones, periodic stakeholder meetings, and defined measures of success.
• communication and engagement with stakeholders and executives are key along with understanding that hard work and hiccups are expected!
Selection Phase: Define Key Attributes All management lines have a vested interest in a successful GRC implementation. Exploring a variety of users will aid in identifying system expectations designed to reduce pain points.
Optimal GRC systems provide risk functions such as compliance, operational risk and audit functions to use common risks, controls, testing libraries and consistent reporting across an organizational hierarchy. Selection committees may be too narrowly focused as success for the occasional user, is dependent on identifying the largest pain points, providing easy user interfaces and allowing creation of dashboards accurately depicting status using KRIs.
Selection committees ideally include:
• A few first line managers responding to findings, authorizing corrective action plans, noting completed tasks;
• Product leaders to be selected from Internal auditors, compliance testers, information security and operational risk managers; and
• IT staff to assess compatibility, security, capacity and reliability.
• An executive sponsor provides support and perspective on KRIs dashboards and likely less opposition to the investment required.
Form a smaller selection committee for investigation and development of relationships with several GRC vendors. The selection committee is assigned to:
• Assess multiple product advantages and disadvantages
• Propose system prioritizations and minimum requirements;
• Present recommendations to the larger group;
• Propose two to three systems for detailed exploration;
• Recommend expectations for degrees of customization;
• Document decisions and next steps.
Establishing resource parameters in a broad working group help move decisions forward. An understanding of costs including the need or desire of an ‘off the shelf’ product compared to customized solutions will be influenced by an organization’s size, geographic breadth, regulatory structure and risk appetite and its desire to improve operational risks assessments of internal controls.
Set Clear Expectations for Vendors Once system specifications are identified and prioritized, vendor testing can begin. After the initial review of GRC systems, the working group should narrow the vendor pool to two or three vendors. These vendors should be willing to provide a ‘sand box’ environment – an application shell. The sand box provides users a test environment preferably including the identified features.
• Sand box testing can help the team formulate a decision but also guide a project management plan, prioritization for implementation and affirms the optimal choice. This improves system awareness such as user interface, adaptability and may identify data or application dependencies.
• Real or sample data can be used in the sandbox. Vendors should upload data to avoid wasting time. In this stage, a NonDisclosure Agreement should be signed to protect both parties.
• The availability and quality of the GRC vendor’s support should be assessed and enables the company to assess the likely support and capability of the vendor post acquisition.
• A small number of line managers from each of the control departments will test the functionality of the sand box. Particular attention should be strengths of the system and its ability to improve efficiencies
. • The sand box may provide an indication of customization needs. ‘Off the shelf’ is simplest. Customization is generally more expensive upfront, impacts ability and willingness of future upgrades but could be an optimal system.
Commercial terms should be discussed and proposed. All implementation, ongoing service and system support costs should be included. Vendor assistance varies widely with some able to provide a full project management service. Others may suggest implementation partners which are likely an additional cost.
Talk to Current and preferably Former Customers
Request multiple recommendations from the vendor. References selected should be organizations with profiles as close to the company’s as possible. Discussing product and implementation support with current customers in multiple stages of implementation should provide thought provoking circumstances, implementation challenges, the value (or not) of customization, unexpected costs and a view as to vendor performance.
Ideally, there will customers with a variety of experiences. GRC software companies often manage conferences to potential and existing customers. Working group participation in conferences can be beneficial albeit generally with a positive selection bias. Lessons learned will be of important if they are shared. As a potential customer, you should attend several events and join conversations on the system effectiveness.
Importance of Clarity in Service
Level Agreements (SLA) Service Level Agreements are a critical part of any software implementation. Approvals of business managers, the legal department, procurement, IT assessments of security, compatibility, reliability and disaster recovery support Carefully construct SLAs to include standards for delivery timelines, inhouse or offshore resource provisions, implementation training, system.
specifications and service monitoring. Escalation procedures should be included to ensure appropriate attention is provided and available. Some elements of an SLA should include:
• 1Maintenanceannex modifications during the project as adjustments are made.
• Schedule of payments that match implementation phases and include certification;
• Verification of completed testing;
• Escalation procedures during implementation and once business is ‘usual’;
• Up time and response time requirements;
• A break out clause.
Finally, it will be time to implement. Implementations should start small, then scale after initial successes in certain modules. Many GRC systems are modular and best considered in increments rather than an all or nothing implementation. User Acceptance Testing (UAT) should be included in all phases of implementation. The SLA should specify standards of when implementation is completed and business as usual service begins. Incremental milestones of approval should allocate both internal and external resources sufficiently. This will isolate and identify system issues sooner. Finding hiccups in one module may reduce implementation time for others as test phases resolve bugs. Testing should provide positive reinforcement that the right software was purchased.
Implement and use the software for at least 12 months to understand system functionality and judge system benefits. Keep abreast of vendorenhancements but don’t seek upgrades until implementation is complete and there is broad acceptance of the system. Training of super users can ease adoption with internal experts capable of supporting occasional users.