Putting Risk into (your) context

Putting Risk into (your) context

At a recent discussion with a bunch of high IQ “quants”, who specialize in risk quantification, it became obvious that they had neither gone through the steps of defining the context of the risks involved in their analysis, nor had they undertaken a very rigorous risk identification process.  So I promised them a few words (which seem to have expanded!) explaining what I was on about. This blog is a rehash of various notes that have accumulated on my hard disk over the years.

The risk analysis/management process should begin by defining what we want to achieve and attempting to understand the  factors (both internal and external) that may influence our success in achieving our objectives. This preparatory phase, called ‘establishing the context’, is an essential precursor to risk identification.

 This contextual review should be the first step in any risk process.

 

According to ISO 31000 (2009),

 3.1 Establishing the context

“By establishing the context, the organization articulates its objectives, defines the external and internal parameters to be taken into account when managing risk, and sets the scope and the risk criteria for the remaining process”

Introduction

By establishing the context, the organization articulates its objectives, defines the external and internal parameters to be taken into account when managing risk and sets the scope and risk criteria for the remaining process.

 It should be established because:

  1. Risk management takes place in the context of the objectives of the organization
  2. Objectives and criteria of a particular project, process or activity should be considered in the light of objectives of the organization as a whole

 

 The first phase of any risk analysis involves a detailed specification and review of the project or activity, its objectives and the main assumptions behind it. Its aim is to ensure the risk analysis team is thoroughly familiar with the project – in other words, make sure that the context is well defined.

 It is useful to divide context into “external” and “internal”

 The external context is the external environment in which the organization seeks to achieve its objectives and can include, but is not limited to:

  • The social and cultural, political, legal, regulatory, financial, technological, economic, natural and competitive environment, whether international, national, regional or local
  • Key drivers and trends having impact on the objectives of the organization
  • Relationships with, perceptions of and values of external stakeholders

 

 The internal context is the internal environment in which the organization seeks to achieve its objectives. The risk management process should be aligned with the organization's culture, processes, structure and strategy. Internal context is anything within the organization that can influence the way in which an organization will manage risk.

 This can include:

  • The organization's culture
  • Governance, organizational structure, roles and accountabilities
  • Policies, objectives, and the strategies that are in place to achieve them
  • Capabilities, understood in terms of resources and knowledge (e.g. capital, time, people, processes, systems and technologies)
  • The relationships with, perceptions and values of internal stakeholders
  • Information systems, information flows and decision making processes (both formal and informal)
  • Standards, guidelines and models adopted by the organization; form and extent of any contractual relationships

 

After having reviewed the differential external and internal contextual elements, they can be incorporated into the process that follows:

Define scope & objectives

  • What are the aims & objectives of the project or activity?
  • How do they relate to corporate strategies?


Stakeholders

  • Which stakeholders are affected by the activity?
  • Which stakeholders can affect the results of the project?
  • Who are the most important stakeholders?
  • What are their aims and objectives?

 

Identify criteria

  • What are the criteria for measuring success?


Define key elements

  • Develop a set of elements for structuring the analysis


Deliverables

  • List critical success factors
  • List key elements

Objectives      

In the first step, begin by identifying the scope of the activity and the main issues of concern. You should state the aims and objectives in terms of the specific project or activity and relate them more broadly to the organization’s key themes, corporate strategies and business plans.

Specific requirements are typically related directly to the activity or project itself. They include such objectives as:

  •  Cost control, ensuring that the activity is conducted within the available budget
  •  Schedule control, ensuring the activity is completed within the specified time frame and milestones
  •  Performance quality control, ensuring the delivered outcome is suitable for its intended purpose
  •  Community acceptance of the new activity

You will need to interpret requirements carefully, depending on your objectives and the phase of the project cycle.

  •  In the planning stages of a project or activity, the requirements are often related to corporate policy, including the growth and rate of return targets.
  •  Technology criteria may be important in the design stage.
  •  In the bidding stage, contractual issues and value for money become important considerations.
  •  Later, in the delivery, operation, maintenance and marketing stages, criteria are likely to be more specific. For example, they may be concerned with the most efficient completion of a project, the optimum provision of products and services at an appropriate price and the satisfaction of users’ needs.

 

Stakeholder Analysis

Explicit stakeholder analysis is important in most risk assessments. The differing objectives of these parties involved in a business activity and the contractual relationship between them, are key determinants in the allocation and management of risk.

 Stakeholders may include:

  •  The Organisation or Company, its shareholders and staff;
  •  Customers for the products or services provided by the project or business activity;
  •  Users, including management, staff and operators of the delivered project;
  •  Principal suppliers, contractors and sub-contractors;
  •  Regulatory, licensing and approval authorities;
  •  People who may be affected by the project, such as those living near a new plant;
  •  The Government and community leaders who may be affected by project activities or associated employment or other opportunities;
  •  Special interest groups, such as native owners or heritage and environmental groups;

 

I like to define stakeholders into external, internal and those who are affected by your activities (for example, local communities, family members of your staff, etc.) as well as those that can affect your project (regulators, finance institutions, etc.)

Stakeholder identification and analysis is so critical it deserves a separate blog post.

 

Critical success factors

Use the requirements of the organization and the key stakeholders you have identified to derive a set of critical success factors for the project. You will need these to determine the specific criteria against which to assess the consequences of risk in the later stage of the analysis. They may also form the basis of project evaluation during the post-completion review.

 The range of critical success factors may be wide. The table below shows an example from a medium-scale project involving local community, technological and environmental factors. This example list of critical success factors was a valuable guide for a project management team through the initial planning and design stages, not just the risk study.

 

Key Elements

In this step you should develop a list of the key elements of the project or activity. This list can then be used for structuring the risk assessment.

 The key elements may be based on different aspects of the project or activity:

1. Key elements based on project phases, used to identify general project risks early in the planning cycle, to  make stop/go decisions and to structure the  commercial and  contractual approach, such as:

  •  Feasibility
  • Design
  • Capital approval
  • Procurement
  • Construction
  • Test & commission
  • Start-up
  • Operation
  • Maintenance
  • Disposal

 

2. Key elements based on physical components, used to examine technical and environmental issues, construction risks, and costs and schedules, and to assist in allocating engineering and management effort, for example:

  •  Site establishment
  • Foundations
  • Structures
  • Plant and Equipment
  • Electrical services
  • Infrastructure
  • Commissioning
  • Management
  • Operator training
  • Other issues

 

Defining risk criteria

Sometimes it may be useful to define criteria which can help to evaluate the significance of risk. The criteria should reflect the organization's values, objectives and resources. Some criteria can be imposed by, or derived from, legal and regulatory requirements and other requirements to which the organization subscribes.

When defining risk criteria, factors to be considered should include the following:

  • The nature and types of causes and consequences that can occur and how they will be measured
  • How likelihood will be defined
  • The timeframe(s) of the likelihood and/or consequence(s)
  • How the level of risk is to be determined
  • The views of stakeholders
  • The level at which risk becomes acceptable or tolerable
  • Whether combinations of multiple risks should be taken into account and, if so, how and which combinations should be considered

 

This "context establishment" phase ideally should be agreed upon by the appropriate decision-makers of the organisation and the the major stakeholders, before starting the risk identification process

Ian Wollff

Principal Geologist. Independent

9 年

Well set out for investors, or perhaps mine safety - but perhaps too much to apply to getting married.

回复
Stephen Grey

Associate Director, Broadleaf

9 年

I agree with the observation that the context is often overlooked. It's almost a silent step in that it does actually exist in the heads of those undertaking the analysis but they don't take the trouble to bring it to the surface or make sure their colleagues have the same view. On the suggestion that we need to decide "Whether combinations of multiple risks should be taken into account", I've never been able to make real sense of a project risk assessment without adopting a holistic approach. Quantitative project risks almost always exhibit connections, whether it is simply a common dependence of an underlying source of uncertainty or a direct dependence of one on another. In the end, we can only decide to proceed or not with a whole project, not with individual risks. So even if some have financial consequences and others affect public perceptions, for instance, there has to be a point at which they are all drawn together so that they can be considered as a whole.

回复

要查看或添加评论,请登录

Peter Cockcroft的更多文章

社区洞察

其他会员也浏览了