Moving from strategic planning to GRC implementation planning, Blue Hill Research found similar trends in how organizations experiencing Worst-Case GRC implementations overlooked key perspectives, primarily those of IT leadership. Additionally, Blue Hill Research found a preference for big bang deployment strategies with the intent to put all planned functionality in place at once.
Largely as a consequence of its youth, the roles most directly supported by GRC, financial and operational risk management, compliance management, and even CISOs often don’t have much experience with enterprise platform implementations compared to their peers in other areas of the organization. This means that key questions related to the success of the implementation, such as the fit of the solution into the rest of the enterprise infrastructure, or how the solution’s architecture might limit its usefulness or impact the deployment process, can be overlooked.
To this end, Blue Hill Research found that organizations experiencing Worst-Case GRC implementations involved IT stakeholders primarily in support of implementation execution, often after decisions had been set, forgoing the opportunity to consider technical factors affecting the success of the implementation. Rather, IT is often left to coordinate with the vendor and outside consultants to “make it work.” Even where IT has the skills needed to overcome the resulting obstacles, avoidable delays and costs result while workarounds are developed. By contrast, where organizations experienced Best-Case implementations, Blue Hill Research found that they largely involved IT in solution evaluation and planning stages. This permits earlier identification of potential issues which can impact solution selection and deployment plans, ultimately serving to avoid obstacles before they can occur.
“It looked easy on the front end to do what we wanted, but no one looked at the architecture. Doing what we wanted required a lot of complicated programming and workarounds and cowboy patches to get there. We still have to do manual data scrubs because we couldn’t get the integration with other systems to work.”
Solution Engineer
Insurance Provider
In terms of the implementation strategy itself, Blue Hill Research found that Worst-Case GRC implementations 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. 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. Even in the best of circumstances, big bang approaches mean that a lot of things have to take place at once as stakeholders attempt to coordinate needs and dependencies between tasks. Working out these processes can create additional delays and costs, as well as add to the difficulty of showing clear value from the implementation.
Organizations experiencing Best-Case implementations may have operated with larger business visions and expectations for the project, but tended to proceed through implementation in smaller stages. Individual implementation components differed and could be tied to a particular case, set of capabilities, regulation or standard, or user base or location. In all cases, the underlying “start small and scale” strategy helped keep the implementation manageable.
Due to the resulting shorter cycles to putting live users on the platform, these organizations also reported shorter time to value, often while other phases of implementation were still pending. This helped the organizations test the solution in the field, while reducing the consequences of missteps. This also contributed to the efficacy of future stages, while helping the organization to show value and build support for the solution, often tied to the greater levels of satisfaction indicated.
“One thing I wish I had known: the vendor we selected is heavy in SQL, but we’re mostly an Oracle shop. It didn’t occur to us during selection, so we had some problems initially when we found we had to do a conversion to host the product internally.”
VP of Compliance
Utilities Provider
Technical Deployment: The Costs of Customization
Differences in the organizations’ approaches in technical needs assessment and deployment were partially a consequence of choices made in prior steps, such as the relative involvement of IT and the degree of focus on business enablement. Blue Hill Research identified further contributors to implementation effectiveness in the amount of solution customization required and the scope of organizational needs that the organization considered in deployment.
The first of these factors, and often the one with the most direct impact on the cost and time required in the implementation, was the degree of customization involved in the implementation. Organizations experiencing Worst-Case implementations tended to make judicious use of customization, or hard-coding of the solution by software engineers, to adapt the GRC solution for its use. In part, this is a consequence of the solution architecture involved, as limitations in the software framework can leave customization as the only option to make it fit organizational needs.
It is also a consequence of the organization’s demand for precise tailoring to current needs. Failure to adequately assess the effectiveness or business impact of supported processes and data management needs, in particular, can lead to over-engineering of the solution in ways that unnecessarily prolong the implementation. Depending on the circumstances, some solution customization may be unavoidable. However, where it proceeds unnecessarily, it can insert excessive cost and time delay in the implementation. High levels of customization can have consequences downstream in the solution lifecycle as well. Heavily customized solutions become very rigid, meaning that changing the solution to fit future needs or simply upgrading to new versions of the software, either cannot happen or require additional rounds of customization to change the solution. Similar issues were identified by organizations suffering Worst-Case scenarios, as a consequence of these organizations’ tendency to focus on present-state needs, rather than the long-term business enablement or the potential for change in underlying requirements.
“I estimated I wasted at least 200 to 300 hours over a year with nothing to show for it. Just to define one control objective took sixteen hours. You could get the objective ok, but then to link it to testing or monitoring processes, took two different licenses and a lot of difficulty. I had to learn HTML and XML to get it done.”
Director of Governance and Risk
Software Provider
In contrast, organizations exhibiting Best-Case implementation experiences demonstrated a preference for solutions that provided a high degree of software configurability, permitting solution capabilities to be adjusted within the solution. Often, these sorts of changes can be performed by a solution administrator or power user, rather than a software engineer. The result is a significant decrease in the amount of time and cost required to map a solution to the organization’s needs. Because the solution architecture is designed to be changeable, this flexibility persists throughout the life of the deployment, permitting the organization to further adapt the solution to changing future needs, based on identified tweaks to processes or changes in requirements and organizational structure. The consequence of this approach is that the organization cannot always obtain a precise fit to existing processes that it might through customization. However, it often can get core components needed without the extended implementation process, with resulting benefits in both time to value and the net gains offered to the organization.
As a related factor, Blue Hill Research found that organizations with Best-Case implementations also demonstrated an emphasis on solution scalability. As noted above, while planning large business visions, these organizations rolled out GRC in small projects, focused on particular components. In support of this process, these organizations looked to solutions providing the modularity and scalability to fit easily into point needs and use cases and scale out to larger enterprise users. This helps ensure that subsequent project phases can be completed with a minimum of effort or renewed planning. This has downstream benefits as well, reducing the scope of effort required to add functionality or capabilities.