E-mail: email@example.com Web Site: www.idc-online.com
AUSTRALIA CANADA IRELAND NEW ZEALAND SINGAPORE SOUTH AFRICA UNITED KINGDOM UNITED STATES
The objective of this chapter is to set out a basis for risk management that will provide
sufficient understanding of the process for implementing effective risk management for a
All projects have associated risks. The extent to which risks exists for a particular project
component determines how sensitive successful project outcomes are to that component.
Effective project management requires that, if project outcomes are risk sensitive, relevant
risks are properly managed.
The procedures described in this chapter conform to definitions and processes defined in
document AS/NZS 4360:2004 Risk management.
A detailed review of the analytical techniques necessary to undertake comprehensive
quantitative analysis is outside the scope of this chapter.
4.1 Definition of ‘risk’
Risk is the exposure to a process or event that prejudices the successful achievement of the
project outcome, by adversely impacting on cost, time, or functional objectives.
The elements of risk are:
• The likelihood of the event arising; and
• The consequences if it does arise
The inter-relationship of these elements is shown in Figure 4.1.
50 Practical project management for engineers and technicians
HIGH R re
Ca ta strophe Disa ster
CONS QU NCE
LOW Unlikely a nd Frequent
Insignifica nt Irritation
L E IHOOD
4.2 Risk management
The following definitions will be used throughout this chapter (see Table 4.1).
Qualitative description of probability and frequency
Residual risk The level of risk remaining after risk treatment measures have been
Risk acceptance An informed decision to accept the likelihood and the
consequences of a particular risk
Risk analysis A systematic evaluation of available data to determine how often
specified risk events occur and the magnitude of their likely
Risk assessment The process to determine risk management priorities
Risk avoidance An informed decision to avoid a particular risk by not allowing the
situation whereby the risk arises
Risk control The use of policies, standards and procedures to avoid, eliminate,
or minimize risks
Risk management The systematic application of management policies procedures and
practices to the tasks of identifying, analyzing, assessing, treating
and monitoring risks
Risk reduction The use of appropriate techniques to reduce either the likelihood or
consequence of a risk, or both
Risk removal Elimination of the risk
Risk retention Retaining, either intentionally or unintentionally, the losses arising
from the risk
Risk transfer Transferring the losses arising from the risk to another party
Risk treatment Selection and implementation of a preferred option for dealing with
The main elements of the risk management process are:
• Establishing the context
• Risk identification
• Risk analysis
• Risk assessment
Risk Management 51
• Risk treatment
• Monitoring and reviewing
4.2.3 Benefits and costs
The benefits from applying risk management accrue to both the project team and to the
project sponsor. These benefits include:
• Providing a more informed basis for committing to the project financially
• An increased understanding of the project, leading to better planning
• Development of more suitable project processes (e.g. contracting
• Facilitation of more rational risk taking
• Improving the distinction between good luck and good management
The cost of applying risk management to a project varies, as a function of the scope of the
project and the depth to which the process is applied. Costs can be very low (say, a few
hours) at one end of the scale, and ranging up to several percent of the total management
costs if done in depth and as an ongoing process throughout all project phases.
4.2.4 Application of risk management
Risk management is applicable to all projects. While this may be obvious, it is the
widespread experience of project managers that it is difficult to convince clients to adopt
comprehensive risk management processes.
While it is clearly of great relevance on large or complex projects, it will provide benefits on
all projects except on recurring projects being undertaken in an unchanging environment - if
such a situation ever arises.
Risk management is a continuous process that can be initiated at any point in the project
cycle, and continued until the costs of maintaining the process exceed the potential benefits.
It has the greatest potential benefits if used early on in the project. The following points
within a project should be specifically addressed within the risk management processes:
• During the feasibility study - to assist the selection of implementation
• At the time of client commitment - to properly understand the real exposure to
• At time of tender - by contracting parties
• Post tender - by the project manager to assess the likely performance of the
• During implementation - to monitor existing and emerging risks and amend
and/or develop appropriate management strategies
In order to maintain a record to facilitate ongoing reviews as well as an adequate audit trail,
all components of the risk management process must be adequately documented.
Sample documentation, based on that recommended within AS/NZS 4360:2004, is
52 Practical project management for engineers and technicians
4.3 Establishing the context
The outputs from this step are:
• Definition of the elements within the project to define a structure for the
identification and analysis of risks; and
• Definition of risk assessment criteria directly related to the policies, objectives
and interests of stakeholders
This process reviews the strategic, organizational and project contexts.
4.3.2 The strategic context
This analysis reviews the operating environment of the organisation. The purpose is to
identify factors that enhance or impair the ability of the organisation to manage risks. This
includes the financial, operational, competitive, political, legal, social, and cultural aspects of
the operating environment.
4.3.3 The organizational context
This analysis is directed at defining the capabilities of the organisation, its goals, objectives
4.3.4 The project context
This analysis is directed to the specific project objectives and its component technologies,
activities, timing and physical environment.
4.4 Risk identification
The purpose of this step is to identify all the risks, including those not under the control of
the organisation, which may impact on the framework defined above.
A systematic process is essential because a risk not identified during this step is removed
from further consideration.
The first step is to identify all the events that could affect all elements of the framework.
The second step is to consider possible causes and scenarios for each event.
The process of risk identification can be complex, and a planned approach is necessary to
ensure that all sources of risk are identified. This process may involve:
• Identifying the key personnel associated with the project, i.e. those whose
understanding of the project environment and the project processes enables
them to properly appreciate the sources of risk
• Undertaking structured interviews with these personnel. Checklists should be
used to ensure comprehensive coverage of all project elements. The objective
is to determine, from each person; concerns, constraints and perceived risks
within their area of expertise
• Organizing brainstorming sessions
• Engaging the services of specialist risk analysts
• Reviewing past experiences in this regard
Risk Management 53
4.5 Risk analysis
The objectives of risk analysis are to:
• Assign a level of risk to each identified event
• Provide data to assist the assessment and treatment processes
• To separate minor, acceptable risks from other requiring further consideration
Risk is analyzed by consideration of the likelihood and consequence of events occurring
within the context of existing controls i.e. management procedures, technical systems and
risk management procedures.
The analysis can be carried out to various levels of refinement by way of qualitative and
quantitative analysis, or a hybrid of the two. It is necessary to avoid subjective biases when
analysing the likelihood and consequences of individual risks.
4.5.2 Qualitative risk analysis
Once the risks associated with every area of the project have been identified, the impacts of
these risks are assessed qualitatively. Where the impact that the risks within specific areas
have on the overall project may be different, the resulting impacts need to be evaluated
independently. All identified risks are categorised into low/high probability, and low/high
Initial responses for the significant risks should be developed at this stage. If risks requiring
immediate response are identified, then the initial response should be implemented. A
proposed response to an initial risk may result in consequential risks not initially present.
These are known as ‘secondary risks’. Secondary risks need to be included in the risk
assessment process as they may dictate that a proposed response to a primary risk is not
This analysis can be performed with software such as ‘RiskTrak’. The advantage of using
software is that it ensures that few questions are left un-asked, and also provides a database
with all risks, their assessment and methods of addressing them that can be accessed by the
entire project team.
Interviews are conducted in general or specific project. Figure 4.2 shows the interviewing in
54 Practical project management for engineers and technicians
Risk interview in progress
Once the project-related risks have been identified, their chance of occurring and the related
severity of such an occurrence have to be ascertained, together with the method and costs of
addressing the issue. This is done via a conventional possibility/consequence matrix as
shown in Figure 4.3.
Risk Management 55
4.5.3 Quantitative risk analysis
A quantitative risk analysis enables the impacts of the risks to be quantified with respect to
the three fundamental project success criteria: time, cost and functionality.
The techniques outlined below have been developed for analysing the effects of risks on the
time and cost outcomes of projects, and are in common use. These techniques are well
documented in the literature, and a detailed treatment is outside of the scope of this chapter.
These techniques are often not applicable to analysing risk impacts on functionality
Generally considered to be the simplest analytical technique to apply, this analysis
determines the effect on the desired dimension of the project - i.e. time, cost, functionality -
from changing each one of the risk variables independently.
The resulting Sensitivity Diagrams - one for each project dimension modeled - identifies
impact each variable has on project outcome, and what those impacts are. By inspection, the
critical variables are apparent. This provides the opportunity to develop a risk management
strategy that targets the most critical risks.
Probabilistic analysis is an analysis to identify the frequency distribution for a desired project
outcome, e.g. total project cost, internal rate of return or total project duration.
56 Practical project management for engineers and technicians
The most common form of this analysis uses sampling techniques, normally referred to as
Monte Carlo Simulation. This can only be practically undertaken using an appropriate
software application package.
A mathematical model of the project is developed, incorporating all relevant variables. A
probability distribution is then defined for each variable, and the project model is analyzed
taking into account all risks in combination. This analysis is repeated a number of times,
typically 100 to 1000 passes, and at each pass the value for each variable is randomly
calculated within the assigned probability distribution. The results from each analysis
provide a distribution frequency of the project outcome. This establishes a mean outcome,
and the range of outcomes possible.
Probabilistic analysis can be performed on cost as well as project schedules. One of the
better-known software packages in this regard is @RISK, although there are various
alternatives on the market, some stand-alone and others as add-ons for scheduling packages
such MS Project and Primavera. An example of an inexpensive software package for Monte
Carlo analysis on project costs is Project Risk Analysis. The following figures show the
statistical behavior of project costs for a given project (see Figure 4.4).
Project Risk Analysis: Cost distribution (Courtesy Katmar Software)
If the above bell curve distribution is integrated from left to right, it yields a so-called S
curve that indicates the possibility that the cost will be less than a given value (see Figure
Risk Management 57
S-curve (Courtesy Katmar software)
From the S-curve (specific values on the X-axis are available via the ‘Statistics’ function) it
can be seen that, despite a mean cost of $4978 being predicted, there is only a 50% chance of
that happening. In order to guarantee the cost with 99% certainty, provision has to be made
for a cost of up to $5395, i.e. a contingency of $417 or 8.79% is required.
An alternative to Monte Carlo Simulation is the Controlled Interval and Memory Method.
On less complex analyses this technique offers great precision for less computer effort.
This method has been in use for a considerable time and provides for decision making based
on a relatively crude risk assessment. Decision trees display the set of alternative values for
each decision, and chance variable as branches coming out of each node. Figure 4.6 shows
the decision tree for the R&D and commercialization of a new product.
Decision tree (Courtesy Analytica)
58 Practical project management for engineers and technicians
This is a relatively new technique, used as an interface with computer based risk models to
facilitate development of complex risk models (see Figure 4.7).
Influence diagram (Courtesy Analytica)
Decisions, shown as rectangles with sharp corners (i.e. ‘Fund R&D’ and ‘Launch Product’),
are variables that the decision maker has the power to control. Chance variables, shown as
oval shapes (‘Success of R&D’ and ‘Market success’), are uncertain and cannot be
controlled directly. Objective variables, shown as hexagons (‘Market value’), are
quantitative criteria that need to be maximized (or minimized). General variables (not shown
here) appear as rectangles with rounded corners, and are deterministic functions of the
quantities they depend on.
Arrows denote influence. If ‘Market success’ influences ‘Market value’ it means that
knowing the extent of the ‘Market success’ would directly affect the beliefs or expectations
about the ‘Market value’. An influence expresses knowledge about relevance and does not
necessarily imply a causal relation, or a flow of material, data, or money.
Influence diagrams show the dependencies among the variables more clearly than decision
trees would. Although decision trees show more details of possible paths or scenarios as
sequences of branches from left to right, all variables have to be shown as discrete
alternatives, even if they are actually continuous. In addition, the number of nodes in a
decision tree increases exponentially with the number of decision and chance variables and,
as a result, Figure 4.6 would need in excess of a hundred nodes to display the decision tree
for Figure 4.7, even if we assume only three branches for each of the two decisions and two
4.6 Risk assessment
Risk assessment is the process of comparing the levels of risks determined from the analysis
process against the acceptance criteria previously established.
The output from the risk assessment is a prioritised list of risks requiring further action.
4.6.2 Categories of risk
The assessment process will determine whether risks may be categorised as low or
acceptable, or other.
Low or acceptable risks may be accepted as they are, or with minimal further treatment,
subject only to ongoing monitoring.
Risks that fall into the other category are subject to a specific treatment option.
Risk Management 59
4.7 Risk treatment
Risk treatment involves identifying the range of options available for treating risks identified
as requiring action in the previous stage, evaluating those options in respect of each risk, and
developing and implementing risk treatment plans.
Note that some risk response activities may have been undertaken during the qualitative
analysis step, if the urgency of developing a response to specific risks warranted it.
4.7.2 Identifying treatment options
Risk treatment options include the following. These options may not necessarily be mutually
exclusive, or appropriate in all circumstances.
• Risk avoidance means not proceeding with the activity or situation giving rise
to the risk
• Risk removal eliminates either the likelihood or the consequences of the risk
• Risk reduction reduces either the likelihood (e.g. by training programmes, QA
programmes, preventative maintenance, etc) or the consequences (e.g. by
contingency planning, design features, isolation of activity, etc)
• Risk transfer transfers all or part of the risk to another party. Mechanisms
include the use of contracts, insurance, and organisational structures (e.g. a
• Risk acceptance, if necessary, can be adopted in conjunction with an
appropriate risk financing plan
There are two additional classifications for risk treatment responses, viz. immediate or
• An immediate response is one where the project plan is amended in order for
the identified risk to be avoided, or its impact minimized
• A contingency response is one where provision is made within the project plan
for a contingent course of action that will only be initiated if the risk occurs
4.7.3 Evaluating treatment options
Options generated for risk treatment should be evaluated on the basis of the extent of risk
reduction versus the costs of doing so, taking into account the risk assessment criteria
Clearly large reductions in risk where achieved for relatively low cost should be
implemented. Other opportunities may be less easily justified on economic grounds,
including the need to consider rare but severe risks that cannot be economically justified, but
which could be fatal if they arose. Some risks provide benefits (e.g. adoption of new
technology) that need to be factored into the evaluation.
4.7.4 Developing risk treatment plans
Treatment plans document how the selected treatment options will be implemented. They
define responsibilities, time frames, expected outcomes, budgets, performance measures and
Effective implementation of the risk treatment plan, including undertaking the planned
reviews, requires appropriate management input on an ongoing basis. This should be
addressed within the project planning.
60 Practical project management for engineers and technicians
4.8 Monitoring and review
Monitoring and review of all elements of the risk management programme is essential.
The specific risks themselves, as well as the effectiveness of the control measures, need to be
monitored. Few risks remain static and factors impacting on the likelihood or consequences
Changing circumstances may alter earlier priorities, and factors impacting on the cost/benefit
of management strategies may vary. If, following treatment for a specific risk, there is still a
residual risk, then the management of that risk needs to be investigated.
Risk management 61
___________________________________________ Compiled by ______________ Date____________
ON _________________________________________ Reviewed by ______________ Date____________
Sheet ____ of
THE RISK LIKELI-HOOD CONSE- LEVEL OF RISK
RIPTION CAUSE LIKELIHOOD CONSEQUENCES ADEQUACY OF EXISTING
ASHCROFT & ASSOCIATES LTD
62 Practical project management for engineers and technicians
RISK TREATMENT SCHEDULE
PROJECT___________________________________________________ Compiled by_________________ Date_______ Sheet ____ of _
FUNCTION/ACTIVITY _________________________________________ Reviewed by_________________ Date_______
THE RISK TREATMEN RATING AFTER COST BENEFIT PREFERRED TIMETABLE FOR PERSON REVIEW
T OPTIONS TREATMENT ANALYSIS OPTIONS IMPLEMENTATON RESPONSIBLE SCHEDULE
ASHCROFT & ASSOCIATES LTD
Risk management 63
RISK ACTION PLAN
PROJECT Compiled by __________________
__________________________________________ Date ________
Reviewed by __________________ Date ________ S
REF DATE BY REVIEW ACTION RESPONSIBILIT
REF DATE REVIEW COMMENT/ACTION REQUIRED ACTION COMPLETE
ASHCROFT & ASSOCIATES LTD
64 Practical project management for engineers and technicians