We break down the process for selecting and implementing a GRC tool into the following phases.
Requirements for a successful plan phase
The first step in the plan phase is to clearly define responsibilities. Who will be driving the process – business departments or IT? Who will structure the selection process? Who will serve as the main contact for the vendors? Who will have the final say if disagreements arise?
Budget responsibility is another key topic to address in the initial stages. Later on, it will be important to know how the costs (e.g. transfer prices) will be transferred internally to the business department and affiliated companies.
Once the requirements analysis has begun and the criteria list has been created, it is essential to differentiate if the software needs to support a single, specific use case (e.g. purely ISMS) or be extensible to holistically integrate various topics. This decision may make it necessary to broaden the group of people involved in the selection process. Taking a close look at the existing IT landscape and strategy is also essential in order to observe strategic guidelines and align them with business requirements.
Having a broad range of expertise in the selection team is a key factor to success. Expert knowledge of the GRC process in general, company-specific circumstances and a solid IT background are all necessary to translate process requirements into software requirements. Current, in-depth knowledge of the market is also a must to ensure that all relevant vendors – especially those who may still be unknown internally – are included in the selection process.
When it comes to reconciling the requirements from the criteria list, defining evaluation scales, and determining their weight, precision is key so that the involved parties clearly understand how the decision will be made and what the priorities are. Transparency is of the essence throughout this entire process to ensure compliance and avoid internal disagreements.
Finally, the quality of the RFP often makes the difference. In order to make an offer and present the software, the vendors need to understand the content well enough without being bogged down by irrelevant details. Here again, clear priorities for the final selection and realistic timelines are beneficial for everyone involved and ensure high-quality offers.
After creating a shortlist during the tool evaluation and selection process, the project team should request a small proof of concept (e.g. one step of the process) as part of the offer presentation. This provides a realistic look and feel for the software and how the company’s unique process could run in it. Transparent evaluation criteria for the offer presentation is also important so that the final decision is clear, understandable and documented. This, in turn, provides a good opportunity to question the vendor’s business and technical expertise. When selecting a vendor for the joint implement project, both human factors and a deep understanding of the underlying business processes are pivotal.
Moving to the build phase
As soon as the project has started, arrangements must be set with the vendor. From day one, the project should be viewed as a joint endeavor. Hygiene factors such as decision and escalation paths should not be underestimated – especially when different departments are involved. Timetables in GRC projects are often very short in the follow-up to compelling events or due to other deadlines. Accordingly, the work atmosphere profits from agreements and guidelines that have been made with great care. A trivial issue, which often manifests as a massive problem, is internal resources. Providing adequate capacities to work on the project is a major challenge because the regular day-to-day GRC responsibilities and control processes typically run alongside the project.
Some tips apply to projects in general. Since requirements and add-ons quickly make an appetite for more, it pays to stick close to the original scope and plan for later additions especially within technical concept. Another best practice is to incorporate key users from the extended community – even during the early phases of the concept design. These individuals typically work for multiple departments or teams and are responsible for many other activities besides GRC in their companies. Simple navigation and intuitive usability, therefore, must be the utmost goal – here even more so than in other software projects. Dashboards and reports ensure that these users can find “their” information as easily as possible. When the time comes for testing business scenarios, they will probably also serve as a valuable source of feedback.
As far as documentation is concerned, there is nothing special to point out. Since this area is wantonly ignored in most projects, we simply would like to make a general appeal for understandable, detailed documentation.
Project communication is absolutely crucial – especially in a GRC environment because the project is only on the users’ radar around certain deadlines or pending actions. The communication should take into account that the individual user groups work very differently with the software with regard to tasks, frequency and the level of their business knowledge. For annual certifications, for example, a simple one pager describing how to access the tool, the 3-5 important clicks and easy analytic capabilities should suffice. Due to the wide range of tasks, the communication must be precise and designed in such a way to “divert” the users’ attention from other tasks.
As a general rule, training should be a top priority. This also provides an excellent opportunity to incorporate and refresh business content from the very start. Possible deficits within the community often only come to light in these cases and can be addressed accordingly.
Transitioning to the run phase
It is important to strengthen the communities even after the go-live and the roll-out phases have ended. Since most probably still view GRC as a necessary burden, the members need a strong community feeling so that they can focus on this task at least during key phases. This, of course, doesn’t relate to software alone, but rather the process of embedding risk awareness in the corporate culture and everyday decisions. The tool, however, does play a prominent role because it is often the flagship for the department throughout the organization.
Exchanging experiences regularly – optimally, in face-to-face meetings or roundtables – is highly recommended. This also provides an ideal opportunity to present new functions, reports or other aspects of the tool. Although this intense support ties up resources from the department, the investment will pay off with less work in the long run. Users worldwide will be able to exchange experiences, share knowledge, and answer questions among themselves in a fast, straight-forward way.
When the time comes to develop the tool further, getting feedback from the users is extremely important. Experience shows that they often have different priorities than the people in charge. It is important to carefully check the time for switching to a new release and mirroring it to the community. Timing is often critical – especially when wrapping up control processes – to avoid unnecessary obstacles. Larger modifications, of course, need to be incorporated in the budget and internal resource planning (e.g. time for testing). Thorough planning and securing a long-term budget is key because most companies anticipate lower costs in the years to follow. In some cases, user feedback can help back this argument and be used to prepare a long-term roadmap that outlines the integration of other areas or related topics.
Experience has shown that updates should be made in a timely matter to avoid the risk of “shocking” casual users with an interface that they hardly recognize. User acceptance also benefits from a steady further development in line with the defined roadmap. When the time comes to integrate further GRC processes, it is also important to ensure that the existing users don’t take a step back or suffer from usability issues.
It is also wise to take a critical look how well the software truly meets the users’ needs and which aspects or features are no longer necessary. In order to ensure smooth, long-term operations of the software, project expertise must also be preserved – especially when the application ownership switches after going live or the role of the team is constantly changing. Designated contacts for business and IT support are also vital in everyday operations. The amount of time available needs to be chosen with care and communicated to the community. The overall goal must be to support the different needs of users individually without neglecting the other responsibilities within the department.
Our goal as a tool vendor is to guide you on this path and provide you the best-possible support every step of the way. Should you have any questions, please do not hesitate to contact us to discuss your challenges and profit even more from our experience.
