GRC Implementation Success, Part 3: Business Requirement Definition
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 3 of this series examines the process of defining business requirements for the software investment and its relationship to the effectiveness of the implementation.
Five years of research into governance, risk, and compliance (GRC) software investment at Blue Hill clearly underlines the connection between effective planning with high levels of satisfaction with the ultimate implementation. To this end, Blue Hill’s Contributors to GRC Implementation Success: Avoiding the Worst-Case Scenario benchmark report observed that the “crucial determining factor” in the outcome of a GRC investment was the organization’s ability to assess how explicitly the implementation accounted for: the intended process change, information consumption needs, and data management practices.
Start with the Business Process
If that sounds like a lot, it is because it is. Truthfully, it is not one factor, but a confluence of considerations that require close attention. It is often easier for organizations (once they identify the investment need) to proceed on assumptions about how the software investment would impact the business. In the same study identified above, Blue Hill observed that organizations experiencing “Worst Case” implementation experiences were more likely to focus on a critical event (such as a regulatory change, increased agency enforcement, or high-profile exposures suffered by peers) or particular solution features and functionality desired.
By contrast, Blue Hill found that Best-Case implementations devoted substantial time to evaluating existing processes and needed changes, based on identified business needs and operational goals prior to considering software functionality in any way. Put another way:
Best Case implementations featured extensive efforts to identify and precisely define the business requirements for GRC. This involves reviewing and understanding the processes to be enhanced, the needs of all stakeholders in the solution, and organizational limitations (such as IT infrastructure constraints, budget, and/or appetite for change).
As an example of this approach, the table below summarizes how professional services and technology firm KBR, Inc. used business needs to drive technical requirements prior to implementing a SOX controls management platform. (Read the case study here.)
Table: Requirements of a Controls Management Platform Sourced by Business Need
When performed with a realistic eye at the start of investment planning, this process provides a blue print that will guide solution and vendor assessments, as well as in implementation planning. When overlooked, organizations leave themselves open to late discovery of needs, solution limitations, or other factors that result in delay and scope change or otherwise warp and impede the implementation process.
Defining Business Requirements
Blue Hill’s KBR case study benchmarked the organization’s implementation of a SOX controls management platform among the most successful Blue Hill has ever studied.
Analysis of KBR’s experiences clearly reinforces the importance of business requirements definition. Before exploring software functionality, KBR dedicated approximately one month to a systematic review of SOX test and review processes and related reporting needs. This resulted in a list of approximately 75 business and technical requirements for its new GRC platform, with fifteen prioritized as “key requirements.”
These requirements became KBR’s primary tool for solution selection as well as implementation planning. In the former, the organization’s requirements document helped to define its RFP questionnaire as well as its demo evaluation framework. In defining the solution itself, the requirements document influenced the shape of KBR’s configuration specifications as well as its UAT test plans.
The requirements document even assisted in KBR’s efforts at user role definition, workflow design, and data property models . . . all factors that are often left to deployment stages and can substantially slow the implementation.
Tempered by the business objectives set for the investment, this sort of thoroughness enables organizations to identify not just the functionality it needs as well as the non-functional architectural and delivery methods that would permit it to effectively achieve its goals. This clarity of purpose translates into the ability to quickly identify and prioritize investment needs and to adhere to a clear deployment cycle. The impact of this step on subsequent activities cannot be overemphasized, particularly when organizations take the time to understand how these requirements relate to its ability to execute on implementation plans.
The first, and starkest, example of the difference this makes will appear in the vendor evaluation and selection process.
Next, we look at: The “Show Me” Approach to Vendor Evaluation.
Before, we discussed: Why Implementation Success is Investment Success
GRC’s Role and Value Contributions to the Business
