GRC in 2019 has focused on the debate of Integrated Risk Management (“IRM”) versus Governance Risk Compliance (“GRC”), one claiming to be the future of risk management, the other stating it is same technologies, just new terminology. At their core, GRC/IRM technology solutions are business process automation tools that the vendor has built risk & compliance use cases as a starting point for an organization. I have considered writing a white paper on the subject, but quickly came to the conclusion that it would just be white noise and one more article that wouldn’t necessarily advance the conversation.

Instead of jumping into the GRC/IRM fray this holiday season, I decided to have a little fun and bring my unsuspecting family into the conversation. Thus, the idea to have a GRC Thanksgiving solution, a collection of custom applications built upon the Onspring software solution, that my family could utilize over the extended vacation weekend. After discussing with my business partner and receiving approval from Onspring to utilize our sandbox environment for a non-traditional use of their solution, I started my work on building the Thanksgiving solution. 

The Thanksgiving GRC Solution

The idea was to have several applications that could be utilized by the family ( ranging in age from 9 to 66) throughout the weekend with little training or support from myself. Onspring’s intuitive user interface, speed, and ease to configure made it any easy choice for this experiment. The solution consisted of the following:

• Give Thanks: My favorite application of the solution enabled users to identify any other family member and provide a message of “thanks” to them. The thanked would receive an email and the message would display on the Thanksgiving dashboard. 
• Daily Schedule: The daily schedule provided family members the full weekend schedule, including times, locations, and links to Google maps to assist the out of town family members with navigating the town. Every morning family members would receive the days schedule via email.   
• Game Tracker: The game tracker enabled family members to track their air hockey and table tennis matches. After each game was logged, the dashboard would automatically update showing win/lose percentages and short by who had the highest win percentage.
• Kid Zone: Since the children were all equipped with devices, I built them their own little sub-solution that would not be visible to the adults and have their own dashboard. 
  • Kids Chat: A simple application to allow the children to post comments to each other on their dashboard. 
  • Playbill Maker: Every year the kids enjoy putting on a “Thanksgiving Show”, featuring dancing, singing, and guitar and drum solos. In past years, the kids would hand out tickets and spend most of Thanksgiving Day planning out every detail of the show. I thought this the perfect opportunity to stretch the GRC solution capability and build a solution that would allow the kids to name the Show, identify the acts, and when complete, automatically email a Playbill to the entire family. After playing with it for a few minutes I realized It was a little more complicated than I’d first anticipated. 
• Belsnickel: A last minute addition to the Thanksgiving solution was an application for my niece, a huge “The Office” fan, where she could deem family members as “Admirable” or “Impish”. Upon making her determination, the system would immediately notify the person via a custom email that featured Dwight in his Belsnickel costume. 

I unveiled the application the Tuesday evening before Thanksgiving to my family, a group that knew nothing more about GRC except the fact that “Andrew is a licensed attorney, who instead of practicing law has dedicated himself to doing something with compliance technology”. After a short 10 minute demo of the solution, I granted access to the group and let the experiment begin.

What I Learned

By the end of the weekend, everyone had used the solution for at least one of the use cases, with varying success of application. The use of it was slowly weaved throughout the weekend as people would send Give Thanks messages, document scores, or review their daily schedule. Similar to what we see at many of our clients, I had to push usage of the tools in the beginning, but they caught on quick and by the end of the weekend I was even getting feature enhancement requests. The most popular applications, “Give Thanks” and “Belsnickel”, were favorites for their ease of sending messages to other family through a simple user interface that could be viewed everyone. On the other end of the spectrum, the “Kids Chat” application had almost no use, as the children found it to be a poor replacement for group text messages.  Plus, they didn’t love the idea that their uncle could view all their messages as an administrator. 

Upon further reflection of the weekend and the use of the solution, I found the experiment to be most valuable for three unexpected lessons:

1. Design Your GRC Use Cases with the End Users Devices in Mind: Most of the time when I build GRC solutions, end users are utilizing the solution on their laptop. The Thanksgiving users, however, were utilizing their phone, which caused issues when an application had fields crammed into a small section Thus, if you are building a true GRC use case to be utilized by users in the field or on their phone, keep the solution design simple and limit the number of fields.  
2. Reports Impact Activity: A common adage in the GRC space is “what gets measured gets done”. In the Thanksgiving solution, however, the Game Tracker solution encouraged people to only play one game to avoid impacting their win/lose percentage. A little more structure around the use of the application or setting up an actual tournament may have resolved this issue, but leaving the solution open resulted in some anxiety regarding logging scores. I have seen similar outcomes in the design of Incident Management solution, where documenting incidents are seen as a negative and employees do not want their name associated with incident. Therefore, reports do drive activity, but as a leader of a GRC solution you need to ensure they are driving the correct activity. Build processes and expectations around your use cases that drive the appropriate use. 
3. Only Replace Point Solutions if there is an Integration Need or the GRC is a Better Platform: The “Kids Chat” solution is the perfect example of trying to replace an effective point solution with a GRC solution that could serve the need, but doesn’t provide the same value to end users. My 9 year old niece summed it up best: “we would use the application, but it is easier to text… plus it keeps our ‘Thanksgiving show’ plans a secret from you.” If you are considering replacing a point solution with a GRC technology, one of the following must be true for an effective implementation:

• The GRC solution provides functionality above what the point solution provides; or
• The benefit from the integration and sharing of data with other use cases in the GRC solution outweighs any negatives.  

If neither of these two rules are met, reconsider your plan to replace the point solution. 

Conclusion

Some members of my family did ask me if I planned on building a Christmas solution, but decided to hold on any more family focused GRC use cases for the time being. However, I would be lying if I said I wasn’t tempted to build an automated thank you note sender any gifts received. If you have any ideas for non-traditional GRC processes that you would like seen automated, add a comment to this post and we will see if we can build one or two out to demonstrate these tools capabilities. 

If you want to see the Thanksgiving solution in action, feel free to reach out and I will be happy to provide a short demo.