Continuous Improvement in GRC
By Evan Stos
If you’re familiar with this blog, you’ll know that we are big, nay, huge fans of metaphors to explain best practices for Governance, Risk & Compliance (GRC) programs—from Bigfoot and Roombas to water buffaloes and bicycles. However, we have yet to foray into the world of golf, which in some ways is similar to an ever-evolving GRC platform. Believe it or not, there are many common characteristics (beyond the fact that they can both be frustrating at times).
Allow me to explain.
At a high-level, the objective of golf is easy enough: For any particular hole, simply hit the ball with a series of clubs until you get it in the cup. Every golf hole is different. Some are more difficult than others. Some have significant obstacles you should avoid, such as water, sand or trees. Also, while a path is laid out for each hole that provides the least amount of difficulty for putting the ball in the cup, following the path is an entirely different story.
You could say the same for the concept of implementing a business process into a GRC platform: It seems easy enough on its surface, right? Simply build the fields you need into an easy-to-use web application, and voila! Your end users are populating fields and providing your organization with valuable, reportable data. Some business processes are easier to implement than others. Some have significant obstacles, such as stakeholder disagreement or non-standard data. Also, like golf, a path is laid out for implementing a business process into a GRC platform that provides the least amount of difficulty, but keeping all your stakeholders on the path can be a challenge.
And now, the most important similarity between your GRC implementation and your golf game: You will never be completely finished improving it. While it pains me to announce this to the internet, I am an incredibly average golfer. On some (read: a few) holes I never leave the fairway, while on others (read: most) I’m trying to hit from behind a tree or wishing I would’ve brought scuba equipment to retrieve the 5 consecutive golf balls I hit into a picturesque, well-placed pond. Because of my inconsistency, I’m constantly making tweaks to reduce errors. These tweaks may be minor, like buying a different type of golf ball, and some are major, like changing how I swing one of my clubs. The point is, while I hope the tweaks become less frequent as my skill level improves, I’ll never be completely finished making changes to my game. Nobody ever declares, “My golf game is completely flawless and has reached its ultimate apex.” Actually, I take that back. Somebody probably has said that at some point, but it usually means they’re:
B) Partaking in a few too many “lemonades” on the course
Implementing a business process into a GRC platform follows the same pattern. You’ll never truly be “finished.” When the implementation is new, think of it as essentially “version 1.0.” Over time and through repeated end-user exposure, people will request updates. Some of those updates will be minor, like adding a value to a dropdown list, and some will be major, like completely overhauling users’ access. My point is that you’ll need a change management solution that enables users to request changes (no matter how small). My preference is to build the change management directly into the platform itself, but I’ve seen situations where an external change management process is successful as well.
As we turn the page on yet another GRC-related metaphor, keep in mind that one of the primary advantages of having a GRC platform is its flexibility. Providing users with a direct conduit to request enhancements and provide feedback is invaluable for everyone involved.
And now if you’ll excuse me, I need to go buy some more golf balls.
Reposted with permission from Orangepoint.com.
Image Source: https://www.pinterest.com/pin/717761259334048677/