Chaos to Control: 4 Crucial Steps for Implementing GRC Software
A guest post from Michael Blumreich, Senior GRC Solution Consultant for OrangePoint
On a daily basis, I work hand-in-hand (or phone-to-phone) with clients to guide them through implementing their GRC processes using platform-based software. Having been involved in the implementation of dozens of GRC processes in a number of different industries, I can tell you the one thing they have in common: they’re all different.
For some clients, this variety is a source of excitement and a challenge to overcome. But for many others, this variety results in a feeling of stress and doubt.
A couple months back, I was on an afternoon flight headed home from a client site and had the good fortune of snagging a window seat. After boarding the plane, instead of plugging in my headphones and tuning out the world, I gazed out toward the tarmac and something immediately caught my eye.
Different vehicles of all shapes and sizes travelling at different speeds to different places all with their specific jobs to do…it was controlled chaos and I loved it! As I watched, I kept thinking, “How is this possible?” How could all these vehicles move so quickly without colliding with each other or any of the taxiing planes? An answer came to me, involving a combination of:
- Core processes
- Structured design and planning
- Precision build
- Detailed, role-specific training
Yes, I’m actually the kind of person who makes these connections while waiting for a plane to board. ;)
If any one of these elements is missing, chaos ensues. But with these four elements in concert, the airport runs (most of the time) like a well-oiled machine. I want to be the first to say that I am not (nor do I claim to be) an expert in anything airport management related, but I do know process when I see it.
With that in mind, I went to work to see if my epiphanous moment could in some way be transformed into something that could help my clients in their GRC endeavors.
Working with a client through the nitty gritty details of processes they’ve flagged for implementation isn’t the most fun way to kick off a project, but it will set you up for success in the long run.
By working through your client’s processes with them, not only will you be able to gain a better understanding of their needs, but this will also start to help them understand how their processes will fit into the GRC tool that is to be implemented.
This combination can greatly ease feelings of stress and doubt and allow for a smooth transition into the design and planning phase of the project.
Structured Design and Planning
Leveraging the work completed in the previous step, you will be set up for a “plug and play” design and planning phase of the project.
What I mean is that by utilizing the detailed requirements gathered in the first step (user access, workflow, data, metrics, notifications, etc.), you will be able to directly map these elements to corresponding components of the GRC tool (applications, surveys, fields / field types, workflows, notifications, etc.).
The design documents (I’ve used a combination of Excel, Word, Visio and PowerPoint in the past) developed during this step, along with regular design and planning review checkpoints, will help flush out any requirements missed in the first step and also help to promote client buy in.
Between thorough process identification and analysis work and equally thorough design and planning activities and documentation, you and your client will have a clear understanding of what the build will entail.
Now, I’ll be the first to tell you that performing build work in any platform-based software is an inexact science. Things will change along the way and at times not work as expected. That being said, going through the build without a clear understanding of your client’s needs and a detailed build plan in place can have negative implications (project delays, client stress / project doubts, backward progress, etc.).
On the flip side, when encountering those same issues with an understanding of your client’s needs and a detailed build plan in place, you have the tools to do the following:
- Present the issue encountered during the build and show how that relates directly back to the original build plan
- Discuss options for a workaround and their direct impact (positive or negative) to the original build plan
- Agree on a workaround with your client, then adjust the build plan before moving on with build activities
What I’ve listed above are great for the consultant, but what really matters is how your client will benefit. By taking your client through these steps, you will have provided them with real visibility into their project (not just the success stories), managed their expectations and continued to promote client buy in, all of which promote low client stress and high project confidence.
Detailed Role-Specific Training
The majority of implementations I have worked on have involved multiple processes, various user groups, roles and responsibilities. What this translates to from a training standpoint is the need to develop role specific user guides and/or training courses.
Each of these guides or courses will have an overlapping element when it comes to general activities that are to be performed in the platform-based software solution (i.e., accessing the login page, logging in, general edit / save activities etc.).
A lot of consultants will stop there and call it good. I don’t feel like that’s good enough.
By taking your clients through the basic solution training as well as a more detailed process / role-specific training, you will not only improve user proficiency and experience on the first day the solution goes live, but also greatly increase your chance as their consultant to be called back again when new implementation activities need to take place.
Image Source: https://i.ytimg.com/vi/UYfkOfFISCs/maxresdefault.jpg