Most of us firmly entrenched in office/cubicle/workspace environments are familiar with the movie Office Space. For those that aren’t familiar with the plot, the film provides insights into the mundane life of a software engineering company, covering all the standard office clichés:
- the demanding boss with annoying catchphrases
- “efficiency experts”
- mass layoffs
- printers that never do what you want them to do
- themed parties (Hawaiian shirt day!)
Though bombing at the box office in the late 1990s, it’s now achieved cult status with its satiric take on office culture.
When Life Imitates Art
While I could definitely spend the rest of this blog post detailing the plot of this cinematic masterpiece, there is one scene that always stands out – the infamous “TPS Report” scene. In the movie, Peter (our protagonist) regularly sends out TPS Reports internally and it just so happens that this time, they contain a few errors. Also, unfortunately for Peter, he has eight different managers he reports to, so as soon as he sits down in his cubicle on Monday morning he is visited sporadically by each of his bosses. One by one, they “pop in” to inform him that he screwed up his TPS Reports.
I too have been in a situation where instead of having one or two primary business process stakeholders, there were five. All five of them had different ideas as to how the business process should be developed in the GRC tool and they usually weren’t ever on the same schedule, so getting them all in the same room was rare. A too common scenario involved me configuring something one way for stakeholder A – something that needed immediate attention. If I ever failed to relay even the smallest change on to the other stakeholders immediately, I became Peter from Office Space. I would be emailed, called or personally visited – individually by each of them – informing me of the errors I’ve made in my TPS Reports…I mean GRC tool configurations.
My point is this: GRC tools, by their very nature, regularly invite a “too many cooks in the kitchen” scenario. While I’ve focused on the managerial side of things, the same can be said for the development of business processes. Far too often I’ve seen multiple stakeholder groups sharing the same GRC tool application/module. While that in itself isn’t a deal breaker by any means, usually each group has their vision of how it should be configured and in many cases they have their own developers making those configuration changes on top of the other groups’ developers. Simply put, things can get messy quickly.
3 Tips for Stakeholder Harmony
Throughout my experiences, I’ve identified three primary ways to curtail the overlap of conflicting business requests. These sorts of issues that seem very basic up front, but are easier said than done. Before you embark on your next GRC endeavor, I encourage you to review the following tips and apply them to your project:
- Have a Plan for Finalizing Decisions
First, in a situation where there are multiple key stakeholders or stakeholder groups providing input, it must be established very early on who has the ultimate authority. Is it one specific stakeholder? Will a democratic approach be employed, where major design items are voted on and majority rules? In my past experiences, the GRC champion of the organization is usually the person who either assumes final authority or delegates a specific stakeholder to be the one where the buck stops.
- Write It Down
Second, and this message is more custom-tailored for the GRC developers among us – document everything. This is especially critical once the design of the business process is approved. Track any and all changes being requested (and whom they were requested by). Place all emails discussing or requesting configuration changes in a special Outlook folder. When responding to a specific request, make sure all pertinent stakeholders are included on the communication. As many of you reading this know, when it comes to developing in a GRC tool, you can be hit from many angles in rapid succession with updates and requests, thus making it easy to lose track of who requested what and when. I also recommend leveraging an in-house change management system, explained in detail in one of my earlier blog posts .
- Have an Audit Trail
Third, management should always be aware of the people who are actively doing the technology development on a particular business process within the software. On the administrative side of things, most of the major GRC tools out there will indicate the user who made the last to update to the various components. Ensure that you can tell a clear story of who did what, all the way from the requirement request to the actual field configuration within your system. If your system can’t track changes at this level, be sure you have a program in place that identifies which administrators are responsible for each update so you can still understand who is responsible for each action item.
Hopefully the above tips will help you avoid your own “TPS Reports” situation in the future. Now if you’ll excuse me, all this talk about Office Space has given me the urge to watch it again, for roughly the 15th time. But first, I need to find my stapler…has anyone seen it?