An example of a Risk Management Procedure

In case you haven't gathered, I'm a fan of straightforward documents. This is especially true of when you want people to take action. Fifty page procedures rarely get followed - or even read. The following however, is an example of a risk management procedure which addresses six main areas:

• Scope
• Purpose
• Reference
• Definitions
• Responsibilities
• Procedure
• Documentation

=========================


RISK MANAGEMENT PROCEDURE

SCOPE
This procedure provides information for all personnel who are responsible for risk management.

PURPOSE
The objectives of this risk-based system of internal control are to assist JBS in achieving its strategic objectives for the benefit of the community by:

• protecting our people, the community, and commonwealth assets (financial, property, and information)
• facilitating optimal use of resources and provide a system for setting priorities when there are competing demands on limited resources
• assisting us to realise opportunities 
• providing stakeholders and the Australian Community with grounds for confidence in the Organization
• supporting innovative decision making through recognition of threats and opportunities
• improving service delivery, reporting systems, outcomes and accountability

REFERENCE

• ISO31000:2009 Risk Management Standard
• Risk Management Policy
• Strategic (Enterprise) Risk Management Guideline
• Program (Divisional) Risk Management Guideline
• Project Risk Management Guideline
• Operational Risk Management Guideline
• JBS Risk Monitoring and Reporting Manual
• Risk Management Team Intranet Site

DEFINITIONS
Barrier
An existing control. includes systems and procedures already in place to mitigate risks.

Consequence
Collective sum of all impacts to the capabilities of an organization(s) including long term and indirect effects such as combined health, economic, and psychological impacts.

Environment
Conditions or influences comprising built, physical and social elements, which surround or interact with stakeholders and communities.

Escalation Factors
Conditions that lead to increased risk due to improvement or diminution of barriers or controls, Eg. Maintenance, foreign currency conditions, failure to audit or inspection treatments or controls.

Hazard
Something which has the potential to adversely impact (ie. cause harm) to an asset if not controlled or if deliberately released or applied. Eg. explosives, bio-hazards, flammable liquids, firearms, trojan, virus et cetera.

Likelihood
The qualitative of semi-quantitative assessment or estimation of whether an event will occur, Used as a qualitative description of probability and frequency.

Impact
The immediate downstream result of a risk manifesting. Multiple direct or indirect impacts, when aggregated, form the collective consequence(s) of the risk event.

Risk
The effect of uncertainty on objectives.

Risk level
The relative measure of risk as defined by the combination of likelihood and consequence.

Risk Management 
The culture, processes and structures that are directed towards the effective management of potential opportunities and adverse effects. The coordinated activities to direct and control an organization with regard to risk.

Risk Treatment
Measures that modify the characteristics of organizations, sources of risks, communities and environments to reduce risk,

Source (of Risk)
A real or perceived event, situation or condition with a real or perceived potential to cause harm or loss to stakeholders, communities or environment.

Threat
An indication of something impending that could attack the system. includes strategic threats such as a regional conflict or tactical threats such as impending physical attack. threats are usually measured in terms of intent and capability. the term includes known (stated or assessed intention or determination to inflict pain, loss or punishment on someone or something) or unknown (undeclared, hidden or potential) threats. Malicious threats such as system hacks, data destruction, data modification, theft of iP, bomb threats, sabotage, fraud, can be categorized within a range going from rational (obtaining something of value) to irrational (attack against of assets without benefit).

Treatment
Controls that are proposed (i.e. not yet existing) to reduce or mitigate the likelihood or consequence of an event occurring, that is to reduce the residual risk.

Vulnerability
The susceptibility of stakeholders, communities and environment to consequences of events.


RESPONSIBILITIES
Risk management is a core management requirement and integral part of day-to-day operations. As individuals we all play our part in managing risk and staff at all levels are responsible for understanding and implementing JBS risk management principles and practices in their work areas.

Division Heads, Line Managers, and Team Leaders are responsible for applying agreed risk management policy and strategies in their area of responsibility and are expected to:

• Ensure that risk management is fully integrated with corporate planning processes and considered in the normal course of activities at all levels 
• Identify and evaluate the significant risks that may influence the achievement of business objectives
• Assign accountability for managing risks within agreed boundaries
• Ensure that a risk based approach is communicated to our people and embedded in business processes
• Comply with JBS and Government standards which relate to particular types of risk
• Define acceptable levels for risk taking and apply fit for purpose mitigation measures where necessary
• Design, resource, operate, and monitor internal risk management systems
• Monitor the effectiveness of the system of risk management and internal control 
• Report identified weaknesses or incidents to executive management in timely fashion
• Provide quarterly risk management and treatment progress reports to executive management

The Chief Risk Officer is responsible for the development, coordination, and promulgation of the JBS Risk Management Framework including monitoring and reporting systems capable of identifying and reporting new and evolving risks.  The Branch will coordinate training and assistance regarding implementation of the risk management framework, and ensure adequate information is available to all staff.
The CEO is responsible for managing risk across the organization.

PROCEDURE
ISO31000 was developed with the objectives of providing a generic framework for identification, analysis, assessment, treatment and monitoring of risk.  The JBS Risk Management process follows the ISO31000 methodology (illustrated below).

Figure 1: ISO 31000 Risk Management Process

The process of managing risk at JBS involves:

• establishing the context associated with the program goals and activities;
• identifying the risks (including identifying the likelihood and consequences associated with each risk);
• analyzing the risks;
• assessing and prioritizing the risks;
• treating the risks (including a cost/benefit analysis of the treatment options); and
• continually monitoring and reviewing the risks and treatments

This is illustrated below in Figure 2 where responsibilities for each step are shown by the lines entering and leaving the respective element of the process flow.

 Figure 2: Risk Management Process Flow at JBS


This procedure should be read and applied in conjunction with the relevant JBS Risk Management Guideline and tailored accordingly to the appropriate level of area/activity being managed. These Guidelines and tools have been developed for the following organizational levels:

• Strategic (Enterprise) Risk Management Guideline
• Program Risk Management Guideline
• Project Risk Management Guideline
• Operational Risk Management Guideline

Establish the context.
Define the stakeholders and review the levels of acceptable risk using tools such as consultative groups, and develop risk evaluation criteria. Successful RM requires the effective engagement of stakeholders and subject matter experts.  Effective engagement enables the strategic management of uncertainty and develops resilience amongst those involved.  RM goes far beyond being a technical or political process - it is also a communications process.

Identify risks.
Identify and describe the sources of risk, stakeholders, communities and environments.  Scope the vulnerabilities and describe the risks.  There may be great diversity of opinion on the actual risks and their various sources, given different perceptions, knowledge and experience.

Analyze risks.
Analyze the risk associated with the problem by determining the likelihood and consequence of the identified risks.

Evaluate risks.
Compare risks against risk evaluation criteria, prioritize the risks and decide on risk acceptability.
Treat risks.
Identify and evaluate the treatments. Respond to the level of risk by deciding which source of risk, stakeholders, communities or environment can be addressed, either by increasing resilience or robustness, to reduce risk. Model changes to obtain the new level of risk. Select treatments, plan and implement.

Communication and consultation.
Where stakeholders and communities contribute to the decision making process there is a much larger pool of information and expertise to enable appropriate solutions to be developed. For catastrophic events communication and consultation is considered extremely important. Communication and consultation develop resilience amongst stakeholders and communities and will be invaluable in terms of regaining control of business activities.

Monitor and review.
Systems that monitor and review risk, and its management, must be established and maintained. Latent and residual risk are ever-present.  RM must be on going to ensure that change and uncertainty can be accommodated.

DOCUMENTATION
Each stage of the risk management process should be appropriately documented to retain knowledge and satisfy audit requirements. Documentation should include objectives, information sources, assumptions, methods, decisions, and results.
Individual projects and groups maintain Risk Registers, and enterprise risks are escalated to a Strategic Risk Database (SRDB).

Decisions concerning the extent of documentation may involve costs and benefits and should take into account the factors listed in Clause 5.2. At each stage of the process, documentation should include:
a) objectives;
b) information sources;
c) assumptions; and
d) decisions.
The Appendices include examples of a risk register and treatment plan, however more detailed templates are also available from the Risk and Security Intranet site.

=======================
The above procedure and process flow examples work equally well for all types of procedures. If you'd like to download templates in MS Office format, you can find them at my download page: http://www.juliantalbot.com/Downloads.htm

Different views for this blog...

Blogger recently started offering some different ways to view and read the articles created here so I thought I might share them with you.

They all have some merit depending on your reading style but my favorite is snapshot view. See what you think:

• http://31000risk.blogspot.com/view/snapshot (my favourite) 
• http://31000risk.blogspot.com/view/sidebar is pretty handy for quickly skimming the blog titles
• http://31000risk.blogspot.com/view/timeslide is a quick way to get a feel for the articles and graphics overall
• http://31000risk.blogspot.com/view/flipcard is OK but (in my opinion) not very helpfulk
• http://31000risk.blogspot.com/view/mosaic is er, a bit of a mish-mash

Hands up if you love Swiss Cheese

I love Swiss cheese. And I’m not talking about the dairy comestible. In my view, there are better cheeses out there – but few better risk management concepts. Swiss-cheese theory is a beautifully elegant way of illustrating the idea that before any risk can manifest, multiple barriers must be breached. This applies both to negative and positive risks although, in the case of opportunities, one might like to rephrase it that multiple enablers must all line up.

Rather than just talk about it though, the easiest way to explain Swiss-cheese theory is with a picture.

Figure 1: Swiss Cheese Example

By way of example, the 2009 bushfires in Victoria, Australia, which claimed 173 lives and injured 414 people, were a classic Swiss cheese scenario that had been building for many years.  To highlight but a few pre-conditions to these sad statistics:

• The Australian population had been moving increasingly to rural areas in search of lifestyle benefits for at least a decade. 
• Building codes which allowed people to move into high risk bushfire areas, didn’t (at the time) require a ‘bushfire attack assessment’ and were based on fire temperatures of 730 degrees Celsius although bushfires can peak at approximately 1,330 degrees.
• Victoria had experienced a decade of drought conditions. Combined with forest management practices, which focused on environmental habitat protection at the expense of controlled burns to reduce fuel loads, created ideal pre-conditions for fire. 
• Unique weather conditions in February 2009 condition for the loss of life.   The Forest Fire Danger Index (FFDI) based on rainfall, evaporation, wind speed, temperature and humidity  considers a rating between 12 and 25 as a "high" degree of danger. Any day having a danger rating of over 50 is considered an "Extreme" fire danger day. The FFDI on Black Saturday, 7th of February, 2009, reached 180, the worst fire conditions ever recorded.

Changes to any one of the above factors wouldn’t necessarily have stopped the fires, but could without question have significantly reduced the death toll.  Of course, there are many more factors and the above illustration is simplistic in the extreme but like 'Black Swans' they were immediately apparent in the post-event coronial inquiries.

The Basic Idea Behind Swiss Cheese


The Swiss-cheese model was initially developed by James Reason to illustrate how analysis of major accidents and catastrophes tended to reveal multiple, smaller failures that allowed a hazard to manifest as a risk.   Although looking primarily at safety risks, his research also indicated that human error was consistently the largest contributor to risk management failures.  It is reasonable to say that human competence or accuracy is equally behind the vast majority of successes.

In Reason’s model, each slice of cheese represents a barrier, any one of which is sufficient to prevent a hazard turning into consequences.  Swiss-cheese theory works on the assumption that no single barrier is foolproof.  They all have failings or ‘holes’ and when the holes are allowed to align, a risk event can manifest as negative consequences.  The interdependent nature and benefits of redundant layers of mitigations associated with the protection-in-depth principle is illustrated by the Swiss-cheese.

In my experience with risk management and incident investigation, I have yet to see a serious incident which didn’t require half a dozen or more pre-conditions to all align. Some of these were pre-event and some post event but in every case, any one of a number of barriers could, if it had been effective, have either reduced the magnitude of consequences, or in many cases, have completely prevented the incident.

It doesn’t take a big leap of faith to understand that opportunity realization works in similar ways. For a major project to succeed, any number of steps and pre-conditions have to line up. Remove funding, planning, competent staff, executive management support and invariably, you will see an adverse impact on the project outcomes.

Swiss cheese theory may look like a simple illustrative tool but it has profound implications for the way that we manage risk. In terms of preventing losses, it's linked to the fundamental idea of protection-in-depth. What this means for us as risk managers, is that when we build risk mitigation plans, the multiple layers of treatments need to integrate and support each other. It’s a near certainty that on a long enough timeline, every risk treatment will fail or leave vulnerabilities.  The trick is to make sure that they don't all fail concurrently.

Equally, every opportunity realization project needs to have mutually supporting enablers that build on each other, assuming (not unreasonably) that at some point each will require the support of another project element.  Swiss cheese… the best thing since sliced bread!

It's not just about the numbers...

The previous article (It's a question of values) discussed how to tell if risk management is supporting organizational objectives.  In the ideal world, it's not a difficult thing to do: metrics such as payback period, Net Present Value (NPV) and Return on Investment (ROI) give an easy cost/benefit calculation. At the very least, you can usually tell if you achieved some tangible benefit. In practice it's not so easy and that's what this article is about.  (By the way, if you're very short of time, the key points are summed up in Table 1 below, but if you're like most of us and only moderately short of time, it's probably worth reading the full article.)

The So-called ‘Soft’ Benefits
Unlike most business investments, risk management is often seen as delivering a 'soft' benefit. By this, I mean that the benefit is sometimes difficult to measure directly. Typically, there is likely to be a benefit, but it is unclear whether the predicted savings will be realized in the bottom-line or otherwise quantified.  Risks are by their nature, abstract concepts - things that may or may not occur, and hence any proposed risk treatments have abstract benefits. Even if you do implement a risk treatment:

1. The risk may not realized and the predicted consequences never occur, 
2. The risk occurs but the scope and damage are less than predicted. 

This issue of soft vs. hard benefits doesn't invalidate the risk management business case, but it does make it rather unusual. While most business cases include both hard and soft benefits, many of the important benefits with risk management have in the past been ill-defined or unstated.

Making Intangible Benefits 'Tangible'

There is no such thing as ‘perfect risk management’. All risk management involves making trade-offs, some of those stated, but many unstated.  More often than not, it's these unstated or seemingly 'intangible' elements that will make or break the case for risk management.  We will often also have to make decisions and trade-offs regarding perceived versus actual risks.  Sometimes managing the actual risk will also mitigate the perceived risks and vice versa.  Sometimes not.

Sometimes it may appear that the perceived risks are more important than the actual risk, and other times vice versa.  There are many reasons, why we might choose to focus more on managing perceived risks.  For example, removing nail clippers from airline passengers may have little to do with managing the actual risk of hijack but it is part of the process that visibly demonstrates that something is being done.  In fact, the risk of hijack is usually perceived by the travelling public, to be much higher than it actually is. The greater risk associated with airline hijackings, is therefore not one of hijack but the risk that people lose confidence in aviation safety, with the resulting economic costs and the increased road fatalities.  

Similarly, it will often be appropriate to put in place measures such as tamper proof packaging on food and drugs even though it is still entirely possible to contaminate the goods inside.  Such measures in practice will only deter the lazy or ignorant would-be poisoner, but they do reassure the consumer to continue purchasing the product.

Of course, these issues of perceived versus actual risk are largely subjective and will vary depending on individual risk criteria and level of understanding. Many risk management projects have more benefits to an organization than the ones that are cited, but some of these benefits may be difficult to quantify in absolute terms. A significant driver in the decision-making process is likely to be personal or organizational agendas, which will involve greater or lesser good to various parties.

Don't lose heart however. I'm about to give you a bundle of ideas regarding how you can identify seemingly intangible risks and illustrate the value they add.

Some Practical Tips on How to Measure the Immeasurable

Firstly, it's worth going out on a limb by saying that intangible benefits are something of a misnomer. All benefits are quantifiable - if we think laterally.  Intangible benefits in this context, represent benefits that are difficult, or impossible, to accurately predict and measure in financial terms. Often, however, these intangible benefits can be quantified into Key Performance Indicators such as percentage market share, or industry ranking. Some simple examples of intangible benefits to be considered when evaluating and measuring the performance of a risk management project include:

• Brand Advantage - reinforcing, advancing or changing an organization's reputation as a safe and/or well managed place to work
• Strategic Advantage - working towards or meeting overall corporate objectives
• Competitive Advantage – getting into markets ahead of competitors faster and less expensively, better addressing customer needs, meeting changing market demand, scaling easily and more cost effectively, and gaining market share
• Intellectual Capital - increase in relevant knowledge gained by risk management and other staff, and the perceived market value from those gains
• Organizational Advantage - enabling an organization to function more effectively, or reinforcing or recreating a corporate culture 
• Risk Avoidance - the risk of NOT implementing a solution

Table 1: Metrics for Measuring Intangible Benefits

Every company or organization has objectives that are measured in non-financial terms. Some of these include improvements in branding, image, customer satisfaction, product development time, employee recruitment, and many others come in this category. Reaching these objectives should ultimately translate into either financial savings or increased income, but the objective and progress towards it are measured first in non-financial terms. Does your proposed action contribute to one of these objectives? If so, it deserves some attention.

If you were writing the business case for risk management, I'd suggest that assigning financial value to benefits should be one of the last additions to the business case, not as is often the way, the first. If you can show in tangible terms that your proposal contributes to a business objective, the benefit is real.  If management agrees that reaching the objective has value, then the benefit has value.  That much of the value proposition is solid.

Sure, measuring the links between risk management and (say) staff skills, can be easier said than done. When trying to assign value to a risk management initiative however, sit down with your colleagues, finance team members, and managers to decide 'what is the value of reaching the objective?' and 'does the risk management framework or treatment contribute to this?'.  If the answer is yes, the only question remaining is: 'what percentage of that value should be credited to the risk treatment?' The figure you agree on may not be 100%, but it should not be 0% either.  

------------------------------------

NB. Hope it's useful reading for you. This article is actually an excerpt from another ebook titled 'The Business Case for Risk Management'. Due out in the next month or so.