I have made two observations related to the selection of Risk Management technology that has inspired me to write this blog, and they are:
- Some companies spend a lot of time and money selecting their Risk Management technology. They go through requirements definition, presentations from multiple vendors, proof-of-concepts, prototypes, shortlisting, evaluation and so forth. These selection processes can take from 6 months to a year, involving dozens of people, at great cost.
- Some companies blame a failed Risk Management implementation on the technology that they have selected.
My opinion on the selection of Risk management Technology is that the process should be quick, easy, and relatively fail-proof.
Principles of Risk Management
The principles of an effective risk management framework according to ISO31000 are the following:
a) Risk management creates and protects value
b) Risk management is an integral part of all organisational processes
c) Risk management is part of decision making
d) Risk management explicitly addresses uncertainty
e) Risk management is systematic, structured and timely
f) Risk management is based on the best available information
g) Risk management is tailored
h) Risk management takes human and cultural factors into account
i) Risk management is transparent and inclusive
j) Risk management is dynamic, iterative and responsive to change
k) Risk management facilitates continual improvement of the organisation
Notice that none of these principles say that you should have a report that looks like ABC, or a dashboard that has DEF graphs, or that certain data must be captured, in a certain format, or that certain analytics must be performed, or that it has advanced predictive analysis such as monte carlo. In fact, none of the principles mention anything related to technology requirements. It’s almost as if the technology functionality takes a back seat to more important Risk Management principles. And, I absolutely agree with this.
When I talk to my clients who are undergoing vigorous selection processes, comparing functionality from technology A to technology B, or comparing how pretty the dashboards are, I remind them that Risk Management is a holistic system of governance, culture, people, process, and technology (and more). Technology only contributes about 10% of the overall success or failure of the system. Admittedly this is a subjective figure, but I stand by it. If you consider the technology contribution of even 20% (double my estimate) to the success or failure of a risk management framework, comparing functionality that only constitutes 1%-5% of the overall functionality of the technology (e.g., a dashboard) becomes such an insignificant task that I would suggest time and focus be better spent on the bigger, more important aspects – such as organisational culture, or governance, or information strategy.
To be more succinct and mathematical, comparing a specific functionality such as the look of a bow tie between two technology alternatives, constituting perhaps 5% of of the total functionality of the tool, multiplied by the fact that the technology only contributes 10% of the overall success of the risk management framework, means that you are spending a significant amount of time on a feature that in of itself, contributes perhaps 1/2 of a percent to the success of your Risk Management framework. Why would you spend 6 months on 1/2 of a percent, when you could be spending that same 6 months on more important aspects such as:
- change management
- ensuring risk management is monitored by the right people
- ensuring the right information is provided to the right people at the right time
- data management
- other important aspects!
Risk Management is relatively subjective, has a very large human element, and is therefore often difficult to implement already. So, my suggestion is, focus on the more important aspects, and spend less time (proportionate) on comparing the finer details of technology A over technology B.
Causes of Failure
The other observation relates to failed Risk Management implementations and blaming the technology. I have seen this at quite a few companies now, and in my opinion, it wasn’t actually the technology, or more specifically, the choice of technology that was at fault here. When pressed for details, failure tended to fall into the failure of one of these broad categories:
- Governance –establishing sponsorship at the right level, championship with the right people, accountabilities and responsibilities.
- Data management –addressed during scoping and data strategy. How much data is collected? What type of risk are we managing? How high does the likelihood/impact of the risk need to be before we capture and manage it? Too little data doesn’t provide enough information. Too much data is unmanageable.
- Culture/Education/Change Management –ensuring that all employees understand and embrace the importance of managing risk
- Training –ensuring all employees know what they need to do as part of their risk responsibilities.
- Operationalisation –ensuring all employees are part of risk management, rather than a segregated and/or separate risk management function
- Information strategy –ensuring the right information gets to the right people at the right time
None of these common failure areas are technology specific. Technology facilitates a lot of the above, but is not the cause in of itself for any of the above failing. For example, you can’t blame the technology selection for a failure in data management that resulted in too much, unmanageable risk data.
Comparing and Selecting the Right Technology
I don’t suggest or support a random or blasé approach to technology selection. Technology still contributes 10% to the success or failure of your risk management system, so it does require some due diligence!
I suggest a proportionate level of effort, and if the technology looks to meet 80% to 90% of your requirements, it’s good enough – lets progress with the more important aspects rather than trying to improve the technology-match to 92% or 94% etc.
You’ll probably find that you have differing, and sometimes contradicting requirements within your organisation anyway, so finding technology that meets 100% of requirements is not always possible or feasible.
The two most common methods for selecting the technology are:
- Gather your requirements, and then provide the requirements to a handful of vendors. Let them demonstrate their system meeting your requirements. If they’re able to demonstrate 80% to 90%, then go ahead with them.
- Include the technology as part of a broader risk management implementation. Part of Conceptual Design will include the technologies required to deliver the solution that meets the requirements gathered during the Conceptual Design phase. The advantage of this method is that the Conceptual Design is developed in consultation with all of the appropriate stakeholders of the organisation and the appropriate technologies are then part of the solution. It may be determined that the technology will include more than just a core Risk Management solution. For example, it may include a solution that also manages compliance, performance, and/or business intelligence (analytics). This is my preferred method for technology selection.
Both methods are light weight in that they do not require a separate 6 month product selection process.
At IncQ Consulting, we implement the most common Risk Management technologies. We’re finding more and more that our clients are implementing the Risk Management solution from SAP. The reason being is that their core ERP, CRM, HR systems are on SAP, and it’s a technology that they’re comfortable with, and have a support team that are already effectively managing the environment. The technology meets 80% to 90% of their requirements, and they’d rather then start focussing on the more important aspects of the Risk Management system than delaying and finding technology that meets 92% or 94% of their technology requirements.