My good friend Michael Rasmussen works with a good number of the companies that sell solutions for risk management (these days typically packaged with other "stuff" and mislabeled GRC solutions). He also helps a good number of buyers of those solutions, as well as participating in related conferences and seminars.
Michael is a smart and insightful individual whose views merit our attention. He recently wrote a blog post on the topic of "Where Risk (and GRC) Technology Fails."
Michael makes a good point when he talks about the need to "normalize" risk assessments. This is what he says:
"Risk normalization is simply the ability to compare apples to apples. If one department's high risk is another department's low risk this should be evident in risk reporting. Risk aggregation is the ability to take risks from different areas of the business and roll them up into an enterprise view of risk that makes sense. Risk normalization and risk aggregation work hand and hand. To aggregate risks properly requires that the technology have the logic to do risk normalization."
I think that while he has a point, Michael has pointed to a detail instead of the big picture.
I believe most failures are due to not adequately following a disciplined approach to purchasing software — the same disciplined approach that has been required for decades and enshrined in life cycle methodologies.
The failure has been in identifying requirements.
I am not saying that buyers are not listing what they see as requirements. I am saying that most of the time they are not done well.
Let me explain what I mean.
In my experience, buyers have a vision for a technology-enabled risk management program that is similar to what they have been doing in risk management and what consultants have told them works well: a periodic review of a list of top risks.
They are documenting what their requirements are from the perspective of the risk officer (and sometimes the internal auditor).
They are not considering what is needed for risk management to be valuable to management and decision-makers across the enterprise.
To be successful, a risk program has to be designed to enable managers to make intelligent, risk-informed decisions every day.
The requirements have to include the perspectives of both the risk officer and of management, both those reviewing high-level reports and those taking risks.
A periodic review of a point-in-time list of top risks is not effective risk management, yet that is all most of the solutions offer.
Where are the risk monitoring tools that automate the updating of risk levels as they and the business change? I wouldn't buy something that didn't have automated risk indicators.
Where are the reports, dashboards, and other tools that let a manager review progress against strategies and objectives with a combined view of both performance and risk?
When it comes to reporting, how do these tools enable management by exception, telling executives
what they need to know
when they need to know, in a concise and easily consumable form, so they can ensure they are taking the right risks as they manage and direct the organization?
A consultant commented on my blog about governance risks that they can be monitored using GRC solutions. Balderdash! As became clear when challenged, he is helping sell a GRC solution that will report risk levels but the monitoring is all manual.
Risks change constantly and if you need to know about changes in risk you need a solution that provides the capability to harness the power of analytics as well as human intelligence to not only maintain a register of risks but their current level — and provide management with alerts and such when action is needed.
Michael makes a second excellent point:
"Another reason is a failure to align risk with business strategy, objectives, and performance. The ISO 31000:2009 definition of risk is "risk is the effect of uncertainty on objectives." This might be done well at a project or operational process, but as you roll out enterprise and operational risk technology the organization fails to provide the alignment of risk to business strategy and objectives."
Management needs to focus on strategies and objectives and how well they are being executed.
An effective risk management implementation must enable managers to see risks from the strategy and objective down.
In other words, it is not sufficient to take each risk and link them to one or more strategies. You need to enable managers to see both performance and risk status for each of their objectives and strategies.
My advice is this:
Understand how risk management can help your decision-makers take the right risks and executives monitor progress against their strategies and objectives.
Now and only now think about how technology can help.
Document that as your requirements definition.
Only buy when you are convinced that the solution will enable your organization to reach an acceptable level of risk maturity (see this discussion of risk maturity models). Don't get something that is acceptable for today but lacking when it comes to what you will need going forward.
I welcome your comments and discussion.