Enterprise risk management (ERM) is the Holy Grail in many organisations. Recent events have made ERM even more desirable in some businesses but is this achievable in reality or just science fiction? What is Enterprise Risk Management?Enterprise Risk Management (ERM) is a process by which the total risk to the business is identified, prioritised and managed appropriately. Part of ERM normally involves attempting to quantify the total risk to the business – and this is where the fiction starts!
What are the benefits of applying ERM?
The key benefits that should be realised from applying effective ERM are improving both short term and long term business profitability and performance by:
- Avoiding costly mistakes – by capturing and managing risks to key projects and operational processes
- Validating strategy – by checking that all key stakeholders are “on the same page” with strategic priorities
- Improved operational effectiveness – through the adoption of a systematic and structured approach
- Building relationships – by increasing confidence of stakeholders/clients
- Preserving reputation – by avoiding corporate disasters and associated publicity
- Anticipating market trends – by ensuring that key market assumptions remain valid
What are the challenges?
If I were asked how many times I have seen a truly enterprise-wide risk management process I would have to answer: about as many times as I have seen Klingons at Waterloo station! In other words, very few organisations have implemented ERM effectively – why is this?
- Quantification is difficult/impossible – some risks (e.g. financial, contractual) are easy to quantify whilst others are virtually impossible (e.g. quality, reputational). Therefore when organisations attempt to quantify the total risk to the business they tend mix “good quality” data with “poor quality” data and therefore dilute the value of the conclusions.
- Prioritising enterprise risks is difficult – when it comes to comparing different risks from different parts of the organisation, it can be like “comparing apples with oranges”. This is often because objectives are not clear or prioritised across the enterprise.
- Risk processes are not consistent across teams – leading to differing focus, analysis, prioritisation and management approaches. Again this makes it impossible to build a consistent picture of risks across the enterprise.
- Risk tools are not supported by effective process – very often, software tools are the first attempt by an organisation to provide some consistency. If these are not backed up by an effective risk process, the effect can be one of “GIGO: Garbage In – Garbage Out” as poor quality data is captured, analysed and then presented as a “high quality” result.
At the highest level the problem is that businesses fails to define their ERM strategy. They fail to agree what they are trying to measure and fail to recognise the difficulties they will face in building an ERM process. The most common trap, which is particularly common in financial institutions, is to integrate the various financial risk management measures (e.g. Credit Risk, Market Risk etc) and to call this “ERM”. Then when a large change programme in the company goes wrong, it happens off their ERM radar and has a massive impact on the business.
It will never be possible to achieve high quality quantification across all types of business risk. However, where it is necessary to calculate total risk exposure, a simple model that will allow quantified risks to be combined is shown here.
Risks that can be readily quantified include all types of financial risks. Even in these areas of risk, there can be enormous uncertainty surrounding the quality of the data. Calculating risks around projects and operations is much more difficult. Techniques such as Quality Based Costing will need to be used to model the uncertainty appropriately; otherwise the numbers will be totally guess work. However, you don’t need to quantify risk in order to manage it – but you do need to measure risks in order to prioritise appropriately and this can be done qualitatively.
A tried and tested model for identifying, analysing, prioritising and combining enterprise risks is shown here. This is a simplification of the Quantified ERM framework with the financial risk element removed. This is not to suggest that financial risk should be ignored – far from it – but it is meant to imply that that financial risks should continue to be identified, quantified and managed using established processes and tools. All other risks should be evaluated qualitatively and only quantified on an exception basis i.e. where this can be justified by the quality of the available data and there is a clear need to have a quantified result.
The elements of the Qualitative ERM model are:
Strategic Risk Management – There is no point delivering products and projects on time and budget if the market no longer wants them! Thus it is imperative to identify strategic assumptions and risks as the highest priority. The prerequisite of identifying strategic risk is that the strategy of the business is captured and communicated around all senior stakeholders. Strategic risks will by definition have massive potential impacts.
Operational Risk Management – These are the risks to the ongoing processes in the business (e.g. the risk that a production line will stop). Often operational risks are relatively easy to identify as the processes are well established and staffed by experienced personnel. Many organisations include their projects under “Operational risk” but this is often not a good idea……………..
Programme/Project Risk Management – These are the risks that a programme or project will fail to deliver (e.g. a new product/over budget/late etc). Project risks are more difficult to identify than operational risks as projects are, by definition, trying to introduce something new to the organisation. Risks within major change programmes are the most difficult of all to identify/prioritise/manage due to the programme complexity which makes it difficult to “see the wood from the trees”. These risks are often massive if they relate to a critical change programme for example.
Transformation Risk Management – Projects and programmes that result in significant change (such as new product development, mergers and acquisitions) will “transform” the current business. This is often when the business is exposed to most risk as the pressures increase the risk to both the current operations and the projects trying to transform them. For process purposes, Transformation Risk is often treated as part of the Programme/Project Risk
Contingency Planning – Strictly speaking, this is not “risk management” i.e. risk management is about stopping risks occurring (i.e. pro-active) whereas contingency planning relates to what to do if the risk impacts (i.e. re-active). However, this is an essential part of any ERM system as business continuity is paramount for any organisation.
ERM in practice
The key to successful ERM is to clearly define the scope of your “enterprise” and be prepared to accept that you will not be able to quantitatively measure all aspects of business risk accurately – recognise and discriminate between good quality estimates and guesswork. Set up a consistent qualitative rating system so that you can compare “apples with apples” and therefore prioritise risks consistently across the organisation.
And having done all that you can beam me up Scotty!
Hi Keith – following on from our conversation a couple of weeks ago – can you do a piece on strategic risk management to follow-on from ERM? I now have the ear of the right people and if we can show them a simple and quick way forward, we may get you some busines :-)
Keith, I would echoe that – would be really interested to understand more about strategic risk management. Loved the Birdman video by the way
[…] De-RISK Blog « Enterprise risk management – Science fiction or reality? […]
Hi keith – Happy Birthday for today! By the way, how many time have you seen Kiligons at Waterloo?
Thanks Susan – still recovering from the party! Actually I did see Klingons at Waterloo – must have been a Star Trek convention. Only ever seen them once though………..
Happy belated birthday. Keith – I am starting to get pressure from “above” to create an ERM system. As you know, we currently have all the usual treasury based risk management plus operational risk, as such. Where should we focus next in your opinion. I appreciate that we may need to discuss off-line but thought that this might be a interesting blog question?
Hi Jon – thanks and a fair question. The answer of course is, it depends…… In your situation in a financial institution it would be tempting to strengthen the operational risk before adding a distinct project risk management element. However, I would always suggest introducing a formal strategic risk management process first as there is no point managing the detail if the big picture is at risk. Feel free to call me anytime to discuss further.
I believe following the Khitomer Massacre, Klingons and Romulans were banned from Zone 1.
Have a look at this post from Riskviews about how risk management is the third most important need of a firm.
Thanks Trevor – yes – I think they got Oyster cards in the end though :-)
Had a look at the Risk Views link – very good -recommended.
Keith – can you expand on the GIGO thing. As you know, we purchsed ARM some time ago and I think that we may be suffering from this problem. The system is open to all programme team members and we are struggling to cope with the mass (and mess) of information. How can we deal with this problem?
Peter – ARM is a classic “tool without a supporting process”. It assumes that people will be able to tell the difference between and issue and a risk and between a well described risk statement and a poor one – and people generally can’t! The only way that I know of to deal with this situation is to manage the data quality on input. This means not allowing team memebrs to enter new risks directly but going through some person (a “Risk Administrator”) who can tell the difference between a good and poor statement. Be aware that this can be difficult using traditional risk managenent approaches as the input is often very loosly structured. Hope that this answers the question?
Keith – thanks. I suspected that I was going have to go the route of appointing a full-time risk manager and I think that you have confirmed that. Maybe we also need to revisit the idea of implementing ABCD again. Is it possible that we could amend ARM to support ABCD do you think?