Decision 2012: GRC Design, Part 1


How do you decide where to start when designing and implementing your GRC technology?

We’ve reached the end (finally) of the US election season, and – speaking for the entire OrangePoint team – I hope all our American friends exercised their right to vote. After months of attack advertisements, stacks of campaign mail and door-to-door volunteers, I’m looking forward to things getting back to normal.

Election Year Strategies vs. Your GRC Design 
American presidential strategy hinges on persuading voters in “swing states” toward a candidate. This means that, for better or worse, a faithful voter in Ohio has more influence on deciding the president than a voter in a place like Kansas. (Cue the bewildered looks from our readers from other countries.) In 2012, our presidential candidates have invested enormous amounts of time and money in just a handful of states – states that represent approximately 20% of America’s total population – while nearly ignoing the rest of the country. In addition, key election promises and proposals are tailored to benefit this fraction of the electorate. As I reflected on the long-term wisdom of this approach, I found myself thinking about a remark I’ve used regularly with the companies I’ve partnered with over the years:

When implementing your business processes into a GRC tool, cater primarily to the 90%…not the 10%.

Allow me to elaborate on these percentages:

  • “90%” – This group represents the end users that regularly use your GRC tool to enter new data and update existing data. Think of the “worker bee” types that provide content and feedback around your GRC processes
  • “10%” – This groups represents upper management types (notice how I didn’t say “queen bee”, since there is no such thing as a “king bee” and this is a non-sexist GRC blog) who consume high-level, statistical reports, usually in the bar/pie/line chart variety. They log in to the tool to view the aggregated data, search for meaningful metrics and, ideally, steer their GRC decisions based on that information. That’s truly the purpose of having a GRC tool, right?

Design Directions: Bottom Up or Top Down? 
All too often when converting a business process into a GRC tool, the key stakeholders that I’m working with (those 90%’ers) view everything through the eyes of a 10%’er first and foremost. The question these stakeholders constantly ask is, “What would these executives want to see on their ‘single pane of glass’ graphical report?” In many cases, this usually results in the addition of several complex fields and data points that, while potentially useful for an executive report, make it very difficult for the end user to complete – either at all or within a timely manner. I’m sure you’ve heard the classic line, “your metrics are only as strong as your data” time and time again. If the 90%’ers are confused and/or frustrated by the business process, they are more likely to enter inaccurate data or cut corners. This leads to 100% of the organization being done a disservice.

My point is that the business process implementation with a GRC tool should drive how the executive reports are put together, not vice-versa. Essentially, you begin with a bottom-up approach rather than a top-down approach. Now, once the business process has been developed and deployed and the 10%’ers have their high-level, organization-wide reports, there may be additional data points they’ll want to capture going forward. (Good GRC tools aren’t chiseled from concrete; they are malleable, allowing administrators to update the tool to accommodate the evolution of the business.) When these updates are applied, though, the 90%’ers will luckily have an efficient, easy-to-use business process already implemented into their GRC tool, making the integration of said data points much smoother.

Closing Arguments and Cliffhangers
GRC technologies provide decision makers with clear, easy-to-understand metrics to empower your organization to chart the best course forward. However, the concept of clear and easy-to-understand should also apply to how the raw data is collected, not just the final metrics. Your grass roots users make up the majority of your user population and understanding their role and needs in the process is critical. Alienating this bloc of individuals with cumbersome screens, redundant requests and unwieldy selection menus can undermine the success of your GRC program. Simply put, we’re ensuring the 90%’ers are completely comfortable with the method in which they enter data first. If we don’t do this, the 10%’ers (and thus, the organization) fail to reap the benefit of having a GRC tool in the first place.

Tune in next week as I offer some specific design tips and approaches for implementing your GRC technology. While you’ll have to wait till next week for “Part 2” of this post, let’s all hope that we don’t have to wait till next week for this election to be closed and in the books.

–Evan Stos, OrangePoint

This entry was posted in GRC Technology Implementation and tagged . Bookmark the permalink.

1 Response to Decision 2012: GRC Design, Part 1

  1. Pingback: Decision 2012: GRC Design, Part 2 | OrangePoint GRC Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s