Decision 2012: GRC Design, Part 2


Great process design should be at the forefront of your GRC technology implementation.

In my previous post, I described the need to understand the audiences using your GRC technology. While much attention gets focused on key management stakeholders, too often we forget to view our GRC systems from an end user’s perspective. A poorly automated process leads to a disenchanted end user and can potentially jeopardize the quality of your GRC metrics. This week I’m concluding my discussion, as promised, on GRC technology design by offering some specific design tips and approaches for the GRC professional. (Seeing that we’re just a week past election day I’m not about to break any campaign promises!) As you finish out your 2012 initiatives and scope your plans for the upcoming year, take a moment to review the following four tips.

1. Be Better Than the Status Quo
In our quest for GRC automation and real-time reporting, we – as GRC technology implementers – can often lose sight of the end user benefits. The old process may not have offered any powerful metrics or opportunities for working across business silos, but it may have required only 15 minutes of the user’s time and allowed a user to get started with a single mouse click. If your new system slows the user down, end users won’t care that your executives revel in their new, fancy dashboards.

Build and architect your process in a manner that optimizes the experience of your end user. Be conscious of the number of clicks it takes to both a) start working, and b) complete the work. If it takes 10 clicks to get from an email notification to the first field for data, you are wasting your users’ time. In the same manner, if the new, automated GRC process takes 30 minutes longer than the old way, your end users may revolt. You achieve a higher data quality and a more timely response when your GRC system has a succinct and clear workflow.  Don’t make the new way worse than the old way.

2. Strategically Manage Your Executive Reporting
Design and optimize your GRC business process, then address executive reporting. When addressing the executive reports, heed the following advice:

  • If specific executive reports ARE already identified in the requirements, determine if providing the reports alters or slows the business process drastically. If it does so in a negative manner, bring the executive into the conversation – explain to him/her what the negative impacts will be for the regular users of the business process, then provide the most logical alternatives/work-arounds (in a format like “Option 1”, “Option 2”, etc.). Have these options prepared before-hand.
  • If specific executive reports AREN’T identified in the requirements, meet with upper management to determine their needs. DO NOT lead with “what type of reports would you like to see?” This can waste cycles and get you into trouble early, since chances are most executives aren’t deeply familiar with the GRC tool their organization is utilizing. This leads to plenty of questions like, “Can the tool provide (fill in the blank)?”This can put you in a hole early, because you’re either answering “no” over and over, or answering “I think so…,” which potentially leads to doing a lot of tinkering with your design and a lot of back-and-forth with upper management. Instead, lead with what reports you believe would be valuable to them (that you know you can provide based on the current design), then close with, “are there any other metrics you’d like to capture?” Bottom line: don’t put the onus for designing reports primarily on individuals who likely aren’t regular users of the technology to begin with.

3. Clearly Articulate the Costs
The majority of executive reports look nice and tidy, but the effort involved to create and maintain them is not. If there is a metric/report that upper management wants that requires changes to the business process, always communicate those changes to executives from a time-to-value perspective. For example, if an executive asks you to change the colors of all of the bar/pie charts to the company’s colors and you inform them it would take a week to complete that, chances are they’ll back away from that request! Don’t forget that simple changes can consume large chunks of your budget if the simple change scales poorly (like changing the colors of 500+ bars, pie slices and lines across 50 separate reports).

4. Over-Communicate Substantial Change
As your GRC technology project and implementation evolves, there will be numerous requests for “tweaks” and “finishing touches.” Be mindful of how these small changes can add up to substantial change to the original process. Adding a single data field to a form or value to a dropdown list is simple enough for end users to accept; adding three new review and approval stages to your workflow is not. If significant changes are made to your GRC business process to address an executive reporting need (or just to enhance the process using a newly discovered system feature), try to capture it in the business process as simply and quickly as possible and over-communicate the change(s) to your end user base via e-mail, training and awareness exercises, etc. As the architect or administrator, you have the ability to slowly absorb and become familiar with the changes as they come in over the course of the project. Your end user doesn’t get to sit alongside you as these adjustments are made; end users pivot from one system to another on the designated “go live” day. Do everything you can to prepare your end users for the “go live” day to ensure a successful roll out.

These four tips are just a sampling of ways you can ensure the long-term success for your GRC technology implementation. Are you a GRC professional? What tips would you offer other organizations and system administrators looking to automate their GRC processes? Feel free to post your tips and recommendations in the comments. Until next time, happy designing.

–Evan Stos, OrangePoint

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

1 Response to Decision 2012: GRC Design, Part 2

  1. Pingback: Decision 2012: GRC Design, Part 1 | 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