Addis Ababa University

School of Commerce Graduate

Program

Project Management
Supported Distance Learning
Program

Decision making &project Risk

Management
(MAPM 607-3)
 Table of contents
PAGE

Preface ……………………………………………………………………………….………... 7

CHAPTER 1

Introduction …………………………………………………………………………………. 10

1.1 Awareness about risk …..……………..…………………………….….………………………………….……..…. 11

1.2 Uncertainty in projects……………………………………………………………………….………………….….. 13
1.3 Projects, Risk and project management……………………………………………………………………... 17
1.4 The need for this module….…………………………………………………………..……………………………… 19
1.5 What is Risk? ……………………………………………………………………………………………………………….. 20
1.6 Summary …………………………………………………………………………………………………………………….. 28

CHAPTER 2

Preparing the organization: Building a risk management culture…….29

2.1 Risk : the organizational culture issue .……………………………………………………………………… 31

2.2 Classifying Risk……………………………………….…………………………………………………………………. 36

2.3 Summary ………………………………………………………………………………………………………………….…40

CHAPTER 3

Looking At Projects ……………………………………………………………………… 41

3.1 Introduction………………………………………………………………………………………...………..………….. 42

2|P ag e
3.2 The nature of projects …………………………………..…………………………………………………….. 42

3.3 Project complexity……….. ……………………………………………………………….…………..………... 43

3.4 Mapping project risks ………………………………………………………………………………………..……. 47

3.5 Risky projects ……..………….……………………………………………………………………………………... 47

3.6 Summary………………………………………………………………………………………………………………… 53

CHAPTER 4

Demystifying risk: Using the PMI PMBOK ……………………………………. 55

4.1 Demystifying risk -PMBOK………………………..…………………………………………………………..…….56

4.2 Inputs to risk management planning……………….………………………………………………………… 59

4.3 Tools and techniques for risk management planning…….………………………………………... 61

4.4 Risk identification……………………….………………………………………………….……………………….… 62

4.5 Qualitative risk analysis………………………………………………………………….………………………... 65

4.6 Quantitative risk analysis…………………………………………………………………………………………... 67

4.7 Risk monitoring and control………………………………………………………………………………………. 69

4.8 Summary of the risk management process……………………………………………………………….. 71

4.9 Summary ……………………………………………………………………………………………………………...…… 82

CHAPTER 5

Systematic Risk Management ……………………………………………………….83

5.1 Introduction ……………………………………………………………………………………………………………… 84

3|P ag e
5.2 Stakeholder risks-Not project risks ……………………………………………………………………………. 84

5.3 Features of systematic risk management …………………………………………………………………... 87

5.4 Risk Management system………………………………………………………………………………………….. 88

5.5 Establishing the risk context………………………………………………………………………………………. 89

5.6 Risk identification………………………………………………………………………………………………………. 92

5.7 Summary……………………………………………………………………………………………………………………. 100

CHAPTER 6

Risk analysis ………………………………………………………………………………...102

6.1 Introduction………………………………………………….………..……….………………………………………….103

6.2 Risk allocation………………………………………………………………….……………………………………….. 103

6.3 A three dimensional risk magnitude perspective………………………….………………………...... 104

6.4 Other assessment techniques…….………………………………………………………………………………. 112

6.5 Risk ranking……………………………………………………………………………………….…………..……….…. 116

6.6 Summary …………………………………………………………………………………………………………………… 117

CHAPTER 7

Risk matrix samples …………………………………………………………………… 118

7.1 Steps in preparing a risk matrix……………………………………………………..…………………………. 119

7.2 Summing up : Risk matrix examples……………………………………………..………………………… 121

7.3 Summary…………………………………………………………………………………..…………………………..... 125

4|P ag e
CHAPTER 8

Customer driven project management, TQM and risk ……………….. 126

8.1 Customer driven Risk management……..…………………………………..…………….………………….127

8.2 Portfolio and program management………………..……………………..…..…………………………… 130

8.3 Value of customer- driven risk management……………………………..…………………………... 131

8.4 Summary……..………………………………………………………………………………………….……………… 133

CHAPTER 9

Risk decisions and actions …………………………………………………………. 134

9.1 Introduction…………………………………………..……………………….………………………………….……...135

9.2 Risk response options……………………………………………………………….……………………….…… 135

9.3 Strategic risk response………………………………………………………………………..…………….…... 141

9.4 Risk monitoring and control…. ………………………………………………….……..……………..……… 143

9.5 Risk disaster planning and risk recovery………………………………………….……………………. 146

9.6 Post project risk evaluation and recording……………………………………………………….……… 147

9.7 Communicating risk messages…………………………………………………………………………………. 148

9.8 Summary ……………………………………………………………………………………..…………………………. 148

CHAPTER 10

Building a risk management system …………………………………………….149

5|P ag e
10.1 Introduction…………………………………………………………………………………..……………………….150

10.2 Organizational maturity in risk management………………………………………………………… 150

10.3 Organizational RMS policy and implementation strategy…………………………………... 155

10.4 Clarifying objectives, tasks and commitments…………………………………………………….… 158

10.5 Creating a project risk management framework……………….……………………………………159

10.6 Assigning RMS responsibility…………………………………………….…………………………………… 163

10.7 Risk management communication…………………………………………………………………….…… 165

10.8 Trialing techniques…………………………………………………….………………………………..………… 169

10.9 Evaluating response options…………………………………………………………………………………….169

10.10 Evaluating monitoring and control procedures………………………………………………..…. 170

10.11 Establishing risk registers ……………………………………………………………………….…………… 170

10.12 Reviewing RMS performance…………………………………………………………………………..….. 175

10.13 Summary …………………………………………………………………………………………………………….. 177

CHAPTER 11

Risk lessons learned and the project risk audit ………………………… 179

11.1 How to do risk lessons learned review………………………………………………..………………. 181

11.2 A postscript to lessons learned..………………………………………………………………………… 182

11.3 Summary……………………………………………………………………………………..…………………... 184

CHAPTER 12

6|P ag e
Opportunity management …………………………………………………………. 185

12.1 The ‘Adverse impact’ risk perspective………………………………..………………………………… 186

12.2 The risk opportunity perspective. …………………………………..…………………………………… 188

12.3 Implications for risk management………………………………………………………………………… 189

12.4 The Summary………………………………………………………………………….…………….…………….. 192

Bibliography ……………………………………………………………………………………………………… 194

7|P ag e
 PREFACE
This module endeavors to exhibit the concepts of project management in tandem with the
possible unanticipated adverse scenarios. It is firmly believed that between time constraints,
technical challenges, and resource difficulties, things that can go wrong often do-which is why
one of the most important parts of a savvy project manager is considering the possible risks
involved at every point in the project management bandwagon. Hence, this module is coined
towards making you a prudent project manager.

It is not uncommon to see projects whose deadlines are not met apart from project failures.
Hence accountable rests on the project managers as everyone puts the blame on them. The
increasing pressures upon projects and their management suggest that it is prudent for anyone
involved in a project to be concerned about the risks associated with that project, and about
how their risks should best be managed. The purpose of project risk management is to obtain
better project out-comes in terms of schedule, cost and operations performance.

This module is based upon the premise that the management of projects can be improved by
firstly raising organizational awareness about risks, and then implementing formal processes to
deal with them and learn from them. Doing this increases the likelihood that projects will be
successful.

This module deemed useful for those seeking a brighter insight in to project risk management
and its associated concepts so that better understanding, promotion and support towards the
field can be delivered.

In general this module is designed to help learners understand different concepts of project
under risk management domain. It also provides learners the desired knowledge, skills, and
competencies that would enable them to become confident project managers who are superbly
wary of project related doubts.

8|P ag e
Decision making and project risk management
(MAPM 607-3)
5 ECTS
Content
Introduction

Chapter one: Introduction to project risk concepts

Chapter two: Preparing the organization: Building a risk management culture

Chapter three: Looking at projects

Chapter four: Demystifying risk: using the PMI PMBOK

Chapter five: Systematic Risk management

Chapter six: Risk analysis

Chapter seven: Risk matrix samples

Chapter eight Customer- driven project management, TQM and Risk

Chapter nine: Risk decisions and actions

Chapter ten: Building a risk management system

Chapter eleven: Risk lessons learned and the project risk audit

Chapter twelve: Opportunity Management

9|P ag e
 Introduction

Dear learners, Welcome to this Module that will well equip you with the fundamental
concepts of project management under the context of undesirable scenarios. This Module
will enable you master superb project management skills coupled with the appropriate risk
management and decision making skills. The module is divided into fourteen chapters. The
first chapter deals with an introductory highlight on project risk zooming in on the basic
concepts of risk and uncertainty. The second, third and fourth chapters deal with establishing
an excellent risk management culture manifested via several models. The rest coming
chapters endeavor to seek answer towards how to become a prudent project manager
inquiry.

Each chapter has short summary. The chapter summary presents important points covered in
that particular chapter. As a teaching material, this module provides you a good background
and understanding of project risk management concepts, principles, strategies, programs and
processes. Therefore, you are strongly advised to summarize concepts using your own
expression after you finish each section and chapter.

Dear learners, to help you understand the concepts discussed in each unit, you are given
numerous activity questions. Attempt all the provisions.

After completing this module, you are anticipated to:

 Understand, explain and appreciate project management in general and project risk
management in particular.
 Acquire awareness of uncertainties and risk as backing factors under project
management career.
 Understand and appreciate the concepts needed so as to pursue a successful project
risk management goal.
 Identify the influences or contributions of project risk management in economic
development.
 Understand and explain the core competencies serving as a stepping stone to yield
successful project risk management.
 Be able to develop project risk management competencies to venture into the
transformation bandwagon that our country is shooting.
 Understand why project delays and risks arise and why this has become a focal point
of project management.

10 | P a g e
 CHAPTER 1
INTRODUCTION
OBJECTIVE:
 To enable learners understand the basic concepts of risk and uncertainty under the
context of project management.
 To enable learners appreciate project risk management behavior.

Content:
Introduction

1.1 Awareness about risk

1.2 Projects, risk and project management
1.3 The need for this module
1.4 What is risk
Summary

Introduction

Dear learners, we may hardly produce a single definition that holds the complete flavor of
the term ‘risk.’ The narrower meanings are closely linked to the adverse discrepancies
observed between the anticipated and actual outcomes. Therefore, here under you will be
acquainted with the diversified nature of risk and uncertainties under the domain of
superb project management skill.

Hence at the end of this unit, you are expected to:

 Identify and interpret the terms and elements involved in the concept of risk,
uncertainty and project management.
 Understand the basic concept of project management under the shadow of
adverse scenarios.
 Identify risk management skills and how they are important to be an excellent
project manager.
 Understand the concept of uncertainty from the project management point of
view.

11 | P a g e
1.1 AWARENESS ABOUT RISK
Risk is pervasive. It is a universal experience and inescapable. We all face risk - some people
more frequently and more willingly than others. While some worry constantly about risk, others
cheerfully seek it out. Risk surrounds us, but we are not always fully conscious of it, nor do we
consistently respond to it wisely or effectively.

Uncertainty, Risk, and their Management

The need to manage uncertainty is inherent in most projects that require formal project
management, using „uncertainty‟ in the plain English „lack of certainty‟ sense. Consider the
following illustrative definition of a project:

an endeavor in which human, material and financial resources are organized in a novel
way, to undertake a unique scope of work of given specification, within constraints of cost
and time, so as to achieve unitary, beneficial change, through the delivery of quantified and
qualitative objectives—Turner (1992).

This definition highlights the change-inducing nature of projects, the need to organize a variety
of resources under significant constraints, and the central role of objectives in project definition.
It also suggests inherent uncertainty related to novel organization and a unique scope of work,
which requires attention as a central part of effective project management.

Much good project management practice can be thought of as effective uncertainty management.
For example, good practice in planning, co-ordination, setting milestones, and change control
procedures seeks to manage uncertainty directly. However, most texts on project management do
not consider the way uncertainty management should be integrated with project management
more generally, in terms of a wide view of what a co-ordinated approach to proactive and
reactive uncertainty management can achieve.

Threats and opportunities

A simplistic focus on project success and uncertainty about achieving it can lead to uncertainty
and risk being defined in terms of „threats to success‟ in a purely negative sense. For example,
suppose success for a project is measured solely in terms of realized cost relative to some target
or commitment. Then both „uncertainty‟ and „risk‟ might be defined in terms of the threat to
success posed by a given plan in terms of the size of possible cost overruns and their likelihood.
From this perspective it can be a natural step to regard risk management as essentially about
removing or reducing the possibility of underperformance. This is extremely unfortunate,
because it results in a very limited appreciation of project uncertainty and the potential benefits
of project risk management. Often it can be just as important to appreciate the positive side of
uncertainty, which may present opportunities rather than threats.

In any given decision situation both threats and opportunities are usually involved, and both
should be managed. A focus on one should never be allowed to eliminate concern for the other.
Moreover, opportunities and threats can sometimes be treated separately, but they are seldom
independent, just as two sides of the same coin can only be examined one at a time, but they are
12 | P a g e
not independent when it comes to tossing the coin. Courses of action are often available that
reduce or neutralize potential threats and simultaneously offer opportunities for positive
improvements in performance. It is rarely advisable to concentrate on reducing threats without
considering associated opportunities, just as it is inadvisable to pursue opportunities without
regard for the associated threats.

Recognizing this, guides published by the US Project Management Institute (PMI) and the UK
Association for Project Management (APM) have adopted a broad view of risk in terms of
threats and opportunities. Their definitions of risk are very similar, as follows:

Risk—an uncertain event or condition that, if it occurs, has a positive or negative effect on a
project objective—PMI (2000, p. 127).

Risk—an uncertain event or set of circumstances that, should it occur, will have an effect on
the achievement of the project’s objectives—APM (1997, p. 16).

These widely used definitions embrace both welcome upside and unwelcome downside effects.
In spite of this, there is still a tendency for practitioners to think of risk management in largely
downside, threat management terms (a tendency that the authors are not always able to resist). It
is important to keep „beating the drum‟ to remind ourselves that we are dealing with the upside
as well as the downside of uncertainty, with a balance appropriate to context. Even in a safety
critical context, when the downside has clear priority, it is a serious mistake to forget about the
upside.

Uncertainty about anything that matters as a starting point

While we warmly endorsed the PMI and APM definitions with respect to their breadth in terms
of threats and opportunities, we strongly resist the very restricted and limiting focus on „events‟,
„conditions,‟ or „circumstances‟, which cause effects on the achievement of project objectives.
Rather than a focus on the occurrence or not of an event, condition, or set of circumstances, it is
important to take uncertainty about anything that matters as the starting point for risk
management purposes, defining uncertainty in a simple „lack of certainty‟ sense. Uncertainty
management is not just about managing perceived threats, opportunities, and their implications;
it is about identifying and managing all the many sources of uncertainty that give rise to and
shape our perceptions of threats and opportunities. It implies exploring and understanding the
origins of project uncertainty before seeking to manage it, with no preconceptions about what is
desirable or undesirable. Key concerns are understanding where and why uncertainty is
important in a given project context, and where it is not. This is a significant change in emphasis
compared with most project risk management processes.

13 | P a g e
1.2 UNCERTAINTY IN PROJECTS
Activity
Dear learners do you agree with the common maxim that sates all projects are exposed to
risk and uncertainty. Support your answer with a practical example.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___
The scope for uncertainty in any project is considerable, and most project management activities
are concerned with managing uncertainty from the earliest stages of the Project Life Cycle
(PLC), clarifying what can be done, deciding what is to be done, and ensuring that it gets done.
Uncertainty is in part about „variability‟ in relation to performance measures like cost, duration,
or „quality‟. It is also about „ambiguity‟ associated with lack of clarity because of the behavior of
relevant project players, lack of data, lack of detail, lack of structure to consider issues, working
and framing assumptions being used to consider the issues, known and unknown sources of bias,
and ignorance about how much effort it is worth expending to clarify the situation.

In a project context these aspects of uncertainty can be present throughout the PLC, but they are
particularly evident in the pre-execution stages, when they contribute to uncertainty in five areas:

1. variability associated with estimates;

2. uncertainty about the basis of estimates;
3. uncertainty about design and logistics;
4. uncertainty about objectives and priorities;
5. uncertainty about fundamental relationships between project parties.

All these areas of uncertainty are important, but generally they become more fundamentally
important to project performance as we go down the list. Potential for variability is the dominant
issue at the top of the list, but ambiguity becomes the dominant underlying issue toward the
bottom of the list. Uncertainty about variability associated with estimates involves the other four
areas: each of them involving dependencies on later areas in this list.

Variability associated with estimates

An obvious area of uncertainty is the size of project parameters such as time, cost, and quality
related to particular activities. For example, we may not know how much time and effort will be
required to complete a particular activity. The causes of this uncertainty might include one or
more of the following:
 lack of a clear specification of what is required;
 novelty or lack of experience of this particular activity;

14 | P a g e
  complexity in terms of the number of influencing factors and the number of
interdependencies;
 limited analysis of the processes involved in the activity;
 possible occurrence of particular events or conditions that might affect the activity.

Only the last of these items is directly related to specific events or conditions as referred to in the
PMI (2000) and APM (1997) definitions of „risk‟. The other sources of uncertainty arise from a
lack of understanding of what is involved. Because they are less obviously described as threats or
opportunities, they may be missed unless a broad view of uncertainty management is adopted.

Uncertainty about the basis of estimates

The quality of estimates depends on: who produced them, what form they are in; why, how, and
when they were produced; from what resources and experience base; and what assumptions
underpin them. The need to note assumptions about resources, choices, and methods of working
is well understood if not always fully operationalized.

Uncertainty about design and logistics

In the conception stage of the PLC the nature of the project deliverable and the process for
producing it are fundamental uncertainties. In principle, much of this uncertainty is removed in
pre-execution stages of the PLC by attempting to specify what is to be done, how, when, and by
whom, and at what cost. In practice, a significant amount of this uncertainty may remain
unresolved through much of the PLC. The nature of design and logistics assumptions and
associated uncertainty may drive some of the uncertainty about the basis of estimates.

Uncertainty about objectives and priorities

Major difficulties arise in projects if there is uncertainty about project objectives, the relative
priorities between objectives, and acceptable trade-offs. These difficulties are compounded if this
uncertainty extends to the objectives and motives of the different project parties and the trade-
offs parties are prepared to make between their objectives. A key issue is: „do all parties
understand their responsibilities and the expectations of other parties in clearly defined terms,
which link objectives to planned activities?‟

Uncertainty about fundamental relationships between project parties

The relationships between the various parties may be complex, even if they look quite simple.
The involvement of multiple parties in a project introduces uncertainty arising from ambiguity in
respect of (Ward, 1999):
 specification of responsibilities;
 perceptions of roles and responsibilities;
 communication across interfaces;
 the capability of parties;
15 | P a g e
  formal contractual conditions and their effects;
 informal understandings on top of, or instead of, formal contracts;
 mechanisms for co-ordination and control.

Ambiguity about roles and responsibilities for bearing and managing project related uncertainty
can be crucial. This ambiguity ought to be systematically addressed in any project, not just in
those involving formal contracts between different organizations. Contractor organizations are
often more aware of this source of ambiguity than their clients, although the full scope of the
threats and opportunities that this ambiguity generates for each party in any contract (e.g., via
claims) may not always be fully appreciated until rather late in the day. For example,
interpretations of risk apportionment implied by standard contract clauses may differ between
contracting parties. The nature of assumptions about contractual relationships and associated
uncertainty may drive uncertainty about objectives and priorities with further knock-on effects.

The six Ws framework for the roots of uncertainty

In the authors‟ experience the initial motivation for applying formal risk management usually
arises because of concerns about design and logistics issues in major projects that involve the
large-scale use of new and untried technology. However, the most important issues that risk
management helps to resolve are usually related to objectives and relationships between project
parties. For example, a common issue in most projects is: „do we know what we are trying to
achieve in clearly defined terms, which link objectives to planned activities?‟ It is important to
understand why this situation arises and to respond effectively in any project context.

A convenient starting point is consideration of the project definition process. There are six basic
questions that need to be addressed:
1. who who are the parties ultimately involved? (parties);
2. why what do the parties want to achieve? (motives);
3. what what is it the parties are interested in? (design);
4. whichway how is it to be done? (activities);
5. wherewithal what resources are required? (resources);
6. when when does it have to be done? (timetable).

The scope of project risk management

Efficient and effective project management requires appropriate management of all the sources
of uncertainty outlined above. Risk Management Processes (RMPs) that adopt a simplistic focus
on threats will not address many of these sources of uncertainty. RMPs concerned with threats
and opportunities using the APM (1997) or PMI (2000) definitions of „risk‟ will do better, but
will still tend to be focused on uncertain events, conditions, or circumstances. This does not
facilitate consideration of aspects of variability that are driven by underlying ambiguity. To
address uncertainty in both variability and ambiguity terms we need to adopt a more explicit
focus on uncertainty management. Uncertainty about anything that matters has to be the starting
point for holistic and integrated project risk management.
16 | P a g e
To this end it is useful to define „risk‟ as an uncertain effect on project performance rather than
as a cause of an (uncertain) effect on project performance. Such a definition of project „risk‟ is
„the implications of uncertainty about the level of project performance achievable‟.

It is essential to see project risk management as an important extension of conventional project

planning, with the potential to influence project design as well as activity-based plans on a
routine basis, occasionally influencing very basic issues like the nature of the project parties and
their objectives for the project. There are many ways to classify „plans‟. In general we will
associate „plans‟ with all six Ws, sometimes identifying „activity-based plans‟, „plan-based
resource allocations‟, and so on.
To realize in practical terms the advantages of this wider perspective, it is essential to see project
risk management as an important extension of conventional project planning, with the potential
to influence project design as well as activity-based plans on a routine basis, occasionally
influencing very basic issues like the nature of the project parties and their objectives for the
project.

„Base plans‟ are target scenarios, a portrayal of how we would like a project to go, incorporating
proactive responses to uncertainty identified by proactive RMP planning. Base plans provide a
basis for project preparation, execution, and control. Underlying the base plan in activity terms is
a design, which may be worth identifying as a „base design‟ if changes are anticipated. Base
plans in activity terms imply base plans in resource allocation terms and associated base plan
timetables. It may be useful to associate the who and why with base plans explicitly too, if
changes are anticipated.

Control involves responding to threats and opportunities, and revising performance targets where
appropriate. „Contingency plans‟ are a second level of plan, a portrayal of how we would like to
respond to threats or opportunities associated with a base plan, incorporating reactive responses
to uncertainty identified by proactive RMP planning. Where uncertainty presents potential future
threats or opportunities, risk management seeks to modify the future incidence and quality of
threats or opportunities and their possible impact on project performance via proactive planning
in terms of base plans and contingency plans. This does not mean that reactive planning will not
be necessary or that all possible out-turns will have been predicted. It means that proactive
planning will have been carried out to an extent that allows reactive planning to cope without
nasty surprises most of the time. Reactive risk management, responding to the control function,
sometimes without contingency plans in place, should be reasonably panic-free, without a need
for crisis management most of the time. A degree of crisis management may be essential even in
the context of very effective and comprehensive risk management, but relatively few crises
should come totally „out of the blue‟.

Proactive risk management needs to be embedded in both base plans and contingency plans.
Further, proactive and reactive planning are not alternatives, they are complementary aspects of
planning as a whole, with proactive contingency planning supporting reactive contingency
planning when this is cost-effective. Similarly, crisis management is not an alternative to risk
management; it is a consequence of risk management failure. Nevertheless, even the most
effective risk management must fail on occasions if it is to remain cost-effective on the average.

17 | P a g e
Only if risk management fails completely, or is simply not addressed, will crisis management
become the dominant management mode.

Project risk management is usually associated with the development and evaluation of
contingency plans supporting activity-based plans, but effective project risk management will be
instrumental in the development of base plans and contingency plans for all six Ws. Really
effective risk management will strongly influence design and may significantly influence
motives and parties. It will certainly influence basic timing and resource allocation plans.
Planning and risk management in this sense are integrated and holistic.

Treating project management and project risk management as closely coupled processes is
central to the approach taken in this course.

1.3 PROJECTS, RISK AND PROJECT MANAGEMENT

An obsessive personal preoccupation with risk is probably unhealthy, but a sufficient awareness
of risk (and a capacity to deal with it) is to be encouraged, especially when making decisions that
are likely to be life-changing.

The same wisdom applies to projects. Indeed, the nature of modern projects makes the proper
management of risks even more important. All projects involve risk, and many of today's
projects are inherently more complex than those of yesterday in terms of their structure,
technology and resource demands, their financial and organisational arrangements. The
objectives set for modern projects have become more demanding. We want them to deliver
greater benefits than before - and usually more quickly. Projects are expected to impose fewer
negative impacts than their predecessors on sensitive environments. The jargon of projects has
expanded to include terms such as 'triple bottom line' (in terms of economic, environmental and
social accountability), 'corporate social responsibility', 'due diligence' and 'governance'. All of
these are capable of exerting influence on the inescapable decision-making that surrounds
projects. They can affect, or are affected by, project outcomes.

All projects have starting points and finishing points. This distinguishes them from other
undertakings, such as manufacturing or retail commerce, where the starting point may be known
but the finishing point may be theoretically indeterminate.

Some projects are undertaken for the purpose of establishing a facility to house or allow other
ongoing activities to take place, for example, a project to install and commission an IT help-desk
is undertaken in order to respond to a need to deal with IT-related problems on an ongoing basis.
The installation project concludes when the help-desk is operating satisfactorily. Other projects
may also incorporate operational and disposal stages following the initial establishment. In
events management, for example, a project may include the setting-up activities for an event; the
event itself; and the subsequent demobilisation of participants and equipment. Another
distinctive feature about projects, therefore, is that they demand the acquisition and application
of resources over and above those normally required for purely operational purposes.

18 | P a g e
Most projects will have objectives that are different from, but related to, the broader objectives
of the client or sponsoring organisation. These differences in objectives have implications for
project and risk management. Beyond this, projects today tend to involve more participants,
partly because of the trend to greater specialisation and partly because the interests of other
groups, perhaps ignored in the past, are now increasingly recognised. Each participant has a
different role to play, and will have different expectations and needs. The nature and level of the
risks that each of these project stakeholders faces will be different.

It can also be deduced that the characteristics of many project risks may themselves change over
the life of the project. Project risks thus tend to be dynamic rather than static.
As projects have got more complicated, so too has the way we undertake them. Traditional
procedural forms of project procurement have been overtaken by newer and different
approaches. This is particularly true for infrastructure mega-projects - dams, power stations,
railways, airports, roads - where publicly financed provision and ownership of these types of
facilities and services has largely given way to privately financed development, ownership and
operational concessionaire arrangements.

All projects must be managed in some way, and all involve the preplanning and organising of
activities that, by definition, will take place at some time in the future. Projects are not created
retrospectively in the past. Nor do they occur exclusively in the present: plans cannot be both
prepared and executed simultaneously, other than in a virtual environment. Consideration of the
future, and making decisions about it, dominate the management processes of all projects. As the
future cannot be known with complete certainty, there will be uncertainty associated with any
project and, since risk is associated with uncertainty, all projects therefore involve risk. For any
project, the extent of uncertainty it exhibits tends to be reflected in the degree of project planning
that can be undertaken. Depending upon the particular nature of the project, long-range plans
(months, years) have to deal with greater levels of uncertainty than short-range plans (hours,
days, weeks). Long-range project plans are therefore more susceptible to risk than short-range
plans.

The process of managing projects is itself undergoing development, especially as more and more
participants have become involved. In addition to organising and controlling the planning and
execution of tasks, the application of technologies, and the acquisition of resources necessary for
all projects, modern project management now has to deal with the often competing and
conflicting demands of many stakeholders. The tools and techniques of project management
have become more sophisticated, providing opportunities for project managers to generate better
information and exert greater control over their projects. Advances in information and
communication technology (ICT) mean that many of the information requirements of project
management can be dealt with more swiftly than ever before, with more controlled distribution.
Project extra-nets are an example of this.

However, few of these advances and developments simplify project management. They enable us
to manage projects better, but for the most part at the cost of adding more layers of complexity.

19 | P a g e
1.4 THE NEED FOR THIS MODULE
Like risk, projects surround us at every point, and in every dimension in life. We are a project-
driven society. The growth of project management as a professional discipline is testimony to
this, although obviously not all projects are professionally managed. Children are confronted
with projects from the very earliest days of formal schooling. Adults in every field of
employment are increasingly expected to be involved with them at various times during their
careers. Even finding a new job or changing one's career is today regarded as a project. There is
no escape for retirees, either, as they take up new interests and new involvements in later life.

Society desires that all projects should be successful, and has become less tolerant of failure.
Pressure is exerted on project managers to minimise the chance that failure will happen. The
increasing pressures upon projects and their management suggest that it is prudent for anyone
involved in a project to be concerned about the risks associated with that project, and about how
their risks should best be managed.

There is a significant growth in risk management education and training at tertiary level, and a
proliferation of professional career development courses on the same topic. Many of these
resources are tailored to the requirements of specific industries and professions.
Few are presented in a project context. That they have become available is due more to a
spreading concern with risk generally in contemporary society than to any particular appreciation
of risk issues in project management. We struggle to understand and deal with many risk
situations - the environment, finance, health, violence and terrorism included - from a domestic
level through to corporate and government levels; and from a personal to national and
international perspectives. Worldwide concern also explains the rise in risk management
consultancy, often offered as an adjunct to their existing services by professional firms such as
accountants. The risk management advice rarely has a project focus. The emergence of all these
factors drives a demand for information about risk and risk and risk management.

There are many books about risk, and an increasing number about risk management, but here
again few bring these together under a project banner. Few look at how risk management could
be used as a way to improve project performance. This module is based upon the premise that the
management of projects can be improved by firstly raising organisational awareness about risks,
and then implementing formal processes to deal with them and learn from them. Doing this
increases the likelihood that projects will be successful.

Projects as a Generic Phenomenon

The uniqueness/similarity paradox of projects exposes a dilemma for the authors of any book
about project management. Should they focus upon the micro-management needs of specific
types of projects, or attempt a macro-management approach that concentrates solely upon
important common project characteristics?

20 | P a g e
This module is intended to be a generic one, applicable to all types of projects. Since we have
already noted that projects are invariably diverse in terms of type, scope, size, technology and
resource requirements, cost, value, duration, location and organisation, this means that some loss
of specific focus will inevitably occur at times in the following chapters. Even for projects of
similar type, e.g. school construction projects, other factors associated with them, such as the
individual site locations, ground conditions, neighbouring buildings, starting and finishing dates,
etc., will ensure that each remains unique. Project diversity, therefore, can extend across the full
range of task, technology, resource and organizational requirements that all projects entail.

While it is not possible to be specific in this text about particular risks for every type of project,
and yet at the same time provide sufficiently comprehensive coverage of the topic, many
examples are presented. The intention of the module is to use these examples to illustrate
principles and techniques of risk and risk management that are generically applicable. There is
no attempt to provide exhaustive lists of risks for particular types of projects. That is the
challenge that always faces you, the reader, as you seek to identify and manage the risks of your
own unique projects. What you will find instead are some useful tools and techniques to help you
in this responsibility.

1.5 WHAT IS RISK?

DEFINITIONS AND CONCEPTS OF RISK

Activity
Dear learners here under you are expected to recall your memories of the term risk. What is
risk? How does it influence the success behind a project?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

The meaning of the term “risk” must be understood clearly for effective project risk
management. In the context of a project, we are concerned about potential impacts on project
objectives such as cost and time. A general definition of “risk” in this context is:
Risk is an uncertainty that matters; it can affect project objectives negatively or positively.
The uncertainty may be about a future event that may or may not happen and the unknown
magnitude of the impact on project objectives if it does happen. Thus, a “risk” is characterized
by its probability of occurrence and its uncertain impact on project objectives.

Risks in a project, should they come to fruition, can mean total project failure, increased costs,
and extended project duration among other things. Risk often has a negative connotation, but like

21 | P a g e
the parachutist, the acceptance of the risk can also offer a reward. For project managers, risk can
mean failure, but the reward can mean a time or cost savings, as well as other benefits.

Risk management is the process in which the project manager and project team identify project
risks, analyze and rank them, and determine what actions, if any, need to be taken to avert these
threats. Associated with this process are the costs, time, and quality concerns of the project
brought about by the solutions to those risks. In addition, the reactions to risks are analyzed for
any secondary risks the solutions may have created.

Risk is a combination of the frequency, or probability, of occurrence and the consequence of a

specified hazardous event. The concept of risk always incorporates two elements: probability (of
occurrence), and consequence. Risk is the chance of something happening that will have an
impact upon objectives. It is measured in terms of consequences and likelihood. Here the notion
of objectives is introduced. In these definitions, 'probability', 'likelihood' and 'chance' are used
synonymously, as also are 'consequence' and 'impact'.

According to the Oxford English Dictionary (OED, 1989), risk is: 'the chance or hazard of a
commercial loss‟. From the same source, two further contextual dictionary definitions are given:
'exposure to mischance or peril' and 'the chance that is accepted in economic enterprise and is
considered the source of profit'. A dual view of risk –loss and gain - is introduced here; hence the
popularity of 'upside risk' and 'downside risk' in some financial circles.

Whichever definition is preferred, the important point to remember is that, in dealing with risk,
all four aspects should be considered:
 the probability that an event will occur;
 the event and its nature;
 the consequences of that event; and
 the period of exposure to the event (and to its consequences if that is also relevant).

Risk, which is uncertainty that has been defined, is a simple concept. a way of thinking through
and planning a program or project. There are many treatments of risk in the literature, but most
tend to overdo the quantitative tools and understate the softer, more people-oriented issues in risk
management.

The demystification of project risk involves some new assumptions about project planning and
control.

First, risk has been narrowly treated in the context of projects and project tasks. but the sources
of risk are more appropriately addressed at the business and industry level first. The prevailing
notion about project risk management has been the assumption that knowledge of internal,
project-oriented planning and control issues was most important in forecasting and managing
risks and costs. This assumption has driven the subject of project risk management in directions
that focus on internal project tasks and risks. But business analysts increasingly find that
emerging external business issues often have a much greater impact on the future of their

22 | P a g e
organizations-and on project success than any internal issues. Thus the roots of project risk lie in
the forces acting on the company, and the customer, as a whole.
Second, and as a consequence of the first point, project risk cannot be separated from business
planning, project selection. Planning and control. It is integral to these processes. Risk is the core
planning challenge at the heart of business development and later, project management. The
separation of risk management process from the rest of the broader business and project
management paradigm is the wrong approach to the subject because it implies that somehow risk
is largely internal to a project and therefore controlled by the project team. Since project risk is
business risk, the whole business strategic planning, marketing, and risk analysis process is
directly relevant to project risk. Risk applied to a business framework produces SWOT
(strengths, weaknesses, opportunities, and threats) analysis and other outputs that support
identification of project risks. These risks include competition, unanticipated technology change,
market shifts, business finance, workforce issues, and changes in the customer base.

Third, risk management is largely a leadership and management challenge first, not
fundamentally a quantitative process as portrayed in texts on the subject. Organizational culture
drives the approach to risk. Risk is actually qualitative and intuitive and brings out the most
creative juices of project process. It is risk that generates the passion of business achievement; to
overcome risk is to overcome a competitive challenge and create opportunity. Overcoming risk
equals business success.

Risk definitions

Risk management is a successful risk management practice is one in which risks are
continuously identified and analyzed for relative importance. Risks are mitigated, tracked, and
controlled to effectively use program resources. Problems are prevented before they occur and
personnel consciously focus on what could affect product quality and schedules.
You can see that this definition is fairly broad and describes a process that goes through the
whole project life cycle. The definition addresses the way project team members think and act in
the planning and organizing process.

There are five principles underlying the definition of risk

1. Risk is any uncertainty in a project plan that you can potentially control, or at least track. This
means that there are many risks in any project. The trick is to identify the most critical risks-the
ones that could make or break your project-and control them. Overcoming a risk-that is being
able to complete a project or project task despite the risk-creates opportunity. The other side of
risk is opportunity-if a business is better, faster, and cheaper in producing its products and
addressing customer needs and reducing the risk in the process at the same time then the payoff
opportunity is market share and business growth.

2. Risk is integral to the business and the project planning process; therefore don't think of risk as
something different or separate from management. Risk is why you do business and plan
projects- if there were no risk, there wouldn't be a project. And addressing risk simply means that

23 | P a g e
you are always looking around you to find things that can go wrong in defining and scheduling
work.

3. Focus only on the high-risk, resource-consuming tasks because you can't focus on all of them
all the time. Assessing risk is a question of rank-ordering risks and keeping your eye on them.
While we will exercise some quantitative tools in this course, such as probability analysis, these
tools have very selective applications when you have a very complex project and you have
background data on technical probabilities.

4. Monitoring risk is a question of identifying key risk milestones or points in the project
schedule where risk decisions need to be made. These milestones would mark whether a piece of
equipment worked, or a key resource was available, or a key technology in a new product
worked as designed.

5. Planning a response to risk involves understanding the project and impacts of various
corrective actions midstream. You create risk scenarios and schedule impacts. An "expected"
scenario is the best guess at what actually will happen, a "pessimistic" scenario is the worst case,
and an optimistic scenario is the "best case."

Risk, Process, and the Myth of Control

There is a natural tendency to study risks as separate problems, to see risk as one shot points-in-
time when risks are systematically identified, assessed qualitatively and quantitatively using
sophisticated mathematical models, and controlled through conceived contingency plans. But
real-world experience teaches us that risk is, in truth, an inseparable aspect of the whole project
life cycle and its daily irrationality and interpersonal dynamic. In a way, risk events are a result
of bad planning. In that sense, risk can be seen as a continuous series of individual and collective
decisions in planning and managing a project. The process is not mystical and quantitative; it is
organic and intuitive. You head off some risks while creating others-you mitigate a technology
risk with information on impacts, and address the potential disease, but there may be risk in the
cure as well. Some risks occur despite mitigation, while others do not, despite being ignored.
Sometimes neglected risks never happen.

Many decisions add up to a successful management of risk. The tyranny of small decisions adds
up to success or failure. Thus risk is part of the planning cycle-planning is designed to reduce
risk, but in fact the role of planning is to see risk coming and to address it in the plan.

Risk and quality are as cost and benefit. Quality may be defined as the extent to which the road
taken (the process) conforms to the proven road already taken successfully. To know your
process and follow it consistently is to produce a quality product. This suggests that if you know
the correct process, you can produce quality at minimum risk and cost, simply because you know
how the process works.

But if the process and product are new, the cost of quality increases as you incur costs of waste,
redundancy, and inspection/appraisal. Risks unattended create costs because they imply

24 | P a g e
repetition, error, and delay. But these costs are not simply costs of delay and schedule; they are
costs of actions, contingencies.

For example, in the design and production of a complex, electronic, digitized avionics
instrument, there is an inherent risk at every step in the process:

1. Customer requirement. There might not be a "customer" per se, or if there is, the customer has
no idea what is needed. Thus customer requirement itself is a risk and that is why we spend time
trying to identify requirements. Requirements analysis is a risk reduction tool. Each time we
assume that we have the requirement down and choose not to test it out with the customer or
each time we do test it out but the customer falsely assures us that the specification is correct-we
add incrementally to the totality of the customer requirement risk. Checking with the customer is
not the simple solution, as the customer changes expectations; risks that they may be
unrealizable change, sometimes for the better. In other words, as the customer is educated on
risk, the customer is liable to make decisions, which lessen his or her risk and sometimes the risk
the project itself faces.

2. Concept. The concept might be flawed because ~t is not feasible. Innovation in project
concept leads to creative vision of what is possible, but it might not be possible or even desirable
in the eyes of the customer or the key stakeholder. Thus there is inherent risk in designing a
concept but there is also opportunity. The more options are presented to the customer in the
concept stage, the more the probability that one or another will delight the customer. at least in
principle. Thus innovation applied in the concept stage is a risk mitigation step in the sense that it
is in this stage where ideas and visions can be addressed without substantial cost.

3. Design. The design might not meet the requirements, or the design might be feasible in
production and assembly. Design, putting a concept into a drawing or rendering, involves a
myriad of steps that are inherently risky; from misstating tolerances to choosing unavailable
components, to designing correctly to an inaccurate requirement or specification.

4. Prototype. The development of the prototype may not be aligned with the requirements, so
testing the prototype does not assure success either in conformance to specifications or customer
satisfaction. In building a physical model of the product and testing it, there is inherent risk that
the prototype is not representative of the (unexpressed) expectations of the customer, or that the
prototype is not exactly like the product that is to be manufactured. Or the costs of the prototype
may not be accurate so that when the time to produce it arrives, the company cannot afford it at
the price used in justifying it.

5. Production. The product process might not be consistent with the time and resources needed
to put the product together and produce it in volume.

Risk/Benefit

25 | P a g e
It is important to see risk as a tradeoff with benefits, opportunities, and payoffs. In other words,
risk is the reason for investment-to seek out profitability by reducing uncertainty and gaining
benefits in terms of customer value and profitability. The following matrix (Fig. 1.2) illustrates
the tradeoffs involved in categorizing and selecting projects for a business portfolio.

Figure 1.1 Risk/benefit template

Activity
Dear learners which combination(s) among the afore-mentioned risk benefit matrix can
produce a superb project outcome? Explain.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_
26 | P a g e
Quadrant I: High risk, low benefit
Projects which fall into this quadrant are not worth doing simply because there is great
uncertainty about outcomes and little foreseeable payoff. Of course, companies typically support
a limited number of exploratory R&D projects, some of which can move from this quadrant to
the next when unexpected payoffs are uncovered.

Quadrant II: High risk, high benefit

Projects here are major investments with high risks of failure, but with outcomes that could
substantially improve market share, company growth, and profitability. A good example of such
a project would be an investment project in the field of space exploration.

Quadrant Ill: Low risk, low benefit

Projects in this quadrant are not worth doing simply because there is no foreseeable payoff, even
though the cost or risk involved is minimal. An example would he a superficial landscaping
improvement to a plant location when the permanence and viability of the plant itself is in
question.

Quadrant IV: Low risk, high benefit

Here the projects are very attractive because for minimal risk there is a potential high benefit. An
example would be installation of a proven technology in manufacturing that promises to double
productivity of a current plant or facility.

Risk as a social construct

The concept of risk is sociologically framed. We derive our understanding about risks, and our
attitudes towards them, largely from the society in which we live and work. A community that
knew nothing about money, as a means of payment for goods and services, would not appreciate
financial risk (but might instead have a comprehensive awareness of the risks of bartering goods
and services). A society that had no knowledge of the practice of human surgery could have no
understanding of surgical risk. Similarly, a religious sect with particular values and beliefs might
understand the risk of dying through an outbreak of food poisoning by ascribing it to the divine
disposition of some higher being or force. For most of the time, this notion of risk as a social
construct makes little difference to the way in which we treat it but, if you are working in a
cross-cultural environment, the way in which risk is understood in that environment cannot be
ignored

Another point is that we do not have to experience a risk personally in order to understand it.
Most adults are perfectly capable, for example, of imagining the cause and consequences of a
vehicle accident without having to first experience one. Our understanding may not be
quantitatively precise, but it is sufficient (or should be) to encourage us to drive more carefully.
Risks are therefore perceived and experienced by people, whose understanding of them is
influenced by the degree to which they accept the values and beliefs of the society in which they
live, and by their ability to assess the capacity of those risks to affect their lives.
This social view of risk is important for project management in two respects. It is people
(through the organisations in which they are involved) who experience risks, not projects. It is
27 | P a g e
people who must manage risks (or at least manage the people who will deal with the risks
operationally). Effective project risk management should therefore reflect this. We will return to
these two points in later chapters. First, however, we must cover a good deal of related
background knowledge, and this starts by considering the contexts of risk.

Risk contexts

Risk is contextual. It arises in the context of a situation that exists or is likely to occur at some
point in the future. The situations which most give rise to risks are those which involve us in
engaging in activities, carrying out tasks, making commitments or entering into obligations.
Thus, if we participate in so called 'extreme' sports, we face the possibility of being killed or
injured. If we offer to wash and dry the dishes after dinner in a friend's home, we may endanger
the relationship if precious crockery gets damaged in the process. If we commit ourselves to
marriage we face the possibility of subsequent divorce and, if we agree to stand bail for someone
charged with a criminal offence, there is a chance that we will have to forfeit a large sum of
money should he or she fail to appear in court to answer the charge.

Note that for each of these contexts, the risks arise out of decisions on our part to participate in
the activity, carry out the task, make the commitment, or enter into the obligation.

Mathematical concepts of risk

As with most applications of mathematics, virtually all of the mathematical exploration of

probability relies on the principle of experimental repeatability. Taking the mathematical
approach, risk situations can therefore be replicated over and over in a manner similar to physical
or chemical experimentation, and the findings analysed with statistical reliability.

While this approach may be possible in industries such as manufacturing, where mechanised and
computerised repetitive production- line processes are encountered, it is less frequently
applicable to projects. Projects tend to be unique, non-serial undertakings, and it is rare for
stakeholders to be able to base their decision-making on repeated prior experimentation.
Mathematical simulation (e.g. Monte Carlo simulation, where iterative random number
generation is used to represent probabilities in order to select unique variable values from a
predetermined range) techniques can be used to replace experiments, but if the validity of the
input data is weak, then the outputs of simulation models cannot be robust.

This is not to say that mathematical concepts of risk have no place in project management. It is
simply that the nature of projects tends, for the most part, to limit the occasions where they can
be properly and reliably exploited.

28 | P a g e
 1.6 Summary
This chapter in general endeavored to enhance your understanding of risk management and
uncertainty under the domain of project management. It is also clear that the term risk can be
seen from several quite distinct perspectives. It is also clear that uncertainty may prevail
throughout the project life cycle but it is quite prevalent at the pre-execution phase of the project
move. Hence, projects can produce satisfying rewards for those who successfully understood
them under the pursuit of uncertainty, risk and their management.

This chapter also preaches about possible variations in project outcomes that may stem from ill
understanding of the six Ws frame works under the project definition process. The definition of
risk also be framed under five basic principles.

The chapter also explained that risk is, in truth, an inseparable aspect of the whole project life
cycle and its daily irrationality and interpersonal dynamic. In a way, risk events are a result of
bad planning. In that sense, risk can be seen as a continuous series of individual and collective
decisions in planning and managing a project. The process is not mystical and quantitative; it is
organic and intuitive.

29 | P a g e
 CHAPTER 2
PREPARING THE ORGANIZATION: BUILDING A
RISK MANAGEMENT CULTURE

OBJECTIVE:
 To enable learners facilitate and build a risk management culture.
 To enable learners appreciate the various categories of risk.

Content:
Introduction

2.1 Risk: the organizational culture issue

2.2 Classifying Risk

2.3 Summary

Introduction
Dear learners, risk management goes in tandem with the fundamental organizational
activities. If risk management is not separated from the way activities are done, risk
planning ends up being a customary procedure. Therefore, here under you will be
acquainted with the mechanisms that will enable you build a superb project risk
management culture..

Hence at the end of this unit, you are expected to:

 Identify and link the various activities of a company with the appropriate risk
management program.
 Understand the mechanism via which risk management culture can be built.
 Develop the required competencies need for the sake of classifying risks..

30 | P a g e
Building a culture of risk management is primarily a process of developing people in your
organization who think and plan projects effectively, and who are supported by company
systems that encourage them to think and plan effectively. That involves looking constantly at
what could go wrong and knowing the difference between theoretical risk and practical risk.
Theoretical risk is risk that could happen; practical risk is risk that is likely to happen. Experience
helps to differentiate the two.

Activity
Dear learners how do you think risky scenarios can be addressed? Why do you think
organizations project risk management endeavors often ruined?

____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

Prepare the Organization

If the organization does not address risk in the way work is done, risk management will fail.
Defining culture as the way work is done in the organization, if risk is integrated in the way work
is done (e.g., project plans incorporate a risk matrix as defined later in this book) risk planning
becomes an expected part of planning. If risk is given lip service but not backed up, then risk
management will be superficial and ineffective (Fig. 1.1).

31 | P a g e
Figure 2.1 The process of preparing the organization

2.1 RISK: THE ORGANIZATINAL CULTURE ISSUE

While risk is traditionally seen as an analytic activity (identifying and assessing risks in the
project task structure, and applying decision trees, sensitivity analysis, and fine-tuned
probabilities) the essence of risk management is the way your organization treats risk and the
way you and your team think about the project. The challenge for the organization is teaching
and training project leaders and team members to think in terms of risk and to internalize the risk
management process into their daily work. They are the front line of risk management. The
assumption behind this approach is that risk management is "something I want my people to do
in the normal course of their work," not something I want a specialist to do later in the project as
a separate audit exercise. Risk is a way of visualizing the project and its successful outcomes and
seeing potential pitfalls. You can't see risks if you are not looking for them.

So the successful management of risk is usually the product of a successful organization that has
instilled into its people the importance of careful planning. Careful planning involves a core
competence-the capacity to dimension uncertainty and risk, to integrate risk identification and
assessment into program and project planning, and to build and sustain a support system for risk
management that provides essential information when it is needed. But how does an organization
build risk into its daily work, and how do executives use their leadership and institutional
leverage to further good risk management?

A Culture of Risk Management Competence

The successful risk management organization has five basic competencies:

 Active training and development in risk planning and management
 Strong linkage between corporate planning and project planning, particularly between
business analysis of threats and opportunities, and analysis of project risk
 Deep project experience in its industry
 Capacity to document project experience and "learn" as an organization
 A workforce of strong functional managers who address product quality as a risk
reduction issue.

Link Corporate and Project Planning

Strong ties between corporate strategic planning, including market analysis, and project planning
ensure that the business "sees" its technological risks early in its business planning and is able to
anticipate and dimension the risks it will face in designing and implementing projects that carry
out its strategies. For instance, a telecommunications firm that performs SWOT (strengths,
weaknesses, opportunities, threats) analysis in its field may uncover a potential threat in
unanticipated breakthroughs in telecommunications cable technology. Addressing contingencies
at the corporate level to address these potential breakthroughs (opportunities created from
32 | P a g e
analysis of threats) helps the business support its selected projects that involve such new cable
systems.

Training and Development in Risk

Training and development programs that address risk identification, assessment, and response
can help build professional competence in handling risk issues in real projects. Such training
would include a curriculum in:
 Building a WBS (work breakdown structure)
 Identifying risks in the WBS
 Producing a risk matrix

Project Experience

A company that "sticks-to-the-knitting," is in a better position to recognize and offset risk simply
because its workforce is likely to have a better handle on the technology and process risks
inherent in its core business. Whenever a business departs fundamentally from its core
competency areas, it stands to experience unanticipated problems, which develop into high-
impact and high-severity risks.

Learning Organization

A learning organization is an organization that does not reinvent the wheel each time it plans and
implements a project. This means that lessons learned from real project experiences are
incorporated in documentation and embedded in training programs so that project managers learn
from part experiences. Communication is open in such organizations, leading to a process by
which project experiences are "handed" down to next generation project teams.

Strong Functional Managers Address Quality

The existence of strong functional management ensures that the basic functional competency of
the company in areas such as engineering or system development is backed up by technology
leaders in the field. Key processes like product development are documented and product
components controlled through with disciplined configuration systems. This means that the risks
of product quality failures that result from product component variation are minimized in
methodologies such as six sigma simply because the company can replicate products and
prototypes repeatedly for manufacturing and production without variation.

Building the Culture

Organization culture can be defined as the "prevailing standard for what is acceptable in work
systems, work performance, and work setting." A risk management culture can be defined as the
"prevailing standard for how risk is handled." An organization with a strong risk management
33 | P a g e
culture has policies and procedures that require its workforce to go through disciplined risk
planning, identification, assessment, and risk response project phasing.

A mature organization does not treat risk management as a separate process, but rather "embeds"
the risk process into the whole project planning and control process. Risk is an integral part of
the thinking of its key people. In the same way that the quality movement matures to the point
that quality assurance and statistical process control processes become institutionalized into the
company rubric, risk assessment tools and response mechanisms become an indistinguishable
part of a company mosaic in a mature organization.

Sustaining the culture of risk management is considered a major function of corporate leadership
in the risk-planning phase. Although most organizations do not enter the risk-planning phase as a
distinct step in the project planning process, best practice addresses potentially high-risk tasks,
assigns probability implicitly to the process, and develops optional contingencies that may or
may not be documented in a formal risk matrix. This is typically not a mysterious, mathematical
process, but rather an open, communicative process in which key project stakeholders, team
members, and the customer talk about uncertainty and identify key "go or no go" decision points.
They often know where the key risks are in the project process because the project itself is
grounded in addressing a risk that the customer is facing.

Performance Incentives

Any organization building a risk-based culture must provide incentives for integrating risk into
the project planning and control process. The incentive for handling risk is top management
support and resources. Top management support comes when project management identifies and
anticipates business risks that save the company time and money. Project managers who manage
risks effectively are likely to be more successful in acquiring additional resources because they
tend to have backup and contingency plans ready when risks occur.

Taking Risks: The Risk of "Blinders"

One of the major risks in any project is the tendency of its key project decision makers,
especially the project manager, to overestimate what they know and underestimate what they
don't know. The risk is that key people will "take risks" but not manage risk. This means that the
beginning of good risk management is the capacity to know what the organization and its people
can do and what they cannot do.

The field of organizational behavior contributes a tool called the Johari Window that is helpful in
analyzing personal tendencies of project managers to take risks rather than manage them.
The Johari Window, named after the first names of its inventors, Joseph Luft and Harry Ingham,
is one of the most useful models describing the process of human interaction and behavior. A
four-paned "window," as illustrated below, divides personal awareness into four different types,
as represented by its four quadrants-open, hidden, blind, and unknown. The lines dividing the
four panes are like window shades, which can move as an interaction progresses.

34 | P a g e
A typical project manager might go through the following thinking process personally to test
what he or she knows:

1. The "open" quadrant represents both things that I know about myself and that others know
about me. For example, I know my name and so do you, and you know some of my interests.
The knowledge that the window represents can include not only factual information, but my
feelings, motives, behaviors, wants, needs, and desires. Indeed, any information describing who I
am.

The risk here is that what is open to some coworkers may not be open to the customer or a
project sponsor. So it is important that a project manager get to know the customer and key
sponsors or stakeholders as people. The focus is customer expectations; if there is an open
process on expectations then the chances of managing risk are high.

Figure 2.2 The Johari Window

2. The "blind" quadrant represents things that you know about me but I am unaware of. So, for
example, we could be eating at a restaurant, and I may have unknowingly gotten some food on
my face. This information is in my blind quadrant because you can see it, but I cannot. If you
now tell me that I have something on my face, then the window shade moves to the right,
enlarging the open quadrant's area.

35 | P a g e
The risk factor here is that there may be variables that a competitor or customer knows about the
organization that the project manager may not know. For instance, a current supplier to the
project may have failed in delivery of a similar component to a competitor, but the project
manager is unaware of the situation.

3. The "hidden" quadrant represents things that I know about myself and you do not know. So
for example, I have neither told you nor mentioned anywhere on my website, what one of my
favorite ice cream flavors is. This information is in my "hidden" quadrant.

The risk here is that a project team member may not be entirely open in divulging important
information about their expertise and experience.

4. The "unknown" quadrant represents things that neither I know about myself, nor you know
about me. For example, I may disclose a dream that I had, and as we both attempt to understand
its significance, a new awareness may emerge, known to neither of us before the conversation
took place.

The risk here is that there are factors at work that are unanticipated both by the project manager
and the customer.

Personal, Project, and Organizational Risk

There is something very personal about the issue of risk. In many companies, taking risks is
rewarded in principle, but failure in taking risks has its implications despite the company
rhetoric. What the company is really saying is, "Go ahead and take risks, but take them only if
you think you can succeed and produce value for the customer and the company. We will
support you with data and information. Don't take risks frivolously.''

For the business and project professional, risk is first a personal issue because project risk is
directly associated with personal risk. If a project manager fails to see and control risk, that
project manager faces the prospect of being associated with a failed project. So the way a project
team faces risk has implications for each team member personally-and for the team dynamics
involved in a given project.

The way the company protects its employees and officers from risk is key as well. If the
company is positioned to absorb the cost of failure then the program or project manager is more
likely to take the risk. Thus the propensity to accept risk and manage it successfully is partly a
function of organizational support if my company supports me, I will address risk and make the
best decisions I can, but I will want to let my top management know the risks as I see them so
that if the risk is not successfully controlled, it will have been a company-wide decision, not a
personal one.

In sum, the model is this-the organization must position itself for risk and must empower and
enable its business and project people to address and take risks, but there must be an open,
organization-wide process for addressing and absorbing risk. If these conditions don't exist, the

36 | P a g e
project manager is not "incentivized" to address risk and will avoid risk, often at the expense of
opportunity.

2.2CLASSIFYING RISK

Activity
Dear learners try to list the several benefits that can be aspired from the task of
classifying risks. How are you going to classify the various risks that a given project
manager may encounter?

______________________________________________________________________
______________________________________________________________________

Why should we try to classify risk? After all, if risk is a social construct, as we have argued, then
each community or individual person will have distinctively different views about what actually
constitutes a risk. Similarly, if the uncertainty associated with a risk is often subjectively
assessed, and we know that risks must be treated individually, why bother to classify them when
we could save time and effort by starting directly with the more 'hands on' activities of risk
management?

Classifying risks enables us to consider them within a more coherent framework. Creating an
acceptable taxonomy establishes a common basis for risk and risk management researchers to
proceed with their investigations and communicate their findings. It provides us with a more
uniform risk language, particularly in fields such as project management, where we might need
to communicate risk information to a wide variety of project stakeholders. It allows us, therefore,
to establish a common understanding of different risks, and provides an essential basis for
effective knowledge transfer, within an organisation and from one project to another.

Classifying risks also provides the opportunity to explore whether a particular class or type of
risk is amenable to a particular type of treatment. To date, little uniformity exists in the
classification of risk, even within recognised discipline areas. Different approaches are found to
classifying what are often the same types of risks.

Three 'conventional' types of risk are: natural hazards; technological hazards; and social hazards.
Two further types are noted: health hazards and financial risk; together with the caveat that
distinctions between all types of risk cannot be absolute because of cultural differences which
may cause one group to perceive a hazard as natural which another group might regard as social
or technological.

37 | P a g e
Under these risk categories, natural hazards are defined as those occurring outside human
systems or agencies. Examples would include earthquakes and hurricanes. Hazards of
technology occur within human-designed systems, and would include events such as collisions
between ships or vehicles, explosions, fires attributable to electrical equipment failure, and
failure of structures. Social hazards arise from human behaviours such as arson and sabotage.
Health risks relate to epidemia and surgery.

Life-cycle application phases are suggested in as another approach to categorising risk. The
phases are identified as: concept and definition phase; design development phase; construction,
production, transportation, operational and maintenance phase; and the disposal phase. Little
obvious advantage accrues from this as a primary categorization approach, although for specific
projects it might serve to provide a clearer focus for the time component of risk.

Yet another approach seeks to separate external and internal risks.

This too is more suited to specific contexts, since a risk might be classed as external in one
situation, but as internal for another.

The obvious problem in classifying risk, apart from the cultural perception difficulties is that
there is a danger of confusing sources, causes, effects, time phases and fields of study for the risk
domains. The confusion may also arise from consideration of individual risk circumstances. For
example, the impact of a hurricane may be aggravated in a region where overgrazing by cattle or
deforestation through deliberate land clearance has taken place (both humanly engineered
situations), but essentially it is the hurricane which gives rise to the risk, so it is still a natural one
in terms of its source. Similarly, while adverse soil conditions are a perennial risk for
construction projects, this risk is also a natural, albeit latent, one. The potential for risk is simply
activated by the decision to build on a particular site and the subsequent commencement of
excavations. Yet again, the damaging effects of a soil wash-away may be increased by the
removal of natural water-courses during the execution of bulk earthworks excavations, but the
source of the risk is still the storm which precipitated the wash-away. These examples suggest
that it is one or more of the elements of risk - probability, consequence and time - which may be
affected by changing circumstances, not the type of risk itself.

While the source/impact dilemma remains a philosophical problem for risk classification, the
source system of the adverse event may be the best primary denominator. In this case, two
primary categories should suffice: natural systems and human systems, since all technological
(system) and social risks must stem from some form of human activity. From this starting point,
sub-categories can be developed for different risk domains.

The subcategories of natural risks are weather systems, geological systems, biological systems,
physiological systems, ecological systems and extraterrestrial systems. The sub-categories of
human risks comprise social, political, cultural, health, legal, economic, financial, technical and
managerial systems.

Natural risks

38 | P a g e
As noted earlier, natural risks arise from systems whose existence is beyond human agency.
These may be found on or beyond the planet Earth. Weather systems, for example, are
responsible for risks posed by hurricanes, typhoons, tornadoes, floods, and lightning strikes.
Geological systems give rise to risks of earthquakes, tsunami, volcanic eruption, and geological
faults. A meteorite shower is an example of an extraterrestrial natural risk. However, a potential
collision between man-made space debris and Earth, caused by a satellite falling from its orbit,
would be regarded as a human risk, in the technical category and not as an extraterrestrial system
risk.

Risks arising out of the natural state of the biological diversity of species on planet Earth are also
natural systems risks, but it should be noted that where effects on these systems are triggered by
human action or intervention, then they are sourced as human systems risks.

Human risks

Risks arising out of human agency are more difficult to categorise than natural risks, due largely
to the overlapping and interrelational characteristics of many humanly devised systems.
Nevertheless, it is possible to indicate examples of human systems risks.

Behaviour which is unacceptable to society generally may be categorized as social risk. This
category might include criminal acts such as theft, robbery, assault and murder, sabotage, arson
and espionage; civil torts including trespass, slander and libel; or substance abuse such as
drunkenness and other drug-induced behaviour. But it is important to remember that it is the
values set by a society that determines which behaviours are anti-social. These values are
culturally determined, and may change substantially over time for a particular society, or differ
between societies.

Risks arising out of government action (or inaction) can be classified as political risks. Among
these, war and abrogation of international treaties are straightforward examples. Political risks
may also arise from opposition to government threat or action; as in cases of civil disorder or
industrial action. The actions of lobby and protest groups fall into this category. In most
instances, the risk falls upon the target of the politicians or protesters. However, innocent third
parties can be caught up in the crossfire. A company leasing office space in the same building as
a foreign consulate, for example, might find its business activities adversely affected by the
actions of groups wanting to demonstrate against events occurring in that consulate's home
nation. Similarly, the picket lines of striking workers rarely discriminate between the purposes
and motives of people wishing or needing to cross them.

Cultural risks emanate from the threat of potentially negative interactions between groups of
people espousing different cultural or religious values. At a government level, of course, such
risks are treated politically, but this does not deny their cultural source.

39 | P a g e
Risks arising through the process of surgery or from an outbreak of epidemia may be categorised
as health risks.

In the legal category of risk would be found risks arising from requirements to observe clauses
relating to private contracts and agreements; as well as other legally enforceable instruments
such as statutes, regulations and codes. It should be noted that, at the pre-enactment stage of
public instruments, such risks would have to be regarded as politically sourced.

It is not always easy to make a clear distinction between economic and financial risk categories
and, for much of project risk management, to do so may be unnecessary. One approach may be
to distinguish between physical factors of production and factors affecting the cost of project
finance or security of project cash flows. Thus, examples of economic risk might include labour
or material supply issues; while changes in interest rates or credit ratings, or the potential
unavailability of project loan finance, would be regarded as financial risks. It should be noted
that the failure to achieve desired income streams, in an investment-related project, is not a
financial risk but rather the consequence of other risk events.
The technical category of risk involves situations where failure of some humanly designed
technical system might occur. Examples range from equipment and system breakdown or
inadequacy, to collisions and accidents. While it is easy to understand the former, which are the
technical risks of design failure, the inclusion of the latter two in this category may be more
difficult to accept. Given that there is no deliberate human intent or presence of substance abuse
(which would place them as the consequences of risk events in the social risk category), then
collisions and accidents can more properly be seen as a failure (or absence) of technical systems
intended to prevent them. This could also be viewed as the consequences of design failure.

Managerial risks relate to the likelihood of adverse events attributable to some failure of
management. Project examples include poor productivity or excessive wastage by workers;
inadequate project quality, and human resource problems such as inappropriate or inadequate
staffing. Occupational health and safety risks may also be included under this category, but care
may be needed to exclude risks that should more properly be sourced as social or cultural.

In the main, allocating risks to a particular category source is best done from the point of view of
the organisation on whose behalf the risk management activity is being undertaken. This brings
the locus for risk management more directly into focus. In the interest rate example above,
treating the possible occurrence of high interest rates as a financial risk for the organisation
allows a more focused approach to alternative response strategies than would the more abstract
category of economic inflation. However, the niceties of fine-tuning risk categories should not be
allowed to occur at the expense of the benefit- to-cost ratio of the risk management process
itself!

40 | P a g e
 2.3 Summary
Dear learners building a risk management culture plays a predominant role in our project risk
management decision errands. This can be achieved through the consideration of risk
management as a subset under the fundamental organizational activities to be done. In addition
classification of risk plays a pivotal role in our project risk management endeavors.

41 | P a g e
 CHAPTER 3

LOOKING AT PROJECTS
OBJECTIVE:
 To enable learners understand projects and their nature.
 To enable learners understand the complexity behind project works.
 To help learners understand project environments and risky project works.

Content:
3.1 Introduction

3.2 The nature of projects

3.3 Project complexity

3.4 Mapping project risks

3.5 Risky projects

Summary

Dear learners, here under you are going to be familiarized with the nature behind projects
and the associated project complexities. Hence at the end of this unit, you are expected to:

 Understand the diversified nature of projects.

 Understand the complexity behind project works.
 Be aware of features behind risky projects.

42 | P a g e
3.1 INTRODUCTION
This chapter explores projects, their nature and complexity, and what makes them susceptible to
risk. It will be argued that the nature of projects is determined by their environments and their
constituent elements of tasks, technologies, resources and organisation. The environments of
projects are determined by their phases of development. Each element of a project is capable of
further subdivision into sub-elements, and the extent of uncertainty that these exhibit contributes
towards project complexity. Complexity, however, is only one aspect to consider. Other factors
which make projects 'risky' are discussed and illustrated through examples and case studies.

3.2 THE NATURE OF PROJECTS

A project is a deliberate undertaking. It is an endeavor that comprises the planned and organized
achievement of predetermined objectives, usually within a given timeframe. Earlier we noted
that it is the pre-planned starting points and finishing points for projects that distinguish them
from other undertakings, such as manufacturing or the ongoing provision of services, although
the initial establishment of these, or subsequent decisions to upgrade or dispose of them, may be
executed as projects.
Projects incorporate three essential elements: tasks, technologies and resources, which are
brought together through a fourth element - organisation. Tasks are the project activities (what
needs to be done). Technologies are the technical processes involved (how it is to be done).
Resources are the means for carrying out the tasks, applying the technologies and staffing the
endeavour. Organisation is the element that integrates and controls the other three. It determines
who will be involved, when, and where. Decisions are made within and about each of these
elements, and every decision will be susceptible to risk to a greater or lesser extent.

For projects, therefore, the context of risk and risk management lies in project decision-making.
Initially, decision-making takes place within the environment of project procurement - the
combination of activities, methods, resources and organisation necessary to bring a project to the
point where it is ready to function as intended. Beyond the stage of the procurement
environment, however, decision-making - and hence risk and risk management - may also be
involved in the post-procurement environment of a project, during its operation, and beyond that
to its eventual abandonment or disposal.

Projects involving all three environments are not uncommon, and each may be as important as
the others. In a medium to long-term situation, an open-cast mine is a good example of a project
where the disposal environment (and, more significantly, its pre-planning in the procurement
phase) may be as rigorous and demanding as the project's procurement and operational
environments. The mining lease may have been granted on strict conditions of land remediation
at the end of the period and the closure of the mine. All three environments may have been
appraised, designed, planned and regulated long before the blade of an excavator first rips into
the soil of the site or the ore flows along the conveyor belt. At the other extreme, events projects,
such as conferences, expositions, exhibitions, parades and sporting competitions, inevitably
demand consideration of all three environments on a extremely short term basis. A life-cycle
43 | P a g e
approach to considering projects will expose the impacts that decisions made in the procurement
environment may have upon the operational and disposal environments. Designing for energy
efficiency, and for eventual disassembly are clear examples of this. The procurement
environment is given prominence here, and throughout this book, simply because it is the
commencing, and often the most critical, phase for all projects.

Risk is associated with all decisions made in any project environment to achieve the desired
goal: in the organisation required for planning, selecting and implementing technologies and
obtaining resources; or for committing to these. Many of these decisions affect other
stakeholders (participants or actors) involved in the project.

Given this view of the nature of projects, is it reasonable to ask whether there is such as thing as
a simple project?

3.3 PROJECT COMPLEXITY

Activity
Dear learners here under you are expected to identify the myriad of factors that determine
the complexity of a project. Which among your mentioned factors play a pivotal role in
project complexity?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

Exploring the contextual nature of projects gives us some idea about how intricate even the
simplest of projects can be. Yet we frequently hear of, read about, or even work on, projects that
are regarded as 'complex'. What do we actually mean by this? What makes some projects more
complex than others, and what are the implications for project risk and risk management?

For this discussion, we are indebted to the work of Baccarini (1996) and Williams (1999), whose
valuable contributions have extended the understanding of project complexity. Beyond this
narrower project view exists the much larger field of systems complexity, which continues to
attract the interest of systems theorists worldwide. That field lies beyond the intended scope of
this book, but it is recommended for further study to readers who are interested in this topic,
since systems theory is an important contributor to project management.

The complexity of a project is influenced by the level of uncertainty associated with two factors
relating to its constituent elements and sub-elements, in any or all of its procurement, operational
or disposal environments. As we have seen, any of the three environments of a project will

44 | P a g e
comprise elements of tasks, technologies and resources brought together through organisation. In
turn, each of these elements will usually involve a larger number of sub-elements.
There will be task sub-elements, technology sub-elements, resource sub-elements and
organisation sub-elements. The level of intricacy in all this is affected by conditions relating to
differentiation and interdependency. It is these factors that contribute to project complexity, and
both are aggravated by uncertainty. Since we have already noted the association of uncertainty
and risk, our interest in project complexity is understandable.

Differentiation

The condition of differentiation in a project is the degree to which its constituent elements and
sub-elements should be treated as individually identifiable or, to put it more crudely, the number
of distinctive parts of the project that we should recognise as such.

Note that this is not necessarily the same as the number we could count. In a riveted steel bridge
project, for example, it might not be necessary to count every rivet. On the other hand, it may be
important to distinguish between different types of rivet or between similar rivets fixed in
different situations.

Remember, too, that we will not only have to differentiate between resource sub-elements (such
as the supply of rivets, girders, braces and plate connectors needed for the bridge), but also
between the various task, technological and organisational requirements for the project. So we
may wish to distinguish between the activities of particular trades people; or between welding,
riveting or bolting technologies; or between local and imported resources, or between the ratios
of management, supervisory and line staff in stakeholder organisations. These are just a few of
the many distinctions that might be necessary to make the project 'work' in the sense of being
able to bring it to effective completion.

High levels of differentiation tend to complicate project planning and execution by the sheer
number of different things which must be dealt with, and thus contribute to project complexity.
For example, assume two similar types of projects, A and B, have the following characteristics as
shown in table 3.1. Ignoring the project location factor for the moment and purely on the basis of
comparing the number of constituent elements (tasks, technologies, resources and organisations)
involved; then Project B is prima facie more complex than Project A.

Table 3.1 Differentiation complexity in projects

Project constituent/element Project A Project B

Project location 1 5
Tasks 5 2000
Technologies 3 30
Resources 4 400
Organisations 2 15

45 | P a g e
Comparisons are not always as straightforward as this, however, since the intra-constituent
characteristics of the two projects might not be sufficiently similar. Thus, although Project B
requires the use of 30 technologies, and Project A needs only three, if those three are less well
developed, more prone to failure, susceptible to higher variance in their outcomes, or require
scarcer and more highly specialized operatives than the 30 well-understood, well-tested, well
practiced and widely available technologies of Project B; then from a technological point of view
Project A might be considered more complex (and certainly more risky) than Project B.

Spatial differentiation occurs in projects where elements or sub-elements have to be prepared in

(or sourced from) several places, and then brought to one location for incorporation into the
project. Or it may be that a sub-element is fabricated in one place, but has to be installed in
many. Banking and other IT projects are a good example of this, where the centrally produced
software package may have to be distributed and installed in perhaps hundreds of branch
locations.
It may be possible to carry out the installation loading for all branches remotely from a central
place, but the project objectives will almost certainly require that the package be tested in situ so
that it functions properly in each location. In terms of spatial differentiation, or indeed for
temporal differentiation (i.e. project elements and sub-elements separated by time), this means
that dispersion can also contribute to project complexity.

All this suggests that comparing differentiation complexity, even in similar types of projects (and
the contrast between A and B in the example is exaggerated for clarity), is not easy. Comparison
of differentiation complexity between different types of projects (e.g. the levels of differentiation
occurring in an IT banking project compared with those in an infra structural civil engineering
project) is far more difficult, best avoided, and probably unnecessary. It can be done, but first ask
why it should be done!
Interdependency

The interdependency between the differentiated parts of a project contributes significantly to its
complexity and cannot be ignored. By interdependency we mean the nature and extent of any
dependent relationships that may exist between the parts. If one part cannot be completed
without another, or if one part cannot function without another, or one technology cannot be
applied without another, or one resource is unobtainable without another, then interdependency
exists. Such dependency can arise within the task, technology, resource and organization
elements and sub-elements of projects, and also between them.

It is generally held that the relationships within an organizational structure can take one of three
forms of dependency: pooled, sequential, or reciprocal. The same relational argument is
applicable to the task, technology, and resource elements of projects, but higher levels of
interdependency complexity are found most often in the task elements. The impact of
interdependency complexity is most profoundly felt in the time planning (scheduling,
programming) aspects of project organisation.

POOLED INTERDEPENDENCY

46 | P a g e
If the differentiated parts required in a project element or sub-element can be dealt with one after
the other, but not in any strict order, and each without interference from others, until the project
is complete or a distinct point of integration is reached, then a minimum dependency relationship
exists. In such a case, for example, completion times for each sub-element are simply pooled (i.e.
added together) to arrive at a total time required for the whole element.

SEQUENTIAL INTERDEPENDENCY
In sequential interdependency, the conditional relationship between constituent project parts is
the influencing factor. One sub-element must follow or precede another (or be undertaken at the
same time) as part of an essential and deliberately planned sequence. This aspect of complexity
is reflected most clearly in the critical path approach to project scheduling, where it is important
to identify discrete tasks that must be completed before a following task can be commenced, as
well as tasks that can (or must) be carried out in parallel. The time required for a project is
represented by the length of the critical path, and not by the pooled sum of the time needed for
each element and sub-element within it. In sequential dependency, however, a change in one part
does not necessarily require a change in its dependent partners, as long as the sequence remains
unaffected.

RECIPROCAL INTERDEPENDENCY
Reciprocal interdependency occurs when a change to, or turbulence occurring in, one element or
sub-element of a project has a flow-on effect and necessitates change to, or induces turbulence
in, one or more of the other elements or sub-elements. On a construction project, for example,
changing the ceiling design might mean changing the type of light fittings to be fitted in the
ceilings. Similarly, the discovery of a fault in a piece of program code for an IT software project
might require the replacement of code in other sections.

Uncertainty and risk

How do all this complexity of differentiation and interdependency of tasks, technologies,

resources and organisation relate to project risks and risk management? It lies in the level of
uncertainty connected with project decision-making.

By definition, uncertainty is some state that is short of certainty. Something is not fully known;
information is incomplete. In projects, many decisions are made on the basis of forecasts of
outcomes or events occurring at some time in the future. The future cannot be known with
certainty. Therefore each forecast is vulnerable to some degree of uncertainty in terms of the
input factors to the model used to produce it (or to uncertainty in the performance of the model
itself). Depending upon the nature of the forecast, this uncertainty may relate to the likelihood of
each event occurring, its timing, or the magnitude of any consequences.

Since these are the essential components of risk, then project risks arise out of the uncertainty
associated with the decision-making relating to the task, technology, resource and organisational
requirements of projects.

47 | P a g e
As we know, most projects are subject to at least some degree of uncertainty, but uncertainty
states are rarely static. The level of uncertainty in a project changes, both in nature and degree, as
time passes and project elements and sub-elements are completed or changed to suit new
circumstances. The relationship between project complexity and uncertainty is therefore
dynamic. There is an obvious paradox in all of this. One approach to dealing with large complex
projects is to split them up into smaller, more manageable parts. Doing this, of course, not only
increases the overall level of differentiation complexity, but it may also create new or different
interdependencies and add to uncertainty.

3.4 MAPPING PROJECT RISKS

The difficulty of comparing complexity in projects has already been mentioned. In many
instances, it may be neither practical nor desirable to make such comparisons on an absolute,
quantitative basis. The relative complexity of projects then becomes a matter of subjective
assessment, and susceptible to all the errors and biases of human judgment. Given these
limitations, however, it is possible to devise techniques to compare risks on an inter-project
basis.

Assuming that we have, as part of an organisational risk management system, completed a

process of identifying the risks for a particular project, then it should be possible to map these
risks against the specific elements and sub-elements of the project, and against agreed risk
classifications.

The benefit of mapping risks in this way is that it is then possible to see more clearly how risks
(and the way in which particular types of risks) are distributed throughout the project. A valuable
picture of the 'riskiness' of the project is obtained, which can be compared with the risk maps for
alternative projects or completed projects. To some extent, this overcomes the impracticality of
making quantitative comparisons of complexity.

3.5 RISKY PROJECTS

Apart from some measures of financial risk, the 'riskiness' of projects -like the complexity of
projects - is relative rather than absolute. We cannot easily say that Project A is 6 units risky on a
scale of 10, and that project B scores 4, therefore A is 50 per cent more risky than B; we can only
infer that Project A appears to be a lot more risky than Project B. Our judgment will be based
upon factors that we may know can contribute towards risk in that particular type of project. Our
knowledge may come from experience, training, reading, or from the analytic information that
project risk maps can provide. Even where risk severity has been assessed in terms of the scoring
approach suggested above, the results are likely to be too imprecise to permit absolute
distinctions to be drawn.

Activity
Dear learners identify the conditions that may expose a project to be treated as risky?

48___________________________________________________________________________
|Page
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
_
For financial risk, mathematical measures such as yield (internal rate of return), net present value
and payback period can be modeled and compared across similar types of income-producing
projects or even against completely different types of alternative investment opportunities.

Other types of risks are less susceptible to such straightforward mathematical assessment. Even
the outcomes of financial risk calculations are rarely known with any reliable degree of certainty,
since they are the outputs of models which depend upon predicted values for much of the
performance input data. Some data may have to be transformed into financial terms. For a
commercial property investment project such as a suburban shopping centre, for example,
variability may exist in any or all of model input factor data including: land price (if not already
owned); construction cost; design efficiency; rentals obtainable (over the whole investment
period); vacancy rates; marketing costs; legal costs; insurance premiums; frequency and costs of
maintenance, repairs and replacements; timing and cost of refurbishment; local authority rates
and taxes; and many more. Thus, there will always be limits to the precision by which the
financial risks of alternative investment projects can be analysed and compared.
Earlier we also noted that there may be limitations in the accuracy and reliability of the models
themselves.

What then, are the conditions which are likely to make a project be regarded as risky? Cooper
and Chapman (1987) and Smith (1999) have proposed factors relating to the riskiness of
construction projects, but most of these factors are applicable to projects generally. According to
these authors, a risky project might be one in which any of a number of conditions exist. The
following list is summarized from the work of these authors, and is not presented in any
particular order of importance:

1. Large capital outlays are involved.

2. Unbalanced cash flows are likely to occur.
3. There are substantial requirements for new technology (technology which is new to the
user).
4. Novel or unusual procurement arrangements are contemplated.
5. Novel operational requirements are intended by the client.
6. The project is extremely large.
7. The project is highly complex.
8. Severe time constraints exist.
9. Some or all of the stakeholders are inexperienced.
10. The client's business is highly sensitive to the performance and/or quality of the project.
11. Stringent, inconsistent, or changing regulatory requirements are encountered.
12. Environmental or ecological sensitivity is encountered in the procurement, operational
or disposal environments of the project.
13. Political and/or cultural sensitivities are significant.
14. Situational turbulence is encountered (e.g. projects in developing or politically unstable
countries).

49 | P a g e
Not mentioned in this list of factors, but just as important, would be the effectiveness of the
stakeholders' risk management. If the risk management is ineffective, or non-existent, then the
potentially adverse impacts of many risks will be exacerbated. Because little or no risk
mitigation is undertaken, the likelihood of occurrence for some risks, their consequence, or the
period of exposure, may also increase.

As noted earlier, few of these characteristics are susceptible to precise measurement, and their
effect on project riskiness is therefore seldom known with any accuracy.

Large capital outlays

Large capital outlays generally affect the risk level of projects through the need to acquire funds
beyond a stakeholder's ability to finance a project from equity. Very large engineering projects,
such as dams, power stations, tunnels, major freeways, etc., may have budgets amounting to
hundreds of millions - or even billions - of dollars.
Their financing may create turbulence in capital markets, and loan security may be of a non-
recourse nature, i.e. based solely on forecast future income streams from toll revenues or output
purchasing agreements.
The sheer financial size of these projects means that they may lie beyond the 'swings and
roundabouts' dampening effect that most financial markets rely on for stability over time. Their
size also means that the financial markets for such projects might be quite restricted, and a
particular market might refuse a loan for a particular project simply because the lenders are
already engorged with loans on other, more attractive projects. This would force the borrowing
project developer to seek finance in alterative, unfamiliar markets, thus raising the level of risk.

Unbalanced cash flows

Long-term projects which include an income-producing operational environment tend to rely on
the regularity of the operational positive revenue streams to counter the large irregular negative
cash flows normally required in the procurement phase to bring the project to operational
readiness. If the operational revenue or expense streams are likely to be very irregular, or the
project requires a massive cash outflows in its final disposal environment (such as the open-cast
mine example mentioned earlier in this chapter), then it may be extremely difficult to model its
financial performance with reliable accuracy.

Highly unbalanced cash flows can actually affect the performance of computerised discounted
cash-flow models used in financial appraisals to calculate an internal rate of return or yield for a
project. Further, the appearance of project instability which such cash flows portray contributes
to a perception of project riskiness which may not be fully deserved. In many markets it is the
perception of performance that counts.
New technology requirements
New technology always carries a higher risk of failure than technology that has been tried and
tested. It is not even necessary for the technology to be new per se. Existing technology, but
which is new to the project user, can have a similar risk effect. In this case however, there should
be less risk of technical failure, as any faults or weaknesses should have been eradicated by
previous users.

50 | P a g e
Novel procurement methods
In regards to novel procurement methods, procurement is understood as the contractual
arrangements defining the rights and obligations of the parties directly involved in a project, and
the relationships between them. These arrangements may take alternative forms, but the
differences usually relate to the ways in which specific risks are allocated between the parties.
This is a more limited understanding of procurement than the definition we assigned earlier as
the total set of activities necessary to bring a project to the state of operational readiness required
by its owner.

With this in mind, it should be noted that there are few completely 'new' methods of procuring
projects. Instead, a method already used in one particular field may be taken up in another, as its
benefits are perceived to be greater than the method currently in use in that field. Or a system
practiced in one country will find its way to another through international trade activity, or
perhaps even through the migration of people with the requisite experience.

The novelty in alternative procurement methods lies mainly in the unfamiliarity experienced by
the people engaged in administering them.

Under one of the building procurement system, design and construction are clearly separated. An
owner engages an architect to design the building, often with the assistance of other professional
consultants, and to prepare tender documentation. A period is then set aside for tendering. Bids
from contractors are submitted to a process of adjudication, and the owner enters into a formal
contract agreement with the successful tenderer, who then proceeds to construct the building
according to the architect's design. Usually, the architect is retained by the owner to supervise the
administration of the contract and ensure the sufficiency of the work carried out by the
contractor.

Minor variations in this system have developed over the years, but the basic principle of
separating the design process from the construction process has remained intact.

In the mid-twentieth century, financial pressure on client bodies to contain building costs saw the
introduction of an alternative building procurement system under which design and construction
became integrated. Using this approach, clients called upon contractors to submit tenders for the
design and construction of building projects. The 'design/build' method, as it became known,
removed one problem associated with the traditional approach. The increasing complexity of
buildings, particularly in terms of their services installations, had begun to put the design of these
components beyond the single capability of many architects. More and more frequently,
contractors were called upon instead to appoint specialist subcontractors to design and install the
required services systems. Although attempts were made to remedy the breach with special
clauses in contract agreements, this development began to bridge the design responsibility gap
that had been carefully put in place under the traditional separated procurement system. The
'new' design/build method placed all design responsibility (and hence the technical risk of design
failure) clearly in the hands of the contractor, even though in practice a contractor might then
employ external consultants to undertake the design work.

51 | P a g e
Novel operational systems
Technically novel operational systems for projects are more likely to be encountered than
administratively novel operational systems, simply because the rate of technological change
generally exceeds the rate of organisational change (and organisation is what administrative
operational systems rely upon). As with novel procurement systems, it is the novelty of the
operational system to the user which gives rise to greater risk.

Very large projects

Very large projects can be risky because of their sheer scale. For example, they tend to be highly
resource dependent and thus vulnerable to turbulence in the supply of these resources. A very
large project can exhaust the capacity of local markets to supply its needs, creating logistical
bottlenecks and driving up prices. Labour unions may hold the project to ransom, knowing that
alternative sources for labour are scarce or non-existent.
The length of time required for development can also act against very large projects, as
momentum may be lost that is difficult or impossible to recover, leading to delay or even
abandonment.

Highly complex projects

The complexity of projects, and how this contributes to risk, has already been discussed. It is
important to stress that complexity is not necessarily synonymous with size. Small projects, with
high levels of differentiation and sequential and reciprocal interdependency, may be far more
complex than large-scale projects containing few elements and straightforward pooled
interdependencies.

Severe time constraints

Most projects have tight time-lines, and it seems to be part of the intrinsic nature of all projects
that they are difficult to complete within a predetermined time. Delays and extensions of time are
the norm rather than the exception. Whether this is due to inadequate preplanning of project
schedules and programs (a management risk); or to deficiencies in project supervision and
control (also a management risk); or to other causes, is a matter of individual investigation for
each project. In some cases, while the impacts of completion delay may be inconvenient, they are
often not critical.
A delay of a week in opening a new shopping centre, with the event scheduled at the end of the
month to exploit the opportunity to attract month-paid shoppers, might be disappointing rather
than disastrous, and would almost certainly not be critical in terms of the longer term financial
profitability of the project. If the delay were to occur just before pre-Christmas opening planned
to exploit the bumper sales season, however, the impact on sales cash flow might be far more
serious, to the extent of critically endangering the ability of smaller retail tenants to survive the
high start-up costs of their participation. The loss of the 'kick-start' event might then affect the
longer term attractiveness and status of the whole centre.
However, examples such as these are at the lower end of the risk continuum for 'time to market'
projects, in terms of their need to be completed in time to capture market opportunities. Other
types of projects have far more urgent time constraints. Time is therefore a critical factor for
them.

52 | P a g e
For other projects, failure to achieve completion by due date may be extremely serious, or even
catastrophic. With such projects, the predetermined completion date is the most critical criterion
in terms of project success or failure.

Stakeholder inexperience
Project failure due to stakeholder inexperience is found, more often than not, in the technology
and organisation elements of projects. Most project stakeholders know what is to be done (the
tasks), and what will be needed (the resources), but how the tasks should be undertaken (the
technologies) and who should be involved and when (the organisation) can often prove far more
difficult to envisage and arrange.

Performance/quality standards
The higher the standard of performance or quality required in a project, the greater is the chance
that completely satisfactory outcomes will not be achieved.

If digital imaging technology using overhead gantries, for example, is to be used for capturing
the licence plate details of passing vehicles as part of a toll-road charging system, then the
resolution of the image must be sufficient to allow human interpretation of numbers which do
not match those held on a database for vehicles whose drivers have prepaid the toll.

Regulatory environment
Projects carried out in a highly regulated environment run the risk that, at some point, something
or someone connected with the project will be in breach of a law or regulation. However minor
the breach is, it may have the capacity to cause a major disruption to the project. There is also the
chance that laws and regulations might be changed during the life of the project and similarly
cause disruption.
Since no project takes place in a completely regulation-free environment, it might be said that all
projects are risky in this regard, and their vulnerability is simply a matter of degree. Even so-
called 'enterprise managed projects', which are projects carried out wholly within an
organisation, will still be subject at least to the internal rules and policies of the organisation, and
are likely to have to comply with numerous external regulations relating to matters such as
occupational health and safety, employee award determinations, permits and licences.

Environmental/ecological sensitivity
Sensitive environmental conditions and issues can complicate an otherwise straightforward
project. As with other factors, the risks may arise not only in the procurement stage, but also in
the operational or disposal phases of a project. Nor are the risks confined to the sensitivity of
purely physical environments. Since the adoption of 'triple bottom line' objectives for many
projects nowadays, the implications of their social and economic environments may also have to
be considered in terms of risk. The impact of a project upon its surrounding community, or upon
local, regional or even national economies, may become critically important to the point where
these can affect the feasibility of the whole project.

53 | P a g e
Ecological sensitivity is a growing area of concern, matching the parallel growth in ecological
research and discovery. On some projects, precautions against ecological damage have had to be
changed or even abandoned after new findings have shown them to be ineffective.
Environmental and ecological issues also have the propensity to arouse activist and protest lobby
interventions, thus giving rise to additional political risks.

Political/cultural sensitivity
Few projects take place in environments that are entirely free from political or cultural
sensitivities. The level of these sensitivities may range from intra-project issues and differences,
through those at intra- or inter-organisational levels, to even higher local, regional, national and
international sensitivities.

Projects which, by their very nature, intrude upon or exacerbate political or cultural sensitivities
are clearly most at risk. However, it is possible for a project to be innocently caught up in such
situations. It is not unknown, for example, for prominent or urgent construction projects to be
targeted for industrial action by unions eager to demonstrate their power to governments or
employer groups unwilling to accede to their demands. Delivery of internationally sourced
project resources may be held up at ports or airports for similar reasons, or for the purpose of
showing solidarity with unions overseas. Nor is it unusual for governments to delay projects until
after elections have taken place, in order to avoid losing key votes. The 'pork barrelling' opposite,
where projects are accelerated to appease influential groups, is also well known.

Multicultural development in many westernised societies has brought with it a parallel increase
in the need to test the cultural sensitivities of many projects in terms of their potential effects on
accepted religious and ethnic practices.

Situational instability
Situational instability is most often interpreted as the additional risks of undertaking projects in
foreign countries, particularly in third world nations. The instability usually derives from a
number of the factors already discussed, particularly environmental, political and cultural
sensitivities, novel procurement systems, capital financing and stakeholder inexperience.

Other situational factors might include the sanctity of government guarantees, the ability to remit
profits, and the safety and welfare of expatriate employees.

3.6 SUMMARY
This chapter should have given you a better understanding of the nature of projects as
undertakings established to achieve predetermined objectives with a given time-frame. We have
adopted a multi-environment view of projects, to encompass procurement, operational and
disposal stages, although not all projects will include all of these.

54 | P a g e
The constituent elements of any project, regardless of type, comprise the tasks, technologies,
resources and organisation required to undertake it. Each element is capable of further division
into more detailed project-specific sub-elements.

The complexity of a project is influenced by the degree of differentiation, together with the
nature and extent of interdependency, discernible in its elements and sub-elements.

The elements and sub-elements of a project involve a substantial amount of decision-making.

Decision-making gives rise to risks, largely because of the uncertainties inherent in the variables
that must be considered in the decision-making process. These uncertainties are exacerbated by
the relative complexity of the project.

These and other factors contribute to the 'riskiness' of projects, and provide a rationale for the
need to manage the risks involved in undertaking them. Before considering how project risks
should be managed, however, it is first necessary to consider the organizational aspects of
projects in terms of the different stakeholders involved. This will provide the necessary
transparency to stakeholder decision making that will allow us to explore risk management in the
most appropriate way.

55 | P a g e
 CHAPTER 4

DEMISTIFYING RISK: USING THE PMI PMBOK

OBJECTIVE:
 To enable learners understand the inputs, tools and techniques behind risk
management planning.
 To enable learners differentiate and master quantitative and qualitative risk analysis.
 To help learners master the concept behind risk monitoring and control.

Content:
Introduction

4.1 Demystifying risk -PMBOK

4.2 Inputs to risk management planning

4.3 Tools and techniques for risk management planning

4.4 Risk identification

4.5 Qualitative risk analysis

4.6 Quantitative risk analysis

4.7 Risk monitoring and control

4.8 Summary of the risk management process

4.9 Summary

Introduction

Dear learners, this chapter tries to give you a highlight on the inputs, tools and techniques
behind risk management planning The chapter, moreover, tries to analyze quantitative and
qualitative risks. Hence at the end of this unit, you are expected to:

 Interpret the inputs, tools and techniques associated with risk management
planning.
56 | P a g e
  Understand and appreciate the quantitative and qualitative risk analysis
approaches.
 Appreciate the risk management process.

4.1 DEMISTIFYING RISK-PMBOK

It is not only important to know the PMI PMBOK guide on risk management but also to simplify
the process to match it with reality. The PMI PMBOK defines risk management as the
"systematic process of identifying, analyzing, and responding to project risk." The concept aims
at maximizing the probability and consequences of positive events and minimizing the
probability and consequences of adverse events to project objectives.

It is important to see the PMBOK as a guide, not a manual. The discussion presupposes a
separate risk management planning process, which serves as an ideal. In practice, risk planning
occurs as an integral part of project planning.

The PMBOK framework is very useful as a process guideline, but in view of developments in
enterprise project management, multiproject environments, project and portfolio selection, and
the new appreciation for the interfaces of project management with other organizational systems,
the PMBOK is only a start. Table 4.1 contrasts the current PMBOK on risk with future needs.

TABLE 4.1 Comparisons of Current PMBOK Standards on Risk with Future Needs
Process focused Management focused

Separate procedure Integrated into project planning and

control

Single project oriented Portfolio, multiproject oriented

Emphasis on quantitative Emphasis on qualitative and professional

judgment
Focused on methods and procedures, not people Focus on training and enabling people
to manage risk
Not related to cost Integrates risk and cost
Not related to quality Integrates risk and quality
Ignores business wide risk Initial focus on business risk strategy
Does not incorporate contingency into Integrates risk into the scheduling process
Planning
Ignores risk as opportunity Connects risk control to opportunity
Process. We are learning that while process focus is important, it misses the opportunity to
integrate risk into current business and project planning and management actions. Process focus
is useful for ensuring quality and discipline, but has limitations in practical work settings.

57 | P a g e
Separate process. The propensity to breakdown the project planning and control process into
components misses the actual dynamic in real organizations where everything goes on all the
time. Risk has not proven to be useful as a separate process, but rather effective only if
integrated.

Single project. Risk is no longer looked at as a single project issue; most risk is associated with
broader issues, such as the business itself and other projects in the company portfolio.

Quantitative. Overemphasis on quantitative tools and mathematical models suggests risk

management as a science rather than art. Most risk management actions are full of judgment and
margins of error, which make quantitative tools ineffective and intimidating.

Focus on methods, not people. The risk process is essentially a thought process, a way or style
of management that is ingrained in the way people work and solve project problems.

Overemphasis on methods and undervaluing of the human element limit the application of the
current PMBOK.

Unrelated to cost. Risk and cost are inextricably intertwined and therefore it is difficult to look
at risk without looking at the costs of control and costs of impact.

Unrelated to quality. Risk and quality are also inextricably connected. Since risk has an impact
on quality, many risks are associated with feasibility, not schedule-some projects may not be
capable of meeting customer standards and specifications in the first place.

Ignores business risk. Project risk is first identified and managed at the business-wide level,
through strategic and business planning.

Separate contingency planning. The current PMBOK describes contingency planning as a

separate process, but in order to be effective contingency actions need to be incorporated into
baseline schedules and budgets. The project manager ensures that the schedule has buffers and
contingency tasks built in.

Ignores risk as opportunity. The other side of risk is opportunity-the ability to control risk
creates opportunity because the competition cannot. Thus anyproject aimed at capturing a market
share is designed to create opportunity.

The current PMBOK risk processes include the following:

Risk management planning. Deciding how to approach and plan the risk management activities
for a project

Risk identification. Determining which risks might affect the project and documenting their
characteristics

58 | P a g e
Qualitative risk analysis. Performing a qualitative analysis of risks and conditions to prioritize
their effects on project objectives

Quantitative risk analysis. Measuring the probability and consequences of risks and estimating
their implications for project objectives

Risk response planning. Developing procedures and techniques to enhance opportunities and
reduce threats to the project's objectives

Risk monitoring and control. Monitoring residual risks, identifying new risks, executing risk
reduction plans, and evaluating their effectiveness throughout the project life cycle

These processes interact with each other and with the processes in the other PMBOK knowledge
areas. The way they interact is key to integrating risk management with the basic project
planning and control process. Here are the salient points of integration.

Risk Management Planning

Risk management planning for a particular project is inextricably connected to how the
organization prepares for dealing with risk and uncertainty in its business development and
strategic planning, in its information technology investments and management of network
communications, and in its organizational structure. No project manager faces risk alone-it is a
company-wide issue and it is quite likely that there are data and information on project risk in the
company files.

Activity
Dear learners it is quite argued that information technology is a significant asset under the
pursuit of effective risk management planning. Why? Explain.

_________________________________________________________________________
A_________________________________________________________________________
company prepares for risk in projects by assessing the overall risk in strategic planning. Then,
in_________________________________________________________________________
its development of a program of projects, or portfolio, the company assigns risk to a general
___
program or product line as part of its decision to proceed. Templates for risk identification and
assessment are available.

A project management office is sometimes available to support risk management by providing

for information templates, project review data and agendas, research findings. and historic
information on various risk subjects.

To address risk effectively, there needs to be an information technology capacity in the company
to ensure that risk documentation and tracking can be achieved within the network and the

59 | P a g e
software assets available. This means a way to organize risk data, for team members to
communicate risk information quickly, and for project managers to present risk data in
acceptable formats.

Finally, if the company is not organized to address projects in some kind of project structure,
project risk will get the same kind of attention other project, issues, such as cost and schedule,
get-very little. In a matrix structure, for instance, risk is addressed in the functional department in
terms of processes and equipment to address risk through testing and monitoring technical
processes. At the same time, the project manager is attuned to risk when schedules are delayed
because of events or developments grounded in risk.

This does not need to complicate the up-front risk process. Risk is still a relatively
straightforward concept of planning and controlling for things that could go wrong. That risk
management planning is tied to business planning and strategy need not suggest that this linkage
complicates the achievement of a good risk management process. In fact, it makes project risk
management easier in the sense that business planning itself provides a precursor to project risk.

4.2 INPUTS TO RISK MANAGEMENT PLANNING

Project charter. The project charter is an ideal project planning document that includes the
business need and product description. In reality, this document is often neglected because the
content for the business need is still in conceptual stages. Anti since at this point the deliverable
is often undefined and unspecified; the product description is not at the level of detail of a
configuration management document. But the deliverable is defined in performance terms at the
scale possible, given the understanding of what is being designed and built.

Organization's risk management policies. If the business has a set of risk management policies
and procedures, they would be used in risk planning. However, many businesses do not have
such policies, nor will they; rather they apply risk tools as an implicit part of the project planning
process. Approaching this process input with a healthy skepticism one can see the value of
writing down policies and procedures, but in today's fast moving companies this is rarely done.
The point is that a nimble midsized business of today that has articulated its approach to risk
would expect each employee and certainly its management to embody that approach in the basic
project management process-without a bureaucratic statement of top-down policy.

Defined roles and responsibilities. One would hope that the basic roles and functions of the
project manager and functional manager is documented, but again this is often left undefined in
order to allow a natural process of negotiating and working out roles between functional quality
and project delivery interests.

Stakeholder risk tolerances. The PMBOK is not very helpful in illustrating this input.
Stakeholder risk tolerances are evidenced in the modern business as "world views" of certain
important people in the process, such as sponsors, customers, investors, top management, and
regulators. A risk tolerance for an electronic instrument might be framed as a technical tolerance
60 | P a g e
(e.g., meantime- between-failures), or a performance tolerance (e.g., must perform in below zero
temperatures). Tolerances are often grounded in expectations, thus it is important for a project
manager to see such tolerances and evaluate their intensity early in the project.

Work breakdown structure. Certainly, a WBS is necessary as a basis for identifying risk, but
the WBS must be comprehensive and show all tasks before the risk identification process can
really be effective. If the WBS misses some important work that is highly subject to failure then
the WBS is not a good input to risk management planning.

Issues not addressed in PMBOK

Some risk issues are not addressed squarely in the PMBOK but are important in gaining a full
understanding.

Building a risk-based organizational culture. Building an organization that protects itself from
project level risk and uncertainty through good organizational planning and management
requires strong leadership. As a project manager you have to first feel that you are expected by
your management to anticipate and deal with risk and that you will be supported in taking the
time and investing the cost involved in building a good risk planning and control process. Risk
management starts at the top leadership level with clearly articulated vision and mission that
incorporates an uncompromising commitment to quality and excellence. In so doing, the
leadership commits also to a risk management process to reduce the probability of failure and to
promote total quality in product design and production.

Program and portfolio management. The management of risk in a multiproject environment,

and the role of risk in selecting and maintaining a portfolio of balanced projects are not really
addressed in the PMBOK. Yet the selection of the right projects for the project pipeline
inherently involves risk management. Projects with high risks must be identified before they
enter the approved list simply because a portfolio of high-risk projects endangers the long-term
growth and profitability of the enterprise.

Interface management. Good risk management is dependent on the availability of effective

support and interface services to project managers. Risk cannot be seen simply as a project
management issue; it is an accounting and cost issue, a procurement issue, and an information
technology issue. Cost data must be available to project managers to assess cost impacts;
contract officers must be attuned to risk and risk sharing issues in managing contractors and
supply vendors; information technology administrators should see the need for web-based, easily
available risk matrix templates and calculations software.

Risk and cost integration. For some reason, the relationship of cost and risk is lost in the daily
routine of project managers, yet it is in cost and "expected value" that future impacts of risk
decisions can be made. Contingency plans add to project cost estimates and when there are clear

61 | P a g e
decisions that must be made and crossroad tradeoffs to be decided, there must be a support
system available on making those decisions.

4.3 TOOLS AND TECHNIQUES FOR RISK MANAGEMENT PLANNIG

Planning meetings. Planning meetings are important and can be fruitful, but they can also be a
complete waste of time unless they are focused and deliver results. Setting agendas, facilitating
meetings, and writing good follow-up notes are all useful tools.
The PMBOK treatment of risk management planning does not cover some of the most important
risk management planning tools, namely:

1. Business plan. The grasp of the business plan helps a prospective project manager get an early
start in project risk management planning. Such a plan, or a business strategic plan, will provide
strategic information, e.g., SWOT (Strength, Weakness, Opportunity, and Threat) data and
information.

2. WBS. The WBS is an early indication of the potential risks in any project, and planning for
project risk requires at least an outline of the WBS to see the basic components of work
involved. Risk management planning requires the project manager to anticipate how risks will be
handled by looking at the WBS, or building one.

3. Information and network systems. A major risk management planning tool is the company
network and information sharing system and data already available on similar projects in the
past.

Outputs from risk management planning

Risk management plan. The plan outlines the approach to how risks will be handled in the
project. Many companies may not need a separate risk management plan, but they should
integrate risk information into the project scope, WBS (definitions), schedule, and budget.

The plan includes:

1. Methodology. It is not clear from the PMBOK what the "methodology" of the plan is, but it
appears that the concept says you should have a methodology. For instance, an electronic
instrument production firm should use safety and reliability tools, such as mean-time-between-
failures, to test its prototypes to avoid the risk of performance variation and failure.

2. Roles and responsibilities. Here the plan addresses who is responsible for what in a functional
and project management context. Here would be where the role of a program management office
would be described.

3. Budgeting. This is a budgeting exercise to estimate the cost of risk management.

62 | P a g e
Frankly, it would be more important to spend time analyzing the cost of the risk event. The cost
of risk management is a program management cost category, as in quality assurance and project
review.

4. Timing. This addresses when various risk management actions will be taken in the project
schedule, such as risk analyses, preparation of contingency plans, and response plans.

5. Scoring and d interpretation. This portion of the risk management plan addresses tools. such
as the weighted scoring model (aligns projects in project selection with business strategy, places
priority weights on various strategic objectives, and scores each project against the strategic
objectives) and cash flow, rate of return, and net present value.

6. Thresholds. Thresholds address the criteria-rules of thumb-for acting on risks or to reduce

risks, such as deploy preventative contingency and response plans for risks which could delay a
project by more than 10 percent of the total project duration unless the risk is reduced in the first
quarter of the project.

7. Reporting formats. This provides guidance to the project manager on the formats,
e.g., email, MS Project team reporting, hardcopy spreadsheets, for project reports to
stakeholders.

8. Tracking. This provides guidance on what risks will he tracked and how.

4.4 RISK IDENTIFICATION

Risk identification should be part of the project planning process, not separated from it. Risks are
identified in the development of the WBS and in estimating durations and resource needs.

Activity
Dear learners, risk identification is perhaps the most difficult task under a risk management
endeavor. Identify the very reason behind such difficulty.
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
__

Inputs to risk identification

Risk management plan. To the extent that a risk management plan is produced, it is an
important input to identifying risks. But since most companies will start the process of handling
63 | P a g e
risk with the WBS and the task list, the identification of risk usually starts in earnest in the
review and final production of the generic WBS. It is here that the project manager reviews
every task for its potential for failure. Identifying risk involves a lot of discussions with team
members and stakeholders. For instance, if a technical task in the WBS, say achieving a given
mean-time-between-failures in a product component, "sticks out" initially because of the
challenges of completing it then it is the subject of much discussion and contingency planning
early in the project.

Project planning outputs

Project charter. If there is a charter, the charter should be helpful in identifying risks and
confirming the judgment of the project manager on where the project vulnerabilities are.

WBS. The WBS is the basic source of risk identification activity since it embodies all the work
of the project, or should. The WBS should be four levels down to give enough detail to the
project profile to see project risks.

Product description. The product description will be embodied in a configuration management

document, or in some document/drawing./specification that defines the product from a
performance and component perspective. This will occur in the design phase at some point when
the deliverable has been fully fleshed out.

Schedule and cost estimates. The schedule and project budget (part of the schedule in MS
Project) will be a good source to confirm risks, but first the project manager must prepare a risk
matrix as described earlier. The risk matrix identifies the task, the task risk description, and the
impact (schedule, cost, and the like).

Resource plan. While there is typically no formal resource plan, there will be a sense of the
personnel, equipment, capital, space, and technology needs of the project. Ideally, this resource
plan is in one place, for example, in MS Project and/or in a planning document of some sort. But
at this point, if all the resources needed for the project are not clear, it is not critical. What is
needed here is a clear idea of the "bottleneck” resources-those resource issues that could
represent a barrier to achievement of the project. These bottleneck resources might be a critical
software engineer who is already spread too thinly in current projects, a piece of testing
equipment that is critical to meeting quality control thresholds, or a work space or station that is
being shared with other projects.

Here also is the beginning of the application of the theory of constraints. Simply put, the theory
states that the focus of attention in planning and control should not be the whole project and all
its tasks, but rather the one or two major resource constraints. The project manager protects
against the risks inherent in these resources by tapping time and cost from the original estimates
and withholding them for allocation when they are needed.

Assumption and constraint lists. The assumption list is a convenient way of indicating the
controlling assumptions, e.g., the assumption that a sole source contract with a foreign supplier

64 | P a g e
for a key product component will last through the project life cycle. In practice, these
assumptions are well known by the project team and stakeholders, but it pays to document them
and revisit them in project review sessions and to treat then1 as risks with contingency plans.

Risk categories

Technical. Technical risks have to do with product, process, or "technique" issues involved with
designing and producing the deliverable.

Project management risks. Project management risks address the things that can go wrong with
the project planning and control process and with expected support services from the information
technology source and a project management office, if the organization has one.

Organizational risks. These are the "soft" issues that a project faces, which have to do with
organizational behavior and dynamics e.g., conflicts, scarce resources, personnel performance
problems, and company-wide crises, such as lack of financing or a downturn in share value. A
key organizational risk is the lack of top management support, which will be evidenced with the
neglect of the project in the company "head-shed."

External risks. External risks are the business and global risks inherent in any business, such as
economic downturns, trade difficulties affecting the deliverable, and the impacts of
communication in multinational companies.

Historical information. Historical information would include past project documents, "lessons
learned" reports, and industry information available on the competition, on demand and market
issues. and on the company's performance on similar projects in the past.

Project files. Project files would he available from the company's file system, but in practice
project managers rarely look back even though it would make sense to do so.

Published information. This would include manuals, articles, and technical publications on the
deliverable.

Tools and techniques for risk identification

Documentation reviews. The key document in risk identification is the WBS. Other documents
would include past project reviews and similar product performance information.

Information gathering techniques. These would include web-based information, electronic

files with product information, and Internet research.

Brainstorming. Brainstorming is simply having meetings with key people who know something
about the project and generating ideas and options without judging them. Brainstorming
generates ideas and docs not filter them.
65 | P a g e
Delphi technique. Delphi is brainstorming with key experts who go through a systematic
process of providing their views, reviewing each other's ideas and coming up with a scenario
based on the integration of their views.

Interviewing. Interviewing key stakeholders, past project managers, and task managers helps to
uncover "subtle" information that has not been documented.

Strengths, weaknesses, opportunities, threats. Here we look back at the business planning
processes for strategic analyses, especially including threats and opportunities.

Checklists. Checklists are typically prepared by a documentation specialist for various project
and product documents. Checklists often key into potential failure points in past projects and
thus are very useful in identifying risks.

Assumptions analysis. The key source of assumptions is rarely captured in one document, hut
the concept of focusing on assumptions is important. A project management office is typically in
charge of documenting assumptions.

Diagramming techniques. Flow charts and diagrams, such as decision trees, are useful in
identifying the various options and decisions, including expected value.

Cause and effect. "Root causes" of risks can be identified through fish-bone diagrams and other
such meeting techniques.
Influence diagrams. Diagrams that indicate cause and effect, and influence of key factors, can
help in identifying risks.

Outputs from risk identification

Risks. The output of risk identification is a better sense of risks over time. In truth, the clarity of
risks increases as time goes on in the project life cycle.

Triggers. Triggers of risk include those indicators or signals of risk events that become clearer in
the risk identification process. For instance, in a contract negotiation in the outsourcing process,
a contractor refuses to sign the contract because. of a schedule requirement for delivery of a key
supply or piece of equipment before a key project milestone.

4.5 QUALITATIVE RISK ANALYSIS

PMBOK separates the risk analysis process into two parts: (1) qualitative and (2) qualitative.
Qualitative connotes a better description of the risk, its dimensions and its characteristics;
quantitative involves getting a finer cut on risk by applying mathematical and other quantitative
tools. In practice, companies rarely split the two. The point of risk analysis is to drill down on
potentially high-risk tasks to get a more detailed picture of their impacts.

66 | P a g e
Inputs to qualitative risk analysis

Risk management plan. The risk plan again is useful.

Identified risks. A completed risk matrix is required before risk analysis proceeds.

Project status. The timing of risk analysis is important because the risk impacts, particularly in
terms of schedule and budget, will change depending on when they are analyzed. The later in the
project cycle, the clearer the impacts will be.

Project type. It is important to dimension the risk here; a project producing an electronic
instrument for a sophisticated aeronautic application will get a different look than a project to
construct a standard building.

Data precision. The accuracy and precision of data are important: if you know that a given
reliability test has a proven failure rate then the results must be tempered accordingly.

Scales of probability. Probability is a subjective judgment unless the product is tested many
times to develop a statistical mean. In most projects, the probability of a risk occurring is the
result of thinking through how many times this kind of risk has occurred in past similar projects,
combined with "gut" judgment of the project manager and key stakeholders.

Assumptions. Again, the assumptions are rarely listed, but they are apparent in the analysis
process.

Tools and techniques for qualitative risk analysis

Risk probability and impact. Using the risk matrix, the project manager has already identified
risks and will assign probabilities to all high-impact risks. For most risks, these probabilities are
subjective and simply communicate a sense of confidence that the project manager has about the
risk in question. Generally, probabilities should be stated in three forms, 25 percent, 50 percent,
or 75 percent, suggesting little change of the risk occurring, substantial chance, or high chance,
respectively.

Probability/impact risk rating matrix. The rating or risk matrix now is fine tuned in the
analysis process, with more data and more attention.

Project assumptions testing. Testing assumptions involves taking time to review key
assumptions and confirming that the assumption is right and that the probability assigned is in
the right ballpark.

Data precision ranking. For most projects, this step is not useful. If the product is highly
complex and must meet detailed performance specifications then the data precision ranking
indicates how precise the test data are compared to a common standard.

67 | P a g e
Outputs from qualitative risk analysis
Overall risk ranking for the project. Once the qualitative process is finished, two rankings are
produced: (1) how the project's overall risk is ranked compared to others (may be completed in
comparing and selecting a portfolio of projects) and (2) how individual risks rank within the
project, usually limiting the list to five or less. Again, this process is related closely to the theory
of constraints. A project typically faces only a few major bottlenecks or risks, and it is the job of
the project manager to accurately uncover those few critical risks during qualitative analysis.

List of prioritized risks. The list of prioritized risks is incorporated in a project report to
stakeholders along with supportive information including the risk matrix and contingency plans.

List of risks for additional analysis and management. A residual list includes other risks that
could turn out to be more important than they appear.

Trends in qualitative risk analysis results. Some review of the credibility of the process will
uncover past analyses and how their results played out in real terms.

4.6 QUANTITATIVE RISK ANALYSIS

Inputs to quantitative analysis
All the inputs to qualitative analysis are relevant here, plus expert judgment.
Expert judgment comes from technical experts who have knowledge at the technical level on the
risk in question. For instance, here is where a project manager brings in a safety and reliability
expert contractor to advise on variability thresholds in testing prototype parts.

Tools and techniques for quantitative risk analysis

Interviewing. Again, interviews are useful with key experts on defined task risks.

Sensitivity analysis. Sensitivity analysis determines how much project outcomes,

e.g., schedule, budget, and quality are sensitive to particular risks. For instance, it may turn out
that although a risk is only medium probability and impact, it could alter the final deliverable in a
measurable way in terms of quality control.

Decision tree analysis. Decision tree analysis aims to uncover expected value of taking one path
or another when a project "crossroad" decision must be made.
In the case already discussed, a decision on whether to purchase land in anticipation of winning a
contract brings with it a set of expected values for going one way or the other.

Simulation. Simulations are mathematical representations of scenarios involving key project

risks. This might include an equation that specifies what happens to an information technology

68 | P a g e
scheme when its capacity is challenged by demand, e.g., shut downs, performance failures, and
the like.

Outputs from quantitative risk analysis

Prioritized list of quantitative risks. Quantitative analysis usually places more content on the
already produced list of risks from qualitative analysis. New data are presented or1 high risks
from the analysis.

Probabilistic analysis of the project. Here the probabilities are worked to a finer level of detail
based on more analysis. A probability set at 25 percent in the qualitative phase might be fine
tuned here to, say, 38 percent with more input from intensive analysis of past projects and
simulations and perhaps some experiments.

Probability of achieving the cost and time objective. A final probability is determined for
meeting the project schedule and budget goals.

Risk Response Planning

Appropriately, the PMBOK places high priority on a response plan that mitigates risk. That
response plan is grounded in the contingency plans already developed in preparing the risk
matrix. The key point about response planning is to outline corrective action and to incorporate
those actions in the baseline schedule so that they will not later be considered add-ons or changes
to the project.

Inputs to risk response planning

Risk thresholds. Risk thresholds help to identify acceptable ranges for risks to occur without
deploying contingencies. e.g., if this work is not done in the estimated time then we will give the
team 3 more weeks before we act since the task is not on the critical path. They come from
customers, stakeholders, and technical experts.

Risk owners. Risk owners are those stakeholders who are accountable for acting on risks. or at
least reporting on risk activity. If there 1s no designated risk owner, a risk could be unattended
long after it is identified because of the tendency to avoid controversy and accountability for
risks that cannot easily be controlled.

Common risk causes. Common to all industries are a set of common risk causes, such as
government regulatory change, had marketing information, faulty safety and reliability
equipment, and lack of proven competencies in particular personnel categories.

Tools and techniques for risk response planning

Avoidance. One approach to a risk is to avoid it and hope that it goes away. Sometimes it does.

69 | P a g e
Transference. Transference involves turning a risk over to a risk owner, e.g., assigning a
contractor the job of responding and providing incentives for risk reduction.

Mitigation. This is the corrective action option leading to deployment of a contingency plan.

Acceptance. Sometimes it pays to accept a risk and deal with it directly rather than transferring
it, avoiding it, or mitigating it. "Living with" the risk means plugging in schedule and budget
reserves assuming that the risk cannot be controlled and working around it.

Outputs from risk response planning

Risk response plan. Although a formal, written risk response plan is not always feasible or wise
because of the cost and effort involved, it is the learning and thinking process that follows from
good risk response planning that gives it value. Once through with the process of defining risks,
planning to respond, and folding the results into planning documents, such as the schedule and
budget, a project manager "owns" those risk responses and has incorporated them into the plan.
The lack of a separate, documented risk response plan is not a good indicator of the fact that
risks have not been considered. It is more important that risks are incorporated in the project
schedule and estimates made from "expected, optimistic, and pessimistic views," which are
driven from risk analysis.

Residual risks. Residual risks are risks that continue to exist after corrective action. Sometimes
residual risks are created in taking a corrective action that was not anticipated in the original
project planning process.

Secondary risks. These are lower level risks that have less impact but which can grow in
importance if neglected.

Contractual agreements. The type of contract used in outsourcing work involves some explicit
assumptions about risk transference. For instance, a fixed price contract is superior to a cost
reimbursable contract in transferring risk to a contractor to control a given risk in performing
contracted project work.

Contingency reserve amounts needed. Sometimes a project must be protected with a reserve
fund, or insurance program, so that the company is not financially exposed from a given risk
even though it is mitigated.

4.7 RISK MONITORING AND CONTROL

The PMBOK places emphasis on monitoring risks and controlling them, but this process is again
an integral part of the project review and control process.

Inputs to risk monitoring and control

70 | P a g e
In addition to the common inputs addressed above, the new inputs to monitoring are
communication and scope change.

Project communication. Communication means exchanging information on anticipated risks so

that people who have a stake in the project can assist in mitigation and can adjust their
expectations for the project. Communication always helps to reduce the uncertainty and
"surprise" factor in dealing with customers, clients, and stakeholders.

Scope changes. As the project is progressing and work is getting done, there may be new
information uncovered in the risk management process that requires a change in the scope,
schedule, budget, or quality standards in the project. Thus scope change is a logical outcome of
monitoring and seeing risks impact the project.

Tools and techniques for risk monitoring and control

Project risk response audits. A project risk audit looks back at how effectively project
management processes in general were handled and how well project risks were monitored and
mitigated.

Periodic risk reviews. Risk review occurs in the normal project review process, not as a
separate process. A standard project review agenda always includes a section on risks.

Earned value analysis. Schedule and cost variances always indicate the possibility of risks
being at work if the project is not performing as planned. Corrective action when uncovering
major earned value variances over 10 percent would include a review of risk contingencies and
impacts.

Technical performance measurement. Technical issues could be at work in a project that is

slipping or meeting insurmountable obstacles.

Outputs from risk monitoring and control

Workaround plans. The so-called workaround plan is a manifestation of the risk mitigation
process. Workaround is a contingency that should be identified in preparing the risk matrix.
Workaround sometimes takes advantage of innovative, creative options to overcome a project
risk, and is often the result of "out-of-the-box" thinking that can be generated in a brainstorming
session.

Corrective action. Corrective action is the action taken when the project is not performing
according to plan-schedule, cost, and quality.

Project change requests. In monitoring, the need to fundamentally change a project scope or
key deliverable occurs often, thus triggering a change request.

71 | P a g e
Updates to the risk response plan. Updates to the risk response plan result from lessons learned
in the monitoring process.

Risk database. The risk database is a documentation of risk information that will be useful in
corrective action and future projects.

Updates to risk identification checklists. Updates to risk identification checklists help keep
tabs on best practices in risk mitigation as they are generated.

4.8 SUMMARY OF RISK MANAGEMENT PROCESS

Identify and categorize risks

Identifying risks 1s not a science. it is an art. It does not require a sophisticated, mathematical
exercise, although some measurement may be useful to dimension the risk.

Given a project description including project goals, work breakdown, schedule, and resource
assignments, identify and categorize potential risks using various tools including risk assessment,
brainstorming, peer review, and document review.

Here we develop the basic skill of reviewing a project scope, work breakdown, and schedule, and
identifying risks from the tasks and processes. The reader goes through a risk matrix, which lists
potential risks, defines them, categorizes them, estimates impact on various project performance
outcomes, such as schedule, budget, and specification, and might include reference to a
contingency plan-a plan to take an action if a "worst case" actually happens.

Assess risks

Assessing risks is part of the planning process, not a separate, quantitative, or qualitative
exercise.

Activity
Dear learners, what are the basic aims/objectives associated with risk assessment?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___

Given a project description and identified risks, apply various quantitative and qualitative
analysis tools, including sensitivity analysis, to determine the effects, outcomes, and
consequences of identified risks.

72 | P a g e
This is where we will apply tools and methods to assess impacts and consequences of various
risks on project success. You can use a variety of tools.
Sensitivity analysis tries to figure out how sensitive the project is to a given risk and there are a
variety of approaches to sensitivity analysis.

In the real world, project managers don't do sophisticated probability analysis to get the
probability of something happening to 88.54 percent. The margin of error is so large in trying to
determine the probability that you are lucky to get in the ballpark. The real issue is saying, "Here
is a potential risk. Is the probability of it happening 25 percent or 85 percent? If it's 85 percent, I
better do something about it."
Risk assessment tools. Here we get into the application of risk assessment tools.
Risk assessment is the process of analyzing project risks to learn more about them. to quantify
probabilities when it makes sense, and to help decide what to do about them. We will learn about
qualitative and quantitative assessment. Qualitative assessment focuses on describing risks,
ranking them, and making sure they are fully understood. Quantitative assessment applies
probability and other analytic tools, such as decision trees, to pin down the extent of risk and risk
impacts.

We will apply some quantitative tools. While risk management is not primarily a quantitative
exercise, it sometimes helps to quantify the risk and its impacts to get a better handle on it.

Risk assessment involves two basic functions: (1) (qualitative-rank ordering risks so that you can
decide which are the most important to tackle and (2) quantitative- doing more quantitative
analysis to pin down risks so that risk response can be predicted on quantitative measures, such
as the probability that something will happen and have the anticipated impact, and so that stake-
holders can be assured that risks have been analyzed.

The goals of risk assessment are as follows:

1. To increase the understanding of the project-the more I know about risks, the more I know
about the project

2. To rank-order risks in terms of severity and impact so that I know which to address first

3. To serve as the bass for identifying alternative approaches to response and risk management
and integrating risk into the risk management process

4. To offset the normal tendency to be optimistic in project planning-the basic human trait of
expecting the best will take over unless you weigh it against a risk analysis that forces you to
identify impacts and worst case, pessimistic scenarios.
Risk qualification

Risk qualification involves listing risks and using a risk matrix to determine how risk should be
categorized and ranked according to their impacts on schedule, quality, cost, and overall success
of the project.

73 | P a g e
Risk quantification

The tools for risk assessment we will address are:

1. Probability. Probability analysis is the process of developing u measure of how likely a risk is
to (a) occur and (b) create the impacts anticipated We want to be able to say that not only is this
risk liable to happen, but there is a 50 percent probability that it will happen. A 50 percent
probability that it will happen combined with a 50 percent probability that if it happens it will
have the impact identified, creates real urgency to respond, as opposed to a risk that has only a
20 percent probability of happening.

Remember that the initial determination of the probability that a risk will occur is typically not
very scientific, that is, there is usually no database available to actually calculate probability
from a statistical perspective. Much of risk assessment is based on prior experience and a full
detailing of project tasks and components so that they can he understood.

2. Sensitivity. Sensitivity analysis involves analyzing how sensitive the project is to a particular
risk, that is, quantifying linkages between a given risk and the "ripple" effect it could have on the
project from a schedule, quality, cost, and overall performance perspective.

3. Decision tree. A decision tree helps to describe the flow of project decisions to points where
there are tradeoffs based on risk. That is, it clarifies where you have to make decisions based on
a risk and other factors, such as cost and quality. For instance, an important leg of a decision tree
on planning a project task may be to "buy or make" a particular component, that is, to contract-
out or to build in-house. The risk implications are different for each. Thus risk is a part of
making that decision.

Risk matrix template

The risk matrix is a very valuable but simple tool to manage the risk "portfolio." Table 5.2 shows
a risk matrix template.

TABLE 4.2 Risk Matrix Template

Risk Description of Impact (technical, Severity Rank Contingency plan
item risk schedule, cost quality) (high, medium, low) (what is planned to offset the risk)
________________________________________________________________________________________________________

74 | P a g e
Building a Risk Management and Planning Process
Building a risk management process is largely a "selling" challenge, not a technical task.
Building support systems for risk management is part of the process by which the organization
matures as an organization.

Given a project description and ranked list of risks, describe the steps in the project risk
management process and develop a risk response strategy including avoidance, transference,
mitigation, and acceptance, and develop a risk response plan.

This has to do with responding to the risks we have identified with a process and risk response
plan. This is where the project manager produces a strategy way of addressing the risk identified.
For instance, for the software debug process referred to above, I must develop a plan to avoid the
risk and/or respond, and it might include alerting the software developer to the risk and getting a
direct estimate of his or her view of impacts, as well as an approach to offsetting the risk-perhaps
assigning another developer to the job or putting more effort into debug or even subcontracting
out a support function to anticipate debug problems during in-house design.

This covers front-end, company-wide risk management system planning as well; you not only
have to describe a risk management system, but you need to install it into the organization as a
way of doing business. The assumption goes like this: If your company or agency is going to
identify and manage risks, it must have the capacity to use the right systems, tools, and formats
to do so and it must have a well-defined process as well. So you have to establish a risk planning
capacity and process. This new process was added in the most recent version of the PMI's
PMBOK to address "getting your company ready" to do good risk management. In sum, we
address organizational capacity as the ability of the company or agency to develop a company-
wide risk management process to help project managers mitigate (offset) project risk and
develop and implement a risk response and communication plan.

Risk management plan

The risk plan does not always need to be documented; it is the thought process that counts.

The risk management plan will include the following sections, which will be submitted to the
project manager.

Risk management policies and procedures define the way the company or agency intends all its
project managers to approach risk. The company or agency in effect says to the project manager,
"here is the way we want to ensure consistent approaches to risk management across the
company, and if you stay with these guidelines, we will support you even if the project does not
produce exactly as planned."

75 | P a g e
Here we address the project risk management process. The basic steps in the project risk
management process, which are mirrored in the structure of our course, are:
 Risk planning: the step that prepares the organization for risk with support systems and
defined roles and procedures, setting a high priority on risk management as an integral
part of the project management process
 Risk identification: the step that identifies risk and ensures that all risks are "on the table"
before more detailed assessment is undertaken
 Risk assessment: the step that assesses risks, analyzes them, and quantifies risks in terms
of probability
 Risk scheduling: the practical application of MS Project, PERT analysis.
 Risk response: includes the development of a risk management plan, contingency plans,
and reflects risk in the project scheduling and resource assignment process
 Risk monitoring and communication: the step that provides for regular reviews and
interchange among key stakeholders and customers on risk, changes in risk, and risk-
related developments

Here is where the company defines the roles of project managers and team members, such as
project engineers or software developers, in defining and controlling risk. Since risk assessment
is an analytic process and since risks change over time, the management of risk takes time and
effort. So jobs that involve risk management must be defined as such, and team members must
be enabled to charge time to risk management.

Work breakdown structure. Remember, a good risk management plan starts with a well-
defined project deliverable accomplished through a WBS. The WBS presents the outline of the
project deliverable. Thus, if it is comprehensive and does not omit major components and work
packages, it lists the potential sources of risk.

Risk identification

Here is where we address the risk identification process. It starts with a full understanding of the
project and a comprehensive project plan. Risks are identified from the work breakdown
structure and baseline schedule. Risks are categorized in terms of technical, technical and
equipment processes, quality, organizational, people resources, project management processes,
or performance risks.

Tools for risk identification include brainstorming (group thinking out loud), Delphi technique
(bringing experts together), interviewing, checklists, assumptions, and process diagramming
techniques. They may also include drawing on lessons learned from similar projects in the
organization.

We want the reader to get: (1) a full understanding of how a company or agency equips itself to
handle risk in its projects-learning what management must do to build the capacity of the whole
organization to control risks and (2) a full understanding of how individual project managers
handle the initial step of identifying risks since this first step is so critical. If you miss major risks
76 | P a g e
upfront, handling them downstream in the project becomes more costly and sometimes just
doesn't work.
Our objective, then, is to learn how to categorize risks and we will use a risk matrix template to
do so. A risk matrix template is a table showing categories of risk down the left column and
providing information on each risk across the top. One approach to this information is to list
definition, potential impact, probability of impact, response plan, and monitoring plan. Another
approach categorizes risks in terms of external unpredictable (like our earlier definition of
uncertainty), external predictable, internal nontechnical (I would call this managerial/
organizational), technical, and legal.

We will go deeper into risk identification, identifying and categorizing risks in various kinds of
projects. This is where you will see "windows and flags" for identifying risks and getting them
"on the screen" early in the project. For instance, in a highway construction project, a rule might
be that you can always predict that subcontractor concrete finishers represent a major risk
(reliability, quality of work) and need to be listed in the risk matrix. If you know you have a
major challenge up front-not because it's a particularly difficult task hut because its history
suggests uncertainty-then use risk management tools to define it and monitor it. This is a risk
"flag" in that it flags a potential risk simply by its definition. It's also a "window" of opportunity
to get on top of that task early.

The success of a risk identification process lies in the initial project work breakdown structure. If
you have identified all the necessary work to compete the deliverable in the WBS then risks can
be identified by looking at each risk and going through the mental exercise of asking, "what
could go wrong and what would happen if it did?"

The real problem results from not identifying a task in the WRS that later creates real risk
exposure-missing a major risk in the initial stages because you missed an important function or
component. If it isn't visible early, a major risk can "show up" later. For instance, you may have
identified a major software engineering task in your WBS that isn't that challenging, so you
assign a low risk to it. But the real risk lies in the availability of a key software engineer to do the
work-which you did not identify in the WBS and which later gives you real headaches!

Communicate risks

Communicating and reporting on risks is part of communicating and reporting on the project
itself. You are not only trying to reduce uncertainty and report accomplishments, but also to alert
stakeholders that the project is in a sensitive stage of uncertainty.

Given a list of risks, you will need to know how to develop a plan to communicate those risks to
the appropriate project team members and stakeholders, as well as to management.

This reminds us that it doesn't make much difference what risks you have identified if you
haven't communicated with people who have a stake in the project and who can help address
risks. This requires us to identify those people who have a direct interest in the project outcome

77 | P a g e
and who must commit to the risk management process. These interested parties would include
the customer or client, all project team members, support personnel, corporate management,
investors, and even the competition.
The challenge here is to figure out how to present a risk so that people understand it and come up
with good ideas on how to handle it. You don't want to create fear; you want to create
commitment and resolve. You also want to focus key people on the right risks, the ones that can
create the most problem and opportunity. The 80 to 20 rule says that 80 percent of your risks will
not be important; it's the 20 percent that will be critical that you need to identify and manage.

Monitor and review risks

Keeping up with risk involves equipping your team members and suppliers with the tools
necessary to monitor risk and the sensitivity to catch risk problems before they occur. It is mostly
an interpersonal process, not a formal project review process.

Given a project in which tasks have been scheduled and risks have been identified and ranked,
develop a plan to monitor and control changes in risks and risk potential as an integral part of the
project review process.

It takes some planning and effort to monitor how risks change as the project progresses and how
those changes affect the original risk assessments and project outcomes. This is typically done
through a project review process where individual project risks are reviewed as part of the
broader review of the whole project. For instance, in our software debug issue, an upcoming
software design review might be scheduled and during the project review prior to that design
review a checklist might be constructed to "flag" debug issues.

The other part of the monitoring process is making sure that the team members closest to the job
are aware of risks and communicate risk information as the design and development is occurring.
They are the most likely to know the extent of change in a risk assessment and how it will impact
the project.

Develop risk-based schedules

The risk-based schedule referred to earlier is simply a schedule, which is "informed" by risk
considerations. Durations reflect things that could happen.

Given project risks, you will need to know how to develop a PERT chart for the project showing
worst case, best-case, and most likely case schedules, based on risk.

This subject is a special one, focusing on building your skills to use the PERT chart tools in
Microsoft Project or equivalent project management software to identify and weigh worst, best,
and most likely cases, and to write notes that will assist in project reviews and communicate
risks through the software.

78 | P a g e
We are not expecting you to be experts in the PERT charts, just to know how they are used. If
you are going to be a project manager dealing with risks in a project, you will have to know the
basics of project management scheduling and PERT analysis.

Risk scheduling. Project schedules serve several purposes:

1. Schedules provide a transition from project definition, such as the WBS, to time and cost, and
to interdependency. That is, schedules pin down actual tasks, durations, start and finish dates,
and resource assignments, and most importantly, linkages between tasks. You manage from a
schedule, not a WBS.

2. Schedules enable a project manager to lay out the total project impact of a given risk scenario,
that is, given a number of complex tasks and interdependencies (links), creating different
durations and resource mixes for selected tasks which involve risk gives the project manager a
way to measure schedule impacts.

This is why we have you identify three scenarios using the PERT tool in Microsoft Project,
pessimistic, optimistic, and expected, for the five greatest risks in your project. This process
helps you see the usefulness of having three schedules with different milestone dates and seeing
that when you assume an optimistic scenario you may have scheduled a given resource to do the
work, but in the pessimistic scenario that resource is no longer available! Now you find that the
worst case impact of one risk has created other risks because it has pushed the schedule into a
window where the original schedule assumptions will not work.

A Note on Microsoft Project PERT and Risk Matrix Terminology

Microsoft Project uses the terms pessimistic, expected, and optimistic. Expected usually means
the duration you originally estimated without concern for risk, although it may not. Optimistic
means the risk and impact are low and you think you might be able to "beat" the expected.
Pessimistic means that the risk and impacts are high and you don't think you will be able to
"make" the expected duration.

In the risk matrix you use the terms high, medium, and low for risk rankings. In general, high is
over 60 percent probability and high severity; medium is less than 50 percent probability and
moderate severity; and low is less than 10 percent probability and low impact.

79 | P a g e
Table 4.3 compares the terms from your risk matrix and your PERT analysis.

TABLE 4.3 Comparison of Risk Matrix and PERT Analysis

Risk ranking in risk High (risk severity Medium (risk is Low (risk is low and
matrix is high and the moderate and impact low even if
probability that it impact not so it occurs)
will happen is high severe

Microsoft Project Pessimistic Expected (original Optimistic (duration

terminology (duration reflects estimate of reflects low risk
concern based on duration without and therefore
the probability that considering risk. "hope"' that the
risk will occur and unless there is a risks can be
will have major reason to change it) controlled by
adverse impacts contingency plans
and slip the and the task can be
schedule) completed quicker
than expected

Risk Response

We will focus on risk response, monitoring, and communication. Here is where we get to the
"meat" of the project risk management process-the planned and scheduled action that a project
manager takes to deal with project risks, the review and monitoring of changes in risks and risk
management effectiveness, and the communication and interchange between key project
participants on risk issues.

By now, you should have a good grasp of what project risk assessment is all about. "So what?"
you say. Well, now we will answer the question, "Once I know what my risks are going to be
and what impacts they may have, what do I do about it?"

There are four parts of the response process- response, monitor; review, and communicate.

1. Response. Response involves developing a risk management plan to address the risks
identified and rank ordered in the project plan. Response means control, e.g., assuring that there
is a contingency plan for each risk that might be triggered by a change in a key indicator, such as
meeting an intermediate milestone in the design of a piece of equipment. This is the key part of
project risk management-the development of a risk management plan that provides you a
prepared response to anticipated risks, tailored to that risk and its impacts. This is why we have
you develop a risk management plan as part of the course.

2. Monitor. Monitoring involves identifying indicators that "flag" that a given risk may be
occurring and that the probability of a given risk has changed. For instance, if the risk involves a
technology performance issue (a given piece of equipment must perform to a standard) then the
earliest indicator that the equipment is not performing should be identified through a monitoring
process. In this case, an engineer or contractor is requested to submit a report on a preliminary

80 | P a g e
"test run" of the equipment, early enough to head off a major disaster when the equipment fails
in use.

3. Review. The project review process involves establishing an agenda and process for regular
reviews. The agenda reflects risks and requires that each review meeting specifically address the
risks inherent in a project.

4. Communicate. Communicating risks to the right parties improves the capacity to respond to
risks and also offsets the tendency to have an isolated view of risk within the team.
Communication involves reporting the results of risk assessment, the risk management plan, and
monitoring and review results to key stakeholders including:
a. Customer
b. Investors
c. Management
d. Project team
c. Contractors

Risk response, monitoring, and communication are integral to the process, not a separate activity.
In the real world of project management, the response to risk is played out in a series of day-to-
day decisions as developments unfold, guided by the risk management plan. Risk response is
really a state of readiness, a focus that the project manager has on certain aspects of the project.
The focus changes over the course of the project because key risks come in and out of focus. The
purpose of risk management planning is to narrow down the critical "things" to keep your eye on
and manage during the life cycle of the project.

Risk response factors

The capacity to respond to risk is heavily dependent on the quality of planning and control in the
project cycle. Risks that have not been anticipated and contingencies that have not been
integrated into the schedule will be difficult to respond to, regardless of intent. This means that
risk response must be timely and embedded into the planning process, beginning with the WBS
and schedule. There are several factors that weigh heavily on the success of risk response.

Earned value. Cost and schedule variance are keg inputs to risk response, particularly root
causes. The root causes of' schedule slippage and cost escalation are typically related to
underlying risks that could and should have beer1 addressed in the up-front planning process
starting with the WBS. Risk planning should uncover potential root causes before the final
baseline schedule is completed. Earned value can be seen as an indicator that a risk has not been
attended to; a late wake-up call that is often difficult to address.

Risk intensity. Despite quantitative tools for calculating probabilities and intensities, there is
considerable personal and professional judgment involved in aligning a risk response with the
intensity and impact of that risk. In the end, a project manager must make the decision on the
expected value of' a given decision at a key project milestone or crossroad. Intensity is best

81 | P a g e
dimensioned by those closest to the point of impact (e.g., customers, project team members,
functional and technical professionals), so the most accurate source for evaluating intensity is to
tap the judgment of the key stakeholders.

People. As we have pointed out earlier, risk management is essentially a people issue, not a
technical or analytic issue. Project managers must depend on the awareness and judgment of
those closest to the work to assess and respond to risk. The key is placing responsibility for risk
identification and response in the hands of those planning and designing the work early enough
to incorporate all worst case scenarios. Key stakeholders will respond to a culture that
encourages and enables early contingency planning by anticipating risks and integrating them
into project schedules and budgets. In the absence of such a culture, the organization can quickly
deteriorate into finger pointing when unanticipated risks impact a project schedule or budget.

Technology. Technology creates risk simply because projects often involve designing and
testing new technologies or integrating new systems. New systems and products are by definition
risky and involve key decision points based on risk. But these risks should be addressed in the
design and testing process itself. In other words, technology risk is integrated into every step of
the design process. For instance, in the development of a new electronic instrument, the project
team faces the risk that the instrument will fail in tough industrial applications. That risk is
translated into a design function to test the instrument in those conditions, thus responding to the
risk at the point of design.

Customer. The customer is a major factor in responding to risk since it is the customer who will
likely foot the bill for response and pay the price for unanticipated risk impacts. Thus the
customer must be Involved in every step, from concept through prototyping and production. The
most practical approach here is to report to the customer on the risks in a project specifically in
terms of customer expectations. That involves understanding customer expectations and
reporting on progress against those expectations regularly.

Processes. Often, a key process will determine how a risk is addressed and how risk response is
managed. For instance, if prototyping is built into a system's development process, the risk of
customer rejection of the product can be offset early. It is in defining the process that key risks
and responses are designed into the way work is done.

Cost/Benefit. Two kinds of costs occur in risk management-the costs of responding to

unanticipated impacts of risk and the costs of planning and addressing risk proactively as part of
the process. It is not the cost of risk response that determines next steps as much as the
relationship between costs and benefits, and the timing of the response. "Pay me now or pay me
later," might well be the guiding principle. The cost of a given product test in the design process
is likely to be much lower than the cost of responding to a product failure on a performance
standard that was not tested in design.

Corrective action. Despite the best-laid plans and schedules, project management is largely a
process of midstream adjustments and corrections based on the actual dynamics of a project in
progress. That means that close monitoring of key project indicators is key to real-time response

82 | P a g e
to actual progress. Corrective action, the process of continually bringing a project into line with
its performance objectives, and aiming the process to completion, is facilitated by contingency
plans already built into the schedule in anticipation of risks and uncertainties. Without such
plans, corrective actions are often ill conceived in the heat of the crisis and often generate
counterintuitive results. What is expected as a result of a given action not only does not happen,
but other things happen in the project as a result, which create new problems.

4.9 Summary
Dear learners, this chapter dealt with the task of discussing the several inputs, techniques and
tools associated with risk management planning. This task plays a pivotal role in our project risk
management efforts. In addition the proper understanding of potential risk management phases
will be accompanied by a prudent risk management system. The quality behind excellent
planning and control in the project cycle firmly determines the capacity to respond to risky
scenarios. Hence, risk response must be timely and incorporated in the planning scheme starting
with the WBS and schedule. Risk intensity, technology, customer and process are some among
the several factors that determine the success of risk response.

83 | P a g e
 CHAPTER 5

SYSTEMATIC RISK MANAGEMENT

OBJECTIVE:
 To enable learners understand the basic features and elements of systematic risk
management.

Content:
Introduction

Systematic Risk Management

5.1 Introduction

5.2 Stakeholder risks-Not project risks

5.3 Features of systematic risk management

5.4 Risk Management system

5.5 Establishing the risk context

5.6 Risk identification

5.7 Summary

Dear learners, this chapter entirely deals with the processes of systematic risk management,
commencing with arguments for the proposition that project risks are more correctly
perceived as the risks of the stakeholders involved in a project.

Hence at the end of this unit, you are expected to:

 Identify and interpret the systematic risk management system.

 Understand the basic features of systematic risk management system.

84 | P a g e
5.1 INTRODUCTION
For the great majority of project stakeholders, risk is too important to their continuing survival
and success to be ignored or dealt with haphazardly. Modern society's expectations of corporate
behavior and public accountability demand that organisations give due regard to the risks they
face (or which they create for others). Accountability has become a critical facet of the ways in
which organisations operate in the modern world.

Given this trend, and the increasingly complex and risky nature of many projects as discussed in
earlier chapters, recognition of the need to adopt and maintain a systematic approach to project
risk management is inevitable, and permeates public and private sectors alike.

This chapter provides the essential turning point between theory and practice. It sets out the
processes of systematic risk management, commencing with arguments for the proposition that
project risks are more correctly perceived as the risks of the stakeholders involved in a project.
Justification for a systematic approach to risk management is given, along with an explanation of
its benefits and implications. The early stages and procedures for a typical risk management
system are then described in greater detail.

5.2 STAKEHOLDER RISKS - NOT PROJECT RISKS

It is convenient to refer to 'project risks' in any discussion or exploration of the myriad of things
that can happen with projects. Indeed, we have made such references throughout this module .
The brevity and familiarity of the term outweigh any lack of validity it might have, but it is
important that terminological convenience should not take place at the expense of achieving a
proper understanding of the ownership of risks and the responsibility for managing them.

In earlier chapters, the point was stressed that risk is a social construct, experienced and
understood by people. Projects, by definition, are impersonal undertakings and thus cannot
experience risk. Projects do not make decisions about the tasks, technologies, resources or
organization required for them. People make those decisions. The risks associated with projects
are therefore more properly those of the people (organisations) involved with those projects.
Nowadays it is customary to identify such people or organisations as project stakeholders.

Even if a project stakeholder is a large corporate entity, it still has a persona - indeed legally it
will be treated as such - and is thus capable of experiencing risk. Furthermore, since risk is
associated with project decision-making, it is the decision-makers within the stakeholder
organisation who will experience risk most directly, and who should be closely involved in
managing it.
Conceptually, therefore, it is incorrect to refer to 'project risks', and 'risky projects', unless in the
context of a specific project stakeholder.
What is a project risk for one stakeholder may not be so for another, and a project which one
stakeholder regards as risky may be completely straightforward and innocuous to others.
85 | P a g e
Some projects are undertaken wholly within an organisation. This 'in-house' perspective is
sometimes known as 'enterprise project management' (EPM). In EPM, projects may be
conceived, resourced and carried out by a single organisation utilising its own project
management expertise. Even with EPM however, it is rare for every project to be completed
wholly within the boundaries of the organisation. External suppliers, contractors and
subcontractors are frequently involved to some degree. In accordance with the proposition we
have argued, each external participant then becomes a stakeholder, responsible for managing the
risks to which it is exposed on the project.

Risk management is one of a number of organizational management processes that each

stakeholder may apply to its activities and thus to each project with which it is involved.

STAKEHOLDER ORGANISATION

Emanating from the multi-management processes, each stakeholder should devise risk
management sub-systems to bear upon the projects in which it is involved. While a sub-system
may be project specific, it should clearly lie within the framework of the broader risk
management system of the stakeholder.

A project may include multiple stakeholders, each needing to apply its own risk management
processes. Similarly, at least some of those stakeholders will be involved in multiple projects at
the same time. Their organisational risk management structures must obviously encompass this
situation. The nature and intricacies of this concept of multi-management processes are really
beyond the scope of this book, and are therefore not discussed further here.

Not all stakeholders maintain a consistent participation throughout every phase on every project
in which they are involved. According to the nature and demands of a project, some will
discontinue their involvement at various times during any of its procurement, operational or
disposal environment phases. Other stakeholders might replace them. During the procurement
phase of a construction project, for example, a specialist piling contractor commences on-site
work early in the construction process, perhaps preceded by an excavation contractor whose task
is to clear and level the site. When the piling work is completed, the specialist contractor leaves
the site (usually for good) and further excavation commences - but this time for the more
intricate digging of pits and trenches for footings and services. Formwork constructors, steelwork
fixers, concretors, plumbers and others follow, according to a pre-planned methodological
sequence of construction activities. Eventually the building begins to rise out of the ground,
gradually taking on more recognizable form and appearance. These 'ebbs and flows' of the
'actors' in the lives of projects are an important reminder of their dynamic nature. A stakeholder
risk management system should be equally dynamic. Indeed, there can be no such thing as a
static system of risk management - it would constitute a contradiction in terms of effective
management.
Another important point to note in all of this is the role of project managers. For many projects
separate person or organisation is appointed to manage the project on behalf of the key
stakeholder (owner, client, project proponent), often on a fee-for-service basis. It is important to
clarify risk management responsibilities in such situations. An independent consultant who is
86 | P a g e
providing project management services is clearly exposed to risks in his or her professional
capacity, and should therefore take steps to deal with them (in order to protect his or her own
interests). Inevitably, however, the relationship between client and project manager means that
the latter will also become involved in the client's risk management processes. Indeed, the
project manager may even be called upon to instigate a formal risk management system for the
client. Any such arrangements should be clearly explained in the service agreement, so that the
rights of each party, and the individual integrity of their risk management systems, can be
maintained.

This issue rarely arises in projects where the project management function is delivered through
EPM, since there is no legal separation of the parties and only one risk management system is
likely to be involved.

Beyond the procurement environment, a project may require further design input before its
operational life can commence. A hospital project, for example, may be built and ready for use,
but staffing, movable equipment, supplies and other operational factors have yet to be fully
planned and organised. Depending upon the nature of the project, the project manager could be
required to continue his or her project responsibilities throughout this period, and many of the
issues of project management risks will still be relevant. On the other hand, the distinctive inputs
of a project manager might no longer be required, and the client immediately assumes full
operational responsibility for the facility. New and different stakeholders then become involved
at various times during its operational life.

At some point in its life-cycle, the project might come to be regarded as an asset (or liability!) to
be liquidated, disposed of or terminated. This project disposal environment will attract yet more
stakeholders.

The argument behind all of this is that, throughout its life-cycle, a project itself does not (and
cannot) possess a unique risk management system. There is no equivalent of the 'owner's manual'
for a car, whereby one risk management system is capable of serving the interests of everyone
involved with a project over its whole life. Instead, each stakeholder - whatever and whenever
and for however long its involvement and participation in a project - must choose how to manage
the risks arising from that involvement.

This is the reality of all projects. For the purposes of this book, however, and in the interests of
brevity and simplifying understanding, discussion about project risks and their management will
be regarded as proceeding in the context of a hypothetical stakeholder whose interests lie in a
particular environment of a similarly hypothetical project. This is actually part of the topic of
system boundaries that we will necessarily have to return to later. First, however, it is important
to examine the essential features of a risk management system.

87 | P a g e
5.3 FEATURES OF SYSTEMATIC RISK MANAGEMENT

We all manage risk. As individuals we tend to do this intuitively most of the time, rarely
exercising a deliberately cognitive approach. While intuition might suffice for an individual
person (even for deciding to cross a road), it is hardly likely to be adequate for an organisation
seeking to achieve specific objectives in a project. As we have noted already, projects are
becoming increasingly complex; the rate of technological change has become more rapid;
expectations of accountability have become more demanding. It is more and more necessary to
cope with volatility and turbulence in almost every aspect of organizational activity. Status and
reputation have to be protected. National and international incidents have lead to greater
recognition of local and global vulnerability. All this has contributed to the development of a
broader conceptual view of risk among communities of all kinds, and to recognition that formal
procedures are required to deal with it.

Activity
Dear learners, what is your understanding of the term systematic risk management? What
are the benefits that can be aspired from systematic risk management?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___
We could adopt an ad hoc attitude to risks, examining and treating each one as we become
conscious of its existence and potential impact.
While this might be acceptable on a personal level, from an organizational perspective it is
unlikely to be sustainable in the long term.

A systematic approach to risk management increases the capacity of an organisation to handle

risks at all levels. It promotes internal transparency and common understanding of the business
activities of the organisation, and facilitates the establishment and growth of an
organisational culture of, and a commitment to, managing risks. Having a formal risk
management system in place simplifies the intra- and inter-organisational capture and transfer of
risk knowledge. It provides the means for assessing best practice and for benchmarking
management performance, and establishes a platform that permits the benefits of modern
information and communication technology to be exploited.

An effective risk management system delivers a number of benefits. Within a stakeholder

organisation, congruence between the organisation's objectives and the project objectives can be
confirmed, or any conflict between them identified. Trust and confidence between the levels of
management, and between management and operatives, is improved. Responsibilities are
clarified, and ownership of responsibility more willingly accepted. Potential problems are
exposed to a wider internal audience. The organisation's capacity to deal with new risks is
enhanced. More focused risk training is possible. Creative approaches to handling risks can be
88 | P a g e
encouraged and developed. The nature and scale of potential crises is better understood, allowing
better visualisation of more distant time horizons. Anticipation replaces surprise, and informed
thinking takes over from reliance on luck. Above all, a systematic approach to risk management
should encourage decision-making within an organisation that is more consistent, more
controlled and yet at the same time more flexible.

5.4 RISK MANAGEMENT SYSTEMS

A good risk management system (RMS) will allow an organisation to look forward to the future
for each project, while maintaining a convenient capacity for looking backwards to the wisdom
gathered from its previous project risk experiences. This might entail the adoption of a dual-
system approach. On the one hand would be dynamic, project- specific systems as the vehicles
for managing the risks of each project. On the other hand, there should also be an organizational
meta-system, containing a risk register structured as a repository of organisational knowledge of
project risks.

There should also be a third system in place. This would have an organisational - as distinct from
a project - macro-focus, in order to encompass the risks associated with the internal tasks,
technologies, and resources necessary to sustain the organisation itself as an ongoing concern,
i.e. to deal with the likelihood of events occurring which could adversely affect the continuing
life of the organisation. As noted earlier however, we will concentrate here upon project risks
and project RMSs.

At a project level, the RMS will comprise the means for identifying competing interests, and
employ techniques for weighing up inadequate information about the project. It will take note of
risks already allocated or risk treatments already in place. It will provide for the recording of
decisions for action, and the assignment of responsibilities. The systematic nature of the RMS
will be inherent in the definitive processes it incorporates, the approaches to data analysis it
employs, the treatment regimes it embraces, and the usefulness of the information and
knowledge that it captures.

Stages in risk management

The literature describes numerous process stages as essential to an effective RMS. Despite minor
disagreements on terminology, and occasional combinations or separations of some stages, there
is a large degree of agreement between nearly all authors about them. It is safe to say, therefore,
that in principle a good RMS for a project should comprise processes to:
 establish the appropriate risk context(s),
 identify the project risks the stakeholder organisation will face,
 analyse the identified risks,
 develop responses to those risks,
 monitor and control the risks during the project, and
 permit post-project capture of risk knowledge.

89 | P a g e
The RMS is a cyclical loop, to indicate a learning process that should be ongoing from one
project to another.

As an organisation engages in a new project, it accesses its repository system of risk knowledge:
the generic project risk register. Possible structures for this will be discussed later in this chapter.
The risk contexts for the project are established. A process of risk identification is undertaken,
and the identified risks are then analysed in greater detail. Once risks have been identified and
analysed, alternative risk treatments can be explored and decisions made about the preferred
response for each risk. Procedures for monitoring and controlling risks during the ongoing
progress of the project are put in place. Return loops to earlier RMS processes may be necessary
during the monitoring phase, as new risks are identified or as the circumstances of known risks
change. Eventually, the risk knowledge gained on the project is captured, transformed into a
suitable format and recorded in the organisational risk register. The whole cycle is then ready to
begin again on the next project.

Within this cycle, risk identification generally takes place as a single, congruent process - at least
in the initial part of the cycle – to identify as many risks as possible. Risk analysis and risk
response processes however, could also be undertaken separately, or jointly for each risk in turn.
This is because the exploration of alternative responses for a risk could require additional
analytical inputs. There are no firm rules or guidelines as to whether or not to keep the risk
analysis and risk response stages entirely separate. One point to bear in mind is that the risk
response stage finishes with clear decisions about risk treatments, and therefore requires the
participation of the appropriate decision-makers in the organisation. On the other hand, the
analysis of identified risks in greater detail is not necessarily the task of decision-makers. Indeed,
it is sometimes necessary to call on the help of risk analysis experts from outside the
organisation. In practice, therefore, risk analysis is usually done separately from at least the final
part of the risk response stage. The planning of risk monitoring and control procedures, and the
post-project capture of risk knowledge, are each usually implemented as separate stages of risk
management.

Given this overall view of a RMS, we can begin to examine each of the processes in more detail.
The project risk context and risk identification techniques are considered in this chapter. The
other processes are dealt with in following chapters.

5.5 ESTABLISHING THE RISK CONTEXT

Establishing the appropriate risk context is one of the keys to effective risk management. It helps
to delineate the boundaries of the RMS and provides an ideal trigger to risk identification.

In deciding upon the risk context (or contexts), a balance has to be struck between contexts that
are too wide, and those that are too narrowly focused. Contexts framed as 'ICT project to update
bank ATMs' or as 'New shopping centre in the High Street', for example, are almost certainly too
wide. 'Tightening holts with torque wrench', on the other hand, is likely to be too narrow.

90 | P a g e
Objectives

Clues for choosing risk contexts have already been provided in the earlier chapters. One
approach might be to start with the organisation's objectives for the project. Where multiple
objectives are sought, each of these should be examined in terms of the more detailed plans
established to achieve it. These will provide the basis for identifying risks that could threaten that
achievement. Also intrinsic to the notion of multiple objectives is a hierarchy of levels for
objectives. This is illustrated in figure 5.1.

Figure 5.1

From the perspective of a client stakeholder, most objectives at a procurement level relate to
time, cost and quality: the time required to get the project delivered ready for use; the cost of
getting it ready for use; and the quality needed to make it fit for use. At a functional, or
operational level, the client will have expectations about what the project should do - an ATM
project for a bank might be expected to deliver a 24-hour cash dispensing service to customers
with 95 per cent reliability, 99.95 per cent accuracy and 98 per cent security.
Beyond this level there may be strategic objectives sought for the project: what the stakeholder
wants to achieve with the project. For the banking client this might be gaining market dominance
in ATM penetration in a particular region. Not every stakeholder organization will have the same
91 | P a g e
objectives, nor even the same number of hierarchical levels of objectives, as other stakeholders
in the projects in which they are involved. This reinforces the proposition that risk management
systems are stakeholder, rather than project, specific.

Project environment

The appropriate project environment provides another contextual starting point. In terms of the
project life cycle, is the stakeholder organisation involved in the procurement environment, the
operational or disposal environments, or some combination of these? Each relevant environment
is then examined and broken down into the process stages or plans necessary to deliver it. Thus,
for the procurement environment for a proposed new hospital, these process stages might
include:
 confirmation of functional needs
 confirmation of funding capacity
 appointment of project manager
 preliminary budget establishment
 outline planning approvals
 site selection and acquisition
 preparation of requirements brief
 call for conceptual design proposals
 appointment of design team
 building design, detailed cost plans and tender documentation
 call for tenders
 tender adjudication and contract award
 contract administration
 occupation of completed facility.

Note that this assumes that the RMS is being implemented for the hospital client organisation,
and that the building procurement system adopted is of the traditional separated design- tender-
construction type. For other stakeholders, or with alternative procurement systems, these stages
would be different. Each stage then becomes an identifiable context for risk management. Note
too that the stages are not strictly sequential in a temporal sense: several could overlap, so that
combinations of stages might form more appropriate risk contexts.

Project elements and sub-elements

As an alternative approach to establishing the stages of each project environment, the breakdown
of any of the appropriate environments into its task, technology, resource and project
organisational elements and sub-elements, could provide a suitable contextual basis for risk
management. Careful control is needed with this approach, lest it is allowed to descend into a
morass of detail and the RMS becomes unmanageable.

92 | P a g e
What might have become evident in all of this is that, in principle, establishing the contexts for
risk management is largely a matter of tracking the decision points for a project. Logic confirms
this, since we have already stated that it is project decision-making which gives rise to risk.

When the risk context has been established, it is possible to proceed with the identification of
particular risks.

5.6 RISK IDENTIFICATION

A satisfactory process of risk identification is crucial to effective risk management, since
unidentified risks cannot be systematically managed. Yet they remain risks. It is therefore
worthwhile for any organization interested in implementing a RMS to spend time in considering
how best to undertake this process.

Essentially, risk identification sets out to answer the question: what could threaten the
satisfactory achievement of this objective, the completion of this task, the application of this
technology, the acquisition of this resource, or the performance of this organisation?
Or, to put it another way: what could happen to make this project decision a bad one?

Note that the emphasis here should be on the risk event, rather than its consequence: on cause
rather than effect. This is not to say that impact plays no part in risk identification. Many people
intuitively use it as a starting point in the process. Cost and time overruns, for example, are often
suggested initially as risks to projects, but a little thought will show that these are actually
consequences of prior risk events and the causal factors or situations must then be explored.

RMS boundaries

The event/consequence dilemma in risk management leads to the issue of system boundaries in
project RMS. Establishing system boundaries helps in distinguishing risks that are exogenous,
i.e. are derived from outside the system, from those that are endogenous, i.e. occurring within the
system itself. Both types will impact upon the project, but the organisation's capacity to manage
them will be affected.
Establishing appropriate contexts and determining the boundaries of its project risk management
system are important matters for each stakeholder to consider. This consideration, however,
should be made well before the stakeholder becomes involved in a project.
Ideally, it will have been part of the organisation's processes in building a risk management
system.

Given that a project stakeholder has established the risk management contexts, and is at least
aware of the system boundaries for its RMS, how should it proceed to identify the risks to which
it may be exposed?

Identification approach

93 | P a g e
All that we have said earlier in this chapter, about ownership of the RMS, should not be seen as
precluding a team approach among project stakeholders to the task of identifying (and assessing)
project risks. Eventually, of course, each risk must become the responsibility of the stakeholder
to whom it has been allocated, but a project team workshop can be a useful approach to
identifying and allocating risks.

Identification techniques

Several risk identification techniques exist. The ingredient common to virtually all of them is
brainstorming. Currently, no automated techniques of risk identification exist, at least for
projects. At relevant intervals in the risk identification process, the people involved should be
asked to respond to the question we raised earlier: what could happen in this particular context to
threaten a satisfactory outcome for this organisation on this project? The process is therefore
iterative to some extent.
Risk identification brainstorming could be used on its own in a completely unstructured manner,
but this would hardly accord with an organisation's desire to be systematic in its risk
management. In fact brainstorming is easier, and usually more successful, when it is guided in
some way, i.e. applied within more structured identification techniques. We can now look at
several of these.

CHECKLISTS

Checklists are often advocated as a technique to stimulate brainstorming in risk identification.

Where the lists are derived from a stakeholder's organisational project risk register (i.e. a
compendium of risk knowledge gleaned from previous projects), there is some merit in them.
However, they are rarely entirely sufficient for effective risk management since they are unlikely
to help in identifying new risks that have not previously been experienced. Lists also require
frequent updating in terms of relevance and currency, particularly where an organisation's
business processes have substantially changed over time.
Many of the lists prepared for other project purposes are less adequate for identifying risks.
Examples might include people lists; information needs lists; and lists of project milestones. Of
these, only the first has direct application as it relates to the organisation element of projects, but
it needs to be placed in a more coherent contextual framework.
As a somewhat crude analogy, shopping lists tell us little about the risks of shopping, since they
usually only indicate what we want to buy, and rarely explain where to buy, when to buy, how to
buy, how much to buy, what not to buy, or how to get everything home afterwards!
Lists therefore have limited usefulness in risk identification, unless they provide sufficient focus.

RISK SOURCE CATEGORIES

Risk source categorisation was suggested in earlier chapters as a way of classifying risks. This
alternative form of list can provide a more structured basis for brainstorming questions along the
lines: what risks of this type could arise on this project? However, while this ensures that each

94 | P a g e
type of risk is considered on each project, it does not mean that all risks within a particular risk
category will be identified.

DECISION POINTS

Since we noted in chapter 3 that risk arises from project decision making, tracking project
decision points should simplify the process of risk identification. To an extent this is true, but
only within a more highly organised framework of where, when, how, and about what the
decisions are made.

PROJECT ENVIRONMENTS AND ELEMENTS

Project environments on their own are insufficient for identifying project risks as their
perspective is usually too broad, particularly where a stakeholder is involved in only one of the
procurement, operational or disposal environments of a project.

Within each project environment, the task, technology, resource and organisation elements, and
more particularly their respective sub-elements, should provide an effective focus for risk
identification. These too may be in list format. The sub-elements within each element are
important for risk identification as they are capable of exposing the levels of differentiation and
interdependency associated with them. Furthermore, they point to the loci of decision-making
and the inherent uncertainties attached to many project decisions. Remember that decision-
making and uncertainty lie at the heart of risk.

Sub-element/risk source category matrices

Given the arguments presented so far, the two-dimensional project sub-element/risk source
category matrix mapping technique is probably one of the more effective approaches to
identifying project risks, especially if combined with an organisational project risk register. For
each sub-element in the left-hand column of the matrix, participants in the identification process
are asked to consider each risk source category and suggest (brainstorm) what risk events under
that category might be associated with that particular sub-element. Care must be taken with this
technique. The sub-element analysis must not become so extensive that participants are faced
with too much detail and lose confidence in ever finishing the risk identification process.

OTHER MATRIX APPROACHES

The element/sub-element project breakdown lends itself to other matrix approaches for
identifying risks. The row breakdown of elements and sub-elements is retained but, instead of
risk source categories as the horizontal column variables in the matrix, these could be replaced
by variables representing each of the people or departments associated with the project within the
organisation. Cell entries would then reflect which parts of the organisation are involved with
each element and sub-element; and what could threaten that involvement. Multiple entries across
each row would indicate the extent of intra-organisational communication necessary to deal with
those risks.

95 | P a g e
In a similar manner, the horizontal column variables could be used to reflect the different
external stakeholders in the project. This matrix would thus reflect identification of inter-
stakeholder risks.

The attractiveness of matrix forms of risk identification is that they are easy to prepare and lend
themselves to the use of structured brainstorming sessions for completing them.

HAZOPS

HAZOPS (hazard and operability studies) is a risk identification technique originally developed
for the process industries such as the petro-chemical industry. As such, it is particularly useful
for projects involving the delivery or operation of production and processing facilities. However,
this does not restrict the use of HAZOPS just to chemical engineering projects. Remember that
hospitals also adopt flow process approaches in designing their operational modes.

HAZOPS uses an interrogatory form of risk identification. Experts in the relevant field (usually
constituted as a panel) interrogate every part of the process design for the whole facility. Their
questions are framed according to the nature of the facility, the purpose of the components being
examined, and their expert knowledge of the processes involved.

While the HAZOPS technique can be adapted to provide a basis for risk identification in other
types of projects, it is best suited to flow processes that are relatively straightforward and linear
in nature. It identifies risks that are for the most part technical, and is therefore less suited to
situations that involve other types of risks. Operator error, for example, is often not easily
detectable through HAZOPS. Stakeholders in complex projects with high levels of
differentiation, and especially with high interdependencies and uncertainties, would probably
find the technique too time-consuming and expensive to apply. The task of framing the questions
would itself be a considerable undertaking.
HAZOPS also assumes that all (or almost all) of the detailed project design is already complete.
This makes it unsuitable for risk identification in the early stages of many projects.

It is appropriate to reflect that the HAZOPS technique could be used in other process-based areas
of stakeholder management, such as quality assurance (e.g. design checking) and health and
safety management.
FMECA

Like HAZOPS, the FMECA (failure mode and effects criticality analysis) technique was
developed for a particular industry, in this case manufacturing engineering. Companies in the
automotive industry adopt this approach largely because it is possible to apply FMECA
uniformly across a large number of subcontract component manufacturers and suppliers, and
require them to respond to parts failures in a standardised manner.

FMECA also needs inputs from experts, particularly in establishing the criteria for faults and
failure and setting component manufacturing tolerance standards. In applying the technique, it is
usual to list all the components in the relevant system, describing their required function.
96 | P a g e
All possible failure modes and their causes are then explored, particularly with respect to the
effects upon the rest of the system and the severity or criticality of these consequences.
Alternative corrective measures are considered.

The application of this technique actually extends beyond initial fault risk identification through
analysis and into the treatment plan, thus effectively creating a mini-RMS for every component
of the final manufactured product. The FMECA technique is also used for quality assurance.
As with HAZOPS, FMECA requires a complete product design to be in place in order to be
applied effectively, and so suffers the same disadvantages as HAZOPS as a generic risk
identification tool for project-based risk management. The emphasis on technical systems means
that the risk of human error may be overlooked. While differentiation complexity is dealt with,
interdependency is less adequately treated.

FAULT TREE ANALYSIS

Fault tree analysis (FTA) may be used as a risk identification technique or as a risk analysis tool.
It is used to deductively explore underlying causes for an event. When these rational causes have
been identified, the top event actually becomes a consequence of one or more of the lower
events. In project risk management, this approach often has the benefit of clearly demarcating the
project boundaries of the stakeholder organisation's RMS. The example shown in figure 6.5
indicates a top event as the risk of automatic loading doors failing to close properly for a vehicle
ferry. Logic is used to trace potential causes for such an incident. The dilemma is where to stop
the tracking process. Should 'blocked fuel lines' be attributed to the ingress of foreign objects
into the fuel system? Is the faulty wiring due to rodents eating the insulation from cables? Are
damaged or missing components the result of deliberate attack or theft? This is where setting the
RMS boundary is important, but this can only be done by each unique stakeholder organisation
in a project.

If the FTA risk identification approach in the example of figure 6.2 is being undertaken on behalf
of a shipyard subcontractor responsible for the loading door installation on a project involving
the construction of a new ferry vessel, then the fault tree as shown probably lies wholly within
that organisation's project boundaries. On the other hand, if risk identification is being done by a
shipping company planning the introduction of a new ferry service, then the top event is
probably the risk trigger event in the context of its operational procedures for the ferry. The
shipping company, as a key stakeholder in the ferry service project, is vitally concerned with the
consequences of this risk event (rather than its causes) and will place it at the boundary of the
organisation's project RMS.

In using FTA for risk analysis, probability expressions might be determined for each of the nodes
on the diagram, to represent the chance attributable to any of these events occurring.

EVENT TREES

97 | P a g e
Event tree analysis (ETA) adopts the opposite approach to FTA. Inductive logic is used to
explore the consequences of a trigger event. Figure 6.3 shows how this might occur for the
shipping company in the ferry loading door example.

Note how this approach explores the consequences of the risk event in an escalating manner,
with outcome exits at each level.

Figure 5.2 Fault tree risk identification technique

98 | P a g e
Figure 5.3 Event tree risk identification technique

These in turn might become the means of defining strategic risk severity levels for the
organisation. ETA techniques can be highly influential in strategic policy development within an
organisation. Probability assessments can also be incorporated into ETA at the risk analysis
stage.

99 | P a g e
SCENARIOS

Even where other techniques have already been used for risk identification on a project, it is
usually worthwhile completing the process with a scenario-testing approach. Ideally, this takes a
background of a particular historical or contemporary world view or event which has been the
catalyst for significant change. From this background, a hypothetical scenario is established. For
the chosen scenario, the question is posed: if there were to be a similar situation today (or if this
type of event were to happen during the project), how would our involvement in the project be
affected?

Examples of world scenario backgrounds might include the periods of economic depression in
the 1930s, the political lead-up to the Second World War (or the Korean or Vietnam wars), the
contemporary conflicts in the Middle East, the removal of the Berlin Wall, or the September
2001 destruction of the New York World Trade Center. Obviously many, many more scenarios
can be devised. Testing should not necessarily be limited to one scenario only. If time permits, a
risk identification workshop can gain benefit from looking at more, particularly if they are
framed to reflect different contexts.

For some projects, it might be more appropriate to replace world views or events with national or
even regional scenarios, such as the introduction of a new tax system, the devolution of central
government power, or the adoption of public/private partnerships for the delivery of public
services and facilities.

Part of the purpose of concluding a risk identification process with scenario-testing is to

encourage participants to break away from identification approaches that by now are likely to
have become too narrowly focused. In the early stages of the process, developing a narrow focus
is desirable, but it can become counterproductive if prolonged. After several hundred risks may
have been identified in an intensive manner, having a refreshment break and then finishing this
stage with a scenario technique gives people an intellectual stimulus that encourages them to
think even more creatively about risks.

Risk identification resource documents

The documents used to record or reflect the myriad of decisions made in projects form a useful
collective resource for risk identification.
Typical among these documents are work breakdown structures
(WBS), Gantt charts, activity networks, schedules, estimates, cost plans, detailed budgets, plans,
drawings, specifications, performance standards and contract agreement clauses.

Official reports (e.g. the findings of accident enquiries) may also be used in risk identification.
Their usefulness is usually limited to confirming the presence of particular types of risks, or the
circumstances that are likely to give rise to them.

Outcomes and risk statements

100 | P a g e
The outcome of the risk identification process should be a formal record of the risks that
participants have identified and are agreed upon as serious enough to warrant further
investigation and treatment. Some risks may already be considered too trivial, even before the
risk analysis stage, and there is little point in continuing to deal with them in the RMS, although
it may be possible to gather several together and treat them as a group. The real benefit that will
have been gained for the organisation through its risk identification is the assurance that the
process has been effective; that either new risks have been identified, or known risks confirmed.

However thorough the process, it is unlikely that every project risk will have been identified at
this stage, especially by an organization unfamiliar with formal approaches to risk management.
The inclusion of risk monitoring and control processes in the RMS cycle acts as a further
precautionary measure against overlooking serious risks.

Identified risks should be recorded as formal, precise statements of likelihood, event,

consequence and time. The greater the precision of each of these statements, the more
straightforward and thorough the subsequent risk analysis process can be, and the easier it is to
detect event/consequence contradictions or anomalies. Single word risk statements should be
avoided. Their potential for inducing misunderstanding is so great that they constitute a
substantial risk for the organisation themselves.

Typically, a complete risk statement will take the form:

There is a "p" chance that "w" event will occur during "x" period, with consequences "Y1" to
"Yn" over the "z" period.

The most important variable to be stated is the event 'w', since the subsequent process of risk
analysis will force attention to be given to the other variables. If the risk statement includes them,
however, this will ensure that no risk variable is overlooked during the analysis.

An example of a risk identification statement for a construction project might be:

There is a chance that exceptionally wet weather will occur during the foundation
excavation work, with the consequence that excavations will be flooded, progress will
be delayed, and extra rectification costs will be incurred.

Note how the progress delay and extra costs are correctly stated as the consequences, or impacts,
of the natural weather risk. Note too that none of the risk statement variables are expressed as
quantitative amounts. This is the work of the risk analysis stage.

5.7 SUMMARY
This chapter has presented the broad framework for a stakeholder-based project risk management
system. It has been argued that project risks are really the risks of a particular stakeholder
involved in a project, and that a single project-based RMS applicable to all stakeholders is not
feasible, since different stakeholders will seek to fulfill different objectives, and will be engaged
101 | P a g e
in different risk contexts, even for the same project. Each project stakeholder therefore needs to
implement its own individual organisational RMS.

The procedural stages in risk management comprise risk identification, analysis, response,
monitoring 'and controlling during the progress of a project, and the subsequent capture of risk
related knowledge.

It is important to ensure that the appropriate context for risk management is understood clearly
by everyone who is participating in the risk management process for an organisation on a
particular project. In a similar way, risk management is informed by the objectives of the project
and the objectives of the participating stakeholder. All these provide the essential guide to
establishing the framework necessary to deal with the risks of specific projects and allow the risk
management team to proceed with the exploratory stage of risk identification. Brainstorming is
an inevitable ingredient of the many techniques available for identifying risks, and this is best
undertaken in a risk workshop environment. Once risks have been identified, they can be
analysed in greater detail.

102 | P a g e
 CHAPTER 6

RISK ANALYSIS
OBJECTIVE:
 To enable learners master the concept of risk analysis.
 To enable learners pursue further with an advanced systematic risk management
approach.
Content:
Risk analysis

6.1 Introduction

6.2 Risk allocation

6.3 A three dimensional risk magnitude perspective

6.4 Other assessment techniques

6.5 Risk ranking

6.6 Summary

Dear learners, this chapter is the continual of the previously seen chapter that dealt with
systematic risk management. Systematic risk management relies on proper risk analysis
pursued.

Hence at the end of this unit, you are expected to:

 Understand the concept of risk allocation..

 Understand and appreciate the various risk assessment techniques.

103 | P a g e
6.1 INTRODUCTION
This chapter continues the exploration of systematic risk management, taking up from the
identification of risks discussed in the previous chapter. The risk statements that are the outcome
of the risk identification process form the input to the risk analysis stage of the RMS cycle. Risk
analysis is an evaluative process that serves the purpose of establishing some understanding of
the magnitude of the risks faced by an organisation in undertaking a project. The analytical
process decomposes each risk into its constituent components and subjects them to some form of
assessment. While the risk analysis stage itself is often lengthy, it is not always necessary for the
risk assessments to be exhaustively exact in terms of mathematical accuracy. Indeed, accuracy
criteria would be difficult to define in terms of many of the risk factors relating to projects. The
financial performance of an investment project, such as a proposed shopping centre, for example,
can rarely be forecast accurately (and perhaps more importantly, reliably) to within two or three
percentage points in early stage modeling of internal rates of return for the project.

The nature of many projects also militates against high levels of accuracy in risk analysis
assessments, since the input data are rarely derived from large sample statistics such as those
used in the insurance industry or in large-scale manufacturing. For the most part, project data are
collected from case-based small samples and gathered in unique situations. This also
distinguishes them from data from repeatable experiments conducted under controlled laboratory
conditions. However, what such case-based project data may lack in statistical adequacy is often
made up by their capacity to generate information that is rich in content.

Appropriate risk analysis allows an organization to gain an understanding of the relative severity
of its risks on a project. In turn, this permits a strategic approach to managing them.

6.2 RISK ALLOCATION

Before embarking on the risk analysis process, a stakeholder organization should investigate
what prior risk allocation arrangements already exist for the project. There is little point in
analyzing a risk further if it has already been allocated to another party through a mechanism
such as a special clause in a contract agreement. For example, a subcontractor normally used to
submitting tenders on a fixed price basis would usually identify the chance of high economic
inflation as a risk factor on a long-term project. However, if the head contract included clauses
agreeing to share cost fluctuations between client and main contractor, with flow-on provisions
for subcontractors, this would mean that the consequences of the inflation risk would be borne
partly by the subcontractor and partly by the main contractor, who in turn would share the
increased cost with the client. The contract agreement has effectively allocated the risk on a
shared basis, and the subcontractor would need to reflect this in his assessment of the inflation
risk.
In theory, of course, any risk should be allocated to the party best able to control it. Practice,
however, especially in the guise of contracts, has a habit of mocking theory!

104 | P a g e
6.3 A THREE-DIMENSIONAL RISK MAGNITUDE PERSPECTIVE
Armed with knowledge of the prevailing risk allocation mechanisms of the project, the
stakeholder can proceed to assess the likelihood of occurrence (chance or probability),
consequence (impact), and time (duration) aspects of the risks that have been identified.
Together these provide an important three-dimensional perspective of risk, as illustrated in figure
6.1, giving more substance to the concept of risk itself.

Figure 6.1

Before considering each of these components of risk, the matter of uncertainty must be addressed
once again, since uncertainty states can affect any or all of them.

Dealing with uncertainty

Risk analysis inevitably involves making estimates of variables that may lie far ahead in the
future. Because the future cannot be known with certainty, uncertainty enters the scene. There
will be uncertainty associated with the values of nearly all of the input variables from which the
estimates are derived. Anyone of a range of values might actually occur for a variable. Returning
yet again to uncertainty in this chapter serves to emphasis its pervasive presence in projects.

Uncertainty is not necessarily confined to the values of input variables in an estimate. If the
estimating technique is based upon some form of mathematical model, there may be uncertainty
associated with the model itself. The model may not perform consistently under different

105 | P a g e
conditions, nor with different ranges of input variable values. Thus, uncertainty of variable input
values, plus model uncertainty, equals inherent variability in output values.

It should be possible to deal with model uncertainty by calibration, i.e. measuring the
performance of the model over the whole range of possible conditions and comparing this with
the real outcomes of what the model is trying to represent. The deviations from reality can then
be translated into measures of confidence in the model. For example, it might be possible to
describe a simple area/cost model for a particular type and configuration of building (i.e. a model
which calculates the estimated construction cost for a proposed building by multiplying the total
floor area by a price rate per m2) as having a 95 per cent confidence level that the calculated cost
will be accurate to within ±25 per cent of the real cost determined after the building has been
built (assuming that the costs of any post-estimate change in project scope or quality are
excluded from the post-completion cost calculation).

Several techniques exist for the treatment of uncertainty in the input values for risk analysis
models. The principle that applies is that any method must be appropriate to the modeling
context and logically defensible.

Quantitative approaches to treating uncertainty generally use mathematically based analyses of

statistical data, and may involve simulation. At a simple level, the analysis might comprise
sensitivity testing of the critical variable values: changing the value of one variable by one
incremental step at a time and observing the effect on the outcome. The limitation of sensitivity
testing is that it is not suitable for exploring the effect of multiple changes in several variables at
the same time.

At a more sophisticated level, Monte Carlo simulation may be appropriate. It is worth noting that
several computer software packages for Monte Carlo simulation are commercially available,
either as independent software applications in their own right or as add-on modules for popular
spreadsheet and project scheduling software.

The main criteria for using quantitative approaches for treating uncertainty in risk analysis are
adequacy and sufficiency of variable input data, cost of data collection and cost of assessment. If
the data are suitable and readily available, and if the assessment process is quick and
straightforward, then quantitative approaches are preferable as they are objective. If sufficient
data cannot be obtained, or if the cost/benefit ratio of collecting data or processing it is too high
(and this may include techniques such as obtaining the consensus judgment of experts using
Delphi methods), then qualitative approaches may have to be used. Earlier in this book it was
noted that, in much of project risk analysis work, qualitative analysis is sufficient, since often the
main purpose of the analysis is simply to gain an understanding of the relative severity of the
risks that the stakeholder organisation faces in its involvement in the project.

In exploring the assessment of each of the components of risk, we will consider the necessary
basis for each type of assessment and then present a qualitative model to represent it.

106 | P a g e
Qualitative assessment is subjective because it relies largely on human judgment. That judgment
will be influenced by experience and by personal biases. Errors in human judgment include
errors arising from biases such as:

 anchoring (wrongly sticking with a first estimate even though it is inappropriate)

 selective recall (remembering only certain facts or incidents)
 base rate fallacies
 over-pessimism
 over-optimism
 over-confidence in the assessment
 inappropriate search for patterns in data
 inappropriate framing of the situation.

The advantage of subjective assessment is that it is generally quick to apply and simple to
understand. The disadvantage is that errors in judgment are often difficult to detect and eradicate.
Because this is happening in human decision-making, the fields of decision science and
behavioural psychology have much to offer in terms of addressing the problems of human
judgment, and you are recommended to further reading in these areas. Reluctantly, they have to
remain beyond the scope of this book.

Assessing the likelihood of occurrence

Probability, expected frequency, chance, and likelihood are used synonymously for this
component of risk. The mathematical probability that a risk event will occur is expressed either
as a percentage or as a decimal fraction greater than a(event certainly cannot occur) and less than
1 (event certainly will occur). The expression is really a contraction of a ratio relationship, so a 1
per cent (or 0.01) chance that a risk event will occur is really stating that there is one chance out
of every 100 possible occasions that it will happen. There is a converse to the relationship, of
course. If we believe that there is a 1 per cent probability of something happening, we must also
believe that there is a 99 per cent probability of it not happening. This tells us that, for a finite
number of possible and mutually exclusive alternatives for an event, the sum of the probability
for each must equal 100 per cent (or 1). Thus, if the weather forecast indicates a 25 per cent
chance of light rain showers over the next 24 hours, with a 5 per cent chance of heavy rain, then
there must be a 70 per cent chance that no rain will occur during that period (assuming that light
rain, heavy rain and no rain are the only possible and mutually exclusive alternatives).

The latter example brings in the issue of exposure period, since technically the likelihood of
occurrence of an event must relate to some dimension of time. In some fields there is no problem
about this. In surgery, for example, it might be stated that the 5-year survival rate for males
between 50 and 55 years of age who have had prostate cancer surgery is 78 per cent (note how
specific the context is here, and how the medical profession has used the optimistic converse: the
death rate is 22 per cent). Other fields also use specific contexts and explicit periods: e.g. number
of road accident deaths annually per 100 000 of population. Because of the probability
convention used, in each example it is possible to make credible comparisons with another
relevant context, such as female breast surgery or deaths due to industrial accidents.
107 | P a g e
Projects do not really 'work' in the same way. Potentially each has multiple environments
(procurement, operation, and disposal); up to four elements (tasks, technologies, resources and
organisation); and usually a great number of differentiated and interdependent sub-elements.
The many hundreds of identifiable risks for a project stakeholder are therefore likely to exhibit a
great array of different exposure periods, and most of these may not be known precisely. This,
together with the difficulties of obtaining reliable probabilistic data, is why the assessment of
risks in project risk management tends to be undertaken using qualitative approaches. For the
most part, the 'time' aspect of risk event probability is either ignored, or treated implicitly as
equivalent to the project procurement period. Later in this chapter you will see that we have
chosen to give this issue more explicit treatment, although still qualitative to a large extent.

Activity
Dear learners, how do you rate/rank the chance of occurrence of risky scenarios?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___

A useful guide to making qualitative expressions of probability or likelihood is given in Table

6.1. This risk management standard offers a 5-interval scale of linguistic descriptors for the
likelihood of occurrence for a risk event, as shown in table 8.1. It is immediately apparent that
the scale is generic, as it does not relate to any specific project context. The table below is
generic and not uniquely project focused. Nor is the scale specific as to time.

Table 6.1 Interval descriptors for likelihood

One implication of offering a generic scale is that, before using a qualitative instrument such as
this, a stakeholder organisation must establish interpretations for the scale intervals that are
meaningful in terms of its involvement in, and objectives for, a project. For most projects there is
108 | P a g e
no point in all the stakeholders coming together and agreeing uniform meanings for each
interval- there will be too much disparity between the nature of their individual involvement and
the objectives each seeks to achieve.

A further implication that arises is that, where qualitative approaches to risk assessment have
been used, any communication about risk between stakeholders will be affected. If different
stakeholders maintain different interpretations of 'rare' or 'likely', for example, they are unlikely
to share completely congruent understanding.

On the other hand, it is desirable and practical for an organization to decide on uniform meanings
for its scale interval descriptors across the organization, which can then be applied to all the
projects it undertakes. Without such uniformity, an organizational risk register would lose much
of its usefulness.

Given an agreed scale, such as that in table 6.1, a stakeholder organization has the opportunity to
'score' its qualitative assessments of probability for identified project risks. The results can then
be incorporated into a risk severity model as shown later in this chapter.

Assessing the consequences

A risk event that occurs on a project must have consequences, since this is fundamental to the
definition of risk. From the 'dual' view of risk, these impacts may be positive or negative;
beneficial or adverse, but it must be remembered that, for the time being, risk events in this book
are presented as leading to negative consequences.

The consequences of a risk event will impact the project, but more importantly they impact the
stakeholder bearing that risk. Impacts from the same event may also be experienced by other
stakeholders in the project and, in some instances, by others beyond it.

For the purposes of assessing the consequences of a risk event, it is often assumed that the
impacts can be expressed in terms of cost to the risk bearer. Where quantitative assessment of
probability has been used, this assumption is even more strongly held, since it allows the
assessor to calculate a financial exposure to the risk, and thus a total financial exposure to all
risks. Thus if a risk event has a 5 per cent chance of occurring each year, and the estimated
consequence is $1000, then the risk bearer is said to be exposed to $50 of risk (0.05 X $1000 =
$50) and might wish to consider spending up to $50 a year to eliminate or avoid it.

One problem with this approach is that not all risk consequences are directly related to costs.
Among many others, the outcomes may lead to impaired reputation, vulnerability to legal
prosecution, loss of capacity, loss of staff, difficulty in recruiting staff, lowered resilience, etc.
Assessing monetary values for any of these, while it can be done (and is done by the courts, for
example), could be extremely difficult for an organisation unfamiliar with such a task. It would
almost certainly involve some degree of financial gymnastics.
For a qualitative approach, a 5-point interval descriptor scale for risk impacts in the risk
management standard is shown in table 6.2 as guidance. With this scale, the table has tried to
109 | P a g e
denote more specific contextual impacts by referring to 'containment' and 'toxic release', but
these should not be seen as limiting the applicability of the scale. It also refers to financial loss
and we have already noted the difficulties that can arise with assessment of this.

Table 6.2 Interval descriptors for risk impacts

As with the qualitative interval descriptor scale for likelihood, a stakeholder organisation must
assign interpretations to the scale intervals that are internally meaningful. For example, it may be
appropriate for the organisation to assess the impacts of risk events in terms of their capacity to
delay the project. Scale interval descriptors such as 'not greater than 2 hours; between 2 and 6
hours; 6-12 hours; 12-48 hours; and greater than 48 hours' might be appropriate for organisations
used to a very short-term involvement with projects, or for event-type projects with an extremely
short duration. Actual monetary amounts could be set against the scale intervals where this is
practicable, and in fact any scalable impact of risks borne by the organisation could be treated in
a similar way.

Care is needed in setting the interpretive levels. An organisation in the early stages of RMS
maturity will tend to score too many of its risk impacts too highly simply because it has not set
the bar high enough for the upper level descriptors. A 'catastrophic' impact descriptor, for
example, should be reserved for a risk impact that might completely destroy a company
financially and cause it to cease to exist. While none of the interval scales offered is intended to
convey absolute value meanings, and while the scales should therefore not be used to attempt to
calculate precise impact values, their purpose is to permit some meaningful comparison of the
relative severity of risks. The interval descriptor interpretations that an organization assigns to
the scales should therefore have some reasonable correspondence with reality for that
stakeholder.
The impact assessment 'score' for each identified risk may also be incorporated into a simple risk
severity model.

110 | P a g e
Assessing the duration of exposure
Earlier in this chapter we noted that, strictly speaking, the duration of exposure belongs to the
component of risk that relates to the likelihood of occurrence (the chance or probability) of the
risk event. It was suggested that, because of the nature of many projects, the risks that arise from
them do not readily fit this time perspective neatly, at least not for the purposes of assessment by
a project stakeholder. This is because the risk event may be framed by one time window and the
consequences by another. The risk event might occur in one project environment, but its impact
could be felt in another.

For example, in most projects there is a chance that poor quality workmanship could occur
during the procurement phase, but the consequences might not become evident until well into the
operational phase, or even not until the disposal phase. This drawing out of exposure time,
perhaps for as much as 30 years or more, is a complicating issue for risk management. It is
usually the reason why time is ignored in much of risk analysis except for discounted cash-flow
models for investment projects and some quantitative long-term health project studies.

While the time factor may complicate quantitative risk analysis, it can be addressed quite simply
in qualitative analysis. For convenience, a 5-point interval descriptor scale can be devised to suit
the characteristics of the project types most familiar to the stakeholder organization in its field of
operations. As before, each stakeholder must assign meaningful values to the scale interval
descriptors. The indicators described in table 6.3 are therefore only suggested interpretations and
should be tailored to suit individual circumstances. For some stakeholders dealing with particular
projects, long-term risk exposure durations might last no more than a few weeks. For other
stakeholders involved in different projects they could endure for many years. A stakeholder
might experience risk exposures spanning only the procurement environment; but another might
be vulnerable throughout the operational and disposal environments as well. The time value
assigned to each risk should include the period of exposure to the risk event and the period
during which the consequences might flow.
Table 6.3 Interval descriptors for risk duration (exposure time)

111 | P a g e
Armed with these qualitative approaches to assessing the likelihood of occurrence, impact and
duration of exposure for project risks, it is now possible to consider combining them into a
subjective risk severity assessment model.

Combining probability, impact and duration

Given the three-dimensional concept of risk presented by figure 8.1, and the rating scales
discussed above (tables 8.1, 8.2 and 8.3) for the probability, impact and exposure duration
components of risk, combining them into a simple risk severity model is quite straightforward.

Many approaches to qualitative risk analysis suggest two-dimensional models, using 3- or 5-

point interval scales for probability and impact only. Scoring each risk is simply matter of
multiplying the chosen probability rating for the risk by the chosen impact rating.
With maximum risk severity scores of 9, 15 or 25 (depending upon the scales used), the results
may be too coarse to allow more subtle distinctions between different risks. There will be too
many with identical scores. It would be possible to expand the rating scales to perhaps 9 or 11
point intervals, but this would pose a difficult linguistic problem in assigning realistic descriptor
labels to each interval, to reflect sufficiently finer shades of meaning. In any case, the main
drawback with two-dimensional scoring models is that they ignore the important dimension of
time. A three-dimensional risk severity model, based upon 5-point subjective rating scales for
probability, impact and duration, is shown in figure 6.2.

Figure 6.2

112 | P a g e
Using the model to assess a risk is simply a matter of assigning a value between 1 and 5 to each
of the three scales. This will produce a potential risk severity score ranging from 1 (1 X 1 X 1) to
125 (5 X 5 X 5). Theoretically, finer-grained scores could be obtained by assigning decimal
values to any scale (e.g. 0.75 probability X 1.5 impact X 3.25 duration = 3.65625), but in
practice this is unnecessary and integer values are sufficient. Injecting decimal precision into the
scale values is more often than not counter-productive in terms of the extra effort required, and
begins to defeat the objective of the assessment being done at this stage. The purpose of the
model is simply to establish some measure of comparative severity for the risks that a
stakeholder organisation faces in a project. It is not intended to produce absolute results. The
severity scores produced by the 5 X 5 X 5 model allow the organisation to confidently rank the
identified risks and hence to prioritise the treatment options and decisions for them. The most
severe risks will have to be revisited for further, more detailed analysis anyway, so there is little
point in prolonging the time needed for initial assessment by setting unnecessarily high precision
targets for the subjective scales of the model.

6.4 OTHER ASSESSMENT TECHNIOUES

Other risk analysis and assessment techniques are available which can be used either objectively
or subjectively, according to circumstances. Prominent among these are 'expected utility' and
'expected monetary value'.

Expected utility

Activity
Dear learners, what is your understanding of the term expected utility?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___

The expected utility (EU) assessment technique originates in decision science, and is simply the
product of probability and impact. This expression of risk was noted earlier when the assessment
of risk consequences was considered. EU assessment may be applicable when the direct and
indirect financial impacts of risk events are difficult (or even impossible) to estimate. 'Utility' in
this case is some measure of the loss of worth, or loss of usefulness, to the risk taker if the risk
event should happen. An example, using a decision tree approach, will help to demonstrate the
technique.

Example 8.1 uses a travel itinerary project as a scenario. From the market survey and time
performance data that the tour company has obtained, it is able to draw up a decision tree as
shown in figure 8.3. The decision nodes are shown as A (flying), B (bus) and C (train).

113 | P a g e
Since the probabilities of arrival on time at the destination town are known from the statistical
performance data the company has obtained, the chance of delay for each travel mode can be
determined (100 per cent - x per cent chance of timely arrival). The values in brackets at the end
of each paired branch, assigned to arrivals on time and to delays, were derived from the
responses to the carefully worded market survey questions as these could be translated into the
perceived worth of each outcome to the potential customers.

Example 6.1

114 | P a g e
Figure 6.3

The EU calculation for each travel option is shown in the small boxes on the right-hand side of
the diagram. The resulting EU value is the sum of the product of probability and utility for the
paired 'on time'/ 'delay' arrival condition states for each travel option. It represents the average
worth to the traveler for that option had the journey been made, and both condition states
experienced, on many occasions. Theoretically, the travel option yielding the highest utility
(flying: EU = 76) should be selected for the itinerary, as it represents the alternative with the
least risk of causing dissatisfaction to the tour company's customers.

Some of the difficulties associated with this technique are obvious.

Obtaining objective time performance data for the aircraft, buses and trains would probably be
the most straightforward task, but even that would not be simple. The data would be expensive
and time consuming to gather, and almost certainly some degree of data manipulation would be
required. The market survey instrument would be expensive to design and administer, and the
response data would have to be carefully processed and interpreted. Significance testing would
be necessary and the results of the model should be compared with those from other decision
making approaches to confirm the validity of the EU technique. More realistically, perhaps,
would one reasonably expect a tour company to make its project decisions in this way?

115 | P a g e
Expected monetary value

Expected monetary value (EMV) is simply a financial version of EU, and used in situations
where reasonably precise estimates of various possible financial outcomes can be made, as well
as the probabilities associated with their occurrence. Example 6.2 demonstrates this.

The organisation now has the data it needs to calculate an EMV for a projected loss in the first
year of trading if it purchases the franchise. Table 8.4 shows the detailed calculation. Note that
the available data reflect the situation for a $100 000 franchise purchase, while the micro-
business is considering an investment of $50 000. In the absence of any other information, it is
reasonable to make pro-rata adjustments to the data as shown, but the organization should be
aware that greater uncertainty will be associated with the adjusted data.

Example 6.2

Table 6.4 EMV calculation for first-year loss in gardening franchise

116 | P a g e
The EMV loss of $5775 in the first year of trading is what the organisation should realistically
plan for if it decides to purchase the franchise. If a more conservative business plan is preferred,
it could assume a $7500 loss.

As with the EU technique, there must be suitable data available and the user must have
confidence in their accuracy and reliability for the EMV to be considered as a practical objective
risk assessment tool. Otherwise, it is no better than any other subjective assessment technique.

6.5 RISK RANKING

Once identified risks have been analysed and scored in some way, they can be ranked in terms of
relative severity. This is a useful way of focusing the stakeholder organisation's attention on the
most serious risks it faces on a project.

While a straight ranking of risks according to their severity scores is useful, an organisation
could adopt a more strategic approach by aligning these scores to a set of predetermined risk
severity categories. A five-category list is shown in table 6.5.

Table 6.5 Interval descriptors for risk severity

Each stakeholder organisation should decide upon how to align its 125-point severity scale to the
five-category list, but it is important to caution that an equidistant interval alignment is not
117 | P a g e
advisable (i.e. assigning 'minimal' category to risks with scores between 1 and 25; 'low' risks
between 26 and 50, etc.).
Once risks have been ranked and prioritised, it is likely that the most severe risks will have to be
revisited for further analysis before major decisions about their treatment can be taken.
Eventually however, a response must be considered for each identified risk.

6.6 SUMMARY
While, by intention, this chapter has not dealt with highly mathematical and financial modeling
approaches to risk analysis (and each of these warrants a separate book in its own right), many
techniques of risk analysis have been presented, ranging from semi-quantitative to subjective and
linguistic assessment tools. The treatment of each of these has been brief rather than extensive.
In real life the risk analysis stage of formal risk management can be quite time consuming.
Each of the components of risk - the likelihood of occurrence of the risk event, the consequential
impact, and the duration of exposure
- must be considered carefully for every identified risk that the stakeholder organisation faces on
a project. In this assessment of risk severity, an organisation must select and use techniques
appropriate to its risk evaluation objectives.

Once risks have been sufficiently analysed, it is possible to make informed decisions for dealing
with them.

118 | P a g e
 CHAPTER 7

RISK MATRIX SAMPLES

OBJECTIVE:
 To enable learners understand the basic concepts risk and uncertainty under the
context of project management.
 To enable learners appreciate project risk management behavior.

Content:
Introduction

7.1 Steps in preparing a risk matrix

7.2 Summing up : Risk matrix examples

7.3 Summary

Introduction

Dear learners, this chapter tries to introduce you with the various forms and templates of risk
matrix analysis. This concept can further be explained through the procedures behind risk
matrix preparation.

Hence at the end of this unit, you are expected to:

 Understand the basic procedures as long as risk matrix preparation is concerned.

119 | P a g e
7.1STEPS IN PREPARING A RISK MATRIX

Activity
Dear learners assume that you are expected to perform risk analysis via the preparation of risk
matrix. List down the procedures that you are going to consider.

The steps behind risk matrix preparation can be summarized as follow.

Step 1: Identify tasks with risk. The overall project risk is the sum of the individual risks
associated with product development plus the risk associated with the market for the product. In
other words, the risks associated with producing the product to specification is different from the
risk associated with its market performance. Thus both risks must he incorporated into the risk
identification process. The first risk-the project market risk-is identified in business planning and
project selection for the company's portfolio. The second risk-the product performance risk-is
identified as the total impact of all the task risks associated with its design and production. It is
the second performance risk that is identified in this step, task by task. The way this is done
involves the work breakdown structure (WBS). Each level and task/component of the WBS is
reviewed and ranked in terms of potential risks and then all risks are racked up for the risk matrix
exercise. Some risks will disappear when intensities are dimensioned; others will be ranked high
and addressed with contingency planning.

Step 2: Describe risk. The description of the risk is a statement that covers what could go wrong
with the task. For instance, if the task is product design, the risk could well be the potential for
the design to be unworkable when it comes to prototyping and production. In other words, the
product cannot be reproduced.

Step 3: Determine impact. The impact of the risk is the change that would occur in key project
indicators when such a risk occurs. For instance, the impact of a design problem would be
delayed schedule, increased cost, loss of customer support, and the business risk associated with
a failed project.

120 | P a g e
 Figure 7.1 Steps in preparing a risk matrix

Step 4: Estimate chance/probability of risk event. The estimation of risk involves ranking a
risk in terms of 25, 50, or 75 percent chance of occurrence. Going further with quantification of
risk is usually ineffective for most projects because the margin of error in such calculations far
outweighs the benefits of going through the mathematics of probability. Project managers are
urged to rely on key stakeholder views of risk rankings and past history of similar projects.

Step 5: Rank risk by severity. Here the risk is ranked in terms of severity. Although a risk may
have a high level of probability, its severity may be minimal. Thus the cost of contingency is
low. On the other hand, a low-probability risk may have a very high severity, e.g., the chance
that a key, sole source supplier would go out of business may be low, but the impact would be
severe, were it to happen.

Step 6: ldentify root causes. Here is the analytic exercise that can actually help manage risks.
This involves identifying root causes of anticipated risks and incorporating response to root
causes in schedules and task definitions. For instance, if a design flaw is apt to be created by new
software then the root cause-the lack of good software suited to the design task-must be
addressed with a contingency.

Step 7: Prepare contingency plan. A contingency plan is a schedulable task that addresses the
likelihood that a linked task will not work. Such a plan is designed to correct an event or action
that delays the schedule or impacts the quality of the work. For instance, a contingency for a
failed software integration task might be the outsourcing of a parallel activity to complete
integration with outside resources.

121 | P a g e
Step 8: Estimate schedule impacts using MS Project software. Here the project manager
applies the theory of constraints. When a predictable resource or other bottleneck is identified in
the planning process, which is created by risk, the project manager identifies the worst case
(pessimistic) schedule impact using MS Project PER?' analysis and establishes a buffer schedule
for that contingency.

Step 9: Incorporate risk in schedules and establish buffers. The new pessimistic, risk-based
schedule is not baselined into the project, but a buffer of' time equal to the difference between the
"expected" and "pessimistic" durations is withheld by the project manager for later use. The
project manager will "dole out" these time buffers as needed and triggered by a risk event.

Step 10: Identify triggers for applying buffers. It is important to identify what events or
indicators will trigger a buffer action based on risk. Sometimes the project team will see
symptoms first and trigger action; sometimes the risk itself occurs and triggers a buffer.
Anticipating how decisions will be made helps to avoid last minute "crisis management" that
inevitably leads to further problems.

Here are some examples of risk matrices.

Note that the Risk Matrix in Table 7.1 addresses a systems development project. Note also that
the contingency plan for the "systems not compatible" risk is "testing the system by simulation
and in integration." This is a good example of a contingency action that would be placed directly
into the project baseline schedule. This way the contingency is embedded into the project
schedule to offset the potential risk.

7.2 SUMMING UP: RISK MATRIX EXAMPLES

These examples are illustrative of the application of the risk matrix tool to risk management. The
key point here is that each contingency action is not simply "noted." It is embedded into the
schedule as a normal task in the baseline schedule. A risk matrix is not designed to establish
another list of things to do; its purpose is to help plan and schedule the project so that all
contingencies are embedded into the project core.

122 | P a g e
TABLE 7.1 Sample Risk Matrix 1: Systems Development Project

TABLE 7.1 Sample Risk Matrix 1: Systems Development Project (Continued)

123 | P a g e
Table 7.2 shows a risk matrix on a hiring project .

TABLE 7.2 Sample Risk Matrix 2: Hiring Project

TABLE 7.2 Sample Risk Matrix 2: Hiring Project (Continued)

124 | P a g e
Note that this risk matrix covers a hiring process including a drug test. The task "supplies"
includes a contingency to check supplies every day to offset the risk of running out of supplies
for drug testing. Again, this contingency- would be added to the schedule--each day if necessary-
to ensure that drug supplies were available.

125 | P a g e
7.3 Summary
Risk matrix preparation is not a onetime activity rather composed of 10 fundamental phases. It
starts from WBS and interviews while culminating at the identification of triggers for applying
buffers. Several examples are given for the sake of explaining the concept behind risk matrix.

126 | P a g e
 CHAPTER 8

CUSTOMER-DRIVENPROJECT MANAGEMENT,
TQM, AND RISK

OBJECTIVE:
 To enable learners understand the basic concepts of customer driven project
management.
 To enable learners appreciate the value of customer driven risk management.

Content:
Introduction

8.1 Customer driven Risk management

8.2 Portfolio and program management

8.3 Value of customer- driven risk management

8.4 Summary

Introduction

Dear learners, the purpose of this chapter is to illustrate the importance of seeing risk from
the customer's perspective and recognizing that risk is inherently a customer and quality
issue as described in total quality management (TQM) concepts.

Hence at the end of this unit, you are expected to:

 Understand the basic concepts of customer driven project management.

 Appreciate the value of customer driven risk management.
 Understand the role of continuous process improvement in risk management.

127 | P a g e
8.1 CUSTOMER-DRIVEN RISK MANAGEMENT

A customer-driven project team is a team that responds to customers and manages customer
satisfaction as a regular team function. Risk management is an overall obligation of the
customer-driven project team. The teams continually assess risk at the project level and in each
task of the project-not only in terms of time and cost, but also in terms of the technical
feasibility. Again, the customer driven lead team establishes the system for risk management.
This risk management system influences the use of the other project management tools and
techniques.

No project is without risk. That is, the probability that a given process, task, subtask, work
package, or level of effort cannot be accomplished as planned. Risk is not a question of time; it is
often a question of feasibility. It pays in the development of the WBS to assign risk factors to
each element of the WBS, separate from the assignments of schedules and milestones for the
work. Risk factors can be assigned based on uncertainty, technological feasibility, availability of
resources, or competition. Later, the elements with high-risk factors are given close attention by
the project manager, whether or not they are on the critical path itself. Special attention is given
to customers, users, and clients.

One of the most effective ways to deal with risk is to develop customer-driven contingency
plans, or parallel courses of action-and changes in the WBS that come into play if the task cannot
be accomplished as the customer sees it. Contingency planning is based on "satisficing," as
Herbert Simon called it, rather than optimizing, and recognizes that in developmental projects,
some things turn out to be impossible dreams.

Customer-driven contingency plans are carried out by the project manager, based on the level of
risk assigned to a particular element of the WBS. When testing a new technique or approach, for
example, a manager might estimate a 15 percent chance of successfully completing Task 1 and
satisfying the user, because few new techniques work well the first time they are attempted.
Similarly, there may be only a 10 percent chance of successfully completing Task 2 because of
the organization's previous experience with a similar problem. Hence, there is only a 1.5 percent
probability of even reaching Task 3 if its performance depends upon successful completion of
the preceding tasks. Once Task 3 is completed, however, it may be implemented again and again,
depending on how many problems have to be solved.

Illustration of Risk Management-the Defense Risk Program

The U.S. Department of Defense (DoD) has for many years provided standard templates to
contractors for reducing risk in system development. The DoD uses templates directed at the
identification and establishment of critical engineering processes and their control methods. For
each of the critical engineering processes a critical path template is provided. The template
addresses the following areas for each critical engineering process:

 Area of risk

128 | P a g e
  Outline for reducing risk
 Timeline

TQM Template. TQM is defined as an organized process of continuous improvement by private

defense contractors and DoD activities aimed at developing, producing, and deploying superior
material and products. The primary risk in reaching and sustaining this superiority is failure to
manage with a purpose of constantly increasing intrinsic quality, economic value, and military
worth of defense systems and equipments. Note the focus on management first, not technical
risk. The armed forces and defense industrial entities may not attain a lasting competitive
military posture and long-term competitive business stature without a TQM at the highest levels.
TQM is applicable to all functions concerned with the acquisition of defense material, supplies,
facilities, and services. Being satisfied with suboptimum, short-term goals and objectives has
adverse impacts on cost, schedule, and force effectiveness.

A short-term approach leads to deterioration in the efficacy of specific products, the firms that
produce them, and the industrial base overall. A major risk is also entailed with the inability to
grasp and respond to the overriding importance attached to quality by the "customer" or user
activities.

DoD outline for reducing risk

 The organization has a "corporate level" policy statement attaching highest priority to the
principles of TQM. This policy statement defines TQM in terms relevant to the individual
enterprise or activity and its products or outputs.

 The corporate policy statement is supported by a TQM implementation plan that sets
enduring and long-range objectives, list, criteria for applying TQM to new and ongoing
programs, provides direction and guidance, and assigns responsibilities. Every employee
at each level plays a functional role in implementing the plan.

 All personnel are given training in TQM principles, practices, tools, and techniques.
Importance is placed on self- initiated TQM effort.

 The TQM effort begun in the conceptual phase of the acquisition cycle is vitally
concerned with establishing a rapport between the producer and the user or customer and
a recognition of the latter's stated performance requirements, mission profiles, system
characteristics, and environmental factors. Those statements are translated into
measurable design, manufacturing, and support parameters that are verified during
demonstration and validation. Early TQM activity is outlined in the Design Reference
Mission Profile template and Design Requirements template. The Trade Studies template
is used to identify potential characteristics, which would accelerate design maturity while
making the design more compatible with and less sensitive to variations in manufacturing
and operational conditions.

129 | P a g e
  Design phase TQM activity is described in the Design Process template. Key features
enumerated include: design integration of life cycle factors concerned with production,
operation, and support; availability of needed manufacturing technology; proof of
manufacturing process; formation of design and design review teams with various
functional area representation; and use of producibility engineering and planning to arrive
at and transit ion a producible design to the shop floor without degradation in quality and
performance. The Design Analysis template and Design Reviews template provide
guidance in identifying and reducing the risk entailed in controlling critical design
characteristics. Both hardware and software are emphasized (refer to the Software Design
template and Software Test template). A high-quality design includes features to enhance
conducting necessary test and inspection functions (refer to the Design for Testing
template). An integrated test plan of contractor development, qualification, and
production acceptance testing and a test and evaluation master plan (TEMP) covering
government-related testing are essential to TQM. The plans detail sufficient testing to
prove conclusively the design, its operational suitability, and its potential for required
growth and future utility. Test planning also makes efficient use of test articles, test
facilities, and other resources. Failure reporting, field feedback, and problem disposition
are vital mechanisms to obtaining a quality product.

 Manufacturing planning bears the same relationship to production success as test

planning bears to a successful test program (refer to the Manufacturing Plan template).
The overall acquisition strategy includes a manufacturing strategy and a transition plan
covering all production-related activities. Equal care and emphasis is placed on proof of
manufacture as well as on proving the design itself. The Quality Manufacturing template
highlights production planning, tooling, manufacturing methods, facilities, equipment,
and personnel. Extreme importance is attached to subcontractor and vendor selection and
qualification including flow down in the use of TQM principles. Special test equipment,
computer-aided manufacturing, and other advanced equipments and statistics-based
methods are used to quality and control the manufacturing process.

Timeline. TQM is used throughout the product life cycle. TQM-oriented defense contractors and
government activities concentrate on designing and building quality into their products at the
outset. Successful activities are not content with the status quo or acceptable level of quality
approach. These activities respond to problems affecting product quality by changing the design
and/or the process, not by increasing inspection levels. Reduction in variability of the detail
design and the manufacturing process is a central concept of TQM and is beneficial to lower cost
as well as higher quality. Defect prevention is viewed as key to defect control. Astute TQM
activities are constantly on the alert to identify and exploit new and proven managerial,
engineering, and manufacturing disciplines and associated techniques.

DoD manuals stress the following TQM principles:

 Total commitment to quality

 Continuous improvement
 Involvement of many functions
130 | P a g e
  Long-term improvement effort
 Customer focus

TQM principles include company action that:

 Produces a policy statement (vision/mission)

 Pursues a TQM environment
 Stresses a TQM implementation plan
 Fosters ownership
 Advocates training
 Includes quality as an element of design
 Encourages measurements
 Includes everything and everyone
 Nurtures supplier and customer relationships
 Encourages cooperation and teamwork

8.2 PORTFOLIO AND PROGRAM MANAGEMENT

Activity
Dear learners, try to identify the basic factors that may bring successful risk management
and end up in the right portfolio of projects.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___
DoD policy first articulated the importance of project selection and portfolio management in the
1980s and has refined the concept. The initial and most disruptive risk involved in program
management lies in the inability to choose the right portfolio of projects in the first place. Fit and
consistency with strategic plans, cash flow analysis, rate of return, company competency (Can
we make this product?), lack of business analysis on markets, technical feasibility, and legal risk
are key factors contributing to successful risk management.
 Fit with company strategy. Alignment with strategy is a key risk challenge because
projects that might otherwise be attractive might not be part of the company's plans for
growth and competence. The weighted scoring model is one tool for assuring "fit with
strategy," but the risk here is in the inability to measure whether, in fact, a candidate
project is going to help implement a company strategic goal.

 Cash flow. Since profitability and rate of return is key to company growth, a project must
be planned out over the long term to ensure net income growth. This means that
candidate projects must he "fleshed out." The risk here is that cash flows are

131 | P a g e
 misestimated and that key decisions and assumptions behind the decision are not made
explicit.

 Consistency with company competency. If the company does not have experience in a
given area. it does not matter whether the project is consistent with strategy and cash
flows are promising. Company capacity to perform is directly related to past experience
and capacity-"sticking to the knitting" is still a major principle of success and therefore a
useful risk management concept.

 Market analysis. If the market and future demand for a given project outcome or
product/service are not well researched, the risk is that an efficient project may meet
schedule, cost, and quality objectives, but produce a product which is not marketable.
Therefore the focus in risk planning must be in the adequacy of early business market
analysis and research.

 Technical feasibility. Since technical feasibility is key to new systems, if a project

involves new, unproven technology there is inherent risk in the project. Technical
feasibility can be offset by embedded risk measures as described earlier in the product
development process.

 Legal risk. Legal and regulatory risk is attributable to changing government regulations
and legal issues involved in liabilities for a given product. The risk here is that the
company fails to understand and anticipate legal and regulatory constraints on a product
or service.

8.3 VALUE OF CUSTOMER-DRIVEN RISK MANAGEMENT

Activity
Dear learners, try to discuss the several benefits that can be exploited from conducting
customer driven risk management system.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___
Customer-driven risk management captures the critical importance of seeing risk in the eyes of
the customer and client. A focus on customer risk can uncover uncertainties and risks in a project
that are not apparent in an internally focused risk management process. For instance, in
developing a software product, the customer focus may be grounded in compatibility or interface
of systems, while the internal, project-oriented focus for software development might well be in
conformance with performance requirements without much attention to interface issues.
Risks in customer expectation, needs, and requirements
132 | P a g e
Program and projects face customer risk in three areas and each challenges the risk management
process:

 Customer expectations
 Customer needs
 Customer requirements

Customer expectations. Sometimes customers expect more than they specify in written
specification documents. Expectations change from new information uncovered in the project
itself. The risk associated with customer expectations reflects the inherent value of projects
themselves; as products and service outcomes are produced and information is made available to
the customer that uncovers new opportunity, customers sometimes change their minds.

Customer needs. What the customer needs is not necessarily what the customer expects or
requires. Needs suggests analytic data on customer needs, an objective view of needs underlies
the project process, but needs are seldom differentiated from expectations and requirements.

Customer requirements. Requirements are the actual specifications for the product or service
outcome. Sometimes requirements are drawn up by project teams based on what is feasible
rather that what is required. The risk here is that the requirements document does not adequately
capture customer need.

Risks in customer and sponsor relationships

There are two basic risks inherent in the relationship with project customers and sponsors. They
are:

1. Losing the commitment and support of sponsors. Project sponsors can withdraw support from
a project for a variety of reasons unrelated to the project itself, e.g., financial issues, market
turns, changes in organizational leadership, mergers and acquisitions. The risk is that the project
manager will be surprised by such a withdrawal of support and have no contingency or
"workaround action to offset it. Again, it is the ability of the project manager to foresee factors
that might lead to loss of sponsor support that will lead to successful management of this risk.

2. Managing sponsor resistance to change. Sometimes a new product or service will produce
changes in a customer or sponsor organization that can be dysfunctional. Thus the risk is that the
project manager again is surprised by resistance in a sponsor or customer organization to the
very product or service the customer specified.

In both of these cases the lesson is this. Build and maintain a close relationship with your
customer and sponsor to help anticipate risks and issues for the customer before the customer
sees them.

133 | P a g e
8.4 Summary
As the major stakeholder and project sponsor, the customer/client pays the price at the end of a
project if risk is not well managed. In the context of the three legs of the total quality
management stool, risk is associated with: (1) customer expectations and satisfaction, (2)
empowering the project team, and (3) the effectiveness of continuous process improvement.

134 | P a g e
 CHAPTER 9

RISK DECISIONS AND ACTIONS

OBJECTIVE:
 To enable learners understand the basic concepts of risk response
 To enable learners appreciate the concept of risk disaster planning and recovery.
 To help learners experience the task of risk monitoring and control.

Content:
9.1 Introduction

9.2 Risk response options

9.3 Strategic risk response

9.4 Risk monitoring and control

9.5 Risk disaster planning and risk recovery

9.6 Post project risk evaluation and recording

9.7 Communicating risk messages

9.8 Summary

Dear learners, this chapter tries to highlight facts associated with risk response, risk
monitoring and control and risk recovery.

Hence at the end of this unit, you are expected to:

 Identify and interpret the terms and elements involved in the risk monitoring and
control.
 Understand the basic concepts of strategic risk response.
 Understand the methodology behind successful risk message communication.

135 | P a g e
9.1 INTRODUCTION
Up to this point, the exploratory and evaluative processes of formal systematic risk management
have been treated in a somewhat passive, abstract manner. Even in real-life projects, it is often
found that risk identification and risk analysis create a similar impression on people engaged in
these tasks: they feel distanced and separated from the risks themselves.

While the discussion in this chapter will continue to be dispassionate, real risk management
protagonists working for real stakeholder organizations on real projects are likely to experience
much more direct engagement at this stage of the risk management process. This is because the
time has come to make decisions about the risks facing the organization, to implement those
decisions and to take actions for monitoring and controlling their outcomes during the progress
of the project. The topics covered in this chapter therefore deal with risk response, risk
monitoring and control, risk recovery, and risk knowledge capture.

Activity
Dear learners, how do you response whenever you run across with a risky scenario?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___

9.2 RISK RESPONSE OPTIONS

There are four basic responses to risk: avoidance; transfer; reduce and retain residual; and retain.
The first option is exclusive, since if a risk is avoided it cannot be transferred, reduced or
retained. The remaining options, however, are frequently encountered in combination.

Risk avoidance

Avoiding a risk means deliberately taking another course of action so that it cannot arise in the
new circumstances for that project. Note that this is not the same as eliminating risk. In fact, risk
elimination is rarely possible: if it becomes necessary to revert to the former circumstances the
risk will return.

The ultimate form of risk avoidance is not to proceed with the project at all. However, this
extreme is seldom adopted as a response to one project risk factor in isolation. Such a decision is
usually arrived at after a number of issues have been considered and their overall influence on
the project assessed. An investment project opportunity, for example, is not rejected simply
because it exhibits a potential rate of return which is not commensurate with the investor's
criterion rate, but because improvements in performance cannot readily be achieved in the major
factors that contribute to the rate of return calculation. In exploring risk avoidance, a stakeholder

136 | P a g e
organisation should always keep in mind that this response might thereby increase the severity of
other risks, or result in lost opportunity. An example serves to illustrate this.
Assume that a construction project, such as a multi-storey residential building, has been designed
with basement parking. However, the site has a history of occasional flooding following periods
of exceptionally heavy rain. The risk is the chance that a heavy rain storm will flood the
basement, causing damage to the vehicles parked there and inconvenience to the residents. In this
case, a risk avoidance measure would be to redesign the building to omit the basement levels and
replace them with ground or above-ground level parking. The risk of the basement becoming
flooded is avoided since there is no longer a basement in the proposed building. Instead,
however, the risk of flooding at ground level is increased - although the impact of this might not
be as serious. Furthermore, the design change might alter the visual effect of the completed
building sufficiently to affect the selling or letting market opportunities for the residential units.
Finally, of course, the cost of making the design change (in terms of the construction costs, the
design costs, and any approval or delay costs incurred) have to be weighed against the potential
impact costs of the risk avoided.

Risk avoidance is rarely a straightforward or easy response measure. Because it is highly

effective in the right circumstances, however, it should always be considered first among the
possible options available to a stakeholder.

Activity
Dear learners, what kinds of merits and demerits can be aspired from Avoidance?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___

Risk transfer

In electing to transfer risk, a project organisation is seeking to shift the burden of a particular risk
to another stakeholder. This is a common response in project situations where stakeholder supply
chains or networks are easily distinguished, as attempts will be made to transfer risks
progressively along the supply chain or to the more distant extremities of the network. Typically,
a project client will transfer risks to a contractor, who in turn will transfer them to subcontractors
or suppliers.

The mechanisms used to transfer risks in such situations include, inter alia, head contract
agreement clauses, subcontracts and supplier agreements.

The principle of risk transfer forms the distinguishing characteristic between many alternative
forms of project procurement and delivery, such as joint ventures, public/private partnerships,

137 | P a g e
and the Private Finance Initiative in the United Kingdom. In the construction industry it is
noticeable in procurement systems such as design/build (D & B), design-build-finance-operate
(DBFO), build-own-operate (BOO), build-own-operate-transfer (BOOT) and many others.
Common to nearly all of these is the intention to transfer risk away from the client stakeholder
and towards the contractor organisation.

Insurance is a transfer mechanism for risks that are insurable: theft, injury, damage to property or
equipment. This introduces a third party risk transferee to the situation, thereby involving
another stakeholder in the project. Performance bonds, sureties and payment guarantees are used
in a similar way to deal with the impacts of the risk of default by parties in the execution of
project contracts and agreements. The risk transferees may be banks, finance companies or other
third parties.
Two things should be noted about risk transfer: it is usually costly; and it is rarely 100 per cent
effective.

Every risk transfer has a cost. This is usually reflected in the price the transferee charges for
accepting the risk - the premium payable to an insurance company, the fee set by a bonding
agent, or the commission charged by the bank. These are fairly obvious forms of direct costs of
risk transfer. More indirect costs occur when, for example, a risk is passed to a project
subcontractor who does not manage it effectively and is then affected by the impact of a risk
event. If the subcontractor organisation survives the risk impact, but cannot recoup its losses
from the main contractor, it will attempt to do so on other future projects. If the subcontractor
does not survive the risk impact, the losses are eventually borne by the players in the relevant
industry and finally by society itself.

Few risk transfer mechanisms completely discharge the transferor from all responsibility
associated with risks. Contemporary views of corporate ethics and social responsibility do not
allow organizations to absolve themselves completely from such risks simply by transferring
them to other parties. Transfer of liability for the consequences of risks events may be achieved,
but accountability often remains in some degree. On a personal level, one cannot insure
possessions against theft, neglect to take any precautions against theft occurring, and still expect
to receive full recompense from the insurer if something valuable is stolen. In a similar way, a
client stakeholder might transfer the risks of accident and injury involving project workers or
third parties to the project contractor. However, should a serious accident occur, the client
stakeholder will inevitably become involved in the resulting adverse media publicity, simply by
reason of its association with the project. A project sponsor might transfer the risk of
environmental damage to a contractor, but then find itself (even in other areas of its activities)
the target of unwelcome public protest demonstrations.

Risk reduction and residual retention

No risk should be avoided, transferred or retained without first checking to see if it is possible to
reduce it and then retain the residual risk.

138 | P a g e
For anyone with a professional interest in risk management, reducing risk is probably the most
absorbing area of involvement. The stakeholder is deliberately attempting to minimise risk in
some way. All dimensions of the risk should be examined, since it may be possible to reduce the
probability of occurrence, the impact consequences, or the duration of exposure to the risk.
Combinations of any two, or even all three, of these may be contemplated in some risk
circumstances. The nature of the risk will influence which of the risk factors can be mitigated,
and the context will influence the possible extent of mitigation. For natural risks, for example, it
is rarely possible to reduce the chance of occurrence (although planning a project to avoid
seasonal weather extremes is one approach).

The risk reduction process also allows the value of a risk classification system to be exploited.
Whenever a new project risk is encountered, it is possible that an effective treatment can be
found among more familiar risks (i.e. from the organisation's risk register) in the same category.

Inevitably, the process of exploring risk reduction requires a return to the analytical processes of
risk assessment. Care must be taken in doing this. There is a natural inclination to try to replace
earlier subjective qualitative assessments with techniques that are more quantitative. Provided
adequate and sufficiently reliable data are available or readily accessible, this is acceptable. If
better data are not available, then it is better to retain a qualitative approach since by now any
subjective judgments involved should be better informed about each risk.

Attempts by project stakeholder organisations to reduce the likelihood of occurrence (chance,

probability) of a risk event tend to focus upon implementing, or increasing the effectiveness of,
other management techniques for the project. These might include: more stringent safety
precautions (occupational health and safety management); more frequent financial audits
(financial management); more frequent stock checks (logistics and asset management); more
stringent or more frequent inspection of finished work (quality management); and regular or
advanced training for staff (human resource management). On a construction project site, for
example, the responsible safety officer might issue instructions for any temporary scaffolding to
the outside of the building to be fitted with additional horizontal intermediate rails at each floor
level, and with higher toe boards on the outside edge of the planked walkways. In doing so, he or
she is trying to minimise the chance that either a worker or an object will fall from the scaffold.
Both such incidents are among the most frequent causes of serious accidents in the construction
industry worldwide. Note that the safety officer is addressing only the likelihood of occurrence
of the risk event. If someone or something does fall from the scaffolding, the impact will be the
same as though no extra precautions were taken. Suitably strong catch nets strung from the
scaffolding would be one way of reducing the impact of an accident, but note too that this alone
would not minimise the chance of the accident happening. Nor do any of the additional
precautions affect the duration of exposure to the accident risk, as the scaffolding remains in
place for the same period of time. In fact, for this example none of the precautions suggested so
far actually addresses the root causes of scaffolding accidents. Prevention measures, such as
improved safety training and safety motivation for workers, are likely to be better ways of
achieving this.

139 | P a g e
In another construction example, it is sometimes necessary to disturb or remove the foundations
of an existing building, in order to deepen them or replace them with new foundations (perhaps
for a new adjoining, heavier building). This operation is known as underpinning, and is regarded
as a risky process since it involves the temporary removal of structural support from the existing
building. The risk reduction response in this case is to carry out the work in very small sections
at a time, each of which is executed in a strictly planned sequence so that no two adjoining
sections in the linear length of the existing foundation are exposed or removed at the same time.
This underpinning technique reduces the likelihood that a foundation collapse will occur.

A principle detectable from these examples is that reducing the likelihood of occurrence of a risk
event generally means looking for ways of doing things better, or doing them differently. Value
engineering techniques can be useful here, since these are aimed at exploring alternative
solutions to delivering required functions.

Reducing the impact of a risk event calls for a different approach. Risk impact reduction usually
depends upon the prudent provision of extra resources, so that the potential consequences of a
risk event are diluted in some way. The old financial investment adage about 'not keeping all
your eggs in one basket' is a typical example of risk impact reduction. At one extreme, risk
impact reduction precautions might amount to having additional sources of supply readily
available for critically essential project materials. At the other extreme, large sums of money
might be kept in reserve to payoff aggrieved people opposed to a project. The tools of risk
reduction, therefore, are most often found in precautionary measures such as back-up resources
and recovery planning, contingency allocations, reserve funds, public relations expertise, and
portfolio investment.

For a theatre performance project, the director will appoint understudies for the leading roles.
Doing this does not reduce the likelihood that a leading actor will become indisposed for a
particular performance (although that may not be strictly true, since the motivating effects of
having someone treading closely in your footsteps are well known in the performing arts!). The
extra rehearsal payments to the understudy, and the costs of advising patrons and offering
refunds to a few disgruntled ticket-holders, are the risk premiums for averting the possibility of
having to cancel the performance completely and thereby losing significant box-office revenue.

Trying to reduce to the period of exposure to a risk can be a complicated process, since it is
almost always necessary to consider the exposure to the risk event separately from the exposure
to its consequences. The tool most appropriate for the former is rescheduling; while effective
instruments for the latter may be the implementation of shorter periods for guarantees and
warranties offered to customers. The one seeks to accelerate progress, and the other to minimize
a period of liability.

In a book publishing project, the publisher might decide to increase the frequency and range of
marketing activities during a given period for a particular book. In doing so, the publisher is
trying to reduce the chance of a publishing failure, but more specifically the time during which
his or her investment will be at risk. The additional marketing and publicity activities are

140 | P a g e
intended to generate more sales more quickly, so that the sales break-even point can be reached
more quickly. The trade-off is the extra cost of the additional activities.

Risk reduction processes may go on iteratively until the point is reached where the residual
amount of a risk is acceptable and can be retained by the project stakeholder organisation. This
means that more than one return to the risk analysis stage may be required during the decision-
testing period.

Risk retention

Retaining risks without mitigating them presumes that the decision is an informed one and based
upon analysis which indicates that any reduction treatment has a negative cost/benefit ratio.
Retaining residual risks shares the same presumption, in terms of further reduction beyond that
already achieved.

Beyond this, of course, there will be risks unwittingly retained by the organisation simply
because they have not been identified.

In some instances it is possible for a stakeholder organisation to reward itself for retaining a risk.
This presupposes that the risk identification and analysis processes of risk management have
been implemented, at least to some extent. An excavation subcontractor tendering for a
construction project might retain the risk of storm water flooding the excavations, but reward
himself by increasing the unit price rate for the work. A developer might increase the 'hurdle' or
required rate of financial return for a project as a reward for retaining a variety of risks, such as
the economic risk of bringing the completed project to market in an unstable commercial
climate. A financier will increase the loan interest rate as a reward for retaining the risk of
payment default on a loan.

In all of these situations, the risk itself may be unchanged in terms of probability, impact and
duration. The 'risk and reward' approach, however, must be carefully balanced as it introduces its
own additional risks. The excavation subcontractor who includes a risk premium might find that
his bid is unsuccessful because competitors have submitted lower prices. The developer might
find competing projects selling (or letting) at lower prices as their developers are satisfied with
smaller returns. The financier might find her share of the market diminishing as borrowers seek
alternative loan sources at lower rates.

While the principle of risk retention is that it should be done on an informed basis, the principle
of seeking compensatory reward should always be on the basis that the stakeholder is not thereby
exposed to other, more severe, risks.

Combination responses to risk

141 | P a g e
Combinations of retention, reduction and transfer responses to risk are possible. Since risk
avoidance aims to change the circumstances through which a particular risk arises, this response
cannot be used in combination with others.

Probably the most common example of combination risk response is the transfer of risk through
insurance, while at the same time retaining a small amount of the impact by accepting liability
for a fixed excess sum in the insurance policy agreement.
Another example can be found in the 'target cost' variation of the cost-plus type of procurement
system sometimes used for construction projects. In contracts for these projects, the risk of cost
overrun is sometimes shared between client and contractor, as an incentive for the client to avoid
scope changes and for the contractor to work efficiently. Contract clauses will make the sharing
arrangement explicit (e.g. 50/50 or some other proportion). Co-incidentally, similar clauses
might deal with the sharing of cost savings on the project, but this does not fall within our
definition of a risk since it is not an adverse event (although the contractor's potential loss of
anticipated profit on any cost saving might be regarded as a risk). A slight variation on the
insurance example is where the risk transferee (in this case the insurance company) requires the
transferor to carry out mitigating action as well as imposing an excess liability. For burglary
insurance, an insurance company may require the policy-holder to fit special window and door
locks, and install an alarm system. These precautions reduce the probability of the unlawful entry
occurring. Risk transfer and retention is therefore combined with risk reduction.

Activity
Dear learners which risk response tool, among the afore-mentioned elements, brings risk to
zero level?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___

9.3 STRATEGIC RISK RESPONSE

Where a project stakeholder organisation has established severity categories for the risks it faces
, it is possible to formulate strategic risk response policies as a guide to determining the level and
type of management responsibility required. Such an approach is shown in table 9.1.

Table 9.1 Interval and strategic management descriptors for risk severity

142 | P a g e
The ALARP principle can be used in conjunction with a strategic approach to risk response. In
terms of this principle, the stakeholder attempts to set criteria for its risk response decisions that
ensure that only the least severe risks are retained. The more risk averse the organisation, the
lower it will set the risk severity score or severity indicators for the risks it is prepared to retain.
Setting these at the lowest level is not always feasible, hence the ALARP acronym (as low as
reasonably practical). This concept is illustrated for a 125 point risk severity scoring scale in
figure 9.1. In accordance with our earlier discussion of risk ranking, the strategic scale intervals
should not necessarily be spaced equidistantly. For a risk-seeking organization looking to exploit
project opportunities, the converse principle AHAPM (as high as possibly manageable) might be
applied.

Figure 9.1 The ALARP risk response strategy

143 | P a g e
Strategic approaches to risk raise the issue of risk attitudes (or risk profiles) and how these can
affect risk response decisions. This is further discussed in subsequent chapters. For now it is
possible to proceed on the assumption that a typical project stakeholder organisation will tend to
be averse to risk, and will thus adopt the ALARP principle. Whether it is risk averse or risk
seeking, any organisation should arrange to monitor the risks it faces during the progress of a
project, in order to place them firmly under continuous control.

9.4 RISK MONITORING AND CONTROL

An important, but often neglected part of systematic risk management is the ongoing monitoring
and control of risks during the progress of a project.

Each project stakeholder should decide how to implement effective monitoring and control
procedures for the risks it faces. Several issues must be considered, such as: determining which
risks are to be monitored; assignment of responsibility; the type and frequency of monitoring
required; reporting methods; the identification and treatment of new risks; and remedial or
recovery planning and processes.

144 | P a g e
The first issue is most easily addressed, since all risks that the organisation has retained in any
way should be monitored - at least to some extent. Assigning responsibility for monitoring and
controlling risks introduces an aspect of risk management that will be covered more fully in the
next chapter. In any project stakeholder organisation, it is rare for one person (or one group of
people) to bear responsibility for all the risk management activities of the organisation. As we
have already noted in exploring risk response, the treatment of risks may need to be undertaken
through financial management, quality management, sales management, safety management, and
in many other areas of an organisation. This multi-management approach was discussed in
earlier chapters. However, it is also important to note that the people responsible for monitoring
and controlling risks may be different to those involved earlier in identifying and analysing those
same risks. Different risks may require different monitoring processes at different times by
different people.

Table 9.1 introduced strategic management approaches at each level of risk severity, and this
provides some guidance to assigning responsibility. The overarching principle is illustrated in
figure. 9.2: the higher the risk severity, the higher should be the level of management assigned to
deal with it. The type and frequency of monitoring and control procedures required will be
influenced by the individual characteristics of each risk.

For negligible risks, minimum resources and staffing levels should be necessary. It is possible
that monitoring and control processes for these risks could be combined with other routine
activities in the organisation. Reporting will probably be by exception, i.e. only where
observation indicates circumstances or situations arising beyond what could reasonably be
expected to occur normally. Few data may be generated, and communication will be kept to a
minimum.

At low levels of risk, monitoring and control activity may increase only slightly over that
adopted for negligible risks. Monitoring is still likely to be combined with other routine tasks,
with the objective of flagging deviations from the norm. Communication will be on a more
regular basis, with performance data relating to specific risks collected on a systematic basis.

145 | P a g e
Figure 9.2 Risk severity / management responsibility levels

For moderate level risks, monitoring and control should take on a more distinctive character. The
frequency of monitoring would be clearly established in all the affected areas of the organisation,
and formally incorporated into procedural policies and manuals. Staff involved should spend
some, but not all, of their time in specific monitoring and control activity. Formal data recording,
collection and reporting procedures are required, using planned communication channels.

For high severity risks it is advisable to appoint dedicated and trained staff to undertake
monitoring and control activity on a regular, if not continuous, basis. Reporting should be to
strictly defined standards and fast communication channels should be made available.
Complex data may be generated and sophisticated data analysis techniques and data base access
may be required. Emergency response and recovery plans and procedures should be in place.

With risks of extreme severity, the highest state of preparedness should exist in the organisation.
Monitoring should be consistent and continuous. Senior management must be directly involved
and back-up personnel and other resources readily available as a standby. High level data
collection and analysis procedures should be implemented in conjunction with secure data base

146 | P a g e
access. Communication capacity should be extensive and flexible, allowing rapid and alternative
means for urgent communication between any part of the organisation, with patch-in capability
to external emergency services if necessary.

The processes of risk monitoring and control may reveal new risks for the project stakeholder
organisation, requiring a return to the risk analysis and risk response stages of the risk
management cycle. This repetition of the cycle may also be necessary for risks that have already
been identified and treated, since it has already been noted that many risks are subject to changes
in probability and impact over time.

In some respects, the monitoring and control process should add greater immediacy and urgency
to the whole RMS, as risks are now closer in terms of the elapsed time of the project. On the
other hand, there is greater knowledge about the project should be available and the uncertainty
associated with many risks will be reduced as better information becomes available.

9.5 RISK DISASTER PLANNING AND RISK RECOVERY

Activity
Dear learners, it is evident that all risks are not preventable?. Hence, how are you going to
deal with those risks that are not preventable?

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___
Since even the best RMS cannot prevent every risk event from happening, project stakeholder
organisations need to prepare and maintain plans to deal with the most severe risks they face.

Many issues are involved here, some of which include:

 assignment of responsibility for co-ordination and action,

 recruitment and training of emergency teams (and back-ups),
 defining key places, or routes for access, exit or congregation,
 defining key system control points,
 rehearsing other staff in emergency procedures,
 alerting of emergency services and specialists,
 provision of adequate communication facilities,
 supplies, equipment and spare parts logistics,
 public relations,
 statutory reporting requirements,
 preservation and collection of evidence,
147 | P a g e
  alternative arrangements for project delivery or completion.

The exact nature of each of these issues will be unique to particular types of risks - if not to
specific risk events. Some relate more to physical risk environments, but recovery and disaster
planning should not be limited to physical risks alone. For example, contemporary organisations
in many fields have had to give considerable thought to the consequences of data loss arising
from IT systems failure or vulnerability to attack.

More importantly, while there is some resemblance here to the issues of risk monitoring and
control discussed earlier, it should be borne in mind that the recovery and disaster planning
process is not the same as monitoring and control. Different people may be involved, at every
level of the organisation. The reporting and decision- making processes may be different. Public
relations requirements will certainly not be the same.

9.6 POST-PROJECT RISK EVALUATION AND RECORDING

Ignored even more often than the systematic monitoring and control of risks, the capturing of
project risk knowledge is important for a stakeholder organisation. It must be able to learn from
its experiences. Without some formal means of collecting information, processing it and placing
it somehow into organisational memory, experiential risk knowledge will be left to reside in
individual people in the organisation. Whilst this happens regardless of the existence of a RMS,
failure to capture valuable information leaves the organisation vulnerable to the demise or
departure of the personnel involved. Even if they remain active in an organisation, people often
move from one project to the next, sometimes in rapid succession. Their memories will rapidly
dim, especially where potentially negative aspects of previous project experiences are concerned.

A good RMS, therefore, should include the means to capture the risk 'stories' of the people
involved in the project. Since members of the stakeholder organisation are also likely to have had
interactions with people representing other stakeholders during the progress of the project,
valuable risk learning from other perspectives may be acquired.

In most cases, post-project debriefing is an appropriate method of collecting risk information.

Sometimes it may be appropriate to do this periodically throughout the project, perhaps when
defined milestone stages have been achieved. While inter-organisational debriefing will be
useful, the greatest value is likely to be derived from the deliberate encouragement and
arrangement of intra-organisational project 'story telling' opportunities.

The information collection processes can be conducted informally, but it is important to

formalise the analysis and archival recording of the collected material in order to maximise its
usefulness to the organisation. The archival format may be incorporated into the formal project
risk register, or dealt with as separate databases for each part of the organisation. We will
examine this more fully in the next chapter.

148 | P a g e
9.7 COMMUNICATING RISK MESSAGES
The essential 'oil' for formal risk management is the degree of communication about risk that
takes place throughout the project stakeholder organisation. High levels of communication are
necessary if the RMS is to be effective. Risk messages and meanings must be clearly understood
by everyone involved with risk management within the organisation. This is why the precision of
risk statements is important during the risk identification stage. Equally important, however, is
the plethora of intra- and inter-organisational communication necessary to deal with risk analysis
processes and outcomes, risk response decisions, risk monitoring and control procedures, and the
eventual capture of risk knowledge from projects and the people involved with them.

9.8 SUMMARY
This chapter has completed the presentation, from an operational perspective, of a broad
framework for a project risk management system. It has been argued that project risks are really
the risks of a particular stakeholder involved in a project, and that a single project-based
RMS implemented by and on behalf of all stakeholders is not feasible, since different
stakeholders will seek to fulfill different objectives, and will be engaged in different risk
contexts, even for the same project. Each stakeholder in a project therefore needs to implement
its own organisational RMS.

A formal RMS should incorporate clearly recognisable processes for identifying, analysing,
responding to, monitoring and controlling the project risks faced by an organisation. It will
assign responsibility at appropriate levels for exploring, evaluating and dealing with risks.
An effective RMS will incorporate the planning of disaster and risk recovery procedures. It will
also facilitate post-project capture of the risk knowledge people have gained from their project
experiences.Good risk communication is essential throughout and beyond the organisation.
Many of the operational issues relating to formal risk management must necessarily be
considered in the process of implementing, or building, a RMS within a project stakeholder
organisation. This topic is addressed in the following chapter.

149 | P a g e
 CHAPTER 10

BUILDING A RISK MANAGEMENT SYSTEM

OBJECTIVE:
 To help learners understand the methodology behind the implementation of formal
risk management systems in project stakeholder entity.

Content:
10.1 Introduction

10.2 Organizational maturity in risk management

10.3 Organizational RMS policy and implementation strategy

10.4 Clarifying objectives, tasks and commitments

10.5 Creating a project risk management framework

10.6 Assigning RMS responsibility

10.7 Risk management communication

10.8 Trialing techniques

10.9 Evaluating response options

10.10 Evaluating monitoring and control procedures

10.11 Establishing risk registers

10.12 Reviewing RMS performance

10.13 Summary

150 | P a g e
Dear learners, this chapter tries to reveal the fundamental facts behind the implementation
of formal risk management systems in project stakeholder entity.

Hence at the end of this unit, you are expected to:

 Master the approach behind formal risk management system implementation.

 Understand the basic concept of reviewing RMS performance.

10.1 INTRODUCTION
Dear learners, we have noted that, to an extent, we all (whether as individuals or as
organizations) manage risk. The question that arises, therefore, is how well do we do it? This is
really a matter of assessing the maturity of our risk management. That maturity in turn is a
measure of how committed we are to managing our risks systematically; and of the system we
have implemented, how it has been implemented, how it operates, how it is maintained and
improved, and who has responsibility in all of this. Risk management is more a people issue than
a mathematical conundrum. For many organizations, the risk management process focuses on
managing the people who are dealing operationally with risks. Encouraging people to have an
informed understanding about risk in general is one important aspect; getting them to adopt a
formal approach to identifying and dealing with specific risks affecting their organization is
another, although it is not unknown for a key stakeholder (particularly a public sector client) to
call for evidence of systematic risk management capability as part of its criteria for selecting
potential participating stakeholders in its projects.

In this chapter we explore the implementation of formal risk management systems in project
stakeholder organizations. Topics covered include: risk management maturity; organizational
strategy and risk attitudes; clarifying objectives, tasks and commitments; creating the risk
management system framework; assigning responsibility; system communication; trialing and
evaluating techniques and procedures; learning from experience; and reviewing system
effectiveness.

10.2 ORGANISATIONAL MATURITY IN RISK MANAGEMENT

The amount of system-building activity for risk management that takes place in a project
stakeholder organisation is likely to correlate strongly with its level of risk management
maturity. While not measurable in any precisely quantitative sense, an organisation's risk
management maturity level should be discernible through careful observation of the ways in
which it has established mechanisms to deal with project risk situations. Drawing upon the work
of Hillson (2002), risk management maturity may be defined in four ascending grades, as
illustrated in figure 10.1. The use of the present participle in each label is deliberate: it is
intended to denote a sense of movement, rather than a static condition. Risk management should
always be a dynamic activity.

151 | P a g e
Figure 10.1

Level 1: Ignoring

Labeling an organisation as 'ignoring' in terms of its risk management maturity is perhaps not
entirely fair, since every organization does something about some risks. In a level 1 organisation,
however, project risks are not dealt with systematically. Instead, risk treatment occurs
sporadically, and usually on an ad hoc basis. More often than not the risk management will be
reactive rather than proactive. By this we mean, for example, that project activity proceeds on the
assumption that everything will occur as planned, and that any deviation from the plan will be
'dealt with on the day' since 'you can never tell beforehand what will happen'. In level 1 risk
maturity organisations, the organisational level of project planning is itself likely to be
rudimentary. 'Luck' may attach itself frequently to the organisation's descriptions of past project
success, but failures are hardly ever mentioned.

Level 1 organisations have little awareness of needing to manage their risks, and thus possess no
developed risk management culture. Nor, since 'ignorance is bliss', will they be fully aware of
how they are responding to risks. They tend to respond only to external pressures.
Matters such as occupational health and safety procedures, for example, may be regarded more
as a necessary observance of regulations than as an integral part of an organisational risk
management system. Often only the bare minimum for compliance is implemented.
Many project risks are simply retained, without attempting any mitigating action.

In such organisations, any treatment of risk that does take place relies almost wholly on
individual experience and expertise. Similarly, any risk learning from projects is rarely harvested
152 | P a g e
organisationally, but is left to reside in individuals. Organisations with level 1 risk management
maturity can survive, but their continuing survival itself becomes a matter of chance. From what
has been written here, you may also deduce that a Level 1 organisation relies too much on
cliches in its risk management. However, we have no evidence for that!

Level 2: Trying

In a level 2 organisation, there is at least someone who is aware of the need to manage project
risks, and someone else (if not the same person) with authority to sanction management action.
The awareness may have come through bitter experience, fortuitous or deliberate reading,
conversations with colleagues or friends, newly appointed staff, or personal development activity
such as attendance at seminars put on by the local chapter of a professional project management
association. Alternatively, it may come about when the organisation is in an expansion mode and
finds that it has to communicate aspects of its project decision-making internally or externally. It
needs to summarise this in a way that will capture the implications for the organisation.
Occasionally, the organization may find itself bidding for project work where tenderers are
required to submit risk management plans for the project. Such requirements are becoming more
frequent in modern projects.

A fledgling or developing risk management culture should therefore be discernible at a

reasonably high level within a level 2 organisation, but will not be visible throughout.
Responsibility for establishing and operating a project-based risk management system (RMS)
will have been assigned to someone, often in addition to his or her existing duties or on a short-
term secondment basis. It is also possible that outside consultants will have been engaged to
provide advice and assistance with implementing the RMS. More rarely, one or two staff
members will have been encouraged to undertake some type of risk management training,
although the type, level and quality of this training may be largely unknown.

Organisations at level 2 risk management maturity tend to set start-up limits for their newly
implemented RMSs. This is done to contain costs (when the benefits are still largely unknown),
and to create conditions that will permit subsequent comparison between RMS and non-RMS
based projects, in order to assess whether or not the whole exercise has been worthwhile. Typical
initial limits might include the adoption of formal RMSs only for projects above a certain value;
for projects of a certain type (e.g. hospital construction projects, or banking ICT projects); or for
projects carried out for a particular client.

While Level 2 organisations are seeking to systematise their risk management procedures, they
will display a continuing reliance on reactive rather than proactive responses to risk. Risk
knowledge capture is likely to be patchy and inconsistent, and any risk learning not yet widely
disseminated within the organisation. Transfer may be the predominant risk response of Level 2
organisations, since they are still largely unfamiliar with mitigation techniques, and are largely
unaware of the potential for exploiting opportunities in any of the risks they face.

153 | P a g e
Level 3: Growing

Within a level 3 organisation, risk management activity can be seen to be growing, but it is still
almost exclusively project based. The majority of senior management is committed to the
development of systematic risk management at all levels of project decision-making, even
though this has not yet been fully achieved. A culture of risk management, and awareness of the
need for it, permeates those parts of the organisation directly involved in projects. A separate risk
management department may have been established. Specialist staff may have been recruited,
and selected staff given the opportunity to undertake advanced risk management education and
training, possibly at a postgraduate level.

Most risk management procedures in a level 3 organisation will have been standardised, and
applied to all projects, although some unique or highly complex projects may test the capacity of
the RMS. Proforma approaches to documentation will be evident. A cycle of improvement to
some risk management procedures may be in train.

All projects will be subjected to risk debriefing at completion and a risk register, or risk
knowledge database will exist. There may be evidence of fairly simple analysis of selected data,
and risk information will be communicated at least across the operational parts of the
organisation. Selected risk occurrences will be treated as learning experiences, as a means of
internal training for staff and as the basis for procedural improvements.
Risk transfer responses will be subjected to increasing levels of cost-benefit analysis, and no risk
will be retained without being subjected to at least a brainstorming attempt at reducing
(mitigating) it.

On some projects, the potential for opportunity management will have been recognised, and
limited exploitation may have occurred.

Level 4: Maturing

Risk management activity will be detectable throughout a level 4 organisation. While most
visible in the operational, project-focused sections of the organisation, a strong culture of risk
management will exist at all levels of decision-making. No project is allowed to proceed unless
acceptable risk management procedures have been implemented for it, and no project lies beyond
the organisation's capacity to assess its riskiness.

A separate risk management department may still exist, but it is possible that trained staff will
now be found in all parts of the organisation, dealing with risk management issues in specific
fields as an integral part of their other activities. Staff in the risk management department will
play a more facilitating role, co-ordinating the postproject risk knowledge capture processes on
every project, providing in-house training for the whole organisation; maintaining, and carrying
out complex analyses of the risk knowledge database; conducting risk management performance
audits; assisting other departments in establishing performance benchmarks; seeking to maintain
a continuous improvement cycle for the risk management procedures; and communicating risk
information throughout the organisation. The risk management department and the quality

154 | P a g e
assurance department may have become seamlessly integrated. Review and maintenance of the
risk management systems within the organisation will be regularly - and in some instances
continuously - conducted, with responsibility assigned at the highest levels.

Analyses derived from the risk knowledge database will help the organisation to develop case
studies for training purposes, and will be used to test different or innovative management
techniques (not just risk management techniques). Strategically, the organisation will seek to
exploit opportunities arising from such innovation, and from other risk situations. In part, the
innovation will be used to increase the amount risk mitigation undertaken by the organisation,
but a positive learning attitude will be taken towards any failures arising from the greater levels
of risk retention. This in turn will contribute towards the organisation's ability to maintain a
competitive advantage.

Decaying

Just as an organisation can mature in terms of its ability to manage risks systematically, so too
can this capacity decay. In general, the higher the level of risk management maturity, the more
gradual is the degradation of the system.

Decay is unlikely to occur slowly in an organisation at level 1 risk management maturity, since it
is largely unaware of its maturity level anyway. Spectacular collapse is a more likely outcome, as
luck is trusted once too often.

A level 2 organisation is likely to experience decay in its risk management activity for several
reasons:

 Several projects have been completed without any clearly obvious benefit being
derived from the application of the risk management system.
 The senior management champion for the RMS loses enthusiasm or leaves the
organisation.
 Staff responsible for the RMS are swamped by other duties.
 The advice of outside consultants proves impractical.
 The post-project debriefings appear to yield little information of value.
 The RMS, or the risk knowledge database, proves too cumbersome or costly to
operate and maintain.

In a level 3 organisation, decay in risk management maturity will be almost entirely due to lack
of continuing commitment from senior management, or loss of key staff. The latter may also
explain decay occurring in a level 4 organisation, but the problem in this case should only be
temporary, given the organisation's risk management maturity and engagement with performance
benchmarking.

155 | P a g e
10.3 ORGANISATIONAL RMS POLICY AND IMPLEMENTATION
STRATEGY

Establishing a risk management system is a project in itself. There will be tasks, technologies,
resources and organisation involved. Time will have to be allocated to implementing the RMS.
Most importantly, there should be someone to champion the RMS-building project, and someone
(not necessarily the same person) to manage it.

The RMS project may even experience all three project environments. Beyond the procurement
phase of achieving an operational system, the RMS will have a functional life and maintenance
needs. At some point it may be necessary to dismantle the existing system and replace it with a
different one.

An important part of initiating a RMS in a project stakeholder organisation is the formulation of

an organisational policy towards risk management and a strategy for implementing it. Ideally,
this activity should start with a scan across the whole organisation, although in practice this is
more often than not limited to the parts directly involved in projects. As noted earlier, an
organisation's interest in risk management usually starts with a distinct project focus, and only
later matures into RMS application to all of its activities.

An organizational scan addresses specific questions such as:

1. What (project) activities clearly require formal risk management?

2. How are decisions made about them?
3. What risk attitudes are evident?
4. What formal risk management is already in place?
5. How effective is it?
6. Is any informal risk management evident?
7. Where are the gaps in current risk management practice?
8. How could the gaps be filled?
9. Who should be involved in that?

The scan provides a risk management picture of the organisation in its current state. Almost
certainly the picture will be fuzzy in places and lack a consistently clear focus. There will be
evidence of activity resembling risk management in some parts of the organisation, but blank
spaces in others.

Ideally, the scan should be conducted by bringing together appropriate representatives from
within the organisation, and brainstorming the questions. Depending upon the size of the
organisation, several meetings may be required. Within each meeting, large groups can be split
into smaller sub-groups of up to five people. Each sub-group may be allocated a few questions
(e.g. 01, 2 and 3 to one group; 04, 5 and 6 to another, etc.). Alternatively, each small group is
required to address all questions. Small groups each dealing with a few questions may be best,
since this encourages focus and discourages distraction, but each group should be aware of the
full range of issues to be considered. Information about the meeting should be circulated
156 | P a g e
beforehand, telling people about the purpose and intended topics to be addressed. Sub-groups
should be reconvened into larger groups again after intervals of not more than about forty-five
minutes, in order to report progress. All summary findings should be recorded in some way - by
voice or video recording, whiteboard, butcher paper, or with secretarial help.

While representatives of senior management must attend these scan meetings, this does not mean
that they should lead them. It may be more helpful to arrange for an independent risk
management consultant to facilitate the activity and be responsible for preparing the agenda
questions, recording findings and writing the subsequent scan report. If there is sufficient
confidence and experience within the organisation, however, the facilitating role can be
undertaken internally.

The scan should start by identifying project (or organisational) activities that participants believe
should be subjected to formal risk management. It may be necessary to explain briefly the
processes of formal risk management before exploring this question. Note that the question does
not ask participants to identify every project activity the organisation engages in; but only those
where formal risk management is desirable. This is deliberate, with the intention of avoiding a
situation where people could become overwhelmed with too much detail. Some activities may be
overlooked, of course hence the blank spaces referred to above. The missing parts will eventually
be filled in as a culture of risk management develops within the organisation.

The second question clearly begins to associate decision-making with risk management. The
answers produced by the scan groups should point to any mismatches occurring in decision-
making levels within the organisation, and will help to identify other staff who might usefully
become involved in subsequent formal risk management implementation processes.

The third question of the organisational scan introduces the concept of risk attitudes. Classically,
in decision science and behavioural psychology, people are described as being either risk averse,
risk seeking, or risk neutral. In reality, the latter attitude is most unlikely.
People either like to buy a lottery ticket or they don't: they are keen to engage in extreme sports
or they are not. You will hardly ever meet anyone who is truly indifferent in his or her attitude
towards risk, regardless of the context.

Risk attitudes are revealed in decision-making - thus providing an additional purpose for
question 2. A person might intimate that he or she is risk averse, but in real life make decisions
which actually reveal a tendency towards risk seeking.

Attitudes towards risk are also complicated by other factors. A person's risk profile is not
necessarily consistent over the whole range of his or her decision-making. Some decisions will
be dealt with in a risk averse manner; others will receive a risk-seeking response. The risk profile
is not necessarily consistent over repeated or similar decision circumstances, nor over time.
Many decision-makers are not consciously aware of their risk attitude for most of the time.
Education, training, culture and experience all combine to shape our risk attitudes. Most adults
are capable of separating professional risk attitudes from personal risk attitudes where the

157 | P a g e
distinction is necessary and the attitudes differ. In turn, project organisations that tend to be risk
averse rely on this capacity in the staff they employ at higher decision-making levels.

In effect therefore, the third question is something of a Pandora's box, since it may lead to a
labyrinth of psychological and behavioural connections that cannot be unraveled in the limited
environment of an organisational scan. The purpose of the question is to expose at least some of
the influences on organisational decision-making, as these will also influence the development of
a policy towards risk management.

Providing participants have a reasonable grasp of formal risk management processes, the fourth
question should be fairly straightforward. In most cases, the answers will reveal patchiness
across the organisation. Some aspects of risk management will be evident albeit under different
labels - in some existing project or organizational activities such as occupational health and
safety management, quality management, value management, financial management and
purchasing. Others will be clearly absent.

Ascertaining the effectiveness of any existing risk management practices (question 5) is almost
certain to produce highly subjective and qualitative responses, since the organisation is likely to
have few, if any, quantitative measures in place. This question is aimed at getting participants to
describe their confidence in existing organizational processes, but is posed in a rather indirect
manner to encourage people to give open responses.

The sixth question could also be rephrased to ask what intuitive or non-standard procedures are
used, when making or implementing project decisions, to ensure that satisfactory outcomes are
achieved and objectives fulfilled. The purpose of the question is to identify effective procedures
that could later be incorporated into the formal RMS, and to weed out weaknesses.

The last three questions may be best left to a post-scan session, since some expertise in assessing
formal and informal risk management systems is required. It may be easier for a small senior
management team from the organisation, perhaps with specialist assistance, to analyse the
information gained from the earlier scan questions and, with their knowledge of the structure of
the project stakeholder organisation, identify inadequacies in its current risk management
practices. However, if the participants in the scanning sessions are maintaining their enthusiasm
for this forensic work, they should be encouraged to continue and suggest how procedures could
be improved.

The outcome of an organisational scan provides a richer picture of the state of risk management
practice within the organisation and guides the directions in which it can be formalised and
improved.

The project stakeholder is then in a position to formulate (and document) a coherent risk
management policy. Documentation of risk management policies and procedures is an important
aspect of corporate governance, since it facilitates communication, accountability and subsequent
performance review.

158 | P a g e
The policy document should be specific rather than general. It should state why the organisation
wishes to adopt a more formal approach to managing risk, and indicate if the RMS is to be
targeted at particular projects, to all projects, or even across all the activities of the organisation.
Where possible, risk management responsibilities should be defined and assigned, using an
organisational structure diagram if necessary.

A RMS implementation strategy should include measures to motivate staff. Personnel who will
be involved in using the RMS should be represented in the implementation team. Too often, the
introduction of a formal RMS is seen as simply another imposition that must be added to an
existing workload. If necessary, of course, workloads and remuneration should be adjusted to
reflect additional duties and responsibilities but, more importantly, employees should be shown
how engaging in effective risk management not only improves their skills but could also
contribute towards greater job security by reducing the organisation's business vulnerability (or
enhancing its performance).

The RMS implementation strategy should also consider the nature and extent of risk
management education and training required, and how risk management knowledge is to be
diffused throughout the organisation. The objective of the strategy should be to grow a risk
management culture within the organisation, by raising awareness of project risks, and by
enabling staff to develop skills and confidence in managing them in a systematic and transparent
manner.

10.4 CLARIFYING OBJECTIVES, TASKS AND COMMITMENTS

As with any project, the implementation of a RMS within an organization should be carefully
planned. Objectives must be clarified, tasks scheduled, commitments confirmed, and resources
obtained and organised.

Ideally, the procurement objectives should state what level of RMS is to be implemented, at what
budgeted cost, and by what intended operational date. Functional objectives should indicate what
the RMS is intended to do (e.g. facilitate the identification, analysis, treatment, monitoring and
control of project risks faced by the organisation; assist in the necessary documentation of the
techniques employed, the decisions made and the outcomes achieved in the risk management
process; and become a repository of organisational knowledge about project risks). Strategic
objectives will describe what the outcomes of the RMS are expected to achieve for the
organisation.

Scheduling the tasks for implementing a RMS largely depends upon how the system is intended
to operate within the organisation. This issue was mentioned earlier, and it is useful to expand
upon it here.

Essentially, there are three ways of operating a RMS:

 as a single, centrally based system to deal with allthe activities of the organisation;

159 | P a g e
  as dual, centrally based systems: one to deal with project activities; the other to deal with
internal organisation maintenance activities;
 as multiple, separate systems for each project; plus a single system for internal
organisation maintenance.
A single organisational RMS may be achievable only for an organization with Level 4 risk
management maturity, where a seamless organisational approach is sought. The dual system will
be found in organisations with level 3 risk maturity; while a level 2 organisation is likely to be
trialing multiple RMSs - at least for selected projects and may not yet have decided to implement
an additional system for its internal activities. Initially, therefore, risk management system
building is most often aimed at individual projects.

The tasks of RMS building will involve staff at all levels in the organisation, and implementation
will require activities involving:
 system design (How will the RMS operate? What sort of framework is desirable? How
should it be implemented?)
 assigning responsibility (Who will be involved?)
 deciding the level and nature of communication channels (How is risk reporting to occur?
To whom? How often?)
 trialing techniques (What risk identification and assessment techniques will be used?)
 evaluating the implications of risk response options (How will each type of response
impact upon the organisation?)
 evaluating the implications of risk monitoring and control activities (How will these
affect the organisation?)
 designing and establishing risk registers (How should risk knowledge be captured?)
 establishing criteria and procedures for reviewing risk management effectiveness (What
are the RMS performance criteria? How should they be assessed? By whom? How
often?).

None of these activities can be undertaken successfully without the committed support and
involvement of senior management. Without adequate support, the necessary risk management
culture will never become completely ingrained throughout the organisation. Nor is support
sufficient without appropriate involvement, since the association of risk with decision-making
means that decision-makers at all levels in the organisation must participate (and be seen to
participate) in the risk management process.

10.5 CREATING A PROJECT RISK MANAGEMENT FRAMEWORK

The system framework for implementing risk management can be as simple, or as sophisticated,
as the requirements of the organization warrant.

At a fairly basic level, computer spreadsheets can be used to deal with individual projects.
Typically, a spreadsheet format for the RMS might resemble that shown in table 12.1 (A and
B).The format can be developed as a template for the organisation and its projects. The 1efthand

160 | P a g e
part of the spreadsheet records the nature and characteristics of identified risks. The centre
section is used for assessing these risks; the right-hand columns reflect decisions made about
their treatment, monitoring and control.

Depending upon the level of risk management implemented, the first few columns of the RMS
spreadsheet are used to list project objectives and the tasks, technologies, resources and
organization necessary to achieve them. This information may be gathered either from existing
project documents, or derived from the collective ideas of project team members.

A key column is allocated to recording every risk associated with the objectives and project
elements and sub-elements. These should be identified through project team brainstorming and
other techniques. The identified risks can be immediately entered into separate spreadsheet cells
during the brainstorming activity, but subsequently each entry should be edited to create precise
risk statements couched in the terms suggested in chapter 6.

The column used to record the type of each identified risk is a useful way of discovering if the
project is significantly vulnerable to particular categories of risk. It can also help in the
subsequent exploration of alternative options for treating these risks. This column does not need
to be completed during the risk identification sessions.

In the assessment section of the spreadsheet, three columns are included to allow subjective
scoring the probability, impact and exposure duration dimensions for each risk, using simple 5-
point scales. Ideally, the scoring should be completed during the risk identification session, but it
could be carried out during a separate subsequent session, especially if considerable editing work
is needed to produce the necessary precision in the risk statements. A fourth column uses simple
cell formula entries to calculate a severity score for each risk. At this point, it is wise to save the
current version of the project RMS computer spreadsheet, and then re-save it as a later version in
the project file sequence.

The sorting capacity of most commercially available spreadsheet software applications permits a
simple re-ordering of the scored risks, ranking them from highest to lowest severity score. The
organization can now identify the most severe risks it faces on the project, since these will be
clustered at the head of the spreadsheet. Alternatively, the most risky objectives, tasks and
commitments for the organization on that project can be highlighted. It is then possible to revisit
these if necessary, armed with greater knowledge, thus providing the opportunity to rethink, and
possibly improve the organisation's performance. Although it has been omitted from table 10.1B
in the interests of saving space, an additional column could be inserted at this point to record the
severity of each risk in terms of the organisation's strategic risk management descriptors (table
10.1).

The system framework should include columns to record any procedures or controls already in
place for the risks that have been identified. Typical entries here might include contract clause
numbers or specification references. In the spreadsheet template, this column marks the
beginning of the treatment section. Much of the cell entry data in these columns will be in text
form.

161 | P a g e
Knowing the extent of the risk treatment procedures already in place allows the risk management
team to consider potential treatment gaps for each of the risks that have been identified; and then
to suggest alternative or additional methods of dealing with them. Another useful column (also
omitted from table 10.1B) could be inserted after this point to record the type of risk treatment
option suggested (i.e. avoid, transfer, reduce and retain, retain, or combinations of these). This
allows immediate comparison with the organisation's preferred treatment strategy for risks of
particular types and severity.

Where it is appropriate, any identified risk can now be reassessed, using the subjective scoring
approach as before. This is a crude but acceptable way of gauging the potential effectiveness of
the proposed risk treatment option. By saving successive versions of the template
RMS computer file, it is always possible to revert to earlier choices.

The remaining columns of the RMS framework template are used to record the actual treatment
decision for each risk, how monitoring will be carried out, and how responsibility is to be
assigned. It may even be possible to include information about the costs of risk treatment. This
will permit subsequent evaluation of the benefit-to-cost performance of the RMS, although
consistent accuracy should not be expected in such assessment.

The simple spreadsheet approach described here will probably satisfy the early risk management
system requirements of an organization with level 2 risk management maturity. With adaptation,
it can be made to serve the needs of organisations with greater risk management maturity. It is
possible, for example, to use cell entries to reference links to other spreadsheets, schedules and
documents where material relevant to each risk is dealt with in greater detail. Organisations with
level 4 risk management maturity are likely to have developed more sophisticated risk
management system frameworks, and may well be using intra- and extra-net computer
information technology networks to process and communicate project risk information within
and, where necessary, beyond the organisation.

162 | P a g e
Table 10.1A Simplified project RMS format

163 | P a g e
Table 10.1 B Simplified project RMS format

10.6 ASSIGNING RMS RESPONSIBILITY

The need for the support and involvement of senior management both for building and operating
a RMS - was argued earlier in this chapter on the grounds of the association of risk with decision
making. Additional arguments lend cogent support to this need.

An appropriate culture of risk management is desirable throughout the organisation. Such a

culture recognises the importance of dealing effectively with potential threats to the organisation
through their impacts upon the projects with which it is involved. While the threats may be
negative, however, the management process for dealing with them needs to be positive in terms
of a forward-looking approach which instills confidence in the way the interests of the
organisation are being safeguarded.

Instilling and growing such a culture is a top-down leadership task and is the responsibility of
senior management. The active involvement of staff at this level, willing to drive the system
building project for the RMS and prepared to champion its adoption and development, provides
the best chance of successfully implementing an effective RMS within an organisation.
164 | P a g e
The appointment of a risk manager does not automatically resolve all risk management
responsibility issues within an organisation, despite the fact that advertisements in the 'situations
vacant' columns of many newspapers indicate that surprisingly large companies appear to make
this assumption. While such an appointment can contribute substantially to the effectiveness of
the RMS - whether at the implementation stage or for system operational purposes - the risk
manager does not thereby become responsible for all the decision-making occurring within the
organisation. Nor could he or she possibly under take all the necessary risk management
activities alone. Risk management is never the exclusive preserve of one person.

As the organisation's risk management maturity increases, it will become evident that the RMS
operating team will be substantially different from the RMS building team. Ideally, the people
necessary for building a RMS will be found within the organisation itself. Members of the
system building team should be familiar with the structure of the organisation and its activities.
They should be able to communicate effectively across any departmental or discipline
boundaries existing within the organisation. Initially it may be best to start with a small team and
allow this to grow organically with the development of the RMS itself. Help may be needed at
the outset.

This raises the issue of using extemal consultants in risk management. While risk management
specialists can make a valuable contribution to the implementation of a risk management system
(and advising on its application to specific projects), it is important to clarify their role and the
extent of their involvement. Remember that, regardless of the number of consultants you appoint,
as a project stakeholder these are your projects - not theirs - and therefore your risks, not their
risks!

Specialist risk management consultants can assist in RMS building by facilitating the workshops
needed to carry out backward and forward organisational scans and undertake SWOT analyses;
and to assist with training staff in the use of risk management techniques. The help of consultants
may also be necessary for tricky or unusual projects, particularly during the risk identification
and assessment stages for projects where the existing risk management expertise in the
organisation may be inadequate.

Personal knowledge or word of mouth may be the only means for an organisation to judge the
suitability of potential risk management consultants, since currently there is no professional
accrediting body for this discipline and micro-specialisms (e.g. safety risk management or
financial risk management) proliferate. A specialist in one area is not necessarily competent in
others. Careful selection of an appropriate consultant is therefore necessary, and it is important to
specify the nature of the services sought and the duration of the appointment. Evidence of
qualifications and previous experience should be examined, and references obtained from the
consultant's recent clients.

165 | P a g e
10.7 RISK MANAGEMENT COMMUNICATION

Activity
Dear learners, discuss the role of communication under project risk management endeavors.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
__

Effective communication is a critically important ingredient in risk management, since risks can
only be managed if they are known and understood, and knowledge and understanding can only
occur if the participants in the risk management process are able to find common meaning about
the nature and extent of each of the risks that they must deal with. Risk communication must be
effective intra-organisationally (i.e. within the project stakeholder organisation). More often than
not, it also needs to be inter-organisationally adequate (i.e. between project stakeholder
organisations).

The potential extent of risk communication required can be seen on projects undertaken under
the Private Finance Initiative (PFI) in the United Kingdom. This scheme has been used
extensively since 1992 to secure the delivery by private sector organisations of public projects
and services on the grounds that such delivery can be more efficiently and economically
managed by the private sector. It is part of a worldwide increase in the involvement of the private
sector in the development and financing of public facilities and services. Procurement
arrangements, under the general label of 'Public Private Partnerships' (PPPs), have been
developed to encourage the public and private sectors to work together to share the risks and
rewards associated with such procurement activities. These PPPs range from the simple
contracting-out of public services to the involvement of the private sector in the financing,
design, construction, operation, maintenance and, in many cases, concessional ownership of
major facilities such as roads, tunnels, water supply infrastructure, hospitals, clinics and schools.
The effectiveness of PFI has yet to be fully demonstrated over the complete life span of an
acceptable sample of similar projects, and some doubts have been raised about many of the
advantages claimed for it. In the United Kingdom however, it is recognised as a means of
avoiding centrally imposed limitations on the extent of public sector local authority borrowing,
since the financing of projects becomes the responsibility of the private sector partners and can
thus be treated as off-balance sheet items by the public sector clients.

The process of implementing a PFI scheme, from the perspective of the public sector client, is
illustrated as a flow diagram in figure 10.2. As a measure of public accountability, before a PFI
project is allowed to proceed beyond the development stage in the United Kingdom, the client
must demonstrate to central government authorities that the PFI proposal compares favourably
with alternative procurement methods including fully public funded delivery.

166 | P a g e
 Figure 10.2 Typical pre-contract development process in public/private partnership
projects

167 | P a g e
Table 10.2 Typical risk allocation matrix in public/private partnership projects

168 | P a g e
Table 10.2 Typical risk allocation matrix in public/private partnership projects (continued)

The risk allocation matrix referred to in figure 10.2, will include a number of different risk
situations, indicating how these are to be dealt with on an allocation basis between the parties but
omitting any treatment detail. Typical risks allocated in this way are listed in table 10.2.

Each of the project stakeholder organisations (and there will usually be many others) must ensure
that it is fully informed about the risks it faces on the project. The public sector client must
ensure transparency of risk information in the documents issued to bidders and partner
organisations. The participating collaborators in the SPV must ensure that they share a common
understanding of the risks each of them has been allocated.

Note that the reference to 'shared risks' in this PFI example does not mean that the process of risk
management for these risks will be undertaken jointly by the public sector client and the project
SPV. The principle enunciated in chapter 11, that each stakeholder is responsible for managing
its own risks, still applies. Each participant will manage its part of each shared risk, although the
stakeholders may confer over the assessment and treatment options for these risks.

In terms of risk communication, therefore, the RMS building process should ensure that
sufficient precision and reliability are incorporated into all of the media-related aspects of the
RMS, including the system framework itself and all supporting identification, assessment,
treatment, control, monitoring and register documents. Similar precision and consistency will
also have to be sought in documents accessed beyond the organisation, including plans,
schedules, contracts, subcontracts, warranties, estimates, tenders and such like.

It is vital that the risk-related implications embedded in all these documents be clearly perceived
and understood as risks, i.e. that they properly reflect the threats facing the project stakeholder.
169 | P a g e
10.8 TRIALING TECHNIQUES
An organisation lacking any formal system of risk management is likely to be unfamiliar with
appropriate techniques, especially in the areas of risk identification and risk analysis where
intuition and personal experience were previously relied upon. Thus there is a need to develop
the techniques required to make the RMS effective in operation. The task of developing precise
risk statements can be daunting to anyone who has never done it before, and even brainstorming
might require some practice among staff unaccustomed to this approach. Practice in dealing with
group dynamics may be necessary. It is also not unusual to encounter confusion about particular
concepts of risk, such as uncertainty and probability, among the staff of an organisation, so the
trialing of techniques may need to be accompanied by education and training.

Different techniques should be trialed during the RMS building process, using the assistance of
specialist risk management consultants if necessary. Ideally, staff should be encouraged to
experiment with as many different techniques as possible (e.g. the methods of risk identification
discussed in chapter 6), and feedback obtained about the perceived effectiveness of each. An
important aspect of this work is the alignment of any subjective rating scales intended for risk
assessment purposes, so that they match organisational values, followed by calibration to ensure
that they are applied consistently across the organisation.

Project simulations and case studies are good vehicles for trialing risk management techniques,
particularly where tricky or critical project situations can be tested. It is advisable to adopt an
incremental approach to these trials, starting with techniques that are sufficiently simple and then
gradually building up to more sophisticated and complex methods. Early mistakes on the part of
participants must be forgiven, and enthusiasm rewarded. Errors should prompt critical review of
the technique in question, rather than blame for the users.

The process of trialing risk management techniques should be carefully planned and properly
resourced when building a RMS, since starting a system with inadequate techniques may damage
it to the extent that recovery is almost impossible. Even where appropriate techniques have been
implemented, wise organisations with good risk management maturity will continue to research
and develop this aspect of their systems.

10.9 EVALUATING RESPONSE OPTIONS

The four risk response options described in earlier chapters (avoid, transfer, reduce and retain,
retain) sound deceptively simple, and even knowing that combinations of some of these are
possible does not appear to add undue complication to the task of deciding how risks should be
treated.
In practice, decisions about risk response options are rarely straightforward since almost every
response will entail ramifications for the organisation. Avoiding, transferring or mitigating some
risks may incur additional and different risks which in turn must be identified and managed.

170 | P a g e
It is important therefore to evaluate response options to risks carefully in terms of their flow-on
effects. As with other risk management techniques, risk response options can be explored in a
simulation or case study environment during the RMS implementation stage. Senior management
input is essential during this process, since staff at lower levels may be unsure about what
constitutes an acceptable or unacceptable risk.

10.10 EVALUATING MONITORING AND CONTROL PROCEDURES

The procedures required for monitoring and controlling project risks will be determined by the
nature of individual projects and the specific risks they impose upon the stakeholder
organisation. Nevertheless, some thought should be given at the RMS system building stage to
the general implications of this task. Most of the system building team will have project
experience with the organisation, and will be familiar with at least some of risks involved in
those projects and the measures that were used to deal with them. In many instances these would
have comprised management procedures from other parts of the organisation, such as financial
control, quality assurance and occupational health and safety management. The team should
therefore be in a practical position to consider how the implementation of a formal RMS in the
organisation might affect procedures already in place, and to suggest any changes or additional
resources necessary to improve their effectiveness from a risk management perspective.

Clearly, the RMS should avoid unnecessary duplication of existing management control
processes, but not at the expense of failing to properly facilitate adequate management of the
project risks of the organisation. A recent example, albeit not from a project management
context, emphasises the need for effective control. Early in 2004, a major Australian bank
conceded losses of AU$360 million in foreign currency option trading. A subsequent
independent auditor's report blamed, among other things, a complacent and arrogant corporate
culture within the bank, management deafness and indifference to earlier warning signals,
misleading reports communicated to senior management, and the by-passing and manipulation of
the bank's risk management systems. The lack of banking experience among the non-executive
board members of the bank was noted. Apart from affecting the bank's share price, this damning
report sent shivers through the whole Australian banking industry. Risk management which is
superficial, or which can be ignored or manipulated, is itself at risk of being ineffective through
failure to adopt appropriate monitoring and control processes. Not unexpectedly, the first
response to the bank's loss was the resignation of its chairman and the chief executive officer.
The new chairman's subsequent reaction to the auditor's report was to dismiss several managers
and staff and reassign the duties of some directors. Instead of attempting to placate shareholders
by the traditional 'blame game', the bank might have served them better by providing clear
explanations of the bank's proposals to improve its risk management systems.

10.11 ESTABLISHING RISK REGISTERS

The more care and attention that is devoted to the design and establishment of the risk register,
the more valuable this component of the RMS will be to the stakeholder organisation.
Companies worldwide are now beginning to appreciate the benefits that knowledge management
171 | P a g e
can bring, and a key part of this is the means of capturing the knowledge that is developed and
resides in the organisation. For the most part, risk knowledge lives within individual members of
the organisation and, while there may be ethical issues of ownership to resolve, the organization
should make every effort to harvest and exploit the available risk learning.

Activity
Dear learners, designing a risk register plays a pivotal role RMS. Discuss the important
factors to be taken in to account under such effort.
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___
For some project stakeholder organisations, a risk register comprising an updated version of the
spreadsheet illustrated in table 10.1 might be sufficient, especially where relatively simple
projects with few risks are involved. As an organisation's risk management capability matures
however, it is likely to need a more extensive means of recording project risk outcomes and
experiences.

In designing a risk register, several aspects must be considered:

 What are the objectives?

 Who will use the register?
 How should the register be structured?
 What data should be collected?
 Who will collect it?
 What are the data sources?
 How should the data be collected?
 How should the data be analysed?
 How will processed data be used?
 Are there issues of confidentiality?
 Will the information have a 'shelf life'?

The objectives of a risk register will normally be associated with:

1. creating a repository of useful risk-related information gained from project experiences;
2. making this information available for beneficial use on future projects;
3. facilitating the use of risk information to guide change in the organisation;
4. ensuring that valuable organisational knowledge is not lost through staff turnover;
5. providing an accessible and auditable database of organisational risk management practice.

The first two objectives are clearly important in terms of the focus of an organisation whose
main activity involves a stakeholder role in projects. The third objective recognises that project
experiences are not necessarily limited to their potential effect on future projects, but can also
172 | P a g e
influence change in other areas of the organisation. An instance of financial risk occurring on a
particular project, for example, might result in changes to the financial management procedures
for the whole organisation.
It is surprising how few organisations take steps to preserve valuable organisational knowledge
and prevent it from being lost when key staff leave. A risk register is a good counter to this risk.

Similarly, organisations should recognise that a properly maintained risk register is capable of
providing powerful evidentiary support in the event of inquiries held to investigate project
incidents. An inquiry is likely to show a more sympathetic attitude towards an organisation able
to demonstrate both proactive and reactive competence in dealing with risks.

Users

The primary users of a risk register will be the decision-makers in the organisation, since it has
already been established that project risks arise out of project decisions.

Structure

The structure and format of a risk register are critical to its effectiveness.
Ideally, the register should be a 'live' repository of information; a resource that grows with the
organisation and is flexible rather than rigid. It should be capable of accommodating a wide
range of uses and users, be searchable, and preferably be selectively interactive rather than
entirely passive.

This suggests that an electronic platform for the register is likely to be more efficient than a
printed hard-copy manual, at least for the majority of intended uses. A computer-based intra-net
information management approach is probably ideal, since this allows control over access within
the organisation, has data storage capacity and permits interactive operation by selected users
and passive access by others. Security and flexibility of access can be assured.

The risk register can be structured in various ways according to the perceived needs of the
organisation. For example, it could be formatted primarily in terms of project type. This might
suit an organization which tends to engage repeatedly in several different types of project, but
would be less useful for one that restricts its activities to a single type (or very few types) of
project.

Another approach might be to adopt risk classification types as the primary denominator for the
register. Thus separate sections of the register would deal with different risk categories such as
weather risks, social risks, political risks, cultural risks, legal risks, technical risks, etc.,
according to the risk classification system adopted by the organisation. Risk classification was
discussed in chapter 2, and this method of structuring the risk register would suit an organization
involved in different types of project but tending to experience the same types of risk on each
project. This approach would also be appropriate for a project stakeholder organisation operating
wholly within an industry with industry-specific risk types.

173 | P a g e
A third alternative would be to adopt project elements and sub-elements as primary structural
determinants for the risk register. The task, technology, resource and organisation elements of all
projects were discussed in chapter 3. In practice, this approach would be most useful for an
organisation which is generally engaged in a limited number of activities that are similar for all
its projects.

Finally, the structure of the risk register could be based primarily upon the project environment
(e.g. procurement, operation or disposal as discussed in chapter 3) or upon the phases within any
of these environments. In terms of the latter approach, for example, divisions in the register
might reflect the risks associated with the design, testing, tendering, installation and
commissioning stages of a project.

A key to deciding upon the basic structure of a risk register is to ascertain the general approach
to risk identification used by the organisation in its RMS. If the RMS tends to favour a risk
identification technique based upon one of the approaches noted above, then this should
influence the format adopted for the risk register.

It should also be noted that none of these approaches envisages the incorporation of the
organisational risk register and the RMS for each project. While it is useful for each project RMS
to be prepared and used with eventual archival purposes in mind, it would create an unwieldy
tool to attempt to combine the project RMS with the organisational risk register.

Data

In chapter 11 we referred to the post-project risk evaluation and recording stage of an

organisational RMS as 'getting the risk stories'. While this implies an anecdotal quality for the
information involved, it certainly does not mean that fictional accounts are acceptable. The data
needed for the risk register of a project stakeholder organisation's RMS may be qualitative or
quantitative in nature, but should all be based upon factual measurement, observation or
objective opinion.

For the most part, data needed for the risk register will relate to any or all of the components of
particular risks: the circumstances (including background details of relevance) and nature of the
risk event and its occurrence, consequences and period of exposure. Information about the
effectiveness of any pre-planned mitigating procedures should be included, as well as details of
unplanned actions that became necessary. It is obviously critical to include full accounts of any
disaster events and the recovery measures taken. Cause and effect observations are extremely
useful.

Most of the data are likely to relate to risks identified and treated in the project RMS, but care
should be taken to gather information about new and additional risks arising during the project
activities.

The 'richer' the data (i.e. beyond mere facts and figures) collected; the more valuable the
information will be for the organisation.

174 | P a g e
Data collection

How and when risk data should be collected, and who should be involved in this task, are clearly
matters for each project stakeholder organisation to determine for itself.

Generally, a post-project debriefing process (or project postmortem) is a convenient way of

gathering risk stories. However, it is not necessary to wait until a project is finished before
undertaking this task, nor should it be assumed that a short, single unbroken process will be
sufficient. Nowadays, many projects have a post-project meeting for all key stakeholders. While
useful risk-related information will almost certainly be gained from this, an organization keen to
improve its risk management performance should arrange additional in-house occasions to
collect data. These may also be undertaken during the currency of the project, perhaps at
significant milestones. Besides group meetings, individual interviews with project staff may be
necessary.

The people responsible for collecting data should be prepared to do this actively rather than
passively. In other words, it is better to go out and seek information and not to assume that others
will bring it to you. For disaster and disaster recovery situations, of course, an active data
collecting and recording intervention is essential.

Collecting project risk data requires people who can listen to others' stories with patience and
accuracy, and who have an ability to organise information coherently. Some of these are
acquired skills, so a prudent organisation will arrange for suitable training for its risk
management staff where necessary. Sound recording can be used during group meetings and
individual interviews, but not all risk data will be verbally based and opportunities (and the
capacity) to use other media for direct data collection, such as video and digital photography,
should not be overlooked. Nor should secondary sources beyond the organisation and its projects
be ignored: newspaper and journal articles, statistical and official publications, television
documentaries and radio broadcasts can all yield useful information about risk.

Analysis and use

Besides the obvious 'what to do/not to do on the next project' value of the risk register, there are
other potential areas of analysis and use for this resource.

Quantitative analysis, however limited this may be, should be possible for at least some of the
risks of similar type encountered on several projects. Where the projects are sequential it may
also be practicable to assess the effectiveness of any treatment procedures implemented over the
intervening period. Time series analysis might be attempted where this is appropriate - for
example, for some economic risks.

An important use of the risk register lies in the development of risk case studies, scenarios and
disaster recovery plans. Because the risk information is so cogent to the organisation itself, it is
capable of providing realistic material that can be developed for training and practice purposes.
Planning and rehearsing disaster recovery procedures, using information gathered from real-life

175 | P a g e
project risk experiences, can contribute enormous value and capacity to an organisation's risk
management capability. In this regard, the benefits of learning from experiences of failure will
often exceed those derived from stories of success.

Confidentiality and currency

In creating a risk register, due regard must be given to any internal requirements for
confidentiality of information, and also to any laws relating to third party information disclosure
in the country where the stakeholder organisation (or the project) is located. The physical
security of the risk register and its data must also be considered.

The currency of a risk register depends upon how long its contents remain useful to the
organisation. All such resources have a 'shelf life'. This may be in terms of relevance of the
content, or in terms of the information management techniques used to create, maintain and
access the risk register.

The relevance of the content of an organisational risk register will change over time. The
organisation might decide to carry out its project activities differently, for example, replacing
some technologies or resources with others. For various reasons it might opt to discontinue any
future involvement with particular types of projects. If a risk register is to maintain a 'live'
quality, it is as important to cull redundant information as it is to add new data.

Developments and changes in information management techniques mean that it might be

necessary for an organisation to enlarge its information storage capacity, upgrade operating
systems, or migrate data from one system to another.

Although care is needed in dealing with any of these changing situations, they provide
opportunities for an organisation to consider the state of its risk register and to take steps to
improve its efficacy.

10.12 REVIEWING RMS PERFORMANCE

One of the most difficult things to deal with in implementing and maintaining a risk management
system in an organisation is evaluating its performance. After all, if risks are successfully
managed so that either they do not eventuate or do not have the impact they might have had if
unmanaged, how is the organisation to measure the invisible benefit? What are the key
performance indicators and critical success factors for a risk management system in a project
stakeholder organisation? Obviously these must be determined by each organization and will be
based upon the objectives established for the RMS as a whole and the functions of the
constituent parts. However, difficulty will almost certainly still be encountered in attempting to
measure system costs and value system benefits. Even if this can be accomplished, what benefit
to cost ratio should be expected for the RMS, and how can it be benchmarked against the
systems of other organisations? How frequently should RMS performance reviews be
conducted?

176 | P a g e
The whole area of RMS performance is considerably under-researched to date; hence the
multitude of questions in the paragraph above. Few answers are available in current risk
management literature. Like any other management technique, the performance of a RMS should
be reviewed. For the most part, a review will have to rely upon the critical assessment of
feedback evidence from staff involved in using the RMS and much of this will be subjective
opinion. Provided this is gathered in a methodical way, and validated wherever possible by
triangulation and comparison, the results should be acceptable. Sourcing the data from a good
cross-section of the organisation will help to achieve this. It will also minimise the risk of
subversion or manipulation of the risk management system itself, as noted in the banking
example earlier in this chapter.

Some clues for the RMS review process are described in table 10.3. The review focus is assumed
to be on system performance from the perspective of the various constituent stages of a RMS. An
organization might choose initially to limit the performance review to one specific project, or
one aspect of the system, on the grounds of simplifying and speeding up the review process.
Eventually, however, reviews should embrace at least several (or a series) of projects and the
whole RMS.

It will be seen from table 10.3 that most of the suggested performance criteria are based upon
subjective assessment. Some guidance on RMS benchmarking can be obtained from the risk
management maturity model presented at the beginning of this chapter, but for realistic
comparison the co-operative collaboration of other organization must be sought.

The frequency of RMS performance review should be at least annually for an organisation of
level 2 risk management maturity. For a level 3 organisation the review could be conducted
every two to three years, and at level 4 level this might be expanded to once every four to five
years. Five years is probably the maximum permissible interval between RMS performance
reviews, since this roughly corresponds with the time normally required to plan, develop and
implement technological and organisational change successfully in most industries. Where there
is opportunity and capacity for reckless decision-making in the organisation, however, there is
little alternative to adopting review procedures which are virtually continuous.

Table 10.3 Performance review focus for a project stakeholder organisation RMS

177 | P a g e
10.13 SUMMARY
The risk management maturity model should enable organisations to assess the extent to which
they currently engage in formal risk management practices. It provides goals for improvement.
Organisations need to establish a clear risk management policy and an implementation strategy
for a RMS, as creating a formal RMS is a project in itself.

178 | P a g e
The organisation must decide upon the type of RMS (multiple project systems; dual project and
internal; or seamless single system) to be adopted. Careful design of the system framework is
needed. In the early stages of risk management maturity a simple spreadsheet approach may
suffice. Issues of responsibility for the RMS must be resolved, and responsibility should be
transparent, extending to the highest levels within the organisation. System building and
performance will be enhanced if due attention is paid to communication, trialing techniques and
training staff. The effectiveness of each part of the RMS should be tested, and appropriate
periodic performance review mechanisms put in place.

While the general ground of building a RMS has been covered here, readers intending to
undertake this in practice are recommended to further reading in the area of change management.

In the concluding chapter, another facet of risk - the management of opportunity - is considered.

179 | P a g e
 CHAPTER 11
RISK LESSONS LEARNED AND THE PROJECT RISK AUDIT

OBJECTIVE:
 To show learners the methodology behind conducting a risk "lessons learned" review.
 To enable learners understand project risk audit and related concepts.

Content:
Introduction

Risk lessons learned and the project risk audit

11.1 How to do risk lessons learned review

11.2 A postscript to lessons learned

11.3 Summary

Introduction

Dear learners, this chapter addresses how to do a risk "lessons learned" review and a project
risk audit, gives examples, and provides insights on corrective actions based on actual risk
feedback from postmortem sessions.

Hence at the end of this unit, you are expected to:

 Understand how to do how to do a risk "lessons learned" review.

 Understand how to conduct a project risk audit.

180 | P a g e
Dear learners, there are two kinds of "postmortem" on a project and both open up opportunities
to look back at the risk management process to see what worked and what did not.

In Fig. 11.1, "lessons learned” is the first step. This is the process of bringing the team together
for an informal discussion of what went wrong and what went right in the project and what the
impacts were. Then the team identifies where such lessons can be applied in the risk
management process, and identifies possible institutional or organizational problems associated
with the lessons learned. Potential audit issues are identified and then an audit is conducted on
the issues top management would like to earmark for policy, system, or organizational change.

The value of a timely postmortem "lessons learned" review lies in the capturing of insights of the
project team members and stakeholders and documented information on the project cycle, fresh
from "combat." The process is like a military debriefing in the sense that it is well-focused and
tries to capture the intensity of feeling and information all at once. The implications for
successful risk management in future projects are major since it is in the insights about what did
and did not work that the organization and management team gains valuable information on
future project risks and opportunities.

Figure 11.1 Transition from lessons learned to audit

Project Audits

Project audits are not the same as lessons learned. Project audits are performed by external teams
who have not been part of the project process-objective outsiders. The audit has been described
as "the process of coming down off the mountain after the battle to kill the wounded." Such
audits can be very useful if they address issues already identified by the project team. The
purpose of an audit is to connect factors that contributed to project successes and failures based

181 | P a g e
on documents and recorded information, and to match the project outcomes with project goals
and objectives.

11.1 HOW TO DO RISK LESSONS LEARNED REVIEW

A lessons learned project review should be conducted soon after project close out and should
include all project team members, a member of top management, and stakeholder
representatives. The focus should be on identifying what went right and what went wrong and
dimensioning what went wrong in terms of unanticipated or unmitigated risks and uncertainty.
This can be accomplished by scheduling and facilitating the meeting around key risk issues or
topics that help to capture the risks inherent in the project. The following is an example of an
outcome report from a risk lessons learned session in a modern avionics instrument product
development process.

Activity
Dear learners discuss the several factors that need to be considered under lessons learned
report preparation.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___

Example of a lessons learned report

What went right? (Things that we want to recreate for future projects)

 This was a focused team with largely full-time assignments

 Our team was autonomous-we drew the line with the customer appropriate "windows" for
changes, disruptions, and the like
 Little or no scope creep
 Resources (e.g., test equip) allocated to resolve problems quickly
 Contingency plans in place when necessary
 Team defined its approach to documentation, and the like together, "as we went" (also
noted as a weakness below)
 Communication within team was good
 Consistent high priority on this project from corporate-this was a high visibility, high-
priority project from the beginning and we knew it
 Responsiveness of team members to each other very effective
 Project itself was not technically insurmountable: success was feasible
182 | P a g e
  Team able to separate what was controllable from what was not-such as flight test-and
managed accordingly
 Team was highly proficient; good professional and technical skills
 Scheduling process handled resource issues somehow
 Program manager was open to change; flexible in responding to team issues
 Program manager used schedules as guides but was very task and action
oriented in meetings

What went wrong? (Things that we want to correct for future projects)

 Company process and procedure requirements and differing interpretations of document

requirements sometimes acted as barriers to necessary work and did not always facilitate
successful completion of the project, e.g. software documents, reference documents, and
tables
 We sometimes described procedures after we completed them instead of before;
documentation often followed verification rather than guiding it, e.g., STD checklist
 Confusion and uncertainty in the actual application of ISO, procedures on the one hand,
versus "actual" procedures that the team decided were necessary to get the product out on
time
 Company changes (split) created resource issues; we had to "ad hoc" it in handling
engineering change notices, assembly drawings, and the like because of resource
problems created by the split and loss of staff
 Document numbering system created a lot of tension and uncertainty
 Training needs-staff involved in the project were not always trained to carry out
procedures, e.g., staff loading the boxes did not have good guidance and training
 Ineffective version control on some documents and configurations
 Stress created by long hours was a problem-can't stretch people and expect them to stay
on
 Schedules were not accurate, in many cases, compared to the real work, e.g., the
sequence of tests and dry runs
 Sometimes the team did not have the "big picture" on the project; sometimes the big
picture helps to facilitate doing your job
 Wasted time in some meetings-meetings had agendas, but there were times when the
team "blew off steam" and wasted a lot of time
 Some residual issues rooted in "military" versus "commercial" approach had an impact
on the project, which came right in the middle of the transition from military to
commercial ways of doing things

11.2 A POSTSCRIPT TO LESSONS LEARNED

Risk management is in the end a people-centered process, and it is in the key decisions that
people make daily that the conditions for effective risk reduction and response are created.
Because the lessons-learned process focuses on the people who actually did the project work and

183 | P a g e
gleans from them a realistic and practical perspective of risks as they played out in the project,
the lessons learned process can be very valuable.
Project Audit

The project audit starts with the appointment of an auditor and and audit team. The auditor is
typically another project manager who assumes the role of an auditor with some experience in
project planning and control.

Activity
Dear learners discuss some of the fundamental factors that need to be considered under
project risk audit tasks.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
___
The audit, unlike the lessons-learned session, is focused on an Independent gathering of
information and documents from the project, and reviewing them against the goals and
objectives of the project and best practice criteria. This involves the question, "did the project
produce what it intended to produce, and how effectively and efficiently?"

Project audit focuses on key aspects of the project, as follows:

1. Business planning. Were the risks which actually occurred and which impacted the project
identified adequately in the early business planning process?

2. Follow-up response. Were those same risks monitored and controlled?

3. Organization-wide culture. Did top management support effective risk management as part of
the project cycle?

4. Project team. Did the project team members perform their roles as "risk managers" during the
process and integrate risk into their daily work?

5. Risk identification, assessment, and response. Was there a systematic process to identify,
assess, and respond to risks?

6. Key processes, decisions, and milestones. Were key risk-related processes, such as testing and
reliability, quality assurance and control, decision trees, and product development integration
milestones actually followed?

7. Resources. Did the project experience resource constraints and were the constraints managed
with buffers?

184 | P a g e
8. Safety and reliability. Were the correct tests and reliability processes in place?

9. Risk-based scheduling. Were project schedules adjusted using risk inputs and using the MS
Project PERT analysis tool?

10. Monitoring. Were risks followed in the project process and decisions made on risk mitigation
and contingency that reduced risk?

The question of efficiency is reviewed through earned value and cost variance calculations. The
issues would be:

Did the project stay consistent with the schedule and budget?

Did the project manager make adequate adjustments based on variations from risk events'?

Did the project make its quality, schedule, and budget goals?

11.3 Summary
Dear learners, this chapter endeavored to let you see risk lessons learned and project risk audits.
A lessons learned project review should be conducted soon after project close out and should
include all project team members, a member of top management, and stakeholder
representatives. The focus should be on identifying what went right and what went wrong and
dimensioning what went wrong in terms of unanticipated or unmitigated risks and uncertainty.
Project audit focuses on key aspects of the project that include business planning, follow up
response, safety and reliability and others more.

185 | P a g e
 CHAPTER 12

OPPORTUNITY MANAGEMENT
OBJECTIVE:
 To enable learners understand risk related opportunity management.

Content:
12.1 Introduction

12.2 The ‘Adverse impact’ risk perspective

12.3 The risk opportunity perspective.

12.4 Implications for risk management

12.5 Summary

Dear learners, earlier in this module we noted that the prevailing view of risk - as a negative
concept - is under challenge. Writers are now suggesting that focusing only on the
consequences of risk events that may threaten or damage an organization is too negative. It
is thought that a persistently negative view of risk may lead to the abandonment of
otherwise potentially successful projects; de motivation of project teams; and overly
pessimistic attitudes on the part of organizations and the individuals within them.

Instead of concentrating solely on adverse risks, argue the proponents of the 'upside' risk
view, an organization should seek to exploit opportunities arising from its project
involvement. Achieving balance between competing objectives is claimed as the essential aim
of project risk management, and opportunity should be recognized as the natural obverse of
a two-sided coin called 'uncertainty', which hitherto has only been proffered with its adverse
risk face showing.

How appropriate is this dual perspective? How does it affect the processes of organizational
risk management that we have already described? These are the issues addressed in this
chapter.
186 | P a g e
Hence at the end of this unit, you are expected to:

 Understand the basic concept of project risk management under the domain of
opportunity management.

12.1 THE 'ADVERSE IMPACT' RISK PERSPECTIVE

The concept of risks as events with outcomes that threaten the project objectives of a stakeholder
organisation is well entrenched. Indeed, a negative view of risk is prevalent throughout society.
It is reinforced in almost every book written about risk and risk management, or about projects
and project management. This module is no exception. Even where writers are careful to make a
connection between risk and opportunity, the treatment is usually brief and invariably the
examples presented are slanted towards illustrating risks with adverse outcomes. Again, this
module is no exception.

Why is this so, particularly since any good dictionary will offer definitions of risk in terms of
both threat of loss and opportunity to profit? Yet earlier in this module, we too followed the trend
and deliberately chose to adopt a definition of risk which emphasized the negative view. Was
that an appropriate choice?

Several factors serve to explain the grip that the negative view of risk has on contemporary risk
management.

In the first place, qualitative approaches to risk assessment have largely superseded purely
quantitative techniques in modern risk management, mainly on the grounds of applicability and
practicality for risk management purposes. We explored this in chapter 8, and noted that, for
many risks involving project stakeholders, reliable data for quantitative risk assessment were
simply not available; nor were they always needed. However, the mathematical underpinnings to
quantitative risk assessment techniques are unbiased in terms of positive or negative risk
impacts, and in any case concentrate almost exclusively upon the probability of occurrence of
risk events. Qualitative risk assessment, on the other hand, relies heavily upon linguistic
descriptors for alternative risk conditions in terms of likelihood, consequence and duration of
exposure. These too were illustrated in chapter 8. By their nature, linguistic descriptors are often
difficult to express in neutral terms. We can rarely use the same words to describe both horror
and delight (although that does not deter contemporary youth from gleefully using negative
terms to denote positive extremes: e.g. 'wicked!' and 'killer!'). The shift to more qualitative
assessment has reinforced the adverse view of risk simply because the need for negative
descriptors outweighed any demand for positives.

The second reason is linked to the first. In our experience, many people (and most project
stakeholder organisations) tend towards risk aversion in their decision-making, especially in
relation to follow- up decisions after an initial risk-seeking choice. We alluded to this in chapter
12 when we said that a person's risk attitude is not necessarily consistent over the whole range of
decision-making. For example, research has shown that construction contractors tend to display
187 | P a g e
risk-seeking (opportunistic?) behaviour when bidding for new work, but switch to risk aversion
(threat protection?) after winning a tender. Similarly, someone deciding to sail solo around the
world, or walk to the North Pole, has made an initial risk-seeking decision to exploit an
opportunity. Almost every decision the adventurer makes after that, however, is made with the
risk-averse intention of minimisng threats to the achievement of his or her objective. Stakeholder
organisations tend to follow the same pattern in projects of all kinds, although not all
stakeholders are involved in the initial, opportunity-seeking, project decision.

In most cases, the organisational structure adopted for projects also precludes a more risk-
seeking opportunistic approach to risk management. Parkin (1996) notes that much of project
decision-making is guided by codes and specifications and that control of knowledge and
information is the decision-making power source of professional groups or highly skilled
technicians. He subscribes to two contrasting modes of organisational management: the
administrative mode of ordering (structure, hierarchy, function, control, adaptability); and the
enterprise mode of ordering (meaning, interests, power, politics, symbolism). The contrast
between the two modes is in terms of interests, conflict and power. For interests, the
administrative mode of organizational management will try to achieve a set of common
objectives and work closely together to achieve them; while the enterprise mode recognises
individual and group interests. The administrative mode of organising seeks harmony and the
removal of conflict; while the enterprise mode accepts conflict as a natural, and often desirable,
feature of organisations. In terms of power, the administrative organization prefers clear lines of
authority, leadership and control; while the enterprise mode recognises the power of groups and
individuals in resolving conflicts of interest in the organisation.

Given the above characteristics, most projects would be identifiable as predominantly ordered
under the administrative organizational management mode. Since the aims of the administrative
mode are self-evidently intended to protect the organisation from threat, it is hardly surprising
that project risk management focuses almost exclusively on the negative concept of risk. In fact,
stakeholder organizations that happen to be enterprise-oriented may sometimes encounter
problems with their involvement in administratively ordered project organisation structures.
They experience difficulty in conforming to 'expected' norms and attract (often unfairly)
reputations for being 'mavericks' or for failing to be 'team members'.

Finally, the influence of education and training should not be ignored. While any normal
population should naturally include roughly equal proportions of risk-seeking (eager to exploit
opportunities) and risk-averse (determined to avoid threats) people, nurture attempts to
manipulate nature in terms of how we are educated and trained to handle projects. Increasingly,
projects are carefully designed, engineered and managed by people with professional
qualifications. Professional education and the requirements for membership of professional
institutions are largely driven by criteria and content which are more analytical than creative,
more focused upon administrative efficiency than entrepreneurship, more concerned with
prudence than daring.

A negative perspective of risk in contemporary project risk management therefore simply reflects
the reality of the sentient management environment of most projects. It is self-perpetuating

188 | P a g e
through the attitudes, education, training, and roles of many of the participants. Before deciding
if the negative perspective is more appropriate, however, the counter-perspective must be
explored.

12.2 THE 'RISK OPPORTUNITY' PERSPECTIVE

Activity
Dear learners,do you think that threat management and opportunity management are equally
important in terms of their influence upon the success of projects. Explain
.

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

Writers challenging the essentially negative view of project risk management argue that it
emphasises the management of bad luck and fails to capitalise on good luck. Another argument
states that the negative approach does not permit consideration of potential trade-offs between
project objectives; that opportunities levered off one objective cannot be used to enhance
achievement in another, simply because the management approach is focused exclusively upon
potential threats to each objective.

It is also suggested that risk management is usually delayed until the project and its scope are
sufficiently defined, because having more information available will permit risks to be dealt with
more effectively. The delay thus limits any early systematic search for opportunities to exploit in
terms of improving project performance.

The first argument is somewhat simplistically reductionist, since it assumes that every
opportunity must have positive outcomes and that every threat will be completely negative. It
fails to consider that exploiting opportunities will almost certainly introduce more risks and
change the characteristics of others. It also fails to consider that treating the negative effects of
threats may produce other positive results.

The argument, that potential trade-off between project objectives is neglected with a purely
negative risk perspective ignores the modern development of value management techniques
which are deliberately aimed at clarifying objectives at the inception of projects, so that the key
project stakeholders can achieve a common understanding about them. An effective value
management intervention in a project should include the explicit exploration of opportunistic
tradeoff between objectives.

189 | P a g e
Delaying the use of risk management on a project until sufficient information is available runs
counter to the purpose of risk management and fails to appreciate the benefits of a dynamic
RMS. Risk management is not a one-off intervention at a single point during a project, but a
systematic and ongoing approach to dealing with risks over the whole life of the project. The
project RMS should be implemented at the commencement of the project, so that it is able to
influence the outcomes of decision-making at the earliest possible stage.

Although the arguments presented to date may be weak, the positive 'opportunity' view of risk
and risk management is valid. The concept of 'risk' and 'reward' is well understood in financial
investment management, and the notion of 'threat' and 'opportunity' is not far distant from this.
The two may be seen as opposite extremes on a continuum of risk, as shown in figure 15.1.

Figure 12.1 Threats and opportunities in risk management

Given this continuum, two inferences can be made. The greater the focus on threats in risk
management, the greater the number of opportunities that may be missed. Conversely, the greater
the focus on opportunities, the greater the exposure to threats will be, since all opportunities
bring with them their own 'downside' potential, and less effort will be directed towards dealing
with existing threats.

12.3 IMPLICATIONS FOR RISK MANAGEMENT

Accepting a dual view of risk has some implications for project risk management. In the first
place, the consideration of opportunities should not be allowed to distract the organisation from
190 | P a g e
properly assessing the nature and magnitude of the threats it faces. Surely it is better to miss an
opportunity than to overlook a threat? In other words, threats to the achievement of project
objectives should be accorded due priority in risk management.

Secondly, the people given the task of managing threats may not be best suited to explore and
exploit opportunities. It should not be assumed that everyone involved with risk management
will be equally adept in dealing with both extremes of the risk continuum. The increasing
proliferation of specialist (subcontractor) project stakeholders is evidence of this. The inability of
a single stakeholder to deliver all the elements of a project (tasks, technologies, resources,
organisation) leads inevitably to the introduction of others who, because of their specialised
knowledge or skills, are able and willing to take advantage of the opportunity to deliver specific
project subelements. In a sense therefore, subcontracting is as much an opportunistic response to
risk by the subcontractor as it is a means of transferring risk by the head contractor.

Given these arguments, the effect of incorporating opportunity management into a RMS must be
carefully considered. The stages of the RMS would remain the same: identification; analysis;
response; monitoring and control; recording and archiving, but some differences will occur
within each stage.

In the risk identification stage, the techniques for recognizing opportunities are essentially
similar to those used for identifying threats, and the risk categories suggested in figure 2.5 would
be applicable to either.

Effectively, however, the threats should be identified first, in order to establish a clear basis for
exploring opportunities. Thus the question 'what could happen to threaten the successful
attainment of this objective (in terms of task, technology, resource, organisation)?' would be
followed (and not preceded) by 'how could this success be improved?'

Precise opportunity statements should flow from the identification stage: there is a chance 'p' that
benefit 'b' will be obtained if opportunity 'c' is exploited during the period 't'. Note that this
statement differs from that suggested in chapter 6 for adverse risk events. In opportunity
management, the probability attaches not to the occurrence of an event leading to a consequence,
but to the attainment of a particular outcome if a particular decision is made.

191 | P a g e
Table 12.1 Interval descriptors for risk opportunity impacts

The risk threat severity scale seen before still applies, but would indicate the potential magnitude
of an opportunity. Theoretically, given the application of the 5-point rating scales suggested in
chapter 8, it should be possible to score both threats and opportunities during the risk analysis
stage. Then any opportunity risk achieving a score substantially higher than its threat counterpart
could be accorded priority in terms of treatment. The validity of such priority should be carefully
tested and justified, however.

The labels used in chapter 11 to describe alternative risk treatment options in the risk response
stage of the RMS are inappropriate to indicate how risk opportunities might be dealt with.
Baccarini (2002) and Hillson (2001) have proposed contrasting risk opportunity labels.
These are set out in table 15.2, showing the contrast between alternative treatments for adverse
risk threats and those for risk opportunities. Clearly, an exact correspondence between treatment
options at either end of the risk continuum is not possible. This fact supports our earlier caution
that threat and opportunity aspects of risk management should not be attempted simultaneously,
especially since the risk response stage of a RMS directly involves a critical decision making
phase for the system.

The monitoring and control stage of a RMS could be adapted to encompass opportunity
management, but the processes involved in this stage are likely to be substantially different to
those needed for monitoring and controlling risk threats. The processes used to capture
subsequent knowledge from risk opportunity management should be conducted separately from
those used to record risk 'threat' experiences, since the nature of the information and the manner
in which it will be used in the two situations are unlikely to share similarities.

For strategic approaches to risk management, the strategic risk management indicator described
in table 9.1 can be applied to opportunity management without amendment.
192 | P a g e
Table 12.2 Contrasting 'threat' and 'opportunity' response options in project risk
management

12.4 SUMMARY
Contrary to some writers, we believe that threat management and opportunity management are
not equally important in terms of their influence upon the success of projects. .

The success of projects is determined by the achievement of the objectives established for them.
Realistically, most projects are undertaken not with the aim of maximising the exploitation of all
possible opportunities but in order to fulfill pre-defined functions. A project which delivers those
functions can still be considered successful, even though a potentially better project which could
have delivered more benefits might have been within reach if identifiable opportunities had been
exploited. The priority of a project stakeholder organization should be to first ensure the
attainment of its objectives.

Our view is therefore that, while threat and opportunity can be seen as opposite poles on a risk
continuum, the prior focus of risk management in any project stakeholder organisation should
always be upon events (and their consequences) that threaten the achievement of objectives. If
these objectives are not attained, the project cannot be successful. On the other hand, if project
objectives are achieved, but could have been exceeded, the project cannot be said to be
unsuccessful.

Note that this is not to say that opportunities must be ignored. It is simply a matter of setting
appropriate management priorities in terms of available resources, and also of ensuring that the
staff engaged in risk management activity are best suited for the tasks they are carrying out.
193 | P a g e
Despite concluding with a chapter which appears to contradict the premise upon which this book
commenced - that risk is the chance that an adverse event will occur during a stated period of
time – we hope that throughout this book a consistent and practically useful approach to risk
management in project organizations has been presented and demonstrated.

As with any management tool or technique, project risk management cannot be applied
passively, nor should it be regarded as static. An active approach to the application of risk
management will yield positive benefits to any project organization. Maintaining an active
approach, through a continuing cycle of learning and improvement, should contribute much
towards ensuring that these benefits are sustained over the long-term life of the organization.

194 | P a g e
 BIBLIOGRAPHY
1. Barkley, B. T., PROJECT RISK MANAGEMENT, The, Mc, Graw-Hill Companies
Inc., 2004.

2. Edwards, P. J., and Bowen, P. A., RISK MANAGEMENT IN PROJECT

ORGANIZATIONS, Elsevier Butterworth Heinemann, 2005.

3. Chapman, C., and Ward, S. PROJECT RISK MANAGEMENT, Processes,

Techniques and Insights, John Wiley & Sons Ltd., 2003.

4. King, R., RISK MANAGEMENT, Scitech Educational Ltd., 2000.

5. Harrington, S. E. and Niehaus, G. R. RISK MANAGEMENT AND INSURANCE,

Irwin/Mc Graw Hill Companies, 1999.

195 | P a g e