GRC Implementation Success, Part 5: Application Tailoring Without Extended Deployment
DoubleCheck Software presents GRC Implementation Success, a guest blog series by Blue Hill Research Principal Analyst David Houlihan. This series draws on five years of Blue Hill studies in GRC in order to highlight key lessons for purchasing and implementing GRC software.
Part 5 of this series examines the importance of application configuration and modular architectures as a mechanism for balancing customization needs without extending the implementation cycle.
What makes application implementations last a long time?
Often, getting to a state of technical availability (a standard application install) is a small matter. Training and user acceptance can take time, but the long pole in the tent is often the process of application customization. To this end, Blue Hill’s Contributors to GRC Implementation Success: Avoiding the Worst-Case Scenario benchmark study found that customization represented the factor with the most impact on the cost and time required for GRC implementation. This is because application customization, particularly when delivered via hard-coded application changes, inserts excessive cost and time delay in the implementation to account for unique needs. It can have consequences in the downstream application management lifecycle as well. Hard-coded customizations create rigid solutions. This means that applying upgrades or changing the application to fit future needs can either break the application or require additional rounds of customization to change the solution.
For enterprise applications, some software customization represents a fact of life. That is not necessarily bad in and of itself. The challenge is to understand how to identify and eliminate unnecessary customization. Addressing this challenge has two major components: (1) clarity regarding what can be addressed out-of-the-box and (2) the use of application configurability to provide needed solution tailoring.
Why Do We Customize GRC?
The answer is simple: the organization possesses unique processes or some combination of data, IT environment, or user needs that need to be addressed in the GRC platform. Often, this is a simple consequence of limitations in the application architecture involved.
This problem can be exacerbated by the organization’s failure to understand the full scope of its needs at the start of the project. As we observed in Part 3, failure to adequately assess the business processes to be supported and data management needs limits the organization’s ability to effectively scope its implementation and assess vendor offerings. Frequently, this results in late stage discovery of needs that cannot be addressed easily out-of-the-box, potentially at a point where an organization has already committed to a particular offering. Conversely, it also leads to over-engineering that prolongs implementation, when simpler approaches are available.
The Importance of Application Configurability
Vendors that design their applications for configurability prioritize flexibility for a wide variety of use cases and processes.
Rather than requiring hard-coding to fit an application to these needs, adapting the platform for unique needs becomes an in-application change that can be performed by an administrator or power user, rather than a software engineer. The result is a significant decrease in the amount of time and cost required in the implementation cycle to tailor the solution to the organization’s needs.
Organizations Blue Hill benchmarked as exhibiting Best-Case implementations demonstrated a preference for GRC platforms that provided a high degree of software configurability, permitting solution capabilities to be adjusted within the solution. This permitted these organizations to achieve implementations that required approximately a quarter of the deployment time and one-third of the cost of those experienced in the Worst-Case.
We can see the same dynamics at work in the experiences of KBR, Inc., the organization we referenced in Part 3 and Part 4 (and the full case study here). A configurable and modular application architecture played a key role in enabling the organization to complete the technical deployment of its GRC platform within three and a half months. (We’ll look at a second technical factor, vendor-hosted delivery, in our next post.)
Table: Factors Contributing to the Success of the KBR Implementation
There are long term benefits to application configurability as well. 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.
Levels of Configurability
Not all GRC platforms are designed with the same level of application configurability. Similarly, the amount of configurability that an organization’s use will vary. This makes it essential to understand both your needs as well as the right level that is needed to support those needs.
As we discussed in Part 2, GRC covers an expansive and diverse array of use cases and business processes. Tailoring the application to a particular organization’s needs requires accounting for a range of information types, frameworks, and other needs that can relate to a similarly diverse range of risks, controls, surveys, requirements, processes, documents, policies, standards, attestations, and other factors, depending on an organization’s compliance and risk management needs. However, at a technical level, there are only a few characteristics that will matter.
Blue Hill’s GRC Vendor Implementation Success Strategies identified five elements: (1) data elements, (2) data relationships, (3) workflow, (4) user interface, and (5) reports and dashboards. These elements range from deep application design components to more superficial characteristics. Examples of the former, such as data elements, data relationships, and process workflow, represent areas that will be tailored to the particular organizational use case. User interface, reports, and dashboard elements will present similar needs, but often benefit from additional layers of configurability to provide personalization addressing specific users or user roles.
Table: Configurable Elements of GRC
Organizations evaluating the configurability of a particular application will benefit by considering which of these elements are relevant to their needs and how they provided by the vendor. It is not sufficient to just consider whether some dimension of configurability exists. You must also assess the depth of configuration options, to ensure that the application possesses sufficient points of articulation to configure it adequately, depending on your needs.
Next, we look at: the role of hosted and cloud deployment models in the deployment cycle.
Before, we discussed: Why implementation success is investment success
GRC’s role and value contributions to the business
How robust business requirements must drive technical requirements
The “Show Me” approach to vendor assessment
