Introduction
Most organisations aspire to practise effective Enterprise Risk Management (ERM), but very few are achieving it. Over the last decade, much effort has gone into implementing systems to comply with Sarbanes Oxley, COSO, Turnbull, Basel II, COBIT and other regulatory standards. As a result, many organisations are now stuck in a world of compliance-oriented risk management. By doing so, they are failing to take advantage of the benefits gained from the more strategic approach that ERM offers.
Putting ERM in place delivers significant benefits:
- Accurate business planning and objective setting
- Enhanced reputation and credit rating
- Faster and more informed decision making
- More efficient use of capital
- Greater confidence in negotiating key contracts
- More efficient management of supply chains
- Increased insight into product demand
- Improved performance and shareholder value
- Reduced cost of insuring risk
- A sound platform for corporate governance.
Figure 1. The five steps to ERM
There are five steps to Enterprise Risk Management, as illustrated in figure 1. These steps were outlined in a whitepaper, “Five Steps to Enterprise Risk Management”, published in December 2010. This whitepaper gave an overview of how organisations can address the gap between compliance and ERM, providing insights for the Chief Risk Officer (CRO).
In May 2011, we published the first of a series of whitepapers that explores each step in more detail.: “The first step to ERM: Establish an Enterprise Risk Structure”. It explains how to establish an enterprise risk structure by:
- Setting out the organisation’s vision for risk management in its risk policy and framework documentation
- Establishing an understanding of the organisation’s risk attitude and defining acceptable thresholds
- Embedding risk management from the executive board down
- Accommodating and assimilating multiple risk perspectives into the enterprise risk picture.
This whitepaper discusses the second step to ERM. It explains how to distribute responsibility for risk management across an organisation by breaking that organisation down into meaningful chunks, called Risk Management Clusters®: a natural structure for rolling up and aggregating risk.
All whitepapers are available to download from the Risk Decisions website https://www.riskdecisions.com/whitepapers.html.
Breaking the organisation into Risk Management Clusters
The first thing the Chief Risk Officer needs to do when distributing responsibility for risk management, is decide on the appropriately sized ‘chunks’, for managing a set of risks. These ‘chunks’ typically have specific objectives, for example:
- programmes and projects have well defined deliverables
- contracts are required to comply with their service level agreements
- departments must deliver against strategic business objectives
Dividing and organisation into these ‘chunks’ allows people to work locally, focussing on their specific objectives, while providing a structure for enterprise reporting and escalation. This means that the right people receive timely information about risk, enabling them to make the informed decisions which underpin any successful business.
The ‘chunk’ of the business, the person responsible and the associated risk management activities are the items that make up a Risk Management Cluster®. The individual manager who has overall responsibility for ensuring risk is managed against agreed objectives is called the Cluster Owner.
Each cluster also has a second named person, the Cluster Leader who is responsible for approving any change to objectives, budgets and risk value thresholds. It is easier to set up clusters in some parts of the organisation than others. For example, programmes and projects are straightforward, as Figure 1. The five steps to ERM they generally have formal processes for managing risk already in place. However, it is less clear how to go about risk management within a functional or support area of the business. Therefore, it helps to consider what different types of cluster may exist in your organisation. These types generally arise whenever there is a different approach or perspective on risk management.
Figure 2: Four different perspectives on Risk Management Clusters
Experience of ERM implementation so far indicates that there are typically four ways in which clusters are used: strategic, horizontal, vertical and third-party, as shown in table 1.
The way that each of these four different types of clusters work are explained in table 1 below. Using these different cluster types supports the rollout of ERM, by allowing each cluster to implement risk management in a form suited to their business perspective, level of maturity of the team etc. Any area of the business that already has wellestablished risk procedures can continue to operate those procedures locally within their cluster. Therefore, the ERM initiative need not impact adversely on existing good practice: the most significant additional work required is to implement roll up and aggregation across clusters, to provide an enterprise view of risk, as is explained further below.
Creating a Risk Management Cluster
Cluster owners are responsible for creating within the cluster all the risk management activities for their local area of the business. They must ensure risk management is relevant, effective and efficient. To achieve this, they need to ensure they establish the following:
- The team of people who will own and manage individual risks and actions – the cluster owner cannot manage all risks
- A definition of high/medium/low risk impact, and the threshold point at which a risk must be escalated. Thresholds are defined within the organisation’s risk framework documentation, by defining risk attitude
- A set of categories representing risk themes – allows searching for and identification of risks that will be gathered together under parent risks
- Approved budget for cost and schedule risk provision (contingency) – enables a fast response to risks that materialise
- A record of progress against objectives and projections of the level of risk going forward
Setting up clusters in this way facilitates timely decision making; with budgets pre-approved and the escalation process known in advance there is a minimum of red tape to get through when fast action is required. For example, after a major earthquake supply chain teams with appropriate risk management plans in place were able to quickly assess the overall impact to the supply of specific components and move to lock-up any remaining alternative supplier capacity assuring continuity of supply, as well as headaches for industry competitors! Provided the organisation has clear risk management policy guidance (defined in the organisation’s risk framework documentation), it is generally straightforward to set up clusters with this information.
Rolling up and aggregating risk using clusters
Figure 3: Vertical managers have a role as both leader and owner of risk management clusters
Having broken the organisation down into discrete Risk Management Clusters, and having set these up in a way which will work within each area of the business, you are now ready to use a structured approach to combining the collective risk information in those clusters. This provides a strategic view of risk information at higher levels of the organisation.
The most effective approach defines relationships that allow roll up and aggregation of risk through vertical escalation, horizontal communication, threshold reporting, and themed aggregation.
(a) Risk roll up through escalation: the Owner-Leader cluster relationship
Vertical clusters use the Owner-Leader relationship chain to escalate information. This involves the owner of one cluster being defined as theleader of the clusters below, automatically providing a chain of accountability back up through the organisation, as shown in figure 3.
When a risk is escalated within Project X, it first gets assigned to Sam, because he is the owner of Project X. He may discuss it with his Cluster Leader Fred, and agree escalation to programme level, where Fred automatically takes responsibility for it. If Fred is able to put in place a satisfactory response to this risk, he can delegate it back down into Project X, along with the necessary budget and resources to handle it. But if Fred cannot manage it at Programme level, he will escalate it to his Programme leader Jo, who automatically picks it up at divisional level. This process continues until it reaches a level where a management response can be put in place, before delegating it back down the same route it came up.
In this way, each person’s responsibility takes two forms: ownership at the higher level and leadership at the level below. For example, a programme manager will manage his programme risks, but also have responsibility for overseeing risk within each of the programme’s projects.
(b) Managing risk through common leadership of clusters at the same level
The cluster structure in figure 3 is not only useful for escalating risks, but is also designed to assist when you identify a risk in one project that is caused by another project. For example, let’s say Contract Q is developing a technology that will be used by Project Y; late or limited delivery of that technology by Contract Q will impact on Project Y. This risk must be managed through communication and cooperation at programme level, facilitated by the fact that the leader Jo, for Programmes A and B, are the same.
Although the example here uses programmes and projects, the same vertical cluster system works for multiple departments, business units, divisions and so on – anything that has a vertical reporting structure would use escalation and then horizontal communication to support management of risk.
(c) Risk roll up through reporting: using thresholds
Each cluster has a set of thresholds, established through setting high/medium/low scoring criteria for risks. As you go up through vertical clusters, the thresholds for reporting increase. Therefore, a risk that appears ‘high’ in Project X will only appear ‘high’ at Programme A above if it is significantly large. Thereby filtering out information as you move further up the organisational structure, and highlighting only the risks that require management attention.
(d) Risk aggregation: using common themes
Typically, horizontal and strategic clusters use themes (or categories) to gather risk information; for example the health and safety functional manager will look for common health and safety risks across the business and manage most of them under a small set of centrally formulated risks with associated actions. Similarly, the organisation’s strategic director will gather risks associated with business objectives. They will then try to understand common causes and appropriate responses and / or consider adjusting business objectives at strategic level.
It is the responsibility of functional and strategic managers to define the categories they are interested in and to ensure that clusters throughout the business use those categories when they are identifying risks.
For example, if the central procurement function manager wants to analyse risk by supplier, they will need each cluster to identify risks associated with a set of suppliers. Then a search across all clusters by supplier will provide an aggregate view of risk by that supplier. Similarly, the HR manager might use global categories, to identify common skills shortfall risks to bring them under central management. And the business continuity manager may identify risks relating to use of a specific test facility and then manage them under one site management plan. The strategic business manager must define the set of objectives to which risks need to be linked.
The next whitepaper, ‘ERM Step 3: Create an enterprise risk map’, will examine the identification and use of categories to define risk themes in more detail.
Viewing enterprise risk across clusters
A view across clusters provides an overview of how well risk is being managed throughout the organisation. A review of cluster status, for example using a Red/Amber/Green cluster flag to show each cluster’s confidence of achieving targets within allocated risk management reserves is a useful measure to provide programme, departmental and organisation-wide risk reporting. Reporting at this level depends on clusters being set up as discrete elements; for example, the risk budget for Project X must be recorded against the Project X cluster. The programme budget at the next level up must only contain budget for programme level risk, not for any of the risks being managed within the projects below. It is just as important to ensure you don’t double count across clusters, as it is to make sure you don’t miss anything out. Cluster level reports provide senior managers with the ability to see which areas of the business need most attention, allowing them to direct management attention and appropriate resources in a timely manner. These reports may also trigger new strategic level risks. For example, consider the risk of failing to win a major contract due to a new competitor entering the market. This might trigger a potential hostile takeover bid for the company; these risks would normally be recorded and managed at executive board level. The use of reporting across clusters will be examined in more detail in the “ERM Step 4: Decision making through reporting” whitepaper.
Summary
Having put in place appropriate risk policy documentation (as described the first step to ERM whitepaper (‘Establish an enterprise risk structure’), the next step to ERM is to assign responsibility through the implementation of Risk Management Clusters. It is important for responsibility to be pre-agreed, to ensure a speedy response when escalating risks.
In order to distribute responsibility across the organisation, Risk Management Clusters define entities that have business objectives associated with them. Only by identifying risk directly against these objectives will you be able to focus enterprise risk management activities towards the things that are important to your organisation.
Different types of clusters are used to represent different business perspectives: the most common ones are strategic, horizontal, vertical and third-party. Although each cluster is responsible for managing its own risks effectively, you will only have successfully implemented ERM when you have effective mechanisms for extracting the significant risk information from clusters and raising it to management level where strategic decisions can be made.
Therefore, clusters are brought together to allow roll up and aggregation of risk through vertical escalation, horizontal communication, threshold reporting, and themed aggregation. There are a number of benefits to be gained by assigning responsibility for risk across the organisation, using clusters:
- Clusters allow roll up and aggregation of risk across the enterprise
- Cluster metrics provide a means of measuring success / failure of managing risks and record lessons learned.
- People become directly accountable for risk in their area (cluster)
- The structure helps to avoid missing out key areas of the business that could harbour significant risks
- You can build on good risk management already in place by capturing it within clusters
In order to implement Enterprise Risk Management, not only must a cluster owner understand the risks that affect their area. But they also need to work with other cluster owners to identify and help manage risk across programmes, divisions and so on to identify and mitigate risk through cross-departmental mitigation strategies.
Successful management of risk depends on people accepting responsibility and working together across the organisation to raise the risk to the right level of the organisation (to board level if required) and responding in a timely manner. This is the basis for sound decision making and successful strategic management of the business. The most appropriate way to do this is by assigning responsibility using Risk Management Clusters.
