Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

BRITISH STANDARD BS 6079-3:2000

ICS 03.100.50

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

Project management Ð

Part 3: Guide to the management ofbusiness related project risk

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

This British Standard, havingbeen prepared under thedirection of the ManagementSystems Sector Committee, waspublished under the authority ofthe Standards Committee andcomes into effect on15 January 2000

BSI 01-2000

The following BSI referencesrelate to the work on thisstandard:Committee reference MS/2Draft for comment 99/402000 DC

ISBN 0 580 33122 9

BS 6079-3:2000

Amendments issued since publication

Amd. No. Date Comments

Committees responsible for thisBritish Standard

The preparation of this British Standard was entrusted by Technical CommitteeMS/2, Project Management, upon which the following bodies were represented:

Association of Project Managers

BEAMA Ltd.

British Computer Society

British Standards Society

British Telecommunications plc

Chartered Inst. of Management Accountants

Federation of the Electronics Industry

Fellowship for Operational Research

GAMBICA (BEAMA Ltd.)

Health and Safety Executive

Highways Agency

Institute of Quality Assurance

Institution of Civil Engineers

Institution of Incorporated Executive Engineers

Institution of Mechanical Engineers

Ministry of Defence

Operational Research Society

Royal Institution of Chartered Surveyors

Society of British Aerospace Companies Ltd.

South Bank University

Co-opted members

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BS 6079-3:2000

BSI 01-2000 i

Contents

Page

Committees responsible Inside front cover

Foreword ii

Introduction 1

1 Scope 3

2 Terms and definitions 3

3 The business related project risk management model 3

4 Undertaking risk management 7

Annex A (informative) Communication in risk management 16

Annex B (informative) Business and risk management tools and techniques 17

Annex C (informative) Risk perception 18

Annex D (informative) Stakeholder analysis 20

Annex E (informative) Common examples of business and project risk 21

Figure 1 Ð The risk management process 2

Figure 2 Ð The relationships between businesses, projects, and sub-projects 4

Figure 3 Ð Business level risk management steps 8

Figure 4 Ð Project and sub-project level management steps 9

Figure 5 Ð Scheme for evaluating risks 13

Table 1 Ð Decision making levels 5

Table 2 Ð Examples of decision makers 5

Table 3 Ð The relationship between decision making focus, and decisionmaking levels in the context of risk management 6

Table 4 Ð Basic qualitative analysis 12

Table 5 Ð Counter measures 13

Table 6 Ð Opportunities 14

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

ii BSI 01-2000

BS 6079-3:2000

1) This was originally published as BS 6079:1996.

2) In the course of preparation.

Foreword

This British Standard has been prepared by Technical Committee MS/2.

It is a part of a series of standards that consists of:

Ð Part 1: Project Management Ð Guide to project management1);

Ð Part 2: Project Management Ð Vocabulary2);

Ð Part 3: Project Management Ð Guide to the management of businessrelated project risk.

The publication contains guidance and recommendations. It should not be quoted as ifit were a specification, and should not be used for certification purposes.

A British Standard does not purport to include all the necessary provisions of acontract. Users of British Standards are responsible for their correct application.

Compliance with a British Standard does not of itself confer immunityfrom legal obligations.

Summary of pages

This document comprises a front cover, an inside front cover, pages i and ii, pages 1to 21 and a back cover.

The BSI copyright notice displayed in this document indicates when the document waslast issued.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 1

BS 6079-3:2000

IntroductionRisk management is a core process within anybusiness or organization regardless of size, activityor sector. Individuals and organizations can losesubstantial sums of money as a result of not payingsufficient attention to the identification andmanagement of threats to their goals and to theprojects they commission. Similarly, full advantagecannot be taken of potentially beneficialopportunities arising in the course of their activitiesif these are not recognized in good time. Riskmanagement is therefore as much about lookingahead to identify further opportunities as it is aboutavoiding or mitigating losses. On a wider level,efficient and effective management of risk can makea significant contribution to the economic andgeneral welfare of society, as well as that of thebusinesses and projects directly concerned.

Although it is often suggested that formal riskmanagement does not begin until the first actual riskassessment has taken place, risks are rarely ignoredwhen initial plans are made, or decisions taken, toproceed with projects. It is simply that it is rare forall risks to be identified and taken into accountsystematically in the early stages of planning. It iswell known that managers and their teams generallyknow what can go wrong and what worthwhileopportunities might occur. Without the benefit ofsystematic risk analysis however, it is not alwayspossible for them to exploit their knowledge to thefull. Even when an analysis is undertaken, a teamwill not always maintain and update it. Equally,sometimes when risks are foreseen, they aredismissed on the grounds that ªit couldn't happenhereº. Risk assessment should therefore be seen aspart of a continuous review process conductedthroughout the life of each project. In this way, themany risks to the business that occur as aconsequence of the projects it undertakes, can beidentified and actively managed.

The benefits of systematic risk identification and riskmanagement include:

Ð more realistic business and project planning;

Ð actions being implemented in time to beeffective;

Ð greater certainty of achieving business goalsand project objectives;

Ð appreciation of, and readiness to, exploit allbeneficial opportunities;

Ð improved loss control;

Ð improved control of project and business costs;

Ð increased flexibility as a result of understandingall options and their associated risks;

Ð greater control over innovation and businessdevelopment;

Ð fewer costly surprises through effective andtransparent contingency planning.

This standard describes a process for identifying,assessing, and controlling risk within a broadframework. The main features of this process areillustrated in Figure 1. The risk management processdescribed in this standard is applicable for eachaspect of the business activity focus at each level ofdecision making.

Projects are the principal means by which a businessmoves forward. In order to manage risk effectively,the business, project, or sub-project goals need to beclearly identified. This is because it is only inrelation to an organization's or individual's specifiedgoals that risk arises. Confusion over projectobjectives is itself a major cause of project failure.Managing business related project risk involvestaking account of business risks that affect itsprojects and project risks that affect the business.Within any project there are also inherent risks tothe project itself, and to its sub-projects.

A vital part in clarifying goals and assessing risk isthe identification of project and businessstakeholders. The guidance in this standardhighlights the importance of stakeholder analysis andsuggests that it is integrated into the riskmanagement process. Unless the stakeholders areidentified and understood at an early stage the trueextent of the management task and the source ofmuch risk can go unrecognized. Identifyingstakeholders also helps define the relationshipbetween the business and its environment and thecontext in which its projects will be carried out. Notall stakeholders are easily recognizable and there canbe many more organizations with influence andvested interests than is readily acknowledged. Takingstakeholders into account can ensure that planningis much more ªviewpoint orientedº.

Annexes A to E are informative and give backgroundinformation for a fuller understanding of associatedrisk management factors.

Annex A describes the importance of effectivecommunication within risk management.

Annex B gives an overview of management tools thatcan be used to provide an analytical framework.

Annex C describes the significant aspects of riskperception which can impede risk management.

Annex D describes the principles involved instakeholder analysis.

Annex E gives a listing of some common types ofbusiness risk.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

2 BSI 01-2000

BS 6079-3:2000

Figure 1 Ð The risk management process

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 3

BS 6079-3:2000

1 ScopeThis standard gives guidance on the identificationand control of business related risks encounteredwhen undertaking projects. It is applicable to a widespectrum of project organizations operating in theindustrial, commercial and public or voluntarysectors. It is written for project sponsors and projectmanagers, either or both of whom are almost alwaysresponsible to higher levels of authority for one ormore projects of various types and sizes.

It is intended that its application will be proportionalto the circumstances and needs of the particularorganization.

This standard offers generic guidance only and it isnot suitable for certification or contractual purposes.It is not intended as a substitute for specificstandards that address risk assessment in distinctapplications, such as health and safety, or areas oftechnological risk.NOTE This standard advises that risk management is treated asan integral part of good management practice. Risk managementis an iterative process consisting of steps that enable continualimprovement in decision making. Its effective use depends on theexperience and judgement of the practitioners applying theguidance, and not simply on routinely following the steps outlined.

2 Terms and definitionsFor the purposes of this British Standard thefollowing terms and definitions apply.

2.1

residual risk

risk remaining after risk treatment measures havebeen taken

2.2

risk

uncertainty inherent in plans and the possibility ofsomething happening (i.e. a contingency) that canaffect the prospects of achieving business or projectgoalsNOTE Such contingencies could make the result more or lesssatisfactory.

2.3

risk analysis

systematic use of available information to:

Ð characterize the risks;

Ð determine how often the specified events couldoccur;

Ð judge the magnitude of their likely consequences

2.4

risk assessment

overall process of risk analysis and risk evaluation

2.5

risk consequence

effect on the interests and goals of those at risk if arisk event happens or a risky situation materializes

2.6

risk evaluation

process used to decide risk management priorities byevaluating and comparing the level of risk againstpredetermined standards, target risk levels or othercriteria

2.7

risk identification

determination of what could pose a risk

2.8

risk impact

a measure of risk consequence

2.9

risk management

systematic application of policies, procedures,methods, and practices to the tasks of identifying,analysing, evaluating, treating, and monitoring risk

2.10

risk sharing

spreading of risk by sharing it with othersNOTE This is also referred to as ªrisk transferº.

2.11

risk treatment

selection and implementation of appropriate optionsfor dealing with risk

2.12

secondary risk

risk arising from the risk treatment process

2.13

stakeholder

individual, group or organization having a vestedinterest or influence on the business or its projects

2.14

stakeholder analysis

process for identifying stakeholders, their interestsand influences

3 The business related project riskmanagement model

3.1 General

The model outlined in this guide is shaped by twogeneric perspectives that can be applied to any kindof business or project. These are as follows:

a) defining the relationships between thebusinesses and its projects;

b) modelling the decision making processesassociated with activities at different levels withineither the business or project.

(Sub-projects often exist within larger projects, someof which can be described as business initiatives butwhich nonetheless have the same general characteristics.)

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

4 BSI 01-2000

BS 6079-3:2000

Figure 2 Ð The relationships between businesses, projects, and sub-projects

The effects of decisions in all parts of the businessand at all levels within the business and its projectscan be far reaching and should not be considered inisolation. Good communication between each levelof a business and between the business and itsprojects is essential. Annex A gives guidance on thefactors that can play a part in an effectivecommunication strategy.

3.2 The relationship between businesses andprojects

Businesses operate in an external environment fromwhich they can derive key opportunities and alsoexperience constraints. Sources include otherbusinesses and organizations; markets; governments;regulatory bodies; the legislative framework; thefinancial system; and society at large.

Any business takes inputs from its externalenvironment, and acts on those inputs to producegoods or services, along with other outputs, such asprofits, or pollution, which are then returned to thesame environment. The nature and extent of theseoutputs will influence the future of the business.Projects should be viewed in exactly the same wayas businesses, because the business or businessesthat set up a project are significant elements of thatproject's external environment. Similarly, a largeproject can consist of several sub-projects, and thislarger project then provides the external environmentfor its sub-projects.

The model, shown in Figure 2, shows the nature ofbusiness and project relationships relevant tounderstanding how to manage business relatedproject risks.

Three types of relationships can be identified asfollows.

a) Businesses can set up projects in which theinputs and outputs are maintained wholly withinthe business boundary.

EXAMPLEA project that trains staff to undertake new jobscan be carried out by a team from theorganization's training department. Project inputs(including risks to the project from the business),and outputs (including risks to the business fromthe project), are mostly retained within thebusiness. Risks that can arise from the functioningof the project should also be considered asoutputs in this context, and will be wholly retainedwithin the business.b) Businesses can set up projects that are partlywithin and partly outside the business boundary.EXAMPLEAn illustration is where one business contractswith another for the supply of parts required bythe first business. Risks from this type ofrelationship are born directly, to varying degrees,by both parties to the relationship, and indirectlyby other parties, such as insurers.c) Collaborative or partnership projects can be setup by two or more parties from which theyindividually and jointly expect to receive benefits.Here also, project risks are also shared in variousways between the parties involved.

A project can itself be composed of severalsub-projects, wholly or partly within the initialproject or business.EXAMPLEConstruction work could be divided betweenseparate plastering, electrical, and carpentrysub-projects. Software production could be dividedbetween teams (sub-projects) responsible fordifferent modules. A sub-project could also beinitiated to manage a particular risk. Each project,sub-project (and sub-sub-project, and so on), is atrisk from the associated business, project, (andsub-project, respectively) that established it initiallyand which contributes inputs to it. The sub-projects,and projects, also produce outputs, both desired andrisky for the associated projects and businesses.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 5

BS 6079-3:2000

Table 1 Ð Decision making levelsDecision making

levelExamples of decision making

Strategic Establishing/confirming goals, means, constraints, key risks, stakeholders and setting incontext for tactical and sometimes operational decisions for each activity/project.

Tactical Choosing how to deploy the most appropriate means for attaining goals and managingtactical risks within the restraints set at strategic level.

Operational Implementing tactical choices and managing operational risks.

Table 2 Ð Examples of decision makersDecisionmaking

For the business For the project For the sub-project

Strategic Non executive and executivesenior management

Project sponsor Project manager

Tactical Middle management Project manager Sub-project management

Operational Operations manager Project team and suppliers Sub-project team andsuppliers

3.3 Levels of decision making for riskmanagement

Decision making is an activity concerned withattaining certain goals. It should proceed in thecontext of goal setting, ranging from activity toidentify goals, through to action/s to accomplish thegoals. Risk management decision making takes placeat three levels:

Ð strategic;

Ð tactical; and

Ð operational.

In the context of this standard, the use and meaningof this terminology reflects normal usage. However,the terms are more specifically applied within thisstandard at all three levels of decision making, i.e. atbusiness, project and sub-project levels.

These levels generally correspond to long, medium,and short-term decision making activities and eachcan pose risks for the others. The business relatedproject risk management model emphasizes that thethree decision making levels not only occur withinthe business but are also found within projects andsub-projects. For example, strategic direction of theproject is the province of the business sponsor,much as the senior management of an organizationset strategy for the organization as a whole.

Table 1 gives an overview of the levels of decisionmaking. Table 2 gives typical examples of those whousually take responsibility for the different types ofdecision. The three types of decision making aredescribed in 3.4 to 3.7. Table 3 gives an overview ofthe relationship between the focus of decisions madeand the different levels of decision making.

3.4 Strategic decision making

Goals are set by strategic level decision making.Once goals have been established, strategic decisionmaking should focus on the environment and broadprinciples of the tasks required to achieve a goal.Strategic decision making should also identify themeans for reaching the goal, and any constraints that

could hinder progress. It is at this level thatdecisions can be taken to modify old goals, or adoptnew goals, or to change the business or project inorder to attain the goals set.

Strategic decision making sets the basic frameworkwithin which tactical decision making operates. Thescope of strategic decision making is very wide, andinfluenced strongly by choices made by decisionmakers at this level. Choices of strategic decisionmakers are wide-ranging and decisions can havefar-reaching and sometimes unintentionalconsequences for subsequent activities and the wayprojects are conducted. In general, strategicdecisions should be concerned with the longer term.Strategic decisions relating to projects cansometimes be taken far in advance of theirimplementation, by which time circumstances couldhave changed markedly. The risks associated withthis type of decision making will not always becomeapparent until well into the future. Strategicdecisions should therefore be reviewed on a regularbasis.

3.5 Tactical decision making

Tactical decision making bridges the gap betweenstrategic and operational decisions. It is concernedwith the broad implementation of strategic leveldecisions. Since these can only be indicative, tacticaldecision making should be concerned with themedium term and choices of approach and methodwithin the framework set at the strategic level. Thescope of tactical decision making is narrower, and,the time frame, financial responsibilities, and scopefor goal setting and policymaking are morerestricted.

3.6 Operational decision making

Operational decision making, should have thenarrowest focus and should take place within theframework and constraints established by tacticaldecision makers. Operational decision making ismore likely to be routinized, and decision makersshould follow rules and procedures closelyconcentrating on the shorter term.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

6

BS

I01-2

000

BS

6079-3

:2000

Table 3 Ð The relationship between decision making focus, and decision making levels in the context of risk management

Decision making type Focus of decision making

For the business For the project For the sub-project

Strategic decisionmaking

(long term goals)

Project initiation and preliminary riskanalyses for the business and project.

Establishes risk management goals andprocesses, looking at business andproject.

Sets context, systems, principles for riskmanagement process.

Can contribute to changes in overallcorporate policies and objectives.

Clarifies project goals and priorities.

Identifies project risks in the light ofreceived project goals.

Carries out preliminary risk analysis forproject goals and project process.

Provides feedback to business level onpotential business level risks identified.

Transfers risks concerning the projectenvironment to business decisionmakers.

Establishes project risk managementprocess.

Clarifies sub-project goals and priorities.

Identifies sub-project risks.

Carries out preliminary risk analysis forthe sub-project.

Transfers potentially unforeseen or newrisks identified to project level.

Establishes sub-project riskmanagement process.

Tactical decisionmaking

(medium termgoals)

Sets policy for risk managementplanning process ± risk analyses,evaluation and treatment.

Carries out risk analyses, evaluation anddevelops treatment plans and options.

Identifies and evaluates risks of riskmanagement process.

Feeds back to strategic project level allnew or altered risks or strategic projectrisks.

Analyses, evaluates and developstreatment plans for sub-project risks.

Identified any consequent risks.

Feeds back to sub-project strategic levelany potential modifications to risks.

Transfers upwards new or modifiedstrategic sub-project risks.

Operationaldecision making(short term goals)

Establishes relevant committees,processes, etc.

Commits resources and makes go/no-godecisions.

Implements risk managementtreatments.

Identifies risks arising from this; feedsback to higher level.

Transfers upwards new or modifiedtactical risks.

Implements sub-project risk treatment.

Identifies any consequent risks.

Feeds back risk analyses to tacticallevel.

Transfers upwards any new or modifiedtactical risks.

Licensed Copy: Rupert Heygate-Browne, Agip KOC, 30 September 2003, Uncontrolled Copy, (c) BSI

BSI 01-2000 7

BS 6079-3:2000

3.7 Combining business focus and decisionmaking levels

In order to facilitate the identification andmanagement of business related project risks it isuseful to combine the business activity focus withthe decision making levels perspective. Thisapproach should recognize that the three levels ofdecision making occur at each of the focus levels ±business, project, and sub-project. The implicationsfor risk management activities are indicated inFigure 3. (Some aspects of the risk managementprocess noted in Figure 3 are described in clause 4.)

Decision making at any level should take account ofrisks emanating from flawed decision making athigher and lower levels, if risk is to be effectivelymanaged.

4 Undertaking risk management

4.1 General

There are two broad phases to the risk managementprocess as follows.

a) The first phase concentrates on defining thescope of risk to be managed and on riskidentification. This can be compared to problemframing activity.

b) The second deals with assessing and managingrisk, and is equivalent to problem solving.

Nonetheless, issues can arise during problem solvingthat require a return to problem-framing activities. Arigid distinction should not be made between thephases as the process of risk management will ofteninvolve the iterative retracing of steps.

Effective problem framing is critical to all businessdecision making and problem solving. Yet in riskmanagement these activities are sometimes givenscant attention or even ignored altogether. Instead,emphasis is sometimes put on risk analysis and risktreatment without first putting the work in contextand being certain as to what or who could be at risk.If problems are not correctly identified, problemsolving is likely to be misdirected. Problem framingis therefore critical to effective risk management.

Annex B gives an overview of various methods ofrisk management and analysis tools. It is notexhaustive but highlights the key features of eachmethod.

Consideration should be given to undertakingseparate risk management exercises where the scopeof the risks is cross-functional as long as the risksare subsequently integrated; for example, risksconcerning project delivery, project performance,safety, environmental safeguards, corporate liabilityin respect of projects and human resources. Bothphases of risk management and the steps withineach phase, should be accomplished for each of thebusiness, project, and sub-project levels.

The basic structure of the process is describedin 4.2.

4.2 Identification of risks and riskmanagement scope

4.2.1 General

The steps and activities within this phase arepresented in a schematic form for ease ofdescription. It should be noted that identifying risksand defining the full scope of risk managementactivity is a creative task, which should, as far aspossible, involve all those likely to be affected by thedecisions reached. Its effectiveness is dependent onthe skills and experience of those involved, and theextent to which they are able to handle some of theconstraints on management decision making, inparticular those due to risk perception (see annex Cfor background information).

The risk identification process should be systematic.Attempts to compress the process are likely to limitthe ability to identify risks effectively. It is advisableto deal separately with risk identification, followedby risk assessment and treatment, althougheventually both will run concurrently.

The steps that should be considered at the project,and sub-project levels are broadly similar, but candiffer in detail. However, the steps that should beconsidered at the business level differ from those atthe other two levels, and are described separately, asfollows. For the business level, the newly identifiedrisks (threats or opportunities) that might affect thebusiness or the project (or both) should beconsidered as significant. See Figure 3.

For project and sub-project, the goals identified atthese levels that either require decisions to be madeat the higher level or that pose risks which cannotbe dealt with effectively at these levels, should beconsidered significant. See Figure 4.

The focus of the first set of activities should be toensure clarity and understanding of, and agreementon, the full set of goals that the business, project, orsub-project have to meet.

These steps are important because:

Ð risk management at each decision making leveltakes place in the context of goals and otherconstraints established by the level above (projectgoals are initially established at the businesslevel);

Ð failure to establish or communicate clear goalsand project objectives is itself a common source ofbusiness related project risk;

Ð the various features of the business, project, orsub-project environment are important to the riskmanagement process;

Ð without a clear view of the full range ofbusiness goals and project objectives, riskidentification is severely constrained and could bemisleading.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

8 BSI 01-2000

BS 6079-3:2000

Figure 3 Ð Business level risk management steps

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 9

BS 6079-3:2000

Figure 4 Ð Project and sub-project level risk management steps

4.2.2 Business level goal setting

At the business level, primary goals should be:

Ð those of the overall business; and

Ð those of the project which the business issponsoring or participating in.

It is important that project goals fit with those of thebusiness in order to avoid either the business orproject threatening the success of the other.Business and project goals should also fit with theoverall business objectives and policies, establishedat the business level.

Business goals and the fit of the project goals cansometimes initially seem unclear or uncertain.However, the fit can be confirmed, and precisionenhanced, as project boundaries and scope areestablished and as an overall risk managementstrategy is developed.

Goals and project scope and boundaries can beidentified by seeking answers to the questions suchas the following.

Ð In whose interests is the project being initiated?

Ð Who are the stakeholders?

Ð Who will benefit from the successfulcompletion of the project?

Ð What constitutes success; what constitutesfailure?

Ð What is the attractiveness of the project to theinvestment decision maker and other relevantstakeholders?

Ð What are the goals of the project?

These questions can also be addressed as part of amuch wider project review involving such techniquesas stakeholder analysis (see annex D). Stakeholderanalysis helps managers establish an understandingof the full range of individuals and groups that couldhave an effect on a business and its projects. Thetechnique also enables the most importantstakeholders to be identified especially those whoseinterests should be taken into account if the projectis to be successful.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

10 BSI 01-2000

BS 6079-3:2000

Once goals have been established, the context orenvironment in which they will have to be achievedcan be identified. This is important because itestablishes the high level or large scale sources ofconstraint or threat (as well as opportunity), both forthe business and its projects.

At the business level the context includes, forexample, the financial, legislative, political, social,competitive and cultural environments in which thebusiness (and therefore the project) is carried out. Itincludes other businesses, competitors andcollaborators, and other groups such as residents,communities, and so on, who could hinder orfacilitate the project's goals, and therefore constitutesources of risk to the business.

On completion of a stakeholder analysis, it could beapparent that existing goals have to be modified andadditional goals have to be met in order to completethe project successfully. Should this be the case, itwill be necessary to review the project's fit with thebusiness goals.

The complete set of goals for a business inconnection with a project consists of:

a) initial goals identified by the business;

b) other goals identified through stakeholderanalysis and other techniques; and

c) other goals identified as a result of riskassessment.

Some goals identified as part of stakeholder analysisor risk management could turn out to be either moreimportant than the goals originally set by thebusiness or too risky to pursue. Once the full extentof goals and related risks has been established, thenthe risk management strategy is completed. For thebusiness level, this will then necessitate decisionsbeing taken about whether to handle some risks atthat level, and which risks to pass down to theproject level or share with other organizations.

4.2.3 Project and sub-project goal/objectivesetting

At the project and sub-project levels, the full set ofgoals to be met should be established and reviewedin the same way as at the business level. That is,through use of a variety of techniques to clarifygoals, scope and boundaries, and confirmation ofoverall project or sub-project goals following aninitial risk assessment.

At the project and sub-project levels, the primarygoals should be those set by the level above(i.e. business, or project, respectively) but others willbe added as a result of detailed planning at thoselevels. Decisions made at project (or sub-project)level can bring in other stakeholders not previouslyconsidered at higher activity focus levels.

Some stakeholders will only come into prominenceat the project level as a result of decisions taken byproject managers. For example, environmental

activists could be part of the total businessenvironment, but only achieve the status of projectstakeholder if the project manager decides to dosomething that creates an interest for them. In thisway, the external environment of the organizationcan be brought directly into play as a source of riskthrough decisions made at project level,independently of the decisions made at businesslevel. Situations like this should prompt a review ofbusiness and project goals to include those relatingto managing this new group of stakeholders.

The final set of goals for a project (or sub-project)should thus consist of goals handed to them, goalsidentified as a result of stakeholder analysis andother project planning and review techniques andmodifications to the goals as a result of the riskassessment. Project (and sub-project) managersshould then distinguish between goals and relatedrisks for which they can be responsible, and those(if any) that cannot be managed at their level.

Managers at each level of authority should be giventhe means to manage the risks they identify. If this isnot possible, a system for passing information aboutthose risks upwards or downwards through theproject hierarchy to the appropriate level ofmanagement, should be put into operation.Responsibility for dealing with individual risksshould rest with the management and decisionmaking level most suited and capable of handling it.

The relative emphasis of each step in the process islikely to vary with the level in the business/project atwhich it is carried out. At the business, and higherproject levels, the emphasis is likely to be on theearlier stages, ensuring clarity of objectives, andbroad understanding of potential opportunities andthreats to business and/or project. Lower down thedecision making tree, the emphasis is likely to be onimplementing the risk management strategy.Nevertheless, scope should be allowed (even in thesephases) for communicating potentially unforeseenthreats or opportunities upwards from sub-project toproject, and from project to business levels.

Once business, project and sub-project managershave completed these initial steps for theirrespective levels of responsibility, they shouldproceed to implement the risk management strategyat their level.

4.3 Risk identification and strategy

4.3.1 Risk model clarification

Risk identification should focus first on individualrisks. Nonetheless, to make an effective assessmentof overall business related project risk requires anidea of how specific risks relate to each other and tothe desired goals and an understanding of theprobable common or underlying causes of risk(if any). Annex E gives a listing of some commonexamples of business and project risk.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 11

BS 6079-3:2000

Once risks have been identified, managers shouldclarify and make explicit their understanding of theways in which the risks might affect the goals. Thisshould include assessing all significant assumptionsrelating to the identification, analysis and overallassessment of the risk. For example, an assumptioncould have been made that certain risks can beconsidered independently of each other. If the risksare truly independent, this assumption will notundermine the subsequent risk assessment orinvalidate decisions on how to treat the risk. If, onthe other hand, the risks are inter-related and thereare underlying or common causes, the presence ormagnitude of one risk could affect the presence ormagnitude of another. Decisions made on the basisof flawed assumptions or estimates will themselvespose risks.

Effective risk modelling in this way requires anunderstanding of causes and causal relationshipsbetween possible events or processes themselves,and between those events or processes, and thedesired goals. One outcome of risk modelling can bethe discovery that several risks share a commoncause, or are related in such a way that managementof those risks is simplified. Treatment can then bedirected to the common cause and as a consequencewill usually be more cost effective than picking offindividual risks one at a time.

The main outputs from this phase should includesetting up a risk register or a database that lists anddescribes all identified risks and records decisionsmade concerning their assessment and treatment.Risks should be listed with details of theircharacteristics, including their ranked importance,any quantitative indicators, and finally risk treatmentplans. Risk registers can be more or less detailedand play an essential role in risk management as aprimary document of record.

The main outcome of the phase should be a clearunderstanding of the risk model and accompanyingassumptions on the part of the business and projectmanagers, together with other key stakeholdersdirectly involved in managing the project. This formsthe basis on which development of an initial riskmanagement strategy can proceed.

The risk management strategy should cover theoverall approach and principles of risk managementto be adopted by the business, and include decisionsabout those risks to be handled by the projectmanagers. The risk management strategy itself canaffect overall goals, or cause other goals to be givenattention as a result of consequential risks arisingfrom the treatment of primary risks. Some goalscould be too risky to pursue and could be dropped.Managers also need to ensure that the fit betweenthese goals, and the overall project and businessgoals continues to be acceptable.

4.3.2 Risk analysis

A risk analysis should be made to establish thelikelihood and potential consequences of theindividual risks or sets of risks previously identified.A risk evaluation should then be made to determinewhich risks take the highest priority, which risksrequire further (and possibly more detailed) studiesand which risks need less attention.

All risks should be assessed on two levels:

a) the likelihood of their occurrence; and

b) the potential consequences for the business andprojects.

Whilst the objectives of risk analysis are easy tostate in principle, in practice obtaining adequateinformation, and analysing it, is difficult. Sources ofinformation on risk likelihood and consequencecould include the following:

Ð records and other sources of historical data;

Ð relevant experience;

Ð reviews of research into project success andfailure;

Ð experiments with prototypes;

Ð market testing and research;

Ð application of behavioural, financial, economic,engineering and/or other relevant models;

Ð use of specialist and/or external expertise.

Techniques for information gathering vary, butshould always fit the characteristics of the data to becollected. Techniques include interviews,self-completion questionnaires, team workshops,focus groups, library searches and translation ofhistorical data into meaningful information for thepresent.

Risk analysis can be conducted by both qualitativeand quantitative methods. The type of analysisdepends on the nature and quality of data available.A qualitative assessment should use words ordescriptive scales to describe the combinedlikelihood and consequences of each risk or set ofrisks. These scales can be developed and adjusted tosuit different qualities of data, and analysisrequirements.

Table 4 illustrates the kind of analysis possible at thislevel.

A classification system like the one used inTable 4 should be used with care as it requires clearunderstanding and agreement on the part of thoseanalysing the risks if it is to be useful. Classificationof risks will also depend on assessment of existingmeasures and procedures for managing them. Thisform of classification can be applied to both threatsand to opportunities.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

12 BSI 01-2000

BS 6079-3:2000

Table 4 Ð Basic qualitative analysis

Likelihood of risk Degree of risk impact

Minimal Moderate Significant

Likely Medium High High

Possible Low Medium High

Unlikely Low Low Medium

Even where reliable data is available, qualitativeanalysis should still be conducted first, with theobject of getting a broad feel for the relativelikelihood and impact of risks. Once a framework isestablished, some form of quantitative risk analysescan be appropriate. Quantitative analysis cansometimes provide a more detailed assessment usingnumerical values given to likelihood and impact,often expressed as probabilities. To what degreequantitative analysis is appropriate depends on thenature and quality of the data available for particularrisks, the nature of the project, potentialconsequences, and whether analyses can provideadditional useful information. It is often overlookedthat in conducting quantitative analyses, subjectivedecisions and estimates, which could be incorrect orinvolve inaccurate assumptions, are necessary forthe process. The past is seldom a good predictor ofthe future and numerical estimates emerging fromquantitative risk analysis should be used with care ±to inform but not decide.

It can be appropriate to employ quantitative analysisfor the more significant risks, especially when thereis doubt over the initial assessment. However, whererisks are themselves combinations of other risks, orare likely to be affected by other risks, quantitativemethods can be difficult to apply with any certaintyas to the value of the analysis. If the analysis isundertaken at an early stage it is sometimes possibleto minimize risk at very little cost. Where this ispossible, risk evaluation is more likely to depend onjudgement regarding the seriousness of the riskconsequences than on likelihood of occurrence. Riskassessment is unlikely to be straightforward.However, any attempt to assess risk as a basis fordecision making will increase the chances of asuccessful outcome.

Whether analysis is conducted qualitatively orquantitatively the resulting information shouldprovide the basis for evaluating the risks. It could bethat all that is required is that risks are categorizedas high, medium, or low priority. Those that fall intothe low category can then, depending on thejudgement of the managers and other stakeholdersconcerned, be set aside for the time being as notrequiring further attention. In doing this, care shouldbe taken not to set aside risks that might act incombination with other risks, or could be affected byother risks. Risks set aside at one point in theoverall risk management process should bere-examined if new information or changingcircumstances suggest that this might be necessary.

All risks and supporting information arising fromrisk analysis should be compiled in the form of aregister. Risk registers should serve as a documentof record and be regularly updated.

4.3.3 Risk evaluation

The purpose of risk evaluation should first be toestablish whether there are risks that could seriouslydamage the business or project, and which could beuntreatable in the light of previously defined criteria.If this proves to be the case, project goals andcriteria should then be reviewed. Second, theprocess of risk evaluation should result in aprioritized list of treatable risks for furtherconsideration. A scheme for evaluating risks isillustrated in Figure 5.

The first step in risk evaluation should be to classifyboth threats and opportunities into three broadcategories.

a) Threats can be classed as unacceptable in anycircumstances, where there are catastrophicconsequences for the business or project or wherethey are unacceptable on other grounds, such asexcessive treatment costs that far outweigh thebenefits. Ideally, these risks should have beenidentified in early business level studies.

b) Threats that are obviously negligible orotherwise insignificant should be recorded and setaside from further consideration, although it willbe necessary to re-evaluate them at regularintervals.

c) Threats are classed as acceptable if they aredeemed worthwhile and can be managed withinacceptable limits.

Opportunities should be classified according towhether they are critical, desirable or negligible.

d) Critical opportunities, (likely to have beenidentified in early business level studies), are thosethat could significantly enhance the value of aproject to the business.

e) Desirable opportunities are those that, ifoccurring, facilitate achievement of project goalsto a level greater than the minimum specified.

f) The third group of opportunities contains thosethat will have a negligible effect on the project.They too should be recorded, and can be set asidefrom further consideration at this point. It issometimes necessary to re-evaluate them at a laterstage.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 13

BS 6079-3:2000

Figure 5 Ð Scheme for evaluating risks

All risks other than the negligible and insignificantshould be subjected to further analysis andevaluation. The aim should be to confirm or amendthe initial categorization. It could be that someunacceptable or critical risks are actually found tobe acceptable, or desirable. Conversely, furtherexamination could reveal that some acceptable ordesirable risks are unacceptable or critical.

Risks that are classified as unacceptable should bereviewed to establish whether they are treatable andif so, whether it is worth doing so. If they are nottreatable, it could be necessary to review the criteriafor treating risks or the goals with which they areparticularly associated. In extreme cases a projectwill have to be cancelled or abandoned as a result ofidentifying an intolerable risk. Treatable risks ±i.e. risks that are tolerable, or desirable ± can beanalysed further to decide on appropriate forms andlevels of treatment.

4.3.4 Risk treatment

The risk treatment process should involve identifyingand evaluating a significant range of options fortreating risks, and preparing and implementing riskmanagement plans. For both threats andopportunities the first step should be to decidewhether special treatment is necessary, or whetherthey can be treated in the course of normalmanagement procedures and activity. The treatmentof threats involves considering counter measures.

Table 5 contains a summary of counter measuresthat can be adopted to minimize threats.

Table 5 Ð Counter measures

Measure Summary

Eliminating oravoiding

Changing or abandoning goalsspecifically associated with the riskin question, or choosing alternativeapproaches or processes that makewhat was previously a risk nolonger relevant.

Risk sharing Sharing risks in part or in full withanother stakeholder who could beinvolved solely to facilitate risktreatment, e.g. an insurer.

Reducing thepossibility

Changing project approach,identifying causal links betweenthreat and impact, or causes ofthreats, and intervening to mitigateoccurrence, acting to reduce thethreat.

Reducing theconsequences

Developing contingency plans forresponding to the threat if itoccurs, even if other steps havebeen taken to minimize the risk.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

14 BSI 01-2000

BS 6079-3:2000

Treatment of opportunities involves consideringmeasures to ensure their occurrence. Table 6 containsa summary of measures that can be adopted toincrease the likelihood of an opportunity occurring.These can include any or all of the following.

Table 6 Ð Opportunities

Measure Summary

Facilitating Choosing project approachaccordingly; enhancing otherbeneficial stakeholders'outcomes.

Involvingfacilitators

Involving stakeholders who canhelp facilitate occurrence of theopportunity.

Enhancinglikelihood

Changing project approach;examining causal links betweenopportunity and project.

Enhancingconsequences

Developing plans for taking fulladvantage of an opportunity if itoccurs.

Any treatment measure should be assessed in termsof the following:

Ð its cost compared with the anticipated benefitsof treating the risk;

Ð the kind of actions involved;

Ð its effectiveness in containing the risk orenhancing an opportunity;

Ð any secondary risk associated with the action.This is to check that the counter-measure itself,does not have any unforeseen consequences,particularly ones that could pose a greater riskthan that which the treatment is designed tominimize. This is especially important whenpursuing opportunities.

These measures should then be compared to the riskassessment to decide which actions are appropriate,given the level of the risk. If new stakeholders are tobe involved as a result of treatment decisions, theirinterests should be integrated with the previousanalyses.

For each risk to be treated, other than those whichare to be avoided altogether, indicators of likelihoodof occurrence should be identified. These can thenbe monitored as part of the risk treatment plans.

4.3.5 Implementation

Following the identification of risk treatmentmeasures and risk indicators, a risk managementplan should be formulated. This should be agreed bythe managers concerned, and communicated to othersignificant stakeholders. Ideally, plans for dealingwith risk should be incorporated in the generalbusiness or project management plan. Sufficientresources should then be allocated to implement theagreed actions.

The nature of the plan should be dictated by thecharacteristics of the risks and the treatmentdesigned to address the risk. A distinction should bemade between:

Ð preventive counter measures built into thecurrent activities of the business; and project; and

Ð mitigation measures which are put in place butwhich will not be operationalized unless the riskarises.

Preventive counter measures might, for example,involve a decision to use a tried method rather thanan innovative approach about which there is lesscertainty as to outcome. Mitigation includes, forexample, insuring against loss or failure. Whereinsurance is chosen, it should provide for sufficientfunds to restore the status quo as well as tocomplete the project as originally intended.

All risk management, especially treatment measures,should be monitored for performance so thatappropriate counter measures or facilitative actionscan be implemented should the risk managementstrategy prove inadequate. Possible methods ofreview include performance evaluation, audits, andinspections. This will allow ongoing feedback onwhich assessment and treatment activities are mosteffective.

Communication between managers implementing thetreatment measures, and those whose goals are atrisk is essential throughout the implementation ofthe risk management plan (see annex A). In parallelwith this ongoing communication, there should be:

Ð regular monitoring of resource usage againstthe risk management plan;

Ð monitoring of the agreed risk indicators;

Ð monitoring of the risks so that they can be seento fall within the previously expected limits.

Re-evaluation of the risks and the search for newones should take place on a regular basis.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 15

BS 6079-3:2000

4.4 Managing the process

This subclause draws attention to some issues in theprocess of managing business related project risk.

Four key steps in the effective management ofbusiness related project risk management are:

Ð developing the organization's policy for riskmanagement;

Ð establishing the organizational infrastructure;

Ð establishing a programme for managing risk atorganizational, cross-organizational, project andsub-project levels;

Ð monitoring and reviewing the effectiveness oforganization's management of risk.

Risk managers should involve all key members of thebusiness and its projects in the process of riskidentification, analysis, and management. If thisdoesn't happen, information and ideas held by otherpeople will not always be understood or accepted bymanagement. Risk management can be significantlyenhanced when there is a better understanding, onthe part of those supporting them, of the situationsfaced by those taking ªriskyº decisions as part oftheir job. The risk manager should take account ofthe following factors.

a) Duplication and overlap of functions and taskscan make a reliable system out of less reliableparts. This is partly because more than oneperspective is brought to bear on a problem andthe associated risks.

b) A culture of risk management needs to bedeveloped and encouraged throughout thebusiness, and fed through into its projects. Thisworks by encouraging everyone, especiallymanagers, to continuously consider and monitorrisk including that arising from their own decisionmaking and actions.

c) Training and simulations (exploration ofªwhat ifº scenarios) can heighten risk awarenessand responsiveness.

d) High levels of communication of plans andintentions and appropriate levels of involvementenhance understanding. Clear lines ofcommunication among team members are alsoimportant.

e) Elements of the ªlearning organizationºapproach, in particular a willingness to learn frommistakes (and to avoid allocating blame)contribute to awareness and to a willingness toraise potential risks for consideration. For thesereasons an incremental approach to business andproject development is less risky.

f) A clear hierarchy of responsibility andleadership, within which senior members set theframework of tasks for those lower in thehierarchy. Within this framework, decision makingis decentralized to permit prompt and flexibleresponses to local conditions.

The management of risk can usefully be treated as asub-process of the business or project. Similarly, thesetting up and successful implementation of a riskmanagement strategy can be treated as a project.From this perspective, the management guidelinesset out in BS 6079-1 can be applied to themanagement of risk within any business or relatedproject. There are however, some additional pointsthat can usefully be emphasized in the particularcontext of managing the risk management processitself.

Risk management should be integrated fully withbusiness and project management. This advice isaimed at meeting one of the shortcomings of thefunctional (staff and line) approach to managing,namely, that if something is someone else'sresponsibility, then people act as if thatresponsibility will, or has, been met. For risk, if thereis a separate manager for the risk managementfunction, other people will tend to assume thatperson or department has done all that is necessaryto manage the risk.

At the same time, if there is not a specialistco-ordinator or manager, there is a risk that peoplewill assume that someone else is taking care of risksthat they do not themselves directly identify andmanage themselves.

There is clearly a need to balance functionalcentralization, (in order to ensure an overview andthat overall risk management is actually carried out)with an appropriate level of decentralization (toensure individuals and groups actively manage theirown risks).

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BS 6079-3:2000

16 BSI 01-2000

Annex A (informative)

Communication in risk managementEffective communication about risks is a critical factorin risk management. Poor communication, whether ingeneral or about risks, can in itself, be a significantrisk to business and project management effectiveness.Managers therefore, always have to bear these twoconsiderations in mind when communicating in thecontext of risk management.

Achieving effective communication of risk is a complexprocess requiring attention to a large number oforganizational and technical processes. This annexdraws attention to some important factors that shouldbe attended to.

The reasons for communicating vary greatly fromordering or instructing someone to do something onthe basis of managerial authority, to seeking to educateand develop understanding. Before attending to themore technical aspects of communicating, managersshould therefore decide on the purpose or combinationof purposes that communicating with particularstakeholders is designed to achieve. Only then can anappropriate communication strategy, that maximizeseffectiveness and minimizes risk, be developed.

The communications strategy should cover the threekey aspects of the communication process as follows:

a) sending of messages to other stakeholders by thebusiness and project managers;

b) receipt of messages from other stakeholders; and

c) independent communication amongststakeholders themselves.

All these can affect the project itself, and the processof business and project risk management. Thecommunications strategy, and management ofcommunications, should be integrated with the overallrisk management process, and should take account ofrisk perception issues (see annex C). Thecommunications strategy should be developed intandem with the strategy for managing stakeholderrelationships (see annex D).

Managers concerned with the business and project,and the management of associated risks, have directcontrol over sending messages to other stakeholders.They also have an important degree of control overhow they receive messages. Attention should be givento sending appropriate messages, and ensuring thatmessages received are interpreted correctly. Bothcommunications to stakeholders, and stakeholders'perceptions of how managers received theircommunications, can affect communication amongstakeholders themselves. Care should be taken thatthis does not develop in ways that threaten thebusiness or project.

Managers should also bear in mind thatcommunication in the context of business and projectrisk management will not be just about risks, but alsoabout anything else stakeholders feel the need to

exchange messages on. The way in which thesemessages are sent and received can have an effect onoverall project risk itself as communication about riskinfluences risk perception. This is why there needs tobe integration between business and project riskmanagement, and the management and development ofthe communication strategy.

Care should be taken to express any message usingwords and images that the target audience canunderstand and using a medium with which they arecomfortable.

When sending messages, it is important to payattention to how the communication is made. Thewords in a communication contribute only a small partof what is received. Non-verbal communication alsooccurs, and this can strongly influence the meaningthat the recipient gives to the message. Non-verbalcommunication factors vary according to how thecommunication is being made. In face-to-facecommunication, important non-verbal factors includebody language (facial expression, dress), the use ofspace, and the timing of communication.Communication timing also affects non-face-to-facecommunication. In this context, other factors such asthe physical appearance of a written document, or thenature of language used, also affect how the messageis received.

Communicating within an organization is affected bythe structures of the organization. An organizationalchart is a diagram of the formal lines ofcommunication. This could be relatively simple for asingle organization. Where projects involve more thanone business, the organization chart for a project couldbe quite complex. It is important to ensure a fitbetween the formal and informal communicationsstructures within a project and with the businesssponsor, and the needs of the communications strategy.

Emphasis has been placed in these guidelines on theneed for upward communication of information aboutrisks perceived to be beyond the handling capacity ofthose at that level of activity. It is important that formalstructures do not hinder this process, otherwise therisks might go unrecognized or emerge later thannecessary or desirable. Upward communication can behindered by other factors, such as subordinates' fear ofblame, or fear that higher managers will not listen.This results in ineffective or inaccurate upwardcommunication. It is vital to effective risk managementto ensure that good upward communication does takeplace.

Communication also takes place along other channels,often informal ones outside the control of managers.Effective communication management requires anappreciation of these channels, what they are, and howthey work. These are likely to be different in everysituation. Informal channels can also help, or hinder,the overall communication process and do much toencourage risk identification.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 17

BS 6079-3:2000

Managers typically spend more of their time receivingthan sending messages. The process of listening istherefore also critical to effective communication,although it is usually taken for granted. Listeningeffectively is about actively decoding and interpretingmessages, and is different in quality from merelyhearing or reading superficially. In order to listeneffectively, managers should pay close attention to howthey are interpreting a message, whether there mightbe alternative interpretations, and what the sendermight actually be trying to communicate.

Annex B (informative)

Business and risk management tools andtechniques

B.1 General

This annex contains two lists. B.2 contains a selectionof business strategy analysis tools that can be used inconjunction with stakeholder analysis to aid riskmanagement in the context of the business, project,and sub-project relationships. The list in B.3 outlinesmajor risk management and analysis tools andtechniques.

B.2 A selection of business strategy techniquesthat support management decision making andplanning

B.2.1 Decision conferencing

This is based on decision analysis, and considersoptions and their relative utilities, and is usedextensively for strategic questions about resourceallocation. It is designed for group use, and usuallymakes use of computer based tools. A processfacilitator is required.

B.2.2 SAST Ð strategic assumption surfacingand testing

SAST attempts to explore and bring to the surface,underlying assumptions of management controlsystems and actions. Facilitation is required.

B.2.3 SODA Ð strategic options development andanalysis

This has been developed from psychology and socialpsychology as a negotiating method and uses areal-time interactive computer based support system. Itis designed for use in groups, and is very facilitatordependent.

B.2.4 SSM Ð soft systems methodology

This soft-systems methodology is a systematic thinkingprocess for tackling situations where problems andissues can at first be unclear, or where there isuncertainty about precise objectives and actions. It isregarded as appropriate for any type and level ofproblem identification and problem solving activity. Afacilitator is useful, though not essential.

B.2.5 Strategic choice

This was originally developed for public sectorplanning issues, and is based on the need to manageuncertainty about values, environment, and theinter-relationship between issues. It is designed for usein groups. Strategic choice requires a strong facilitatoralthough it can be used by a group facilitating itself.

B.2.6 Systems dynamic modelling

This is based on control system theory. It uses acomputer program to provide feedback, and can beused in group situations. It requires a facilitator.

B.3 Risk management and analysis tools

B.3.1 Assumptions analysis

Assumptions analysis is a process designed to formallyrecord and assess the assumptions underlyingidentified areas of uncertainty. This process principallyinvolves the scrutiny of statements of belief concerningfuture outcomes and an assessment of their stabilityand significance to the project. This will result in a listof identified project risks which require further action.

B.3.2 Brainstorming

A process of group identification and discussion ofrisks which is mediated by a facilitator. Discussion iskept as open as possible by discouraging criticism.Once identified, possible risks are discussedconstructively and those risks thought worthy offurther analysis can be assigned to a risk ªownerº.Skilled and purposeful facilitation of this process isessential.

B.3.3 Checklists

Checklists contain questions on specific areas of theproject to allow identification of risk, often based onpast project experience within an organization.Checklists should be kept flexible enough to allowchanges in the format as project experience informspractice. The advantage of checklists is that they canbe structured to rapidly identify sources of risk. Theycan, however, be overly prescriptive and overlook riskswhich are not based on past project performance.

B.3.4 Criticality analysis

Often used in conjunction with Monte CarloSimulation, criticality analysis identifies which activitiescould become most critical if not effectively managed.Tasks are assigned a value of between zero and 100 %according to their potential to affect the duration ofthe project. Further statistical analyses can identifywhich activities are most likely to introduce the mostuncertainty to the project.

B.3.5 Cumulative frequency plots (S curves)

Cumulative frequency plots are often used to representthe likelihood of certain milestones achieving targetsand are often used in determining bid prices andproject budgets. The plotting of these ªSº shapedcurves can be used to quantify the interaction of thelikelihood of certain events and their cumulative effectupon the project as a whole.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

18 BSI 01-2000

BS 6079-3:2000

B.3.6 Decision analysis

Decision analysis is a method used to determineoptional strategies and choose between alternativecourses of action. It often utilizes the expectedmonetary value (EMV) method. This allows thecalculation and selection of the best yieldingalternatives in relation to the organization's objectivesin undertaking the project.

B.3.7 Delphi technique

Structured method of consulting a group of experts onproject risks and their outcomes. This process isusually conducted by a chairperson who structures theconsultation so that opinions are first collectedindependently and then circulated amongst the groupuntil it is felt that a consensus has been achieved.

B.3.8 Expert interviews

Interviewing technical experts is often used to identifyand assess probable risks in the project. Interviews canbe relatively structured or unstructured but should besystematically recorded. Interviews can sometimes bethe only way that information can be elicited wheregroup sessions are impractical or inappropriate.

B.3.9 Event tree analysis

A tool for representing the sequence of possibleoutcomes following the occurrence of a specifiedinitial event. Event trees show the variouscombinations of events and the ways in which thechain of events can be broken. They permit thecalculation of the probability of different outcomesfrom other known probabilities.

B.3.10 Fault tree analysis

A deductive method of working backwards from aªtop eventº resulting in system failure. FTA works byconsecutively analysing the previous functional system.These chains of causation are then represented, usingconventional symbols, as a fault tree. These can beanalysed in either a qualitative or quantitative fashion.As these fault trees are often complex, quantificationcan depend on sophisticated mathematical formulae.

B.3.11 HAZOP study

Hazard and operability (HAZOP) methods wereoriginally developed for use in the chemical industrybut are equally appropriate for other process plants. Itis a procedure for systematically identifying hazardsand operability problems throughout the wholeproduction process and it often proceeds through thefollowing stages. First, a full description of the plant isundertaken, including the intended design conditions.Secondly, each part of the process is reviewed todiscover how deviation from planned performance canoccur. Finally, a detailed assessment of how thesedeviations can result in either hazards or operabilityproblems is specified. HAZOP studies undertaken inthe design stage can result in avoidance of some risksthrough project re-design.

B.3.12 Influence diagrams

Influence diagrams are used to represent chains ofcausation between events and decisions, usuallydepicted as nodes. These are then evaluated accordingto assessments of probability and can involvecomputer simulation of complex relationships.

B.3.13 Monte Carlo simulation

This method is a process of quantitative simulation ofpossible outcomes through generating values andweights for each possible outcome. Thiscomputer-generated simulation results in a probabilitysimulation of possible model outcomes which can thenbe used by the project management to evaluate risks.

B.3.14 Prompt lists

Prompt lists are created in order to ensure that abroad range of categories of project risk are examinedin the risk identification process. Prompt lists willidentify headings appropriate to each project in whichrisks will be explored. Some might begin by workingthrough activities while others concentrate on aspectsof the project common throughout the activities. Thesecan be a useful focus of attention during abrainstorming session.

B.3.15 Risk registers and databases

This comprises a document or database which lists allidentified risks along with other useful information,which can be used for the management of those risks.Risks are listed with information about theircharacteristics, including their ranked importance, anyquantitative indicators, and eventually risk treatmentplans. Risk registers can be more or less detailed andoften play an essential role in risk management.

B.3.16 Sensitivity analysis

Sensitivity analysis is a form of quantitative modellingwhich allows combinations of ªwhat ifº scenarios to beexplored. The analysis identifies those elements of theproject which most effect the outcomes. Sensitivityanalysis can be performed through spreadsheetsoftware and the results represented, for example, inthe form of ªtornado chartsº, ªspider plotsº or ªriskreturn graphsº for ease of interpretation.

Annex C (informative)

Risk perception

C.1 General

Perception relates to how we see things and situations,and is a critical factor in risk management because theway in which we do this affects our decision making,largely through causing us to make assumptions thatmight not always be accurate. In risk management, theaim should be to achieve as thorough and as objectivean assessment of a situation as possible. However,pure objectivity and rational behaviour is usuallyimpossible because of the ways in which we perceiverisk. Understanding this helps managers to devise waysof controlling the risks that arise from the limits onour ability to be objective.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 19

BS 6079-3:2000

Risk perception issues can be considered under threeheadings ± individual perception, group perception,and how perception influences stakeholderrelationships.

C.2 Individual risk perception

Perception of risk by individuals is highly subjective,and perceptions of risk vary with a number of factorsrelated to the individual, and the circumstances underwhich the risk is being perceived. Among the mostimportant factors are the following.

a) Familiarity and understanding

People tend to underestimate risks associated withthings or events that are familiar to them, or thatthey feel they understand. Experts oftenunderestimate risk, while the general publicoverestimate the risks from the same thing. Peoplewho play football, or engage in adventure sports,have a fair idea of the risks they run. Othershowever, underestimate the risk of injury in football,and overestimate the risk from sports like hanggliding, or rock climbing.

b) Relative place in space

Things or events people perceive as being physicallynear to them are often seen as posing greater riskthan those far away. There can be some moreobjective truth in this, but in reality what is shapingpeople's perceptions is the distance, not an actualevaluation of actual risk.

c) Relative place in time

As with space, things occurring soon are seen asinherently more risky, or as incurring risks that needattending to without delay. On the other hand, thingsseen as occurring at a more distant time are notalways given sufficient attention. Managers do notalways recognize long range planning as worthwhileand so give tomorrow's urgent problem moreattention. This can happen even when the benefits ofconcentrating on the longer term, rather thanbecoming involved in minor issues of the day, areobvious.

d) Degree of personal control

If someone feels they are controlling some thing orevent, their perception of the risks involvesdiminishes. Car drivers underestimate the risks fromtheir driving, while car passengers and others not incontrol of the situation, but dependent on someoneelse being in control, overestimate the risks.

e) Presentation of things or events

The way in which things are presented to thedecision maker has been shown to influenceperception of the kind of risk, and level of risk,involved. If things are presented in a positivemanner, there is a tendency to overestimateopportunity, and underestimate threat. Conversely, ifthings or events are presented in a negative light,there is a tendency to overestimate threat.

This has another side ± the way in which individualspresent things or events to themselves affects howthey perceive the risks involved. A manager familiarwith technical issues will generally overlook, ordownplay, issues of risk arising from human factorsor behaviour. Subconsciously, we look for risks wecan manage, or benefit from, and overlook othersbecause of the way we perceive the problem in thefirst place.

f) Perceived importance

If people feel something is important, for example, adecision, an outcome, or both, they tend tooverestimate the risks involved, regardless of theprobability or likelihood of occurrence. This canhappen with perceived threats, or opportunities.

Since a) to f) all feed through into risk management, itis important to take them into account if riskmanagement is to proceed as effectively and asobjectively as possible. It is vital to be aware of ourown perceptual limitations, as well as those of others,and to take remedial steps to check our perceptionsand understanding of risk in different situations.

C.3 Perception by groups

There are two kinds of behaviour in groups that affectrisk perception and identification.

Where the group is composed of like-mindedindividuals, who perhaps know each other well, andthere is a high level of group synergy, the group canbegin to act too well from the perspective of objectiverisk identification. This happens because theindividuals in the group assume too much about asituation, and, because they all make the sameassumptions, no one notices. Psychologists have calledthis kind of behaviour ªgroup-thinkº, and have shownit to be responsible for a number of near and actualdisasters.

The second kind of group behaviour that can pose arisk occurs when members of a group begin toexaggerate the problem or situation withoutjustification. They can do this for a variety of reasons,such as wanting to be seen as eager and willing byimportant members of the group. Since others in thegroups can also have similar motives, the problem caneasily be exacerbated. Objective risk assessments canbe lost in all this and someone who attempts to bemore objective can find themselves labelled asªnegativeº.

The two kinds of group behaviour can act together,with obvious adverse consequences for any attempts atan objective risk perception.

C.4 Risk perception and stakeholderrelationships

The way we perceive something not only affects ourdecision making. It also affects what we expect islikely to happen, and what we desire. It is particularlyimportant to take account of expectations andperceptions of desirable outcomes, when consideringrelationships with stakeholders.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

20 BSI 01-2000

BS 6079-3:2000

When business and project managers assess risks fortreatment, they should be aware that otherstakeholders will not always make the sameassessment. They can identify different risks, and inaddition, they can place different values and prioritieson the risk to be managed, and the way in which itshould be managed. This follows from consideration ofindividual and group factors affecting perception ofrisk. If their assessment differs from that of the projectmanagers, then they will also have differentexpectations about when and how that risk is to bemanaged. If those expectations are not met, then thestakeholder relationship to the project can changesignificantly.

The consequences for business related project riskmanagement are that if stakeholders' perceptions ofparticular risks are not properly taken into account inproject risk management decisions, managers can incurstakeholders' hostility to the project.

C.5 Implications for risk managementIn general, the consequences of perceptual problemsand issues are potentially negative (threats, rather thanopportunities), and hence require particular attentionin order to deflect, inhibit, and overcome.

The risk posed by perceptual biases to riskidentification can be managed by seeking a variety ofperspectives on an issue. Multi-functional teams, andcross-functional groups have been found useful. It canalso be important to ensure that teams are not tooªcomfortableº as a result of having worked togetherwell in the past. Introduction of newcomers can helpto minimize the possibility of ªgroupthinkº. However,teams require effective management to ensure thatnewcomers' contributions are not excluded. Includingoutsiders who have little to lose or gain frominvolvement in the project or the business can alsohelp the objectivity of the risk identification andmanagement processes.

How stakeholders perceive project risks can beinfluenced in various ways, ranging fromcommunication, to participation in the project.Engaging in these kinds of activity can also posefurther risks. Experts can be challenged by others withopposing viewpoints, and the fact that there is noexpert consensus on a particular issue will then beexposed. Project managers should assess this riskalongside the potential of threats from failing to meetstakeholders' expectations.

Annex D (informative)

Stakeholder analysisStakeholder analysis has been found to be particularlyuseful in risk management and as a general support tomanagement decision making. Traditional riskmanagement tools and techniques do not encourageattention to the human and organizational factorsaffecting business and projects although it is widelyaccepted that these factors are major sources of risk.Understanding risk perception (see annex C) is oneway to begin to handle these factors. Stakeholderanalysis is another.

Stakeholders are all those individuals, groups, andorganizations, including business and project teams,who have an interest in the business or project, interms of processes, outcomes, or both. Because theyhave this interest, they can be affected by the businessand its projects, or can wish to exert an influence.Whatever the nature of their interest, the existence ofthat interest means that they are a potential source ofrisk to the project and perhaps to the business.

It is not up to business or project managers to definewho has an interest, or what that interest is. Interestsare defined by individuals and groups themselves, andif a stakeholder feels that they have an interest, theycan pose a risk to the project.

Stakeholder analysis helps risk management in fourmain ways:

Ð identification of risks and risk sources;

Ð identification of the wider business and projectboundaries;

Ð identification of the wider business goals andproject objectives;

Ð identification of the relationships betweendifferent types of risk.

The more a manager knows about the business or itsprojects, the more they are able to identify potentialrisk factors. Many risk factors stem from theexpectations and perceptions that different projectstakeholders have of the project. Understanding whostakeholders are, and what their perceptions andinterests are, enables business and project managers toidentify potential areas of conflict, approaches to rolesand responsibilities, and attitudes to risk andperformance.

It is not enough to identify stakeholders who are partof the business or project organization. Otherimportant stakeholders can lie outside those innerboundaries. They can therefore be difficult tounderstand, control, or influence. But if they are in aposition to pose risks to the business or project,attempts should be made to include them in the riskanalysis. Failure to do so increases the likelihood ofoverlooking significant causes of risk, and imposesunrealistic limits on stakeholder and risk analysis.

If a project's stakeholders are identified, this alsoprovides an indication of project boundaries, andobjectives that have to be fulfilled in order to reach theproject goals. Project boundaries extend beyond thebusiness or businesses concerned to include allrelevant stakeholders. In this way, it is possible to gaina fuller appreciation of the potential scope of risksassociated with the project than would be achieved bylimiting concern to a narrower set of activities.Identifying other stakeholders draws attention toobjectives the project has to achieve in order to reachthe intended goals.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BSI 01-2000 21

BS 6079-3:2000

Finally, stakeholder analysis is a tool in total riskidentification. Many different types of risks, such asfinancial, technical, strategic, and so on, can be tracedto the behaviour and decision making of stakeholders.Stakeholder identification and analysis enablesmanagers to develop strategies for handlingrelationships with particular stakeholders or groups ofstakeholders on particular issues. The strategy towardsstakeholders should aim to minimize the threat theycould pose to the business project, and maximize anyopportunity they could provide. This process shouldalso be linked to the risk communication strategy(annex A). To develop this strategy can requireunderstanding of any conflicts of interest betweenstakeholders, including those close to the project, aswell as those further away. It also requiresunderstanding of relationships between stakeholdersthat can be built upon, and decisions about relevanttypes and appropriate levels of stakeholderparticipation at different stages of the project.Stakeholder analysis should be undertaken at thebeginning of a project, and reviewed whenever majorchanges are made, or new stakeholders involved oridentified. On occasions it can be risky to sharestakeholder analysis too publicly, and the extent ofinvolvement of stakeholders in this analysis has to bejudged at the time.

Annex E (informative)

Common examples of business andproject riskE.1 GeneralThe following subclauses list some of the mostcommon types of business and project related risk thatcan occur in association with a business and itsprojects. It should be noted that the listing is notcomprehensive.

E.2 Human factorsThe following list notes the major human resourceissues that are associated with business risk:

Ð management competence;Ð corporate policies;Ð management practices;Ð poor leadership;Ð inadequate authority;Ð poor staff selection procedures;Ð lack of clarity over roles and responsibilities;Ð vested interests;Ð perceptual errors regarding risk;Ð individual or group interests;Ð personality clashes.

E.3 Political/societalThe following list notes some of the external factors(stemming from government, regulation and society)that can affect risk in business:

Ð unexpected regulatory controls or licensingrequirements;Ð changes in tax or tariff structure;Ð nationalization;

Ð change of government;Ð war and disorder;Ð failure to obtain appropriate approval(e.g. planning consent);Ð higher than anticipated compensation costs.

E.4 EnvironmentalThe following list notes the physical environmentalfactors that can affect business risk:

Ð natural disasters (earthquake, floods,landslides etc.);Ð storms/tempests;Ð pollution incidents;Ð aircraft/ship/vehicle collisions.

E.5 LegalThe following list notes the major legal considerationsthat can affect business risk:

Ð unforeseen inclusion of contingent liabilities;Ð loss of intellectual property rights;Ð failure to achieve satisfactory contractualarrangements.

E.6 Economic/financialThe following list notes the major economicconsiderations that can affect business risk:

Ð exchange rate fluctuation;Ð interest rate instability;Ð inflation;Ð shortage of working capital;Ð failure to meet revenue targets.

E.7 CommercialThe following list notes the major commercialconsiderations that can affect business risk:

Ð under performance to specification;Ð management under performance;Ð collapse of contractors;Ð insolvency of promoter;Ð failure of suppliers to meet contracts (quality orquantity or timescales);Ð cost and time over-runs;Ð failure of plant and machinery;Ð insufficient capital revenues;Ð market fluctuations;Ð fraud;Ð increased costs of revenue collection.

E.8 Technical/operationalThe following list notes the major technicalconsiderations that can affect business risk:

Ð inadequate design;Ð professional negligence;Ð human error/incompetence;Ð structural failure;Ð operation lifetime lower than expected;Ð residual value of assets lower than expected;Ð dismantling/decommissioning costs;Ð safety;Ð performance failure;Ð residual maintenance problems.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I

BS 6079-3:2000

BSI389 Chiswick High RoadLondonW4 4AL

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

BSI Ð British Standards Institution

BSI is the independent national body responsible for preparing British Standards. Itpresents the UK view on standards in Europe and at the international level. It isincorporated by Royal Charter.

Revisions

British Standards are updated by amendment or revision. Users of British Standardsshould make sure that they possess the latest amendments or editions.

It is the constant aim of BSI to improve the quality of our products and services. Wewould be grateful if anyone finding an inaccuracy or ambiguity while using thisBritish Standard would inform the Secretary of the technical committee responsible,the identity of which can be found on the inside front cover. Tel: 020 8996 9000.Fax: 020 8996 7400.

BSI offers members an individual updating service called PLUS which ensures thatsubscribers automatically receive the latest editions of standards.

Buying standards

Orders for all BSI, international and foreign standards publications should beaddressed to Customer Services. Tel: 020 8996 9001. Fax: 020 8996 7001.

In response to orders for international standards, it is BSI policy to supply the BSIimplementation of those that have been published as British Standards, unlessotherwise requested.

Information on standards

BSI provides a wide range of information on national, European and internationalstandards through its Library and its Technical Help to Exporters Service. VariousBSI electronic information services are also available which give details on all itsproducts and services. Contact the Information Centre. Tel: 020 8996 7111.Fax: 020 8996 7048.

Subscribing members of BSI are kept up to date with standards developments andreceive substantial discounts on the purchase price of standards. For details ofthese and other benefits contact Membership Administration. Tel: 020 8996 7002.Fax: 020 8996 7001.

Copyright

Copyright subsists in all BSI publications. BSI also holds the copyright, in the UK, ofthe publications of the international standardization bodies. Except as permittedunder the Copyright, Designs and Patents Act 1988 no extract may be reproduced,stored in a retrieval system or transmitted in any form or by any means ± electronic,photocopying, recording or otherwise ± without prior written permission from BSI.

This does not preclude the free use, in the course of implementing the standard, ofnecessary details such as symbols, and size, type or grade designations. If thesedetails are to be used for any other purpose than implementation then the priorwritten permission of BSI must be obtained.

If permission is granted, the terms may include royalty payments or a licensingagreement. Details and advice can be obtained from the Copyright Manager.Tel: 020 8996 7070.

Lice

nsed

Cop

y: R

uper

t Hey

gate

-Bro

wne

, Agi

p K

OC

, 30

Sep

tem

ber

2003

, Unc

ontr

olle

d C

opy,

(c)

BS

I