10 pitfalls when implementing GRC technology and how to avoid them

Selecting a GRC solution is a major business decision and capital expense. This decision cannot be done by investing an hour or two in research and reading some online reviews, because the information that is available online cannot fully cover the organisation’s needs. The problem is that there is no one-size-fits-all process for selecting a GRC solution, meaning a solution that works perfectly well for one company may not be a good fit for another organisation’s requirements, even though both firms are of comparable size and operate in the same industry.

How to avoid?

Setting up a well-structured GRC solution selection project can substantially reduce the risks of choosing an inappropriate GRC solution. The project should include a project team that knows what requirements need to be covered by the GRC solution, and detailed planning of the approach for evaluating the GRC solutions that are available on the market. During the evaluation, relevant stakeholders (especially the end users who will be using the tool) need to be involved and sufficient time needs to be invested to ensure that the most appropriate GRC solution will be selected.

Having an inadequate service level agreement (SLA) with the GRC solution vendor or not having one at all can have a negative impact on the service quality delivered by the vendor because the expectations of the level of service, metrics by which the service is measured, mitigation actions and penalties are not properly defined. Without this, there is no basis for tracking satisfactory or unsatisfactory service.

How to avoid?

A properly negotiated service level agreement helps to protect the organisation if the vendor is unable to deliver services in a satisfactory manner. When setting up a service level agreement, the following points should be considered:

• Which services are expected to be delivered by the vendor;
• Conditions related to service measures;
• Penalties for breaches (e.g. the vendor is not able to deliver its service within the agreed timeline); and
• Rights to terminate the SLA without penalties if there are chronic problems or critical failure.

In general, some vendors may try to insert questionable terms and conditions (e.g. cure periods (time to fix a problem before penalties kick in or a termination provision can be exercised)). Therefore, the organisation should pay very close attention to these inclusions and involve the procurement/legal department to ensure that they do not miss any relevant clauses in the SLA.

Implementing a new technology in an organisation without having enough server capacity can reduce the performance of the technology massively and, in the worst case, it can lead to technology being no longer usable.

How to avoid?

Before a new technology is implemented, the server capacity requirements for the new technology must be clarified with the vendor and the internal IT of the organisation. The vendor needs to outline which IT infrastructure set-up is required so that the new technology is compatible, and internal IT needs to ensure that the IT infrastructure is set up accordingly. This is because expanding the IT infrastructure during the implementation can be very time-consuming and cause delay in the agreed implementation timeline, which will probably lead to additional costs.

If the business requirements related to a GRC technology are not clearly defined from the beginning, how does the organisation know which GRC technology would be most suitable? The business will also not know what goals they need to achieve, which will most likely lead to an implementation failure.

How to avoid?

Developing and managing business requirements are key to a successful GRC technology implementation. The business requirements must be clearly defined (without room for interpretation) and aligned with multiple stakeholders to ensure that implementing the GRC technology will be successful and provide added value to the organisation.

Vendors mostly offer standard GRC tools that comprise the most relevant functionalities related to GRC processes, but – as mentioned above – the GRC tools are not tailored to the organisation’s specific needs. Therefore, organisations tend to heavily customise the GRC tool in order to meet their requirements. However, these customisations entail the following issues:

• Change requests are costly and sometimes the price-performance ratio is not always comprehensible (e.g. the costs of renaming a field name in two different forms can be different even though the effort should be the same);
• Changing a workflow can cause an error in another workflow, which worked properly before the change; and
• Customisations might not be upgrade-safe, which means that upgrading to a new version can sometimes require the redeveloping of all the customised functionalities, making the organisations have to pay for the same customisation again.

How to avoid?

In order to avoid the issues, it is recommended to stay as close to a standard GRC tool as possible. Of course, sometimes customisations are necessary and cannot be avoided. But if the organisation decides to customise the standard GRC tool, then it knows at least the potential risks and can prepare appropriate mitigating measures to prevent the customisations making the tool unusable or turning into a huge long-term cost generator.

Insufficient software testing (or a complete lack thereof) increases the chance of software complications (e.g. not identifying technical bug early enough) and bad consumer experiences (e.g. end users are frustrated because they cannot use the software for the daily business).

How to avoid?

Most software will have bugs in its early versions and these bugs can be caught and fixed with sufficient testing before going live. It must therefore be ensured that the organisation plans enough time for the testing, that robust test cases covering all possible scenarios have been defined, and that relevant end users are involved during the testing.

If not enough people are assigned to the GRC technology implementation project from both the organisation and the vendor side, the delivery will probably fall behind the expected timeline. Yet overstaffing a project can easily lead to miscommunication and it is harder to keep a large team of people unified. This can also lead to duplication and a lack of consistency, with too many duties being distributed.

How to avoid?

Before the GRC technology implementation starts, it is necessary for both the organisation and the vendor to assess the staffing situation correctly and include the project management team in the final staffing decision. In addition, each side should appoint a single point of contact who is responsible for coordinating the implementation.

Failure to involve relevant stakeholders during the selection and implementation of the GRC technology may result in stakeholders not accepting the new technology, which could lead to the technology being replaced or decommissioned. If this happens, the implementation and the related efforts would have been in vain.

How to avoid?

Relevant stakeholders (especially the end users) should be involved during the GRC technology selection and implementation processes so that they have an opportunity to raise their specific requirements. They should also have the chance to perform the testing so that they can see what to expect from the new technology. In addition, regular updates on progress need to be communicated to stakeholders in order to avoid any surprises.

Even though most people speak the common language (e.g. English), the interpretation of that language differs completely. For example, if we ask 20 people to draw a tree, then we are certain that we will get 20 different kinds of trees. This is the same for business and technical requirements: even though a requirement might be clear to one person, it might not be clear to another and this often leads to misunderstanding between an organisation and a vendor. If the vendor is in another country, the cultural differences make the communication even more challenging.

How to avoid?

Effective communication is one of the keys to avoiding misunderstandings and can be achieved by:

• Being as specific as possible and keeping straight to the point;
• Staying focused and not mixing up topics;
• Choosing words carefully and not using very specific vocabulary (e.g. technical terms or abbreviations) that other people might not be familiar with;
• Repeating and verifying that the counterparts have understood completely, and at the end of the conversation summarising what has been said, highlighting the most important parts; and
• Trying to put oneself in the counterpart’s situation and understanding the other culture (if applicable).

Not having sufficient time to select or implement a GRC technology might reduce the overall quality of the GRC technology, e.g. the vendor delivers a release without conducting quality assurance in order to meet the deadline and, consequently, the release may comprise more bugs, which could have been avoided if the vendor had invested more time in quality assurance.

How to avoid?

The organisations should define a realistic timeline in which the quality of the GRC technology can be ensured and employees are not overstrained. All relevant stakeholders including the vendor should be consulted in the development of the timeline. This is a form of risk management because an unrealistic timeline will make the project team and the vendor cut corners, leading to an unsatisfactory result.