Project Risk

A project risk is often described as:

“any event with an undesirable outcome for the project that may happen sometime in the
future.”
The 2000 edition of the Guide to the Project Management Body of Knowledge (PMI, 2000)
states that a project risk is:
“an uncertain event or condition that, if it occurs, has a positive or negative effect on a
project outcome”
Project risks are characterised by the fact that:
they are usually at least partially unknown
they change with time
they are manageable, in the sense that action may be taken to change their impact
they exist only in the future tense – there are no past risks, only actual occurrences
they exist in all projects.
Risk management is about balancing the harmful effects of risk against potential project
benefits.
The more beyond your control, the higher the risk
Examples of risks in a project include:
Costs & timescales underestimated (contingency mismanaged)
Resources (Skills, availability, numbers)
Project management shortfalls
Lack of planning
Operational conditions
Image/credibility
Health and Safety
Scope: Definitions, scoping of project
Integration, planning problems, resource allocation
Quality, poor quality attitude, no QA plan, workmanship
Communications, poor links with project team & stakeholders
Risk, ignoring risk, attitude
Procurement, contractual, confrontational or adversarial approach, claims, liquidated
damages, arbitration
Risk Management Process (Pinto, 2007)
Identify
Analyse
Devise strategy for risk mitigation
Apply control and documentation to track changes
Risk assessment
The following activities are associated with risk assessment:
¨ Risk identification
¨ Risk analysis
¨ Risk prioritisation
Risk identification
Technology risks
People risks
Organisational risks
Requirements risks
Estimation risks
A risk assessment matrix is a convenient way to categorise this information in order to assess
the overall risk of ‘project failure’
Assessing Risks
Assess probability and seriousness of each risk
Probability may be very low, low, moderate, high or very high
Risk effects might be catastrophic, serious, tolerable or insignificant
Risk resolution
The primary goal of risk management
Is achieved by implementing the activities in the risk response plan to eliminate or
reduce exposure to the identified risks
The key to risk resolution is making sure that risk response plans are fully integrated
into the project plans and actioned by the appropriate people in a timely manner.
Risk response planning
Consider each risk and develop a strategy to manage that risk:
Avoidance strategies
The probability that the risk will arise is reduced
Minimisation strategies
The impact of the risk on the project or product will be reduced
Contingency plans
If the risk arises, contingency plans are plans to deal with that risk

Risk Management
The Project Management Institute’s (PMI) publication A Guide to the Project Management
Body of Knowledge (PMBOK® Guide) 3rd Edition, 2004, states that risk management is “the
systematic process of identifying, analyzing, and responding to project risk”* and consists of
six subprocesses, and, as we shall see below, a seventh subprocess needs to be added.

1.Risk Management Planning—deciding how to approach and plan the risk management
activities for a project.
2. Risk Identifi cation—determining which risks might affect the project and documenting
their characteristics.
3. Qualitative Risk Analysis—performing a qualitative analysis of risks and conditions to
prioritize their impacts on project objectives.
4. Quantitative Risk Analysis—estimating the probability and consequences of risks and
estimating the implications for project objectives.
5. Risk Response Planning—developing procedures and techniques to enhance opportunities
and reduce threats to the project’s objectives.

6. Risk Monitoring and Control—monitoring residual risks, identifying new risks, executing
risk reduction plans, and evaluating their effectiveness throughout the project life cycle.
Before proceeding, we must add a seventh subprocess, which is our addition, not the PMBOK’s.
7. Create and Maintain a Risk Management Data Bank—a permanent record of identifi ed
risks, methods used to mitigate or resolve them, and the results of all risk management
activities.
Ward (1999) defi nes a straightforward method for conducting PMBOK’s six subprocesses
that includes a written report on risk management, if not the creation of a risk database. In our
opinion, there are two major problems in the way that risk management is carried out by the
typical organization that actually does any semiformal risk management. First, subprocess 7
is almost invariably ignored. Second, risk identifi cation activities routinely (1) fail to consider
risks associated with the project’s external environment and (2) focus on misfortune, overlooking
the risk of positive things happening.
If the risk management system has no memory, the task of risk identifi cation will be
horrendous. But the system can have a memory—at least the individuals in the system can
remember. Relying on the recollections of individuals, however, is risky. To ensure against
this particular risk, the risk management system should maintain an up-to-date data bank that
includes, but is not restricted to, the following:
• identifi cation of all environments that may impact on the project
• identifi cation of all assumptions made in the preliminary project plan that may be the
source of risk for the project
• all risks identifi ed by the risk management group, complete with their estimated
impacts on the project and estimates of their probability of occurring
• a complete list of all “categories” and “key words” used to categorize risks, assumptions,
and environments so that all risk management groups can access past work done on risk
management
• the details of all qualitative and quantitative estimates made on risks, on states of the
project’s environment, or on project assumptions, complete with a brief description of
the methods used to make such estimates
• minutes of all group meetings including all actions the group developed to deal with
or mitigate each specifi c risk, including the decision to ignore a risk
• the actual outcomes of estimated risks and the results of actions taken to mitigate
risk
If all this work on data collection is going to be of value to the parent organization beyond
its use on the project at hand, the database must be available to anyone proposing to perform
risk management on a project for the organization. Almost everything a risk management
group does for any project should be retained in the risk database. Second, all risks must be
categorized, the environments in which projects are conducted must be identifi ed, and the
methods used to deal with, augment, or mitigate them must be described.
The use of multiple key words and categories is critical because risk information must be
available to managers of widely varied disciplines and backgrounds. Organizations may be
conducting a great many projects at any given time. If each risk management team has to start
from scratch, without reference to what has been learned by previous groups, the management
of risk will be extremely expensive, take a great deal of time, and will not be particularly
effective. Rest assured that even with all the experience of the past readily available, mistakes
will occur. If past experience is not available, the mistakes of the past will be added to those of the future.
Unfortunately, the literature of project risk management rarely mentions the value
of system memory. (An exception to this generalization is Royer (2000) and the latest version
of PMBOK.)
The identifi cation of potentially serious risks can be done in a number of ways, but the
following method is straightforward and extensively used, particularly in engineering analysis.
Risk Identifi cation through Failure Mode and Effect Analysis (FMEA) FMEA (Stamatis,
2003) is the application of a scoring model such as those used for project selection in
Chapter 2. It is easily applied to risk by using six steps.
1. List possible ways a project might fail.
2. Evaluate the severity (S) of the consequences of each type of failure on a 10-point scale
where “1” is “no effect” and “10” is “very severe.”
3. For each cause of failure, estimate the likelihood (L) of its occurrence on a 10-point scale
where “1” is “remote” and 10 is “almost certain.”
4. Estimate the ability to detect (D) a failure associated with each cause. Using a 10 point scale,
“1” means detectability is almost certain using normal monitoring/control systems and “10”
means it is practically certain that failure will not be detected in time to avoid or mitigate it.
5. Find the Risk Priority Number (RPN) where RPN _ S _ L _ D.
6. Consider ways to reduce the S, L, and D for each cause of failure with a signifi cantly
high RPN.
An Added Note on Risk Identifi cation The risks faced by a project are dependent on
the technological nature of the project, as well as on the many environments in which the
project exists. [Recall that we use the word “environment” to refer to anything outside a system
(the project) that can affect or be affected by the system.] Indeed, the manner in which
the process of risk management is conducted depends on how one or more environments
impact the project. The corporate culture is one such environment. So consider, for instance,
the impact of a strong corporate “cost-cutting” emphasis on how risk managers identify and
deal with risks in the areas of personnel and resource allocation. Note that this refers to the
process of risk management—carrying out the six or seven subprocesses—not merely to the
identifi cation of risks.
The need to consider the many environments of almost any project is clear when one
examines the recent articles on risk management. It is typical to consider only the internal
environment of the project, e.g., the technical and interpersonal risks, and occasionally, negative
market risks for the project. Articles on risks in IT and software projects rarely go beyond
such matters—Jiang et al. (2001) is an example. This is a thoughtful development of a model
for generating numerical measures for IT project risks. The specifi c user of the IT and the
institutional setting of the project are considered, but competitors, the IT market, user industries,
the legal environment, and several other relevant environments are ignored.
Organizing for Risk Management The mere existence of a set of activities that must be
undertaken in order to manage risk implies that some sort of organization is required to do
the work of risk management. Because any individual fi rm might undertake a wide variety of
projects based on different technologies, developed for different markets, subject to potential
regulation by different levels of government, and with different stakeholders, no single risk
management unit can be expected to deal with all projects. Routine machine repair and
maintenance projects (if they are similar in size and scope to one another) might have one
risk management group for all such projects. In general, however, a unique risk management
group is formed for each project.

The specifi c membership of this group depends on the nature of the project. If the project’s
objective is to develop a new product (or product line), the risk management team might
include the following: (1) a specialist in the science or technology of the proposed product;
(2) a market specialist who can make an informed estimate of the total market size and amount
of sales for the potential product as well as the impact that the proposed product may have on
the sales of the fi rm’s other products, and the state of potential competition; (3) a manufacturing
specialist who can foresee risks in the fi rm’s (or its subcontractor’s) ability to manufacture
the product with an acceptable level of quality; (4) a purchasing specialist who can foresee
risks in the fi rm’s supply chain; (5) a product safety expert to foresee risks in the area of product
liability as well as a public relations professional and an attorney to help deal with matters
if safety claims are made against the fi rm; (6) a patent attorney to assess the risks of patent
infringement; (7) an individual (perhaps a program manager) who understands the complete
set of the fi rm’s projects and can identify any projects that might contribute to or profi t from
the project in question; (8) the same or a different person who can foresee possible personnel,
resource, or scheduling confl icts caused by or threatening this project; and (9) a governmental
relations expert who knows what governmental licenses or approvals may be required for
manufacturing processes or product release. Clearly, some of the above members might only
attend meetings during the risk identifi cation and response planning sessions. The group could
investigate the potential product’s window-of-opportunity that we discussed in Chapter 2 as a
way of estimating market risk.
If we had chosen a different project, say a process improvement, the list of risk management
group members would have included some with the same expertise as above and some with
others. For example, the group would need to include industrial engineers who could understand
risks affecting the ability to maintain current production schedules while installing a
new machine in the production system, fi nancial experts to look for potential glitches in the
estimated cash fl ows, a specialist in air and water pollution to foresee risks in those areas, and
potential users of the process.
It is never too early in the life of a project to begin managing risk. A sensible project selection
decision cannot be made without knowledge of the risks associated with the project. Therefore,
the risk management plan and initial risk identifi cation must be carried out before the project can
be formally selected for support. The risk management group must, therefore, be formed as soon
as a potential project is identifi ed.
At fi rst, project risks are loosely defi ned—focusing for the most part on externalities such
as the state of technology in the fi elds that are important to the project, business conditions
in the relevant industries, and so forth. The response to external risks is usually to track the
pertinent environments and estimate the chance that the project can survive various conditions.
Not until the project is in the planning stage will such risks as those associated with project
technology, schedule, budget, and resource allocation begin to take shape. The actual development
of a risk management plan will be discussed in Chapter 6.
Because risk management often involves analytic techniques not well understood by PMs
not trained in the area, some organizations put risk specialists in a project offi ce, and these
specialists staff the project’s risk management activities. For a spectacularly successful use of
risk management on a major project, see Christensen et al. (2001), a story of risk management
in a Danish bridge construction project.
Dealing with Disaster Thus far, we have focused mainly on risks that might be considered
normal for any fi rm undertaking projects. We have dealt with these risks by using an “expected
value” approach to a cost/benefi t analysis, as in the PsychoCeramic Sciences example,
that is, the estimated loss (or gain) associated with a risky output times the probability that
the loss (or gain) will occur. We might also compare the expected loss associated with a risk
5.6 TWO SPECIAL CASES—RISK MANAGEMENT AND THE PROJECT OFFICE 209
to the associated expected cost of mitigating or preventing the loss associated with the risk.
If the reduction in expected loss is greater than the cost of risk mitigation or prevention, we
would invest in risk prevention.
What about the case when the loss is catastrophic, even potentially ruinous, though it
may have a very low probability of occurring; e.g., a run on a bank; a strike at a critical supplier’s
plant; a fl ood that shuts down a construction project; an attack by a terrorist group on a
building; or the discovery that a substance in a complex drug might cause toxic side effects?
In many such cases, the cost of the risk may be massive, but the likelihood that it will occur is
so small that the expected cost of the disaster is much less than many smaller, more common
risks with far higher probabilities of occurring.
An excellent book, The Resilient Enterprise (Sheffi , 2005), deals with risk management
concerning many different types of disasters. The book details the methods that creative
businesses have used to cope with catastrophes that struck their facilities, supply
chains, customer bases, and threatened their survival. The subject is more complex than we
can deal with here, but we strongly recommend the book, a “good read” to use a reviewer’s
cliché.