Business, Accounting and Finance

BSBPMG517 - Manage project risk

Learner Materials and Assessment Tasks

1|Page
Table of Contents

About BSBPMG517 Manage project risk ............................................................................................... 4

Determine risk objectives and standards, with input from stakeholders ............................................ 8
Activity 1 ............................................................................................................................................... 11
Establish project risk context to inform risk management processes................................................ 15
Activity 2 ............................................................................................................................................... 17
Identify project risks using valid and reliable risk identification methods ........................................ 21
Activity 3 ............................................................................................................................................... 23
Classify project risks within agreed risk categories ............................................................................ 24
Activity 4 ............................................................................................................................................... 27
Determine risk analysis classification criteria and apply to agreed risk ranking system .................. 28
Activity 5 ............................................................................................................................................... 30
Use risk analysis processes, within delegated authority, to analyse and qualify risks, threats and
opportunities ........................................................................................................................................ 32
Activity 6 ............................................................................................................................................... 39
Determine risk priorities in agreement with project client and other stakeholders ......................... 41
Activity 7 ............................................................................................................................................... 45
Document risk analysis outcomes for inclusion in risk register and risk management plan ............ 47
Activity 8 ............................................................................................................................................... 54
Identify and document existing risk controls ...................................................................................... 56
Activity 9 ............................................................................................................................................... 58
Consider and determine risk treatment options using agreed consultative methods ...................... 59
Activity 10 ............................................................................................................................................. 64
Record and implement agreed risk treatments .................................................................................. 65
Activity 11 ............................................................................................................................................. 69
Update risk plans and allocate risk responsibilities to project team members ................................. 70
Activity 12 ............................................................................................................................................. 70
Establish regular risk review processes to maintain currency of risk plans ....................................... 72
Regularly monitor risk environment to identify changed circumstances impacting project risks .... 72
Activity 13 ............................................................................................................................................. 74
Determine risk responses to changed environment ........................................................................... 76
Implement agreed risk responses and modify plans to maintain currency of risk treatments and
controls ................................................................................................................................................. 76
Activity 14 ............................................................................................................................................. 77

2|Page
Review project outcomes to determine effectiveness of risk-management processes and procedures
.............................................................................................................................................................. 79
Identify and document risk management issues and recommended improvements for application to
future projects ...................................................................................................................................... 80
Activity 15 ............................................................................................................................................. 85
Assessment………………………………………………………………………………………………………………………………………88

3|Page
About BSBPMG517 Manage project risk
Application

This unit describes the skills and knowledge required to manage risks that may impact achievement
of project objectives. It involves identifying, analysing, treating and monitoring project risks, and
assessing risk management outcomes.

It applies to individuals responsible for managing and leading a project in an organisation, business,
or as a consultant.

No licensing, legislative, regulatory or certification requirements apply to this unit at the time of
publication.

Unit Sector

Management and Leadership – Project Management

Elements and Performance Criteria

ELEMENT PERFORMANCE CRITERIA
Elements describe the Performance criteria describe the performance needed to
essential outcomes. demonstrate achievement of the element.
1. Identify project risks 1.1 Determine risk objectives and standards, with input from
stakeholders

1.2 Establish project risk context to inform risk management

processes

1.3 Identify project risks using valid and reliable risk identification
methods

1.4. Classify project risks within agreed risk categories

2. Analyse project risks 2.1 Determine risk analysis classification criteria and apply to agreed
risk ranking system

2.2 Use risk analysis processes, within delegated authority, to analyse

and qualify risks, threats and opportunities

2.3 Determine risk priorities in agreement with project client and

other stakeholders

2.4 Document risk analysis outcomes for inclusion in risk register and
risk management plan

4|Page
 3. Establish risk treatments 3.1 Identify and document existing risk controls
and controls
3.2 Consider and determine risk treatment options using agreed
consultative methods

3.3 Record and implement agreed risk treatments

3.4 Update risk plans and allocate risk responsibilities to project team
members
4. Monitor and control 4.1 Establish regular risk review processes to maintain currency of risk
project risks plans

4.2 Regularly monitor risk environment to identify changed

circumstances impacting project risks

4.3 Determine risk responses to changed environment

4.4 Implement agreed risk responses and modify plans to maintain

currency of risk treatments and controls
5. Assess risk management 5.1 Review project outcomes to determine effectiveness of risk-
outcomes management processes and procedures

5.2 Identify and document risk management issues and

recommended improvements for application to future projects

Foundation Skills

This section describes language, literacy, numeracy and employment skills incorporated in the
performance criteria that are required for competent performance.

Skill Performance Description

Criteria
Reading 1.1-1.4, 2.1, 2.2, 3.1,  Interprets and critically analyses complex texts
3.2, 4.2, 5.1, 5.2 from a range of sources and determines how
content may be applied according to
organisational requirements

Writing 1.3, 1.4, 2.1, 2.4,  Documents risks, risk analysis and risk controls
3.1, 3.3, 3.4, 4.1, using required formats and structure
4.3, 4.4, 5.2  Modifies and updates workplace documentation
according to requirements

Oral 1.1, 2.3, 3.4  Participates in verbal exchanges using clear

Communication language to provide and seek information

5|Page
  Uses active listening and questioning techniques
to confirm understanding

Numeracy 1.3, 2.1, 2.3  Analyses numerical data to identify project risk
levels and rank risks according to agreed system
of classification

Navigate the 1.1, 2.2  Determines and adheres to organisational

world of work policies and standards
 Considers own role in terms of its contribution to
broader goals of work environment

Interact with 1.1, 2.3, 3.4  Selects and uses appropriate conventions and
others protocols when communicating with internal and
external stakeholders to seek or share
information
 Actively identifies requirements of important
communication exchanges, selecting appropriate
channels, format and content to suit purpose and
audience

Get the work 1.1-1.4, 2.1, 3.2, 4.1,  Identifies and develops approaches to risk
done 4.4, 5.1 management and implements complex tasks to
achieve outcomes
 Analyses information to make decisions, involving
others when appropriate
 Uses formal and informal processes to monitor
implementation of decisions and reflect on
outcomes

Unit Mapping Information

Code and title Code and title Comments Equivalence status

current version previous version

BSBPMG517 Manage BSBPMG517A Manage Updated to meet Equivalent unit
project risk project risk Standards for Training
Packages

Assessment requirements

Modification History
Release Comments
Release 1 This version first released with BSB Business Services Training Package
Version 1.0.

6|Page
Performance Evidence

Evidence of the ability to:

 conduct effective risk management for a project of sufficient complexity to demonstrate the
full range of performance requirements
 apply risk management techniques, strategies and tools.

Note: If a specific volume or frequency is not stated, then evidence must be provided at least once.

Knowledge Evidence

To complete the unit requirements safely and effectively, the individual must:

 identify project risks in a range of risk categories

 explain key components of a risk management plan
 outline industry sector risk classifications and relate these to different risk contexts
 summarise organisational and industry standard risk frameworks
 identify and describe characteristics, techniques and appropriate applications of quantitative
and qualitative risk management techniques and approaches.

7|Page
Determine risk objectives and standards, with input from stakeholders1

Consider this: Effective risk management underpins a successful project – true or false?

Was 'true' your first reaction? We believe that you’re right.

All three of us are strong believers in the positive value of a well-managed and controlled approach to
project risks. An Internet search for “images of risk management” will return many illustrations of dice
being rolled.

If it is done well, risk management measures the uncertainty involved when you 'roll the dice' during
your project, and allows the project manager to obtain a consensus on how to best handle risks and
unexpected events on the project.

Take-away points to consider

We put forward the following considerations for risk management (this list is not exhaustive or
prioritised):

1. Risk management affects all aspects of your project – your budget, your schedule, and your
scope, the agreed level of quality, your communications and stakeholder engagement, the
success when the project’s output is implemented, and so on.
2. Risks can be positive (i.e. opportunities), as well as negative (generally referred to as risks).
3. Risk management is about behaviours that prove that risk management is a top priority for
you and the team, such as “being constantly aware of what might happen,” agreeing on
strategies for all risks, and undertaking actions to prevent negative risks from becoming issues
(i.e. occurred events) whilst maximising the opportunities of positive risks.
4. Risk management needs to be conducted from the start of the project, constantly discussed
and monitored, and involve all members of the project team.
5. How you choose to handle risks depends on your most influential project stakeholders’
'appetite for risk'.
6. Each identified risk needs to be assessed, a strategy for dealing with it agreed upon by all
appropriate parties, and tracked until closure.
7. Project risk management is not “the project manager tracking risks in a Risks Register and
sharing it occasionally when or if people ask to see it” – it is much more than that.

The essentials of project risk management

A project risk can be defined as an uncertain event or condition that, if it occurs, will have a positive
or a negative effect on a project’s objectives.

1
Source: CIO, as at
http://www.cio.com.au/article/385084/risk_management_project_management_go_hand_hand/, as on 4th
December, 2016; Free Management eBooks, as at http://www.free-management-ebooks.com/dldebk-
pdf/fme-project-risk.pdf, as on 4th December, 2016.
8|Page
Some very comprehensive guidelines and procedures for managing risk are available from many
sources. For example, the Project Management Institute describes the following summary process to
managing project risks:

1. Plan risk management.

2. Identify risks.
3. Perform qualitative risk analysis.
4. Perform quantitative risk analysis.
5. Plan risk responses.
6. Monitor and control risks.

You may come across other models. Your means of conducting risk management and the behaviours
you and your team display in 'making it real' make all the difference. We have mentioned 'behaviours'
a few times in this article. We are referring to the communication (in all its shapes and forms) that you
use, the importance with which you treat risks, and the willingness and drive to see actions through
to completion and closure.

Here are a few questions for you to ask yourself:

1. At the start of a project, do you plan how you and the team will approach risks? By this, we
do not mean jumping straight to a Risks Register, but putting some serious thought into how
risks will be managed during the project.
2. Do you understand and monitor the appetite for risk of your customer and influential
stakeholders?
3. Do you involve all people in the team to identify project risks – not only at the start, but
throughout the project?
4. Do you review the risks of previous projects, and look to lessons from the past as part of your
initial review and identification process?
5. Do you strive to ensure each risk has an owner, and that the method to tackle them is agreed
upon, i.e., whether to mitigate the risk with an action, to transfer, avoid or accept it and so
on?
6. Do you readily assess opportunities as well as negative risks, and devise strategies to maximise
the likelihood of opportunities occurring in order to exploit or enhance them?
7. Do you assess “triggers” to each risk so that you can monitor if/when there is danger of their
becoming real?
8. As well as qualitative assessment of risks, are you able to apply a quantitative financial or time
value to each risk, both negative and positive, should it eventuate? If the impact is negative,
will it turn into an issue? Can this estimated financial value help you justify an appropriate
project contingency in terms of cost and/or time?
9. Are you pro-active in tracking the agreed strategies to handle risks?
10. Do you maintain a project Risks Register on a regular basis – moving priorities up and down
the list, watching for low-priority risks that may escalate in importance, being attentive to risks
that are likely to occur soon?
11. Do you discuss the “current high-priority risks” with your key Stakeholders at each project
review (in whatever forum you have for such review meetings)?
12. Do you discuss what will happen if major and problematic “unknown unknowns” occur on
your project, perhaps with action scenarios if such events happen?
9|Page
Remember: Risk management is your friend and ally

As per the title of this article, risk management is the project manager’s friend. Done well, it helps you
ensure that the 'appetite for risk' is appropriately understood at the start; that all risks are agreed
upon, prioritised, assessed, communicated and understood in alignment with this 'risk appetite'; and
that you have a solid platform to track agreed actions, including escalation up the management chain
if necessary.

The key is to demonstrate positive behaviours in a way that ensures risk management is kept at the
forefront of all your project activities. There is always the potential of 'unknown unknowns' impacting
your project, but the more you can assess reasonable risks from the start of the project and actively
manage them throughout, the better placed you will be as a team to realise a positive outcome for
your project.

Everything that is done in business contains some measure of risk. No matter what the activity, there
is an element of risk that must be analysed and weighed against the potential rewards. The best
organisations are those who can choose the right risks to take on, and the ones to avoid. Dealing with
too little risk often means that the organisation is being too conservative and is limiting their potential
for growth—too much risk, however, and the company is likely to crash and burn at some point along
the way.

As projects are a regular part of business, it only stands to reason that they incur a certain level of risk
as well. Managing project risk deals with the activities involved in identifying potential risks, assessing
and analyzing them, finally monitoring them throughout the life of a project. Every project will have a
unique set of risks based on the specific details of the work being done. It is often up to the project
manager to outline these risks ahead of time and include them as part of the overall plan of the
project.

10 | P a g e
Dealing with the risk inside of a project isn’t much different from dealing with any other business risks
that you encounter. While it probably isn’t possible to foresee all potential risks that could come down
the line, planning for as many of them as you can will give the project its greatest chance at success.

Activity 1

Risk should be managed in every project. Is this true or false? Why?

11 | P a g e
Activity 1

12 | P a g e
Risk is defined in ISO 31000 as2:

Effect of uncertainty on objectives

Key processes in risk management are risk assessment and risk treatment; together these comprise
the four steps of risk identification, risk analysis and risk evaluation and risk treatment. These aim to
determine:

 What could happen, where and when?

 Why and how it could happen?
 What could be the consequences if it happened?
 What controls are in place to enhance gains and prevent or minimise adverse impacts?
 How effective are these controls?
 What is the level of risk?
 How do we best treat the risk further?

There is no one method for risk assessment and treatment. As a general rule, the type and rigour of
the risk assessment process adopted depends on the potential severity of the consequences and their
likelihood. For the greatest severity consequences or where there are high levels of risk, very rigorous
risk assessment is required. On the other hand, where the consequences are less serious or the level
of risk is low, simpler techniques can be used

Risk Management Process Overview

Outline

In Broadleaf we normally advocate an approach to managing risk that is based on ISO 31000:2009.
The process is depicted in outline below.

2
Source: Broadleaf, as at http://broadleaf.com.au/resource-material/risk-assessment-and-risk-treatment/, as
on 5th December, 2016.
13 | P a g e
The risk management process

Continuous process elements

Communication and consultation

Managing risk necessarily involves people because:

 The interests of people are part of the organisation’s objectives

 People will need to take (or not take) particular actions in order for risk to be managed
effectively
 People have most of the knowledge and information on which effective risk management
relies
 Some people might have a right to be informed or consulted.

Communication and consultation are therefore key supporting activities for all parts of the risk
management process. Communication and consultation are processes and not outcomes. They
normally take place with stakeholders, defined as those persons or organisations that can affect, be
affected by or perceive themselves to be affected by a decision or activity.

Monitoring and review

Monitoring and review are two distinct processes intended to detect change and determine the
ongoing validity of assumptions. Both are necessary to ensure that an organisation maintains a current
and correct understanding of its risks, and that those risks remain within its risk criteria.

14 | P a g e
Both require a systematic approach, integrated into an organisation’s management systems, that
reflects the speed at which change occurs within the internal and external environment.

Establish project risk context to inform risk management processes

Establishing the context

Before any risk management activity takes place and especially before risk assessment occurs, the
external, internal and risk management contexts should be established.

A key aim of the ‘establish the context’ step in the risk management process is to identify the
organisation’s objectives, and those external and internal factors that could be a source of
uncertainty, so that risks can be identified more readily.

Establishing the context also provides the information that allows the other steps of the risk
management process to occur.

A risk is a future event that may or may not happen, but if it does occur it will have an effect on project
scope, schedule, budget, or quality. It may have one or more causes and, if it occurs, it may have one
or more impacts.

All project activities carry some element of risk, which are uncertainties about them that could affect
the project for better or worse. It is important to understand the difference between business risks
and project risks. What a project manager needs to know is what is the likelihood a risk will occur and
if it does what it will impact as this affects the project plan.

What is certain is that if the risk happens in the future it will have an effect on project project scope,
schedule, cost, or quality.

15 | P a g e
It may have one or more causes and, if it occurs, it may have one or more impacts. All project activities
carry some element of risk, which are uncertainties about them that could affect the project for better
or worse.

The important distinction that must be understood is the difference between business risks and
project risks. Business risks are more general and relate to the organisation, whereas project risks
relate specifically to the project objectives.

Business risk implies uncertainty in profits or danger of loss and the events that could pose a risk due
to some unforeseen events in future, which causes business to fail.

For example,
● Project scope—to build the stadium to the agreed specification within an agreed timescale and
budget.
● Project risk—that the building costs may be higher than expected because of an increase in materials
or labor costs.
● Business risk—even if the stadium is constructed on time and within budget that it will not make
money for the business.

This could be because of lower than expected ticket sales or higher than expected maintenance costs.
These risks exist outside of the scope of the project. Risks are caused by a requirement, assumption,
constraint, or condition that creates the possibility of negative or positive outcomes.

Continuing the example above: a risk cause would be a change in health and safety legislation during
the build phase. Whereas a risk outcome would be increased costs to modify the parts of the stadium
in accordance with the new legislation before it can be used.

Project Impact on cost, schedule and performance needs to assess:

1. Shortage of skilled personnel due to demand by other building projects.
2. Unexpected cost of inspection & license.
3. The build of the affected parts of the stadium can be brought forward to finish project on time.

16 | P a g e
Risks include both threats and opportunities that project managers must assess. Opportunities do
have uncertainty associated with them, but they should be grasped, and action taken to ensure that
they are realized. Threats have potentially negative impacts that the project management team should
strive to mitigate. Organisations and stakeholders are willing to accept varying degrees of risk. This is
called risk tolerance. Risks that are threats to the project may be accepted if they are in balance with
the rewards that may be gained from taking them.

For example, using unproven productivity-boosting software is a risk taken in the expectation that the
work will be completed more quickly and with fewer resources. The risk of the software not
performing as advertised would need to be considered as part of the risk assessment.

All organisations have a ‘risk tolerance’ that is affected by their legal status and their culture. For
instance, a pension fund is likely to be more risk averse than a small startup company. In all cases,
attitudes to risk are driven by perception, tolerances, and other biases, which should be made explicit
wherever possible.

To be successful, the organisation should be committed to address risk management proactively and
consistently throughout the project. A conscious choice must be made at all levels to actively identify
and pursue effective risk management during the life of the project. Communication about risk and
its handling should be open and honest.

Risk exists the moment a project is conceived. Moving forward on a project without a proactive focus
on risk management increases the impact that a realized risk can have on the project and can
potentially lead to project failure.

17 | P a g e
Activity 2

What is a project risk context?

18 | P a g e
 Activity 2

Documenting the context provides an overview of the organisation, its objectives and specific criteria
for business success, the objectives and scope of the risk assessment activity and a set of key elements
for structuring the risk identification activity. As part of the planning process, establishing the context
is an essential and very important step in the risk assessment process. It is focused on3:

 Obtaining an understanding of the subject of the risk assessment activity and its risks.
 Establishing the scope of the risk assessment activity being undertaken.
 Developing a structure for the risk assessment activities.

Elements of context requiring consideration include the internal and external environments of the
organisation and the purpose of the risk management activity. The depth of information required
relates directly to the size and complexity of the risk management activity being undertaken.

3
Source: risk.com.au, as at http://www.risk.com.au/establish_context, as on 5th December, 2016.
19 | P a g e
External Context
Defining the external context includes consideration of the external environment in which the
organisation operates and understanding the relationship between the environment, external
stakeholders and the organisation. The external context may include the:

 Environment - business, social, regulatory, cultural, competitive, financial and political

situation.
 SWOT - organisation's strengths, weaknesses, opportunities and threats.
 Stakeholders - objectives and expectations of individuals, groups and organisations with a
significant interest in the business.

Internal Context

Defining the internal context includes documenting the key aspects of the business and may include:

 Goals and objectives.

 Structure, function and key processes.
 Physical and technological infrastructure and maintenance arrangements.
 Locations of business sites and other operations.
 Details of internal stakeholders.
 The prevailing culture and workforce morale.
 Resource capabilities such as people, systems, processes and capital.

Risk Management Context

Defining the risk management context includes establishing key information related to the subject
(activity, project, organisation etc) to which the risk assessment process is being applied. This includes
defining the:

 Goals and objectives of the risk assessment activity.

 Scope and parameters of the risk assessment, including specific inclusions and exclusions.
 Identification of data sources to be utilised.
 Risk assessment approach to be utilised.
 Reporting and recording requirements.
 Relationship of the risk assessment with other business activities and plans.
 Criteria against which risks are to be evaluated, such as how likelihood will be defined, the
kinds of consequences that will be considered and what level of risk will require further risk
reduction treatment.
 Key components - the subject of the risk assessment is best broken down into parts or key
topics. This establishes a framework to facilitate risk identification for each part, one by one.
It provides for consideration of all areas of risk and formulation of a comprehensive list of
risks. The manner of establishing and selecting key topics will depend on the objectives of the
risk assessment activity and the issues of concern.

20 | P a g e
Identify project risks using valid and reliable risk identification methods
Before a project even gets started, it is essential that any potential risks are identified
and a strategy for managing such risks developed. One of the best ways to do this is by learning from
past experience—either your own experiences, or those of the organisation as a whole.

Even if the type of project you are working on presently is different than anything you have done
before, it is likely the organisation has already done something at least remotely similar. Look back on
those projects to see how they played out. Did anything pop up along the way that you could be ready
for this time? Learning from the past is the best way to predict the future, especially in business.

Another risk identification strategy to use is speaking with all of the members of the project team and
asking for their input. Although they might not have the same high-level view of the project that you
do as manager, they likely have a great deal of knowledge within their specific field of expertise. Ask
them to highlight the potential risks that they see developing down the line and work on making plans
for those possibilities as well. There is only one output of this process and that is the all-important risk
register, which plays a key role in how well a project is monitoring during its execution.

Among the most common risks that need to be dealt with are losing key members of the team partway
through the project, or running out of money to see the project all the way through to completion. In
the case of both of those risks, there are steps that can be taken to mitigate the damage they would
do and be prepared in the event that they do occur.

For example, having redundancy within your team can help to limit the damage if a team member
moves on to another job partway through the work, and building the project in such a way that it can
be ‘paused’ while waiting for more funds could prevent it from being completely wiped out by a
temporary lack of funding.

21 | P a g e
 Identification of project risks is a subsidiary process that involves using of a risk identification
approach4 to define which risks and threats surround the project and affect project activities, and
to document risk characteristics. The project risk identification involves participation of the project
manager, project team members, an assigned risk management team and risk experts,
stakeholders. Project risk identification is an iterative process because new risks and threats may
arise any time during the course of a project.

One of the best risk identification approaches is a workshop with project participants, especially
with those carrying out daily duties. Workshops (or project risk management presentations) involve
using a combination of both brainstorming and reviewing to create standard project risk lists and
define types of project risks. All risks of a project can be classified into the following types:

 Strategic risks concern long-term strategic objectives of the project. This type of project
risks affects such areas as initial project financing, technology, reputation, changes in the
physical environment, etc.
 Operational risks concern issues and problems that project participants are confronted
with from day to day. Mitigation of operational risks contributes to reducing of strategic
risks.
 Compliance risks concern issues associated with the need to comply the project course
with documented statements and regulations. Managing compliance risks lets ensure that
current project activities are undertaken in the manner which project stakeholders and
customers expect.
 Financial risks are associated with existing financial structure of the project and with all the
transactions made to carry out the project. Identification of financial risks involves
examining daily operations. Financial risks are an indicator that shows whether current
project has serious implications for viability.
 Knowledge risks are associated with effective management and control of knowledge
resources, communication mechanisms, and protection systems. Project knowledge risks
may include abuse of intellectual property, loss of the key project staff, system malfunction,
etc.

The given project risk classification is also known as the nature of project risks. It covers the major
project risks. Sometimes, the given risk classification is broken down into a wider range of project
risks, including environmental risks, staff management risks, political and economic stability risks,
safety risks.

4
Source: My Management Guide, as at http://www.mymanagementguide.com/guidelines/project-
management/risk-management/risk-analysis-assessment-identifying-describing-estimating-project-risks/, as
on 5th December, 2016.
22 | P a g e
Activity 3

Create a list of possible questions you could ask members of the project team to identify the
project risks (aim for at least 6 questions).

23 | P a g e
 Activity 3

Classify project risks within agreed risk categories5

All projects start off with a bang. Yet, some are destined for failure from its very inception, whilst
others collapse later on.

Yet, others reach the finish line triumphantly, carrying with them a few scars from battles faced and
overcome.

Therefore, in order to minimise project failure, it is prudent to identify the main causative factors that
contribute to project risk.

5
Source: Tutorials Point, as at
https://www.tutorialspoint.com/management_concepts/project_risk_categories.htm, as on 5th December,
2016.
24 | P a g e
The three main constraints on projects can be classified as schedule, scope and resources, and the
mishandling of each can cause a ripple effect on the project, which would then face imminent collapse.

Scope Risk

Defining what is required is not always easy. However, so as to ensure that scope risk is minimised,
the deliverables, the objectives, the project charter, and of course, the scope needs to be clearly
defined.

All scope risks, be they quantifiable or not, needs to recognize. Scope creep, hardware defects,
software defects, an insufficiently defined scope, unexpected changes in the legal or regulatory
framework and integration defects can all be classified under the broad umbrella of scope risk.

There are a variety of methods that help stakeholders identify the scope of the project. The risk
framework analyses the project's dependency on technology and the market and then assesses how
changes in each would affect the outcome of the project.

Similarly, the risk complexity index looks at the technical aspects of the projects, which can be easily
quantified and allocated a number between 0 and 99 to indicate the risk of the project.

Risk assessment, on the other hand, uses a grid of technology, structure and magnitude to assess the
proposed risk of the project.

A work breakdown structure, commonly abbreviated as WBS, also considers the risks of projects,
which are ill defined and where the stated objectives are ambiguous.

Scope risks can be minimised and managed with savvy planning. Defining the project clearly, managing
the changes in scope throughout the duration of the project, making use of risk registers to better
manage risks, identifying the causative factors, and the appropriate responses to risky situations and
developing greater risk tolerance in collaboration with the customer, would pay great dividends in the
long run.

Schedule Risk

Keeping to timelines and agreed critical paths is one of the most difficult situations that project
managers now face.

An extensive reliance on external parties whose output is not within the project's scope of control,
estimation errors, which most often are too optimistic, hardware delays and putting off decision
making, all tend to delay the project at hand.

To minimise schedule risks, there are a few time-tested methods that can be put to good use. The
process flow of the project should be broken down into small, clearly defined components where the
allocated timeframe for each process is relatively short in duration (this makes it easy to identify things
when tasks veer off schedule, at its earliest).

25 | P a g e
Be wary of team members or external parties, who hesitate to give estimates or whose estimates
seem unrealistic based on historical data and previous experience.

When formulating the critical path, ensure that any holidays that arise are in-built into the equation,
so that realistic expectations are created, right from inception. Defining re-work loops too is also
recommended, wherever possible.

Resource Risk

People and funds are any project's main resource base. If the people are unskilled or incompetent to
perform the task at hand, if the project is under-staffed from the beginning, or if key project members
come on aboard far after the inception of the project, there is an obvious project risk that has ill-
planned human resources as its base.

Similarly, from a financial perspective, if insufficient funds are provided to carry out the necessary
tasks, be it relevant training programs for the people in question or be it inadequate investments in
technology or required machinery, the project is doomed to fail from inception.

Estimating project costs accurately, allocating a suitable budget to meet these costs, not placing undue
expectations on the capacity of the staff in question and avoiding burn-out at a later date are all factors
that help minimise the project resource risk.

Outsourced functions merit even more attention to detail, as it is for the most part, it is away from
the direct purview of the project manager. Clearly defined contracts and regular monitoring would
lessen this risk substantially.

Conflict management, which too generally arises with the progression of a project, should also be
handled in a skilful manner, so that the project has a smooth run throughout its entire duration.

As is readily apparent, all projects do run the risk of failure due to unplanned contingencies and
inaccurate estimates.

Yet, careful planning, constraint management, successful recovery from mistakes if and when they do
arise will minimise most risks. True, luck too, does play a part in the success of a project, but hard work
and savvy management practices will override most such difficulties.

Project risk description is a subsidiary process that follows the project risk identification process
and aims at displaying the identified risks in a structure format (often by using tables and
spreadsheets). The project results in creation of a risk description table that facilitates better
assessment and further risk management. By considering consequences and probability of each risk
set out in the risk description table, the project manager can prioritize key risks which should be
reviewed and analysed in more detail. Then the project manager makes descriptions for the key
risks and the rest risks to be used later for project risk analyzing. Prioritization of the key risks results
in creation of the agreed risk priority scale.

26 | P a g e
Activity 4

Describe a possible risk categorisation approach you could use for a small scale IT project (such
as a web site development or server implementation).

27 | P a g e
 Activity 4

Determine risk analysis classification criteria and apply to agreed risk ranking
system
With a list in place that highlights which risks you will be taking on during the project, you can start
looking closely at each of them and deciding what kind of threat they actually are. Is the risk something
that would do long-term damage to the organisation if it came to pass? Usually, risks that fall into this
category are of the legal variety. A project that could put you in legal trouble for one reason or another
is often one to be avoided. However, if the worst-case for a project is simply some wasted time and a
small amount of wasted capital, you may decide that those risks are worth the potential reward. It is
all about balance in risk management, so the pros and cons have to be weighed carefully with respect
to each potential risk.

28 | P a g e
Both qualitative and quantitative analysis must be performed for each risk. Firstly, each risk is assessed
and rated according to its likely probability and then secondly on the impact it would have on the
project if it happened. There are a variety of tools that are used to assist in these processes:

Qualitative Risk Analysis

○ Risk Probability & Impact Assessment
○ Probability & Impact Matrix
○ Risk Data Quality Assessment
○ Risk Categorization
○ Risk Urgency Assessment
○ Expert Judgment

Quantitative Risk Analysis

○ Sensitivity Analysis
○ Expected Monetary Value (EMV) Analysis
○ Decision Tree Analysis
○ Tornado Diagrams
○ Monte Carlo Analysis

29 | P a g e
Beyond what kind of damage a certain risk could do is the consideration of how likely that risk is to
occur. For example, a risk that is very likely to occur and would also be highly damaging to the company
is one to take very seriously. On the other hand, a risk that is unlikely to be realized and also wouldn’t
do much harm is one that you can mostly ignore.

Activity 5

What is the difference between qualitative and quantitative risk analysis?

30 | P a g e
Activity 5

31 | P a g e
Use risk analysis processes, within delegated authority, to analyse and qualify
risks, threats and opportunities
Performing a Risk analysis
This process analyses each risk from the risk register in terms of its probability and impact on the
project if it were to occur. It should be performed as soon as possible after risks have been identified
so that appropriate time and resources can be allocated to the more serious risks. It uses the
probability and impact matrix (PIM) to rank and prioritize risks, and this information is placed back on
the risk register.

Like all the processes and procedures for managing risk, this one should be performed regularly
because new risks will be identified and the characteristics of existing risks may change as the project
progresses. The risk management plan (part of the overall project plan) will explain the overall
approach that needs to be taken to risk management on this particular project. It will detail how much
risk is acceptable and who should be involved in carrying out the qualitative analysis of the known
risks.

The key elements of this plan used in this process are roles and responsibilities for conducting risk
management, budget, schedule for risk management activities, definition of risk categories, definition
of risk probability and impact, probability and impact matrix, and stakeholder’s risk tolerances.

32 | P a g e
The scope of the project will have a direct bearing on the type and amount of risk that is likely to be
encountered. In general terms, certain types of project are associated with certain types of risk. For
example, Construction projects the risks would include such things like, planning permissions,
weather, health and safety legislation, and labor union issues.

IT project risks tend to be concerned with whether development software will perform as advertised
and with compatibility issues. Projects of a common or recurrent type tend to have well understood
risks, whereas those breaking new ground tend to have more uncertainty.

There are various techniques that can be used to identify risks.

Risk Probability and Impact Assessment

Risk probability assessment investigates the likelihood that each specific risk will occur, whereas risk
impact assessment investigates the potential effect on a project objective such as schedule, budget,
quality, or performance.

33 | P a g e
Both the likelihood and impact are given a score according to the definitions given in the risk plan and
these can be considered together to provide a risk score. Risks with a high score will be given high
priority while those with a low score will be included on a watch list for future monitoring.

Probability and Impact Matrix

Evaluation of each risk’s importance and, hence, priority for attention can be done using a probability
and impact matrix as shown.

This specifies combinations of probability and impact that lead to rating the risks
as low, moderate, or high priority. The type of management response should be:
1) Threats
○ High-risk (shown in dark gray boxes) are priority and need a hard line response.
○ Low-risk (mid-gray boxes) need to have a contingency made for them & monitored
2) Opportunities
○ Dark gray boxes show ones to pursue first as they offer the most benefit & are more easily achieved.
○ Mid-gray boxes indicate the ones to be monitored.

34 | P a g e
It is possible to rate a risk separately for cost, time, scope and quality. In addition, it can develop ways
to determine one overall rating for each risk. An overall rating scheme can be developed to reflect the
organisation’s preference for one objective over another and using those preferences to develop a
weighting of the risks that are assessed by objective.

You will also need to examine how well the risk is understood and the accuracy, quality, reliability, and
integrity of the data regarding it. If data quality is unacceptable, it may be necessary to gather higher-
quality data. The risk breakdown structure (RBS) is the normal way to help structure and organise all
identified risks into appropriate categories, and these will assist in determining which aspects of the
project have the highest degree of uncertainty.

Risks that are likely to occur in the immediate future require more urgent attention than those that
may occur later on in the project. Indicators of priority should include the time required to affect a
risk response. In some qualitative analyses the assessment of risk urgency can be combined with the
risk ranking determined from the probability and impact matrix to give a final risk severity rating.

The risk register can be updated with the following information.

Relative ranking or priority list of project risks—the probability and impact matrix can be used to
classify risks according to their individual significance. Risks may be listed by priority separately for
schedule, cost, and performance since organisations may value one objective over another. The
project manager can then use the prioritised list of risks to focus attention on those items of high
significance to the most important objectives.

Risks grouped by categories—this can point to common underlying causes of risk, which may in turn
suggest a holistic approach to dealing with them. Discovering concentrations of risk may also improve
the effectiveness of risk responses. List of risks requiring response in the near-term —includes those
risks that require an urgent response and those that can be handled at a later date may be put into
different groups.

List of risks for additional analysis and response—some risks might warrant more analysis, including
Quantitative Risk Analysis, as well as response action.

Watch lists of low-priority risks—those that are not assessed as important in this process can be placed
on a watch list for continued monitoring.

Trends in the analysis results—as this process is iterative, trends for particular types of risk may
become apparent. This information can be fed back into the risk management process.

35 | P a g e
Assumptions log—the project scope statement may contain assumptions about the project, which
may be updated as a result of the qualitative risk analysis done in this process.

This is the process of analyzing the effect of those risks identified as having the potential to
substantially impact the project. It may be used to assign a numerical rating to those risks individually
or to evaluate their aggregate effect. You will need to use the Risk Management Plan (part of the
overall Project Plan) and the Risk Register, along with cost and schedule information.

In some projects it may be possible to develop effective risk responses without this process. The
availability of time and budget, and the need for qualitative or quantitative statements about risk and
impacts, will determine which method(s) to use.

Structured interviews can be used to determine the probability and impact of risks from subject
matter experts. This information can then be used in the following modelling techniques:
Sensitivity Analysis—this involves analyzing the project to determine how sensitive is to particular risks
by analyzing the impact and severity of each risk.
Expected Monetary Value (EMV) Analysis—determining the expected monetary value is to multiply
the likelihood by the cost impact to obtain an expected value for each risk, these are then added up
to obtain the expected monetary value for the project. A typical way of calculating EMV is using
decision trees:
Decision Tree Analysis—these are in the form of a flow diagram where each node, represented by a
rectangle, contains a description of the risk aspect and its cost. These rectangles are linked together
via arrows each arrow leading to another box representing the percentage probability.

36 | P a g e
Tornado Diagrams—these are named because of their funnel shaped and portray graphically the
project sensitivity to cost or other factors. Each tornado diagram will represent the impact of risks in
terms of particular aspects. These aspects may be the stages of phases of all project, and are ranked
vertically and represented by a horizontal bar showing plus or minus cost impacts.

Monte Carlo Analysis—is normally calculated by computer by analyzing many scenarios for the project
schedule and calculating the impact of particular the risk events. It is helpful in identifying risks and
the effect they have on the project schedule.

Rather than ask each expert for a single value for each, the project manager would normally encourage
each expert to provide an optimistic, pessimistic and realistic probability and impact value for each
risk.

The risk register is further updated to include a quantitative risk report detailing quantitative
approaches, outputs, and recommendations. Updates include the following:

Probabilistic Analysis of the Project—Estimates are made of potential project schedule and cost
outcomes listing the possible completion dates and costs with their associated confidence levels. This
output, often expressed as a cumulative distribution, can be used with stakeholder risk tolerances to
permit quantification of the cost and time contingency reserves.

37 | P a g e
Probability of Achieving Cost and Time Objectives—with the risks facing the project, the probability of
achieving project objectives under the current plan can be estimated using quantitative risk analysis
results.

Prioritised List of Quantified Risks—this list of risks includes those that pose the greatest threat or
present the greatest opportunity to the project. These include the risks that may have the greatest
effect on cost contingency and those that are most likely to influence the critical path. These risks may
be identified, in some cases, through a tornado diagram generated as a result of the simulation
analyses.

Trends in the analysis results. As this process is iterative, trends for particular types of risk may become
apparent. This information can be fed back into the risk management process.

Project risk estimating is a subsidiary process that enables an analysis of project risks and
allows removing or mitigating identified risks which threaten successful achievement of
project objectives or producing of project deliverables. A properly undertaken project risk
analysis increases a probability of successful completion of project in terms of time, cost
and performance objectives.

There are common suggestions for conducting the project risk analysis process. The
suggestions involve investigation of various risks and uncertainties, including the following:

 The structure of financial management and authority is not established yet

 Technological foundation of project is not proven yet
 Project resources are unavailable at the required level

All the listed uncertainties produce an exposure to risks which may cause a failure of:

 Project budget
 Completion dates
 Performance objectives

In order to remove or at least mitigate risks, the project manager in cooperation with risk
analysts and experts analyses uncertainties of project activities and estimates risks. The
process of project risk estimating is usually divided into two sub-processes, including
Qualitative analysis and Quantitative analysis.

Qualitative analysis allows defining factors and causes that create a risk for project.
Qualitative analysis can be done by using checklists, questionnaires, interviews or
brainstorming sessions. The analysis uses risk assessment forms which describe the
impacts of each risk and a likelihood of risk occurrence. Qualitative analysis uses the
following documents:

38 | P a g e
  Risk register
 Project scope statement
 Risk management plan

Quantitative analysis often involves more sophisticated techniques and methods to

investigate and analyse project risks. Quantitative analysis is conducted with help of project
risk management software. It involves measurement of uncertainties associated with the
project schedule and budget. Qualitative analysis uses the following documents:

 Risk register
 Risk management plan
 Cost management plan
 Schedule management plan

Both analyses result in making updates to the risk register. After Qualitative analysis and
Quantitative analysis have been conducted, the results can be used to create a profile for
each risk. A risk profile is a signature that rates each risk and provides a foundation for
prioritizing risk treatment efforts. Risk profiles are also used later for reporting project risk
activities.

Activity 6

Select one risk analysis tool and describe how it can be used to analyse project risk.

39 | P a g e
Activity 6

40 | P a g e
Determine risk priorities in agreement with project client and other
stakeholders6

Risk analysis is about developing an understanding of each risk. It provides an input to decisions on
whether risks need to be further controlled and the most appropriate and cost-effective treatment
actions to take.

Risk analysis involves consideration of the positive and negative consequences and the likelihood that
those consequences may occur. Factors that affect consequences and likelihood may be identified.
Risk is analysed by combining consequences and likelihood, taking into account the existing controls.

Broadleaf uses a qualitative method of risk analysis to prioritise risks for attention, at least initially.
Even if quantitative analysis is required later, we normally find it efficient to use a qualitative system
for screening purposes.

Quantitative approaches can be used when more definition and rigour are needed. In general they are
only used:

 Where the most likely consequence is high

 Where reliable quantitative data is available or can be generated
 Where the level of definition required by decision makers is high.

We often conduct the risk rating process during the workshop used for risk identification. However,
sometimes it is preferable to analyse the risks at another time using subject matter specialists, and
then reconvene the original workshop team to agree and verify the ratings.

We always analyse the risk in terms of how the organisation currently operates, and in particular
taking into account existing controls and their effectiveness. We use control effectiveness (CE) to take
into account both the adequacy and effectiveness of the controls for a particular risk.

We also determine a measure of potential exposure (PE) that represents the total plausible maximum
impact on the organisation arising from a risk without regard to controls. This is estimated by
considering the consequences that could arise if all existing controls were ineffective or missing. This
measure is use to identify the key controls that should be subject to assurance and, in particular,
monitored continuously for effectiveness.

From the risk analysis output we can advise clients on:

 The preferred strategies for risk treatment

 The priority with which risks should be considered for treatment
 Those risks that should be the subject to senior level oversight, particularly in terms of
monitoring the progress of risk treatment plans

6
Source: Bright Hub PM, as at http://www.brighthubpm.com/risk-management/34628-risk-management-
prioritizing-risk/, as on 5th December, 2016; MDC Systems, as at http://mdcsystems.com/risk-management-
recognizing-and-prioritizing-project-risks/, as on 5th December, 2016.
41 | P a g e
  The risks and the associated controls that should be subject to planned assurance, particularly
through continual monitoring as well as periodic review.

Assigning Priorities
The word risk may be looked at from many different angles. In risk management, risks are tools. The
trick is to align those tools in such a way that they will work for you and not against you.
During project initiation meetings, with the help of team members and stakeholders, identify risks.
The best way to accomplish this is through past experience, including positive and negative results.
What worked and what didn't? What made a prior risk a risk to begin with? Was the risk external or
internal? Was the risk handled properly? Who handled the risk?
For risk management to be effective, you must take the time to identify risks; otherwise it's impossible
to prioritize them. Once you've identified potential risks, use a risk treatment plan template to help
you prioritize them. Project managers need to be a sort of judge and jury when prioritizing risk.

42 | P a g e
Too much intervention to align your risks will produce chaos. To begin, put on that judge hat and get
a head start on your project using effective prioritizing skills.

43 | P a g e
 Align Your Toolbox
To help you align and prioritize risks, follow these tips:
 Project or Product Risk - This should be first. If an identified risk will affect the project or product,
that's important.
 Process - What is your process for the project? How will it flow? Risks you identify here are
important to stay on track.
 Resources - Who will be the best team for the project? Use Six Sigma to help you choose good
team members.
 Stakeholders - Who are the stakeholders and at what level will they be involved with any risk?
Using stakeholder management is essential in risk management.
 Risk Tools - What tools will you put in place to deal with risk? Your risk treatment plan can help
you define these tools.
 Acceptable Risk - These should be a low priority and are not risks that affect a project's outcome.
 Evaluate Risk - Hold a post-project meeting to evaluate your prioritised risks.
Use the tools and templates provided in this article to help you take a lot at potential risks before the
project begins. Scheduling time to analyse risks is essential if you want your projects, teams, and
processes to succeed.

Since every project is unique, the priorities of certain risks will be different for every project. Three
simple steps can be used to create a project Risk Matrix in order prioritize risk events. It is imperative
that all stakeholders are involved in this process so all points of view are taken into account. In order
for risks to be properly mitigated, the matrix should be revisited and updated on a regular basis.

1) Identify: Similar to recognizing risk, listing every potential risk to the project is necessary before any
assessments can take place. Even events that have only a slight chance of occurring should be
considered when creating the beginnings of your Risk Matrix. For example, a lost time accident could
occur on any project but, with the proper safety precautions in place, it is rare. On the other hand,
change orders due to unforeseen conditions are almost inevitable on any project, but with the proper
precautions taking place by all parties the cost of these could be minimised.

2) Measure Likelihood: Each risk identified should be given a ranking based on the likelihood of them
occurring. The scale for this ranking is at the discretion of the project team, it could be 1-5 with 1 being
unlikely and 5 being likely, or it could be on a likelihood percentage basis. Using the examples
discussed above, a lost time accident while using a contractor with a stellar safety record would be
ranked as a 1, while encountering unforeseen conditions on a renovation without existing drawings
would get a 5. Each risk on the list should be weighed and discussed with the stakeholders.

3) Assess Impact: Using the same guidelines established when calculating likelihood, the project
stakeholders should next rank the impact of different risks. Continuing with our examples, a lost time
accident could be devastating to a project with little to no float and given a ranking of 5. However, if
the project is not a tightly scheduled one and has a lot of float, then this occurrence may only be given
a 3. The impact may also change throughout the project duration. A change order from an unforeseen
condition may not affect the project if found early when there is float in the schedule or contingencies
are high, ranking it at a 1, but as the project draws to a close that same change request may cause
schedule disruption or budget problems, making the impact more like a 4.

44 | P a g e
4) Find the Overall Calculated Risk: Depending on the scale used to measure likelihood and impact, a
formula can be put together to calculate the overall risk associated with a certain event. From there,
the risks can be weighed low, medium, and high so that the team can determine which risks are
priorities. After the overall risk for each event is calculated, stakeholders should look at the urgency
of each kind of risk. If the majority of the risks are shown as high, they should be revisited and
reranked. If every risk on the project is labeled high priority, then in essence you have just
deprioritised all of them, because you won’t be able to concentrate on every risk all the time- the
entire point of the matrix is to demonstrate where to focus mitigation efforts.

Controlling & Mitigation

Many projects begin in an organised manner with a strong Risk Matrix, and as the day to day
management of the project carries on, it becomes harder to stay on top of this document. The failure
to update the Risk Matrix is the most common reason that some risks seem to arise out of nowhere
at the last minute. In order to have a successful risk management program, the Risk Matrix must be
updated and controlled on a regular basis. Priorities will shift, impacts will change, and new risks will
arise. If the Risk Matrix is consistently being evaluated, plans to mitigate the high likely high impact
risks.

Mitigating the highest calculated risks does not completely deter them from occurring, but establishes
a workarounds and contingencies to lessen the overall impact to the project. Using the examples
discussed above, in order to mitigate the risk of a lost-time accident, you would ensure that all parties
are properly safety trained and have submitted their respective safety manuals. You would also build
your schedule to have little or no trade stacking in congested areas and continue regular jobsite safety
audits. In order to mitigate the risk of change orders resulting from unforeseen conditions, you would
have both the designer and contractor perform site surveys, have coordination and shop drawing
reviews, and have regular stakeholder meetings to discuss design issues. To lessen the project impact
should either of the above risk events occur, the project would ideally have float built into the schedule
as well as contingencies in the budget.

Every project comes with risks, and risk events will occur no matter the initial plan. A solid risk
management program is the best way to keep these risk factors low, keeping priorities in place for the
good of the project. Stakeholders from all parties must be involved in contributing to the Risk Matrix
early and regularly, which can be accomplished by following the three simple steps of recognizing,
prioritizing, and controlling.

45 | P a g e
Activity 7

Is it necessary to prioritise all project risks? Why/Why not?

46 | P a g e
 Activity 7

Document risk analysis outcomes for inclusion in risk register and risk
management plan
A risk plan details how the project management team will perform risk management for this project.
It does not involve actually identifying project risk. The aim of the risk plan is to ensure that the risk
management protocol that is used on the project is commensurate with both the risks and the
importance of the project to the organisation.

Establishing this protocol early on in the project ensures that all members of the project management
team are using the same methods to evaluate risks and that the associated tasks are budgeted for in
the project plan.

The level of detail in the risk plan will depend upon the level of risk within the project and the level of
risk that the performing organisation is prepared to take. This plan will need to be consistent with
other certain other project documents. For example, the project charter document provides the
selected project manager with the authority to organise and control the defined resources of the
organisation for the duration of the project. It can also be referred to as the project definition, or
project statement and is a statement of the scope, objectives, and participants in a project.

47 | P a g e
It establishes the authority assigned to the project manager, especially in a matrix management
environment, and is completed by the sponsor or individual initiating the project. The project name is
usually shortened or abbreviated into a working title for ease of communication. There are several
key sections that you need to include in your project charter. They are:
1. Contact points for key individuals of the project.
2. Project Purpose—the issue/problem to be solved by the project.
3. Business Objectives for the project as they relate to the organisations strategic plan.
4. Assumptions that have been made as part of the project.
5. Description of the project.
6. Definition of the project scope and the limits identified.
7. Overview of major milestones and deliverables for the project.
8. Project Authority—including an organisation chart and definition of roles and responsibilities.
9. Resources required for the project including costings, equipment. staffing, support, operational &
IT facilities.

The scope statement defines the scope of the project, which will have a direct bearing on the type and
amount of risk that is likely to be encountered. It provides a clear definition of such risk areas.
The cost plan defines how risk in terms of budgets, contingencies, and management reserves will be
reported and accessed.

The schedule plan includes information about activities and their timing including aspects such as
internal and external constraints that will help identify risk areas.

The communications plan includes information on all key stakeholders and in particular their concerns
for specific risks, and hence, how such communications should be handled.

You will also need to take account of any legal obligations and regulatory frameworks that the
organisation may be subjected to as well as processes and procedures to be followed, the industry
and its norms towards risk and the organisations appetite towards risk.

48 | P a g e
Collective decision-making is very important area of project management that can make or break this
part of the project. Almost all risk management activities will involve meetings between the project
manager, the team and other stakeholders in order to make decisions about the activity definitions
and associated estimates.

How well these meetings are conducted will have a major impact on how smoothly the project runs.

The resulting risk management plan forms part of the project plan and describes how managing risk
will be structured and performed on the project. It contains the following elements:
Methodology
Defines the approaches, tools, and data sources that may be used.

Roles and Responsibilities

This part of the plan needs to make clear who is responsible for each type of
activity in the risk plan, and clarifies their responsibilities.

Budgeting
This part of the plan assigns resources, estimates funds needed for managing risk. These are included
in the cost performance baseline, and establish how any extra funding required (if risks are realized)
will be raised.

Timing
This part of the plan defines when and how often the risk management activities will be performed
throughout the project life cycle.

49 | P a g e
Risk categories
This provides a structure that ensures a comprehensive process of systematically identifying risks to a
consistent level of detail. An organisation can use a previously prepared categorization framework,
which might take the form of a simple list of categories or might be structured into a risk breakdown
structure (RBS) as shown in the diagram.

This is a hierarchically organised depiction of the identified project risks arranged by risk category and
subcategory that identifies the various areas and causes of potential risks.

Definitions of Risk Probability and Impact

This ensures that all stakeholders have a common understanding of these definitions. For example, If
the probability of a risk can be described as low, medium or high, what do these categories actually
mean?
Similarly, what effect would a high impact event have on the project in practical terms?
How much would it add to the costs?

50 | P a g e
The table above is an example of definitions that could be used in evaluating risk impacts related to
scope, quality, time and cost. By using pre-defined definitions in this way, the project management
team ensures that everyone involved is talking the same language when it comes to risk.

Probability and Impact Matrix

Risks are prioritised according to their potential implications for having an effect on the project’s
objectives by using a matrix like the one shown.

The specific combinations of probability and impact that lead to a risk being rated as ‘extreme’, ‘high,’
‘moderate,’ ‘low’ or ‘minimal’ importance, with the corresponding importance for planning responses
to the risk, are usually set by the organisation.

Revised Stakeholder Risk Tolerances

If there is a need to revise stakeholder risk tolerances then these should be documented.

51 | P a g e
Reporting Formats
This part of the plan describes how the outcomes of the risk management processes will be
documented, analysed, and communicated. It describes the content and format of the risk register as
well as any other risk reports required.

Tracking
This part of the plan describes how risk activities will be recorded for the benefit of the current project,
as well as for future needs and lessons learned, as well as whether and how risk management
processes will be audited.

Options

It is usually not cost-effective or even desirable to implement all possible risk treatments. It is,
however, necessary to choose, prioritise and implement the most appropriate combination of risk
treatments. Treatment options, or more usually combinations of options, are selected by
considering factors such as costs and benefits, effectiveness and other criteria of relevance to the
organisation. Factors such as legal, social, political and economic matters may need to be taken into
account.

Treatment of individual risks seldom occurs in isolation, and options should be considered together
as part of an overall treatment strategy. Having a clear understanding of a complete treatment
strategy is important to ensure that critical dependencies and linkages are not compromised and to
ensure the use of resources and budgets is efficient. For this reason development of an overall
treatment strategy should be a top-down process, driven jointly by the need to achieve objectives
and satisfy organisational and budgetary constraints while controlling uncertainty to the extent that
this is desirable.

We advise our clients to be flexible about risk treatment options and consult broadly with
stakeholders as well as with peers and specialists. Many treatments need be acceptable to
stakeholders or those who are involved in implementation if they are to be effective and
sustainable.

We often use bow-tie analysis to help our clients identify possible risk treatment measures based
on control gaps.

Cost benefit analysis

The primary consideration for most risks is whether the risk can be further treated in a way that is
reasonable and cost effective.

In general this involves considering:

 Whether the risk is being controlled to a level that is reasonably achievable

 Whether it would be cost-effective to further treat the risk
 The organisation’s willingness to tolerate risks of that kind.

52 | P a g e
Determining the cost-effectiveness of further treatment involves the application of cost benefit
analysis. This should consider all direct costs and ancillary costs (dis-benefits) as well as all the direct
benefits and ancillary benefits (opportunities). If most of the costs or the benefits are unlikely to be
experienced within the first year or so then it may be necessary to discount the benefits and costs
to allow the assessment to be made ‘in today’s money’.

We help our clients identify possible options for risk treatment and then test each of these using
cost benefit analysis. As with risk assessment, preparation for a risk treatment workshop is vital if
it is to be effective and efficient.

The table below contains an example of cost benefit analysis applied to risk treatment options.

Table 1: Treatment options associated with surface traffic accidents at a mine site

Completion
Treatment option Benefits Disadvantages Result
date
Understand the current
Survey current rules and situation and the potential
Will require some
variations across for confusion. Move to
effort to achieve.
company. Develop a understand the need for
May conclude that
standard for safe driving despatch or the
the removal of Yes 31-Jul-13
in mines and safe alternatives. Ultimately it
despatch is not
behaviours. Consider the will reduce the likelihood of
desirable from a
role of despatch on each accidents that can cause
safety perspective.
mine. death and serious injury
and plant damage.
Currently there are no
Conduct a study to
standards or rules. Many
determine safe speeds Will require effort to
vehicles do not have
below and above ground. achieve (but could be
speedos. Speeds are Yes 31-Jul-13
Develop a strategy to limit conducted at the
enforced by removal of
speeds through blocking same time as 1).
gears which places motors
gears etc.
under stress.
Survey pedestrian and
vehicle interactions below
and above ground. Development of a solution
Consider proximity that is suitable for all mines. Will take some effort
devices as part of the Consistency between mines to achieve. Will lead
solution. Develop and avoidance of to some opposition Maybe 31-Dec-13
standards in terms of ambiguity. Provide a basis as it may restrict
delaminated areas, for training and where people walk.
walking areas etc. Train all enforcement of standards.
mine staff on rules and
enforce.

53 | P a g e
Risk treatment plans

We help our clients generate and record potential options for risk treatment as that shown above.
For each option, the benefit and costs or disadvantages are expressed and a decision is placed in
the final column. The decision is either ‘yes’ because the risk treatment option is value accretive, or
‘no’ because it is not. If the evaluation in inconclusive, a ‘maybe’ is recorded and more detailed
benefit-cost analysis may be required.

All those options marked ‘yes’ go ahead as risk treatment measures and plans are developed for
their implementation.

Activity 8

What information is documented in a risk register and who uses this information?

54 | P a g e
Activity 8

55 | P a g e
Identify and document existing risk controls
Project risks should be documented in the risk register, a list of all of the identified risks, their root
causes, categories and responses. Because the assessment of risk is an ongoing activity, the risk
register will be updated continuously throughout the life of the project.

All project team members should be encouraged to identify risks and this is an iterative process
because new risks may become known as the project progresses. The process of identification should
involve the project team so they can develop and maintain a sense of ownership and responsibility for
the risks and associated risk response actions.

The risk plan defines the level of risk that is considered tolerable for the project, how all this will be
managed, who will be responsible for them, what time and cost is needed for each, and how risk will
be communicated. The stakeholder register lists all of the project stakeholders as well as describing
and classifying them. This information will be useful in soliciting inputs for identifying risk, as it will
ensure that key stakeholders participate in the process.

Other elements of the overall project plan that describe how cost, schedule and quality are to be
managed and implemented will have a bearing on project risk, as will information on how project
human resources are going to be defined, staffed, managed, and eventually released. The scope of
the project in terms of the products to be created and the activities required will be a source of risks.

Any estimates of cost and duration are useful in identifying risk as they provide a quantitative
assessment of the likely cost to complete scheduled activities.

Reviewing these may indicate that the estimate is insufficient to complete the activity and hence poses
a risk to the project. These include, assumptions log, work performance reports, earned value reports,
network diagrams, baselines, and other project information proven to be valuable in identifying risks.

If the project requires buying-in of resources, procurement documents become a key input to this
process. The complexity and the level of detail of such documents should be consistent with the value
of, and risks associated with, planned procurement.
56 | P a g e
Laws and regulations governing the creation or use of the projects products need to be taken into
account along with the operational environment within which the project is taking place. The views of
the project stakeholders and their willingness to accept risk must also be taken into consideration.

Risks can be identified directly by experts with relevant experience of similar projects or business
areas. These should be identified by the project manager and invited to consider all aspects of the
project and suggest possible risks based on their previous experience and areas of expertise, and there
are several techniques that can also be used to identify project risk.

Documentation Reviews
These are structured reviews of all project documentation up to this point in time including plans,
assumptions, previous project files, contracts, and other information. The quality of the plans, as well
as consistency between those plans and the project requirements and assumptions, can be indicators
of risk in the project. Missing, inaccurate or incomplete information may hinder the identification of
risks and may itself be a source of risk. You can also use the risk breakdown structure developed either
from this project or from a previous project to help ensure that all significant risks or categories have
been identified.

Assumptions Analysis
Every identified project risk is based on a set of hypotheses, scenarios, or assumptions.

Assumptions analysis explores the validity of assumptions as they apply to the project. It identifies
risks to the project from the inaccuracy, inconsistency or incompleteness of assumptions.

Fishbone Diagrams
Risk diagramming techniques include cause and effect diagrams, also known as Ishikawa or fishbone
diagrams, and are useful for identifying causes of risks. Flow charts can also be used to show how
various elements of a system interrelate, and the mechanism of causation, as can influence diagrams,
which show causal influences, time ordering of events, and other relationships among variables and
outcomes.

SWOT Analysis
This technique looks at the project from the perspective of its internal strengths and weaknesses as
well as external opportunities, and threats. SWOT analysis is a useful approach to risk assessment.

Identified risks should be documented in a risk register that consists of the list of all the identified
risks, their root causes, categories and responses. This information may be used to update the risk
breakdown structure.

57 | P a g e
Because of risk is an ongoing activity, the risk register will be updated continuously throughout the life
of the project and it is a key tool to aid in the management of risks within a project. The risk register
ultimately contains the outcomes of the other risk management processes as they are conducted,
resulting in an increase in the level and type of information contained in the risk register over time.

Activity 9

Provide an example of a project risk control.

58 | P a g e
 Activity 9

Consider and determine risk treatment options using agreed consultative

methods
Mitigating the Risks
This was touched on briefly above as far as taking steps to limit the damage that any of your potential
risks would do. The easiest example to understand is the one regarding members of the team.

When you are building a team to work on the project, keep in mind that not every team member will
see the project through from start to finish. If you only have one person who is capable of performing
a vital portion of the work, you are exposed to risk if that person should leave for any reason. Instead,
there should be as much redundancy as possible—especially in the critical areas of the project—so
the loss of one or two people along the way doesn’t derail the entire project.

59 | P a g e
Doing what you can to limit your exposure to risk throughout the project, while still giving the project
a chance to succeed is the task that a project manager takes on. No one likes to have to deal with risk,
but it is an unavoidable part of doing business.

The best that can be done is to evaluate each risk that you might face, and weigh it against the
potential rewards that are waiting at the end of the project. Project managers also plan how they will
control risks using a variety of tools and techniques shown in the diagram below.

The goal is to make the level of risk acceptable to the organisation and to take steps that minimise the
element of risk as much as possible.

Risk Treatment Plan is one of the key documents in ISO 27001, however it is very often confused with
the documentation that is produced as the result of a risk treatment process. Here’s the difference7:

Risk treatment process

Risk treatment is a step in the risk management process that follows the risk assessment step – in the
risk assessment all the risks need to be identified, and risks that are not acceptable must be selected.
The main task in the risk treatment step is to select one or more options for treating each unacceptable
risk, i.e. decide how to mitigate all these risks. Four risk treatment options exist:

1. Apply security controls from Annex A to decrease the risks – see this article ISO 27001 Annex
A controls.

7
Source: 27001 Academy, as at http://advisera.com/27001academy/knowledgebase/risk-treatment-plan-and-
risk-treatment-process-whats-the-difference/, as on 5th December, 2016.
60 | P a g e
Annex A of ISO 27001 is probably the most famous annex of all the ISO standards – this is because
it provides an essential tool for managing security: a list of security controls (or safeguards) that are
to be used to improve security of information.

It would be a violation of intellectual property rights if I listed all the controls here, but let me just
explain how the controls are structured, and the purpose of each of the 14 sections from Annex A:

 A.5 Information security policies – controls on how the policies are written and reviewed
 A.6 Organisation of information security – controls on how the responsibilities are
assigned; also includes the controls for mobile devices and teleworking
 A.7 Human resources security – controls prior to employment, during, and after the
employment
 A.8 Asset management – controls related to inventory of assets and acceptable use, also
for information classification and media handling
 A.9 Access control – controls for Access control policy, user access management, system
and application access control, and user responsibilities
 A.10 Cryptography – controls related to encryption and key management
 A.11 Physical and environmental security – controls defining secure areas, entry controls,
protection against threats, equipment security, secure disposal, clear desk and clear screen
policy, etc.
 A.12 Operational security – lots of controls related to management of IT production:
change management, capacity management, malware, backup, logging, monitoring,
installation, vulnerabilities, etc.
 A.13 Communications security – controls related to network security, segregation, network
services, transfer of information, messaging, etc.
 A.14 System acquisition, development and maintenance – controls defining security
requirements and security in development and support processes
 A.15 Supplier relationships – controls on what to include in agreements, and how to
monitor the suppliers
 A.16 Information security incident management – controls for reporting events and
weaknesses, defining responsibilities, response procedures, and collection of evidence
 A.17 Information security aspects of business continuity management – controls requiring
the planning of business continuity, procedures, verification and reviewing, and IT
redundancy
 A.18 Compliance – controls requiring the identification of applicable laws and regulations,
intellectual property protection, personal data protection, and reviews of information
security

One of the biggest myths about ISO 27001 is that it is focused on IT – as you can see from the above
sections, this is not quite true: while IT is certainly important, IT alone cannot protect information.
Physical security, legal protection, human resources management, organisational issues – all of
them together are required to secure the information.

The best way to understand Annex A is to think of it as a catalogue of security controls you can
select from – out of the 114 controls that are listed in Annex A, you can choose the ones that are
applicable to your company.

61 | P a g e
 2. Transfer the risk to another party – e.g. to an insurance company by buying an insurance
policy.
3. Avoid the risk by stopping an activity that is too risky, or by doing it in a completely different
fashion.
4. Accept the risk – if, for instance, the cost of mitigating that risk would be higher that the
damage itself.

Risk treatment is usually done in a form of a simple sheet, where you link mitigation options and
controls with each unacceptable risk; this can also be done with a risk management tool, if you use
one. According to ISO 27001, it is required to document the risk treatment results in the Risk
assessment report, and those results are the main inputs for writing Statement of Applicability. This
means that results of risk treatment are not directly documented in Risk Treatment Plan.

Risk Treatment Plan

So, where is the Risk Treatment Plan in this whole process? The answer is: it can be written only after
Statement of Applicability is finished.

Why is this so? To start thinking about Risk Treatment Plan, it would be easier to think of it is an
“Action plan” where you need to specify which security controls you need to implement, who is
responsible for them, what are the deadlines, and which resources (i.e. financial and human) are
required. But in order to write such a document, first you need to decide which controls need to be
implemented, and this is done (in a very systematic way) through Statement of Applicability.

The question is – why didn’t ISO 27001 require the results from risk treatment process to be
documented directly in the Risk Treatment Plan? Why was this step in between needed, in the form
of Statement of Applicability? My opinion is that the authors of ISO 27001 wanted to encourage
companies to get a comprehensive picture of information security – when deciding which controls are
applicable in Statement of Applicability and which are not, the result of risk treatment is not the only
input – other inputs are legal, regulatory and contractual requirements, other business needs, etc. In
other words, SoA serves as a kind of a checklist that takes a global view of the organisation, and Risk
Treatment Plan wouldn’t be complete without such a check.

To conclude – Risk Treatment Plan is the point where theory stops, and real life begins according to
ISO 27001. Good risk assessment and risk treatment process, as well as comprehensive Statement of
Applicability, will produce very usable action plan for your information security implementation; skip
some of these steps and Risk Treatment Plan will only confuse you.

Risk Treatment8

Now that the risks have been identified with their impacts and probability scored, it is time to think
about how to treat each risk. Risk treatment will generally by 1 of these 5 options:

8
Source: Striking Project Management, as at http://strikingprojectmanagement.com/qualitative-risk-analysis/,
as on 5th December, 2016.
62 | P a g e
  accept
 transfer
 mitigate
 avoid
 exploit

Accept – perhaps the risk has low impact and low probability, or the cost to mitigate may be too
high. One option is to just accept it and monitor the risk.
Transfer – Transferring a risk is quite common through insurance and contracts, issuing a contract
to a supplier is essentially transferring some of the risk to the supplier, especially in a fixed price
contract.
Mitigate – Do something to reduce the impact of the risk, we mitigated the risk of the Chinese
port strike by having a backup plan in place and multiple tranches to build in extra capacity in the
schedule
Avoid – Perhaps the risk is too great, cannot be transferred or the cost of mitigation it too high.
You may choose to avoid the risk, either by changing or removing certain scope items or changing
the approach.
Exploit – Perhaps the risk has a positive outcome? A change in the exchange rate might mean that
your forward purchase certain materials.

Making the Treatment Choice

Options should be assessed based on extent of risk reduction and the extent of any additional benefits
or opportunities related taking into account the criteria developed previously. A number of options
may be considered and applied either individually or in combination. Selection of the most appropriate
option involves balancing the cost of implementing each option against the benefits derived from it.
In general, the cost of managing risks needs to be commensurate with the benefits obtained. Where
large reductions in risk may be obtained with relatively low expenditure, such options should be
implemented. Further options for improvement may be uneconomic and judgment needs to be
exercised as to whether they are justifiable.
Decisions should take account of the need to carefully consider rare but severe risks, which may
warrant risk reduction measures that are not justifiable on strictly economic grounds. In general, the
adverse impact of risks should be made as low as reasonably practicable, irrespective of any absolute
criteria. If the level of risk is high, but considerable opportunities could result from taking the risk, such
as the use of new technology, then acceptance of the risk needs to be based on an assessment of the
costs of risk treatment, and the costs of rectifying the potential consequences versus the opportunities
afforded by taking the risk. In many cases, it is unlikely that any one-risk treatment option will be a
complete solution for a particular problem. Often the organisation will benefit substantially by a
combination of options such as reducing the likelihood of risks, reducing their consequences, and
transferring, or retaining any residual risks. An example is the effective use of contracts and risk
financing supported by a risk reduction program. Where the cumulative cost of implementing all risk
treatment exceeds the available budget, the plan should clearly identify the priority order in which
individual risk treatments should be implemented. Priority ordering can be established using various
techniques, including risk ranking and cost-benefit analysis.

63 | P a g e
 Risk treatments which cannot be implemented within the limit of the available budget must either
await the availability of further financial resources or, if for whatever reason any or all of the remaining
treatments are considered important, a case must be made to secure additional finances. Risk
treatment options should consider how risk is perceived by affected parties and the most appropriate
ways to communicate to those parties.
Activity 10

Who would you need to consult with to determine your treatment options?

64 | P a g e
Record and implement agreed risk treatments
It is important that planned responses are appropriate to the significance of the risk, cost effective in
meeting the challenge, realistic within the project context, agreed upon by all parties involved, and
owned by a responsible person. The individual owner of each risk will need to communicate with the
appropriate stakeholders who may be impacted by it’s occurrence as part of managing the risk.

The risk plan defines the level of risk which is seen as acceptable, how risks will be managed, who will
be responsible for carrying out risk related activities, the time and cost of each risk activity and how
the communication of risk is to occur. You will need to use this along with the risk register to plan your
responses.

There are four possible strategies for dealing with threats or risks that may have negative impacts on
the project.
1. Avoid—This involves taking action to either reduce the probability of the risk and/or its impact to
zero. In either case this response enables the risk to be circumvented entirely. For example, using a
certain supplier might carry the risk of them going out of business during the course of the project.
This risk could be avoided by using a supplier who was bigger, better established and more financially
secure.
2. Transfer—This involves transferring the risk to a third party so that they are responsible for its
management and impact. It does not eliminate the risk it simply transfers the liability to someone else.
This can be done by:
○ Taking out insurance (the insurance company is now liable) or
○ Having the work done under a fixed-price contract (the contractor is now liable).
65 | P a g e
Risk transference nearly always involves payment of a risk premium to the party taking on the risk and
may introduce new risks. For example, an insurance company may contest the claim or a contractor
might dispute the terms and conditions of the contract if they are having problems delivering.

3. Mitigate—Taking early action to reduce the probability and/or impact of a risk occurring is often
more effective than trying to repair the damage after it has occurred. Adopting less complex
processes, conducting more tests, or choosing a more stable supplier are examples of mitigation
actions.
4. Accept—The most common acceptance strategy is to establish a contingency reserve, including
amounts of time, money, or resources to handle the risks. It is usually chosen either because: the risk
is low in terms of impact or probability, or the cost and effort of taking a different action is out of
proportion to the risk itself.

There are four possible strategies for dealing with opportunities.

1. Exploit—examples of directly exploiting responses include assigning an organisation’s most talented

resources to the project to reduce the time to completion or to provide lower cost than originally
planned.
2. Share—sharing a positive risk involves allocating some or all of the ownership of the opportunity to
a third party who is best able to capture the opportunity for the benefit of the project. Examples of
sharing actions include forming risk-sharing: Partnerships, Teams, Special-purpose companies, or Joint
ventures (JVs). These can be established with the express purpose of taking advantage of the
opportunity so that all parties gain from their actions.
3. Enhance—examples of enhancing opportunities include adding more resources to an activity to
finish early.
4. Accept—accepting an opportunity is being willing to take advantage of it if it comes along, but not
actively pursuing it. This is the process of implementing risk response plans, tracking identified risks,
monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout
the project.

66 | P a g e
Planned risk responses that are included in the project plan are executed during the life cycle of the
project, but the project work should be continuously monitored for new, changing, and outdated risks.
There are several techniques that can be used to control risks

Reassessment
Project risk reassessments should be regularly scheduled to keep the risk register updated. The
amount and detail of repetition that is appropriate depends on how the project progresses relative to
its objectives, as well as, which risks (if any) actually manifest themselves.

Audits
These should be scheduled in the risk plan and examine the effectiveness of risk responses in dealing
with identified risks and their root causes. The objectives should be clearly defined in advance and the
audit may form part of the routine project review meetings, or may be run separately, each producing
its own project audit report.

Trend Analysis
Earned value analysis and other methods of project variance and trend analysis may be used for
monitoring overall project performance. Outcomes from these analyses may forecast potential
deviation of the project at completion from cost and schedule targets. Deviation from the baseline
plan may indicate the potential impact of threats or opportunities.

67 | P a g e
Performance Measurement
This is designed to indicate the degree of technical risk faced by the project. Where deliverables can
be measured against the plans in a quantitative way e.g.: Response times, Number of defects, etc. This
can predict the degree of success in achieving the technical aims of the project.

Reserve Analysis
This compares the contingency reserves remaining to the amount of risk remaining at any time in the
project in order to determine if the remaining reserve is adequate. Implementing contingency plans
or workarounds sometimes results in a change request. Recommended preventive actions are
documented directions to perform on activity that can reduce the probability of negative
consequences associated with project risks.

Recommended corrective actions include contingency plans and workarounds. The latter are
responses that were not initially planned, but are required to deal with emerging risks that were
previously unidentified or accepted passively.

If the approved change requests have an effect on the process of managing risk, the corresponding
component documents of the project plan are revised and reissued to reflect the approved changes.

Just as in any project, there’s always a certain amount of paperwork that is part of the finished
deliverable. In the case of risk management, that’s the action plan for implementing risk treatment.
You can have the best ideas and plans, but until it’s written down and distributed to interested parties,
it won’t accomplish anything.

After a treatment option has been chosen for a particular risk, an action plan can be developed in
order to implement the treatment option. This action plan should state at a minimum:

 What the risk event is

 What actions are required
 Who is responsible for the various actions
 Time lines for execution
 Monitoring processes

As with any business process, the implementation of the treatment plan should include:

 Identifying stakeholders
 Identifying key personnel
 Developing timelines
 Training and communication processes
 Collection of data and formation of baselines
 Development of performance outcomes measures
 Examination of outcomes
 Feedback

68 | P a g e
Activity 11

Who is responsible for the implementation of risk treatments?

69 | P a g e
Update risk plans and allocate risk responsibilities to project team members9

Not only do you need to distribute the risk management plan to relevant parties, you’ll need to insure
that copies are created and stored in your company’s information management system. In many
companies, this is a computerized system for the storage of all pertinent company information. Since
part of your risk factors include the possibility of something happening to the company’s computer
systems, you should also insure that hard copies are created and stored.

It is essential that all copies of the risk management plan are created equal. Nothing can cause more
confusion than to have two different versions of a contingency plan floating around, when it is time
to implement that plan. Instead of the plan becoming a tool to insure that everyone knows what to
do, it becomes a point of argument, impeding corrective action.

To insure that all copies are created equal, you want to limit people’s ability to copy it. That can be a
little tricky, considering the ready access to copy machines in most companies. The one thing that can
work in your favor is that most people don’t like standing in front of a copy machine, waiting for it. So,
by placing notices in the plan, instructing people where they can get their own copy, you reduce the
likelihood of them copying somebody else’s.

Now that you have everyone coming to the same place to receive their copies of the risk management
plan, your next step is to insure that you keep an accurate log of who has those copies. This log should
contain a minimum of:

 Person’s name
 Title
 Department
 Phone number or extension
 Office location

This list will then become your distribution list for any changes. While not everyone will be quick to
put the updates into their binder, those who have secretaries will be sure to have accurate binders,
with all the latest updates. In other words, the people who have the greatest responsibility and
authority in your company will have the updated copies; not because they do the updating, but
because secretaries are really good at making sure that gets done.

9
Source: Fortress Learning, as at http://students.fortresslearning.com.au/bsbrsk501a-manage-risk/section-4-
select-and-implement-treatments-4/, as on 5th December, 2016.
70 | P a g e
Activity 12

How often should you update the risk management plan?

71 | P a g e
Establish regular risk review processes to maintain currency of risk plans10

On a regular basis, the project manager must review the risk log with the project team. The risk log
must be kept up-to-date at least on a weekly basis. In a risk based approach to managing project, this
should be the first thing in the agenda of any status meeting. Client should be part of the risk log
reviews. The objectives are to 1) determine if any of the risk item severity score has changed, and 2)
capture any new risk events. Go over the high severity risk items first, and then quickly review if any
of the low severity risk items need adjustment. If there are new risk items, they must go through the
same process and added to the risk log.

How would the risk owner know when to act on the risk response strategy? Each risk item also has a
trigger event. When a risk trigger event occurs, that would be the time for the owner to act. He/she
must inform the project manager and then start executing on the risk response strategy.

As the project progresses towards completion, the total risk severity score should display a downward
trend. This can be presented visually with a trending chart. If the severity score is not trending lower,
then most likely the initial round of risk identification did not capture most of the events. The PM
should conduct a risk review session with the team to ensure its completeness.

Regularly monitor risk environment to identify changed circumstances

impacting project risks11
Risk monitoring should be ongoing and continual. As you travel through the project lifecycle you
should be monitoring for changes in the environment and regularly recheck your assumptions. The
likelihood and impact of risks changes over time.

Early on in the project the likelihood of risks occurring is much greater due to the relative uncertainty
compared to the end of a project. Also the impact of risks changes over time; for example if you cancel
s project at the beginning you have expended less labour costs that at the end.

10
Source: Risk Based PM, as at http://riskbasedpm.com/risk-management-best-practices/, as on 5th December,
2016.
11
Source: Better Projects, as at http://www.betterprojects.net/2007/02/monitor-your-risks.html, as on 5th
December, 2016.
72 | P a g e
A project’s success factors change over time also. For example a building development may acquire a
success factor of dealing successfully with local anti-development protestors. The risks associated with
dealing with these stakeholders will change as their importance and influence changes.

As well as monitoring existing risks you will have the opportunity to monitor for new risks. Have new
opportunities for risk come up as a result of changing environment or scope? Has the project’s
business case or relationship with the rest of the world changed?

Specific things you can do to help monitor risks include:

73 | P a g e
  Risk Owners: Ensure all risks have an owner, even if there is no active management plan for
them. It is best if these risk owners will have to deal with the results of the risk occurring to
give them motivation to pay attention.
 Risk Meetings: Have formal risk review meetings where people have time to stop and think
about risks. Time may cost money but often risks can be much more expensive that they first
appear. You can also schedule low likelihood and impact risks to future dates.
 Triggers: Identify triggers for reviewing risks. If a risk is minor today but will become important
if something occurs, look out for the something.

Activity 13

Develop a sample agenda for a project risk monitoring meeting.

74 | P a g e
Activity 13

75 | P a g e
Determine risk responses to changed environment12

Risk Response generally includes:

 Avoidance…eliminating a specific threat, usually by eliminating the cause.

 Mitigation…reducing the expected monetary value of a risk event by reducing the probability
of occurrence.
 Acceptance…accepting the consequences of the risk. This is often accomplished by developing
a contingency plan to execute should the risk event occur.

In developing Contingency Plans, the Project Team engages in a problem solving process. The end
result will be a plan that can be put in place on a moment’s notice.

What a Project Team would want to achieve is an ability to deal with blockages and barriers to their
successful completion of the project on time and/or on budget. Contingency plans will help to ensure
that they can quickly deal with most problems as they arise. Once developed, they can just pull out
the contingency plan and put it into place.

Implement agreed risk responses and modify plans to maintain currency of risk
treatments and controls
Invariably, your risk management plan will require a number of actions to be taken in order to
implement it. I’ve already mentioned the need to take the initiative to insure that those items are
completed. You can’t count on others, even other managers doing it, because they are all busy with
other work

.
It would be advisable to create a master list of action items that need to be done to implement your
risk management plan. Depending upon how many risk factors you have discovered, and the types of
options you have selected for dealing with these risks, you may have a rather extensive list of items
on your to do list.

Hopefully, there will be some overlap in different action items, where the same action item may deal
with several different risks. Take insurance for example; you may have identified several different risks
(fire, hurricane, earthquake) for which the option decided upon was to share the risk with a third
party, an insurance company. In reality, that’s only one action item, although it deals with three
separate risks. You can take that one action item to the appropriate party, and track the progress of it
as one line item on your master list.

12
Source: Business Improvement Architects, as at https://bia.ca/risk-management-the-what-why-and-how/, as
on 5th December, 2016.
76 | P a g e
While there are parts of the risk management plan which require your direct involvement to
implement, especially if the appropriate manager doesn’t have the time or resources to implement
them, there are other parts which will be implemented by other. You will still want to track these
areas, to insure that they are actually completed and not derailed mid-stream.

Once the action items have been implemented, you also need to check and monitor, to insure that
they will function as expected. There are always a certain number of plans that don’t work out the
way we expect. Don’t be so rigid that you can’t recognize a failure when you see it. Should that happen,
be willing to admit your fault and try something else. People will respect you for admitting your fault.

Activity 14

Describe 2 ways modified plans could be distributed to project stakeholders.

77 | P a g e
Activity 14

78 | P a g e
Review project outcomes to determine effectiveness of risk-management
processes and procedures
Risk management is actually a never ending process. Reaching a point of completion in a risk
management project, only means that it’s time to go back and review everything over again. In the
months that it took to accomplish the project, there could have been enough change in one of the
variables to require review and changes to your plan.

It is critical to constantly monitor and review the processes and outcomes. Monitoring and reviewing
risk management processes helps to incorporate risk management as not only a corporate value, but
an employee value as well. The risk management process in not static but is taken in the context of
the internal and external environments. As these environments change, the variables affecting risk
also change. Evaluating the process of risk management can be assigned to individuals within
departments or to dedicated staff depending upon the nature of the organisation and the resources
available. Consultants may be brought in at critical times to evaluate processes and institute changes
based on risk contexts or environmental, social and political changes.

When a risk management plan is initiated, the set of variables that define the parameters are
evaluated and a course of action is taken. During that course, new variables are discovered and new
risks uncovered. Take a bike race, for example. When the race is begun, a biker has a given set of
parameters for the race: personal capabilities, bike performance, race route, etc. The racer may have
even trained on the course in a variety of different weather conditions in order to mitigate weather
conditions as a risk. As prepared as the racer is to face the known risks, other variables can emerge
that create risk before and during the race. New race conditions including cracks in the asphalt and
crowded conditions may create an entirely different set of risks that need to be identified, analysed,
evaluated, and treated while on the course itself.

In addition to planned and scheduled monitoring and review sessions to examine new risk, review of
the management plan must be ongoing in order to stay relevant. As policies, procedures, and visions
of a corporation change, risk changes. As external contexts change, risks change. Suitability and cost
factors for treatment options change. Treatment options or contingency plans may lose relevancy
throughout the process. External variables such as legislative actions may develop which creates a
different context under which to analyse and evaluate risk.

Examination of successes and failures in relation to anticipated outcomes is a necessary component

of the risk management process. It increases the probability that future risks can be evaluated with
higher levels of accuracy and greater success. An inability to achieve outcomes does not indicate
failure, but provides an opportunity to gain valuable knowledge regarding process change. Duplication
of ineffective processes leading to a repetition of unachieved outcomes indicates a failure to learn.
That can be tragic when corporations, and the people that depend on them, are at risk.

79 | P a g e
One of the key components to the risk management process is keeping an accurate record of
documentation relating to the communications, justifications, analyses and relevant information
pertaining to risk. Remember how we began the risk assessment process? With research relating to:

 Data or statistical information

 Information from other business areas
 Lessons learned from other projects or activities
 Market research
 Previous experience
 Public consultation
 Review of literature and other information sources

Developing logs in order to keep accurate records can greatly facilitate the research process. Logs and
records help us remember the reasons why things have been done in the way that they have been
done. They are also critical in cases where we need to pass the baton on to another risk manager.

Identify and document risk management issues and recommended

improvements for application to future projects13
Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) defines
lessons learned as the learning gained from the process of performing the project. Formally conducted
lessons learned sessions are traditionally held during project close-out, near the completion of the
project.

However, lessons learned may be identified and documented at any point during the project’s life
cycle.

The purpose of documenting lessons learned is to share and use knowledge derived from experience
to:
• Promote the recurrence of desirable outcomes
• Preclude the recurrence of undesirable outcomes

As a practice, lessons learned includes the processes necessary for identification, documentation,
validation, and dissemination of lessons learned. Utilization and incorporation of those processes
includes identification of applicable lessons learned, documentation of lessons learned, archiving
lessons learned, distribution to appropriate personnel, identification of actions that will be taken as a
result of the lesson learned, and follow-up to ensure that appropriate actions were taken.
Lessons learned document the cause of issues and the reasoning behind any corrective action taken
to address those issues. When thinking about how to effectively document a project’s lessons learned,
consider these types of questions:
• What was learned about the project in general?
• What was learned about project management?

13
Source: Mind Tools, as at https://www.mindtools.com/pages/article/newPPM_69.htm, as on 5th December,
2016.
80 | P a g e
• What was learned about communication?
• What was learned about budgeting?
• What was learned about procurement?
• What was learned about working with sponsors?
• What was learned about working with customers?
• What was learned about what went well?
• What was learned about what did not go well?
• What was learned about what needs to change?
• How will/was this incorporated into the project?

Lessons learned should draw on both positive experiences – good ideas that improve project efficiency
or save money, and negative experiences – lessons learned only after an undesirable outcome has
already occurred. Every documented lesson learned should contain at least these general elements:
• Project information and contact information for additional detail
• A clear statement of the lesson
• A background summary of how the lesson was learned
• Benefits of using the lesson and suggestion how the lesson may be used in the future

At any point during the project life cycle, the project team and key stakeholders may identify lessons.
The lessons learned are compiled, formalized, and stored through the project’s duration. Upon project
completion a lessons learned session is conducted that focuses on identifying project success and
project failures, and includes recommendation to improve future performance on projects.

The lessons learned session is typically a meeting that includes:

• Project team
• Selected stakeholder representation including external project oversight, auditors, and/or QA
• Project support staff

Participants in lessons learned sessions typically discuss questions similar to the following:
• Did the delivered product meet the specified requirements and goals of the project?
• Was the customer satisfied with the end product(s)? If not, why not?
• Where costs budgets met? If not, why not?
• Was the schedule met? If not, why not?
• Were risks identified and mitigated? If not, why not?
• Did the project management methodology work? If not, why not?
• What could be done to improve the process?
• What bottlenecks or hurdles were experienced that impacted the project?
• What procedures should be implemented in future projects?
• What can be done in future projects to facilitate success?
• What changes would assist in speeding up future projects while increasing communication?

Lessons learned and comments regarding project assessment should be documented, archived,
presented, and openly discussed with the intent of eliminating the occurrence of avoidable issues on
future projects.

81 | P a g e
Since most issues are, by their nature, unexpected, how do you make sure you'll be able to deal with
them quickly and effectively? Ideally, you need an issue resolution process in place before you start
your project – to make sure that you stay on schedule, and meet your objectives.

Issue management is the process of identifying and resolving issues. Problems with staff or suppliers,
technical failures, material shortages – these might all have a negative impact on your project. If the
issue goes unresolved, you risk creating unnecessary conflicts, delays, or even failure to produce your
deliverable.

Issues versus Risks

Issues and risks are not quite the same thing. However, the exact nature of both is largely unknown
before you begin. With risks, you usually have a general idea in advance that there's a cause for
concern. An issue tends to be less predictable; it can arise with no warning. For example, being unable
to find qualified staff is an identifiable risk. However, when one of your staff is in a car accident, and
hospitalized for three weeks, that becomes an issue!

It's important to identify risks before the project begins. A Risk/Impact Probability Chart provides a
useful framework to help you prioritize your risks. You can then develop a plan to manage those risks
proactively with solutions that you've already thought through and prearranged. However, when it
comes to issues, you have to deal with them as they happen. Issue management, therefore, is a
planned process for dealing with an unexpected issue – whatever that issue may be – if and when one
arises.

Tip:

When you don't identify and reduce risks at the beginning of a project, they can often become issues
later on. Make sure you understand your risks early. Learn from previous projects, and benefit from
the team's past experiences. This way, you'll have fewer issues to manage as you move forward.

Issues Log

Issues – otherwise known as problems, gaps, inconsistencies, or conflicts – need to be recorded when
they happen. When you create an issues log*, you provide a tool for reporting and communicating
what's happening with the project. This makes sure that issues are indeed raised, and then
investigated and resolved quickly and effectively. Without a defined process, you risk ignoring issues,
or not taking them seriously enough – until it's too late to deal with them successfully.

An issues log allows you to do the following:

 Have a safe and reliable method for the team to raise issues.
 Track and assign responsibility to specific people for each issue.
 Analyse and prioritize issues more easily.
 Record issue resolution for future reference and project learning.
 Monitor overall project health and status.

82 | P a g e
You can create an issues log by hand, build your own spreadsheet or database, or buy issue
management software from a wide variety of vendors.

However, do bear in mind that the success of your issue management process doesn't necessarily
depend on which tracking mechanism you use, but rather on the type of information you track.

You can include following information in an issues log:

 Issue type – Define the categories of issues that you're likely to encounter. This helps you
track issues and assign the right people to resolve them. You could have broad descriptions
like these:
 Technical – Relating to a technological problem in the project.
 Business process – Relating to the project's design.
 Change management – Relating to business, customer, or environmental changes.
 Resource – Relating to equipment, material, or people problems.
 Third party – Relating to issues with vendors, suppliers, or another outside party.
 Identifier – Record who discovered the issue.
 Timing – Indicate when the issue was identified.
 Description – Provide details about what happened, and the potential impact. If the issue
remains unresolved, identify which parts of the project will be affected.
 Priority – Assign a priority rating to the issue. Here's an example:
 High priority – A critical issue that will have a high impact on project success, and has
the potential to stop the project completely.
 Medium priority – An issue that will have a noticeable impact, but won't stop the
project from proceeding.
 Low priority – An issue that doesn't affect activities on the critical path, and probably
won't have much impact if it's resolved at some point.
 Assignment/owner – Determine who is responsible for resolving the issue. This person may
or may not actually implement a solution. However, he or she is responsible for tracking it,
and ensuring that it's dealt with according to its priority.
 Target resolution date – Determine the deadline for resolving the issue.

If a date for resolution changes, keep both the old date and the new date visible. This helps you spot
issues that have been on the log for a long time. Then you can either give them extra attention, or
take them off the list if they're no longer important.

 Status – Track the progress of the resolution with a clear label identifying the issue's overall
status. Here's an example:
 Open – The issue has been identified, but no action has yet been taken.
 Investigating – The issue, and possible solutions, are being investigated.
 Implementing – The issue resolution is in process.
 Escalated – The issue has been raised to management or the project sponsor/steering
committee, and directions or approval of a solution is pending.
 Resolved – The resolution has been implemented, and the issue is closed.

Use 'traffic lights' when reporting issues. This provides an easy-to-see indication of whether issues are
under control. Traffic lights could be used as follows:
83 | P a g e
  Red – Cannot proceed before issue is resolved.
 Yellow – Resolution in process, and you'll be able to proceed soon.
 Green – Resolution implemented, and issue no longer exists.

 Action/resolution description – Describe the status of the issue, and what has been done to
find and implement a resolution. Include the dates of each action. Here's an example:
 January 5 – Assigned issue to Samantha.
 January 7 – Testing started to identify origin of problem.
 January 8 – Solution suggested, and sent to steering committee for approval.
 January 10 – Approval received. Assigned implementation to Gregory.
 January 14 – Solution successful. Issue resolved.
 Final resolution – Include a brief description of what was done to address the issue.

Issues Management Framework

Supplement your issues log with a framework, or process, for dealing with those issues. This
framework helps the project team understand what to do with issues once they've been identified
and logged. Developing the framework answers questions like these:

 How will you assign responsibility for resolving the issue? For example, is there one person
who handles all technical issues? Who would handle a vendor issue?
 How will you know when to escalate an issue to management or the steering committee? You
may want to create a matrix of potential business impact versus issue complexity to help you
decide which issues should be taken to higher levels of management.
 Which criteria will determine an issue's priority status?
 Who will set the target resolution date?
 How will issues be communicated within the team? Will you use regular meetings, log checks,
status update emails, and so on?
 How will you identify different issues if several occur during one project? It is helpful to
number them so that you can identify issues easily when discussing them in progress
meetings.
 If change orders are needed, how will those be handled?
 When the resolution affects the budget or schedule, what will the update process be, and who
will be responsible?

One of the key challenges of issues management is to resolve the problem quickly and then move on,
with as little impact to the project as possible. The framework provides a structure for making
decisions when issues arise. Remember to consider your team's needs as you develop the framework.

It's also important to make sure you cover all issues in your Post-Implementation Review. This is where
you capture lessons learned for future projects. The more you learn about your issues, the better
prepared you'll be for the next project. Some issues might occur again, so by recording what you've
learned from previous projects, it will be easier for subsequent project teams to identify the issues,
and resolve them successfully. Other issues might be part of a risk pattern that you can proactively
identify and manage with early risk assessment.

84 | P a g e
An issues management process gives you a robust way of identifying and documenting issues and
problems that occur during a project. The process also makes it easier to evaluate these issues, assess
their impact, and decide on a plan for resolution. An issues log helps you capture the details of each
issue, so that the project team can quickly see the status, and who is responsible for resolving it. When
you add an issues management framework, you have a comprehensive plan to deal with issues quickly
and effectively. This organised approach to managing issues provides many valuable insights that can
be used to refine and improve future project results.

The ultimate purpose of documented lessons learned is to provide future project teams with
information that can increase effectiveness and efficiency and to build on the experience that has
been earned by each completed project. If documented and disseminated properly,

lessons learned provide a powerful method of sharing ideas for improving work processes, operation,
quality, safety and cost effectiveness, etc. and helps improve management decision making and
worker performance through every phase of a project. They also helps validate some of the tougher
times endured during the project’s life and helps future Project Managers avoid similar difficulties.

Best Practices
The following are recommended best practice approaches to Lessons Learned:
• Include All Experiences
- Lessons learned should draw on both positive and negative experiences.
• Act Quickly
- Obtain feedback as quickly as possible to avoid people forgetting the challenges faced during the
course of a project.
• Document
- Store lessons learned throughout the project in a central repository.
• Make Accessible
- Make lessons learned accessible to other projects.
• Archive Lessons
- Lessons learned should be archived as historical project data and incorporate into the organisations
lessons learned.
• Disseminate Lessons
- Disseminate lessons learned to the project management community.
• Reuse Lessons
- Reuse lessons learned from past projects to help better manage current projects.
• Involve Stakeholders
- Involve all project participants and stakeholders in the lessons learned process.
• Solicit Feedback
- Conduct a post-project survey to solicit feedback on the project from the project team, customers,
and stakeholders who were well-acquainted with the management of the project.
• Identify Lessons Learned
- Convene a lessons learned session to promote the success of future projects.
• Archive Data
- Archive all project data in a central repository. Include best practices, lessons learned, and any other
relevant project documentation.

85 | P a g e
Activity 15

How can an issue log be used in risk management in future projects?

86 | P a g e
Activity 15

87 | P a g e
 Business, Accounting and Finance
BSBPMG517 MANAGE PROJECT RISK
BSBPMG517 Manage project risk
Identify project risks

Analyse project risks

Establish risk treatments and

controls

Monitor and control project

risks

Assess risk management

outcomes

THE IMPORTANCE OF PROJECT RISK

PROJECT RISK MANAGEMENT
MANAGEMENT
• Project risk management is the art and science of identifying,
analyzing, and responding to risk throughout the life of a project and in Online video follows:
the best interests of meeting project objectives
• Risk management is often overlooked in projects, but it can help
improve project success by helping select good projects, determining
project scope, and developing realistic estimates
• Unfortunately, crisis management has higher visibility due to the
obvious danger to the success of the project but it’s risk management
that helps a project have fewer problems to begin with.

3 4

RESEARCH SHOWS NEED TO IMPROVE PROJECT

RISK MANAGEMENT
• Study by Ibbs and Kwak shows risk has the lowest maturity rating of
all knowledge areas
• A similar survey was completed with software development
companies in Mauritius, South Africa in 2003, and risk management
also had the lowest maturity (1.84 vs average of 2.29)
• A KLCI Research Group study (2001) shows the benefits of following
good software risk management practices
• 97% had procedures to identify and asess risk
• 80% identified anticipating and avoiding problems as the
primary benefit of risk management
5 • 70% had defined s/w development processes 6

• 64% has a Project Management Office

 BENEFITS FROM SOFTWARE RISK MANAGEMENT
PROJECT MANAGEMENT MATURITY BY INDUSTRY PRACTICES*
GROUP AND KNOWLEDGE AREA*
KEY: 1 = LOWEST MATURITY RATING 5 = HIGHEST MATURITY RATING
Engineering/ Telecommunications Information Hi-Tech Manufacturing
Knowledge Area Construction Systems

Scope 3.52 3.45 3.25 3.37

Time 3.55 3.41 3.03 3.50
Cost 3.74 3.22 3.20 3.97
Quality 2.91 3.22 2.88 3.26
Human Resources 3.18 3.20 2.93 3.18

Communications 3.53 3.53 3.21 3.48

Risk 2.93 2.87 2.75 2.76
Procurement 3.33 3.01 2.91 3.33

*Ibbs, C. William and Young Hoon Kwak. “Assessing Project Management Maturity,” *Kulik, Peter and Catherine Weber, “Software Risk Management Practices – 2001,
8 ”
Project Management Journal (March 2000). 7
KLCI Research Group (August 2001).

NEGATIVE RISK
RISK CAN BE POSITIVE
• A dictionary definition of risk is “the possibility of loss or injury”

• Negative risk involves understanding potential problems that might • Positive risks are risks that result in good things happening;
occur in the project and how they might impede project success sometimes called opportunities

• Negative risk management is like a form of insurance; it is an

• A general definition of project risk is an uncertainty that can have a
investment
negative or positive effect on meeting project objectives
• If IT projects are so risky, why do companies pursue them?
• The goal of project risk management is to minimize potential
negative risks while maximizing potential positive risks

9 10

BEST PRACTICE RISK UTILITY

• Some organizations make the mistake of only addressing tactical and • Different organizations and people have different tolerances for risk
negative risks when performing project risk management • Risk utility or risk tolerance is the amount of satisfaction or
pleasure received from a potential payoff
• David Hillson (www.risk-doctor.com) suggests overcoming this
problem by widening the scope of risk management to encompass • Utility rises at a decreasing rate for people who are risk-averse
both strategic risks and upside opportunities, which he refers to as • Those who are risk-seeking have a higher tolerance for risk and
their satisfaction increases when more payoff is at stake
integrated risk management
• Ensure that project delivery is tied to organizational needs and vision • The risk-neutral approach achieves a balance between risk and
payoff
• Allowing an appropriate level of risk to be taken intelligently with full
awareness of the degree of uncertainty and its potential effects on
objectives

11 12
 RISK UTILITY FUNCTION AND PROJECT RISK MANAGEMENT
RISK PREFERENCE PROCESSES
• Risk management planning: deciding how to approach and plan the
risk management activities for the project

• Risk identification: determining which risks are likely to affect a

project and documenting the characteristics of each

• Qualitative risk analysis: prioritizing risks based on their

probability and impact of occurrence

13 14

PROJECT RISK MANAGEMENT PROJECT RISK MANAGEMENT SUMMARY

PROCESSES
• Quantitative risk analysis: numerically estimating the effects of
risks on project objectives

• Risk response planning: taking steps to enhance opportunities and

reduce threats to meeting project objectives

• Risk monitoring and control: monitoring identified and residual

risks, identifying new risks, carrying out risk response plans, and
evaluating the effectiveness of risk strategies throughout the life of the
project

16
15

TOPICS ADDRESSED IN A RISK

RISK MANAGEMENT PLANNING MANAGEMENT PLAN
• The main output of risk management planning is a risk management • Methodology: How will risk management be performed on this project? What
plan—a plan that documents the procedures for managing risk tools and data sources are available and applicable?
• Roles and Responsibilities: Who are the individuals responsible for
throughout a project implementing specific tasks and providing deliverables related to risk
• The project team should review project documents, corporate risk management?
management policies, lessons-learned reports from past projects and • Budget and Schedule: What are the estimated costs and schedules for
understand the organization’s and the sponsor’s approaches to risk performing risk-related activities?
• Important to clarify roles and responsibilities, prepare budget and • Risk Categories: What are the main categories of risks that should be
addressed on this project? Is there a risk breakdown structure for the project?
schedule estimates for risk-related work and identify risk categories for
• Risk Probability and Impact: How will the probabilities and impacts of risk
consideration
items be assessed? What scoring and interpretation methods will be used for
• The level of detail will vary with the needs of the project the qualitative and quantitative analysis of risks?
• Risk Documentation: What reporting formats and processes will be used for
risk management activities?
17 18
 CONTINGENCY AND FALLBACK PLANS, COMMON SOURCES OF RISK IN INFORMATION
CONTINGENCY RESERVES TECHNOLOGY PROJECTS
• In addition to a risk management plan, many projects also include:
• Contingency plans – predefined actions that the project team will take if an • Several studies show that IT projects share some common sources of
identified risk event occurs risk
• Expecting new release of a s/w package, must plan to use older version
if delayed • The Standish Group developed an IT success potential scoring sheet
• Fallback plans - developed for risks that have a high impact on meeting (next slide) based on potential risks
project objectives, and are put into effect if attempts to reduce the risk are
• If a potential project does not receive a minimum score, the
not effective
organization might decide not to work on it or to take actions to
• College grad has main plan and contingency plans of where to live
after graduation but needs fallback plan to possibly live at home
reduce the risks before it invests too much time or money
• Contingency reserves or allowances - provisions held by the project • The Standish Group developed specific questions for each success
sponsor or organization to reduce the risk of cost or schedule overruns to criterion to help decide the number of points to assign to a project
an acceptable level
• Project falling behind schedule due to inexperience with new 19 • User Involvement: Do I have the right users? Did I involve the users early 20
on?
Do I make involvement easy? …
technology, use these funds to hire outside trainer

INFORMATION TECHNOLOGY SUCCESS BROAD CATEGORIES OF RISK

POTENTIAL SCORING SHEET • Many organizations develop their own risk questionnaires. Some of the
Success Criterion Relative Importance categories of risk might include:
User Involvement 19
 The number of • Market risk – Will the new service or product be useful to the organization
Executive Management support 16
questions or marketable to others? Will the users accept it? Will someone else create
corresponding to each
Clear Statement of Requirements 15 a better product?
success criterion
Proper Planning 11 • Financial risk – can the organization afford to undertake the project? Will
determines the number
Realistic Expectations 10 the project meet NPV, ROI and payback estimates?
of points each positive
Smaller Project Milestones 9 • Technology risk – is the project technically feasible? Is it leading edge or
response is assigned
Competent Staff 8 bleeding edge technology?
Ownership 6  Ex: User involvement:
• People risk – Are people with appropriate skills available to help complete
19/5 (or 3.8) points
Clear Visions and Objectives 3 the project? Does senior management support the project?
per question
Hard-Working, Focused Staff 3 • Structure/process risk – What is the degree of change the new project will
answered positively
Total 100 introduce into user areas and business procedures? With how many other
21 22
systems does a new project/system need to interact?

WHAT WENT WRONG? RISK BREAKDOWN STRUCTURE

• KPMG, a large consulting firm, published a study in 1995 that found that
55 percent of runaway projects—projects that have significant cost or • A risk breakdown structure is a hierarchy of potential risk
schedule overruns—did no risk management at all; 38 percent did categories for a project
some (but half did not use their risk findings after the project was
underway); and 7 percent did not know whether they did risk • Similar to a work breakdown structure but used to identify and
management or not categorize risks
• The timing of risk management is also an important consideration
• In addition to identifying risk based on the nature of the project or
• Comair delayed replacing a legacy system that managed flight products produced, it is also important to identify potential risks
crews and, when it eventually crashed over the holidays, 3,900 according to project management knowledge areas
flights were cancelled, 200,000 passengers were stranded and ran
up a tab of $20 million.
23 24
 SAMPLE RISK BREAKDOWN POTENTIAL NEGATIVE RISK CONDITIONS
STRUCTURE ASSOCIATED WITH EACH KNOWLEDGE AREA

25 26

RISK IDENTIFICATION BRAINSTORMING

• Risk identification is the process of understanding what potential events • Brainstorming is a technique by which a group attempts to generate
might hurt or enhance a particular project ideas or find a solution for a specific problem by amassing ideas
• This is an ongoing process throughout the project lifecycle as things change spontaneously and without judgment
• You can not manage risks that you don’t identify • An experienced facilitator should run the brainstorming session
• Risk identification tools and techniques include:
• Be careful not to overuse or misuse brainstorming
• Brainstorming
• Psychology literature shows that individuals produce a greater number of
• The Delphi Technique
ideas working alone than they do through brainstorming in small, face-to-
• Interviewing
face groups
• SWOT analysis
• Group effects often inhibit idea generation

27 28

DELPHI TECHNIQUE INTERVIEWING

• The Delphi Technique is used to derive a consensus among a panel of
• Interviewing is a fact-finding technique for collecting information in
experts who make predictions about future developments
face-to-face, phone, e-mail, or instant-messaging discussions
• Developed by the RAND Corporation for the US Air
• Useful to have a prepared set of questions as a guide to the interview
Force in the late 1960s
• Provides independent and anonymous input regarding future events • Interviewing people with similar project experience is an important
• Uses repeated rounds of questioning and written responses and avoids tool for identifying potential risks
the biasing effects possible in oral methods, such as brainstorming
• Requires a panel of experts for the particular area in question

29 30
 OTHER RISK IDENTIFICATION
SWOT ANALYSIS
METHODS
• SWOT analysis (strengths, weaknesses, opportunities, and threats) can • Checklists based on risks encountered in previous projects
also be used during risk identification
• Analyze the validity of project assumptions as incomplete,
• Project teams focus on the broad perspectives of potential risks for
particular projects
inaccurate and/or inconsistent assumptions can lead to
• What are the company’s strengths and weaknesses related to this project identifying more risks
• What opportunities and threats exist • Diagramming techniques: cause-and-effect, fishbone,
• Helps identify the broad negative and positive risks that apply to a flowcharts and influence diagrams
project
• Influence diagrams represent decision problems by displaying
essential elements, including decisions, uncertainties, causality and
objectives and how they influence each other
31 (www.lumina.com/software/influencediagrams.html) 32

OTHER RISK IDENTIFICATION METHODS OTHER RISK IDENTIFICATION METHODS

• An influence diagram is a simple visual representation of a decision problem.
Influence diagrams offer an intuitive way to identify and display the essential A decision is a variable that you, as the decision
elements, including decisions, uncertainties, and objectives, and how they maker, have the power to control.
influence each other.
A chance variable is uncertain and you cannot
control it directly.

An objective variable is a quantitative criterion

that you are trying to maximize (or minimize).

A general variable is a deterministic function of

• This simple influence diagram shows how decisions about the marketing budget the quantities it depends on.
and product price influence expectations about its uncertain market size and
market share. These, in turn, influence costs and revenues, which affect the overall An arrow denotes an influence. A influences B
profit. means that knowing A would directly affect our
belief or expectation about the value of B. An
• The product manager, VP of marketing, and market analyst may work together to
influence expresses knowledge about relevance.
draw such a diagram to develop a shared understanding of the key issues. The
It does not necessarily imply a causal relation, or
diagram provides a high-level qualitative view under which the analyst builds a
33 a flow of material, data, or money. 34
detailed quantitative model.

RISK REGISTER RISK REGISTER CONTENTS

• The main output of the risk identification process is a list of
identified risks and other information needed to begin creating a
risk register • An identification number for each risk event
• A risk register is: • A rank for each risk event
• A document that contains the results of various risk management
• The name of each risk event
processes and that is often displayed in a table or spreadsheet
format • A description of each risk event
• A tool for documenting potential risk events and related information
• The category under which each risk event falls
• Risk events refer to specific, uncertain events that may occur to
the detriment or enhancement of the project • The root cause of each risk
• Negative risks: delays in completing work as scheduled, increases in
estimated costs, supply shortages, litigation, strikes, etc.
• Positive risks: completing work sooner and/or cheaper than planned,
35 36
collaborating with suppliers to produce better products, good publicity,
etc.
 RISK REGISTER CONTENTS SAMPLE RISK REGISTER
(CONTINUED)
• Triggers for each risk; triggers are indicators or symptoms of actual
risk events
• Cost overruns on early activities, defective products

• Potential responses to each risk

• The risk owner or person who will own or take responsibility for
each risk
• The probability and impact of each risk occurring
• The status of each risk

37

38

QUALITATIVE RISK ANALYSIS PROBABILITY/IMPACT MATRIX

• After identifying risks, the next step is to understand which risks are
• A probability/impact matrix or chart lists the relative
most important
probability of a risk occurring on one side of a matrix or axis on a
• Assess the likelihood and impact of identified risks to determine their chart and the relative impact of the risk occurring on the other
magnitude and priority
• List the risks and then label each one as high, medium, or low in
• Risk quantification tools and techniques include: terms of its probability of occurrence and its impact if it did occur
• Probability/impact matrixes • Deal first with those risks in the high probability/high impact cell
• The Top Ten Risk Item Tracking
• Expert judgment
39 40

SAMPLE PROBABILITY/IMPACT MATRIX RISK FACTORS

• Can also calculate risk factors
• Numbers that represent the overall risk of specific events based
on their probability of occurring and the consequences to the
project if they do occur
• Probabilities of a risk occurring can be estimated based on
several factors based on the unique nature of each project
• For example: technology not being mature, technology too
complex, inadequate support base for developing the
technology
• The impact of a risk could include factors such as the availability
of fallback solutions or the consequences of not meeting
41 42
performance, cost and schedule estimates
 HIGH-, MEDIUM-, AND LOW-RISK TECHNOLOGIES TOP TEN RISK ITEM TRACKING
 Example of how risk factors were used to graph the probability of
failure and consequence of failure for proposed technologies in a
research study to help design more reliable aircraft
• Top Ten Risk Item Tracking is a qualitative risk analysis tool that
 Based on this chart, the recommendation was made to invest in low- to
medium-risk technologies and not pursue high-risk technology helps to identify risks and maintain an awareness of risks throughout
the life of a project
• Establish a periodic review of the top ten project risk items
• List the current ranking, previous ranking, number of times the risk
appears on the list over a period of time, and a summary of progress
made in resolving the risk item

43 44

TOP TEN RISK ITEM TRACKING EXAMPLE OF TOP TEN RISK ITEM
TRACKING
• Keeps management and the customer aware of the major influences
that could prevent or enhance the project’s success
• By involving the customer, the project team may be able to consider
alternative strategies for addressing the risks
• It’s a means of promoting confidence in the project team by
demonstrating to management and the customer that the team is aware
of the significant risks, has a strategy in place and is effectively
carrying out that strategy

45 46

WATCH LIST QUANTITATIVE RISK ANALYSIS

• Often follows qualitative risk analysis, but both can be done together
• A watch list is a list of risks that are low priority, but are still • Large, complex projects involving leading edge technologies often
require extensive quantitative risk analysis
identified as potential risks
• Main techniques include:
• Qualitative analysis can also identify risks that should be evaluated
• Decision tree analysis
on a quantitative basis
• Simulation
• Sensitivity analysis

47 48
 DECISION TREES AND EXPECTED MONETARY VALUE (EMV)
EXPECTED MONETARY VALUE (EMV)
• A decision tree is a diagramming analysis technique used to help
select the best course of action in situations in which future outcomes
are uncertain
• Estimated monetary value (EMV) is the product of a risk event
probability and the risk event’s monetary value
• You can draw a decision tree to help find the EMV

49 50

SIMULATION STEPS OF A MONTE CARLO ANALYSIS

• Simulation uses a representation or model of a system to 1. Assess the range for the variables being considered – gather most
likely, optimistic and pessimistic time estimates for each task
analyze the expected behavior or performance of the system
2. Determine the probability distribution of each variable
• To use a Monte Carlo simulation, you must have three estimates (most 1. Optimistic 8 weeks, most likely 10 and pessimistic 15
likely, pessimistic, and optimistic) plus an estimate of the likelihood of
3. For each variable, select a random value based on the probability
the estimate being between the most likely and optimistic values distribution
1. 20% chance between 8 and 10 weeks, 80% between 10 and 15
• Monte Carlo analysis simulates a model’s outcome many
4. Run a deterministic analysis or one pass through the model
times to provide a statistical distribution of the calculated
5. Repeat steps 3 and 4 many times to obtain the probability
results distribution of the model’s results – usually between 100 to 1,000
• Predicts the probability of finishing by a certain date or that the cost iterations
51 52
will be equal to or less than a certain value

SAMPLE MONTE CARLO SIMULATION WHAT WENT RIGHT?

RESULTS FOR PROJECT SCHEDULE • A large aerospace company used Monte Carlo simulation to help
quantify risks on several advanced-design engineering projects, such
as the National Aerospace Plan (NASP)
• Design a vehicle that could fly into space using a single-stage-to-
orbit approach
• The results of the simulation were used to determine how the
company would invest its internal research and development
funds
• Although the NASP project was terminated, the resulting research
has helped develop more advanced materials and propulsion
systems used on many modern aircraft
• Eli Lily uses simulation to determine the optimal plant capacity
53 54
that should be built for each drug
 SENSITIVITY ANALYSIS SAMPLE SENSITIVITY ANALYSIS FOR
DETERMINING BREAK-EVEN POINT

• Sensitivity analysis is a technique used to show the effects of

changing one or more variables on an outcome
• For example, many people use it to determine what the monthly
payments for a loan will be given different interest rates or periods of
the loan, or for determining break-even points based on different
assumptions
• Spreadsheet software, such as Excel, is a common tool for performing
sensitivity analysis

55 56

RISK RESPONSE PLANNING GENERAL RISK MITIGATION

STRATEGIES FOR TECHNICAL, COST,
• After identifying and quantifying risks, you must decide how AND SCHEDULE RISKS
to respond to them
• Four main response strategies for negative risks:
• Risk avoidance – don’t use h/w or s/w if unfamiliar with them
• Risk acceptance – prepare for risk with backup plan or
contingency reserves
• Risk transference – to deal with financial risk exposure, a company
may purchase special insurance for specific h/w needed for a
project. If h/w fails, insurer has to replace it.
• Risk mitigation – reduce probability of occurrence e.g., use proven
58
technology, buy maintenance or service contract
57

RESPONSE STRATEGIES FOR RESIDUAL AND SECONDARY RISKS

POSITIVE RISKS
• It’s also important to identify residual and secondary risks
• Risk exploitation – do whatever you can to make sure the risk occurs, • Residual risks are risks that remain after all of the response strategies
call press conference to advertise new product, take out ads, etc
have been implemented
• Risk sharing – allocating ownership of the risk to another party. Hire
an outside firm to do your advertising and PR • Even though used stable h/w platform, it still may
• Risk enhancement – identify and maximize key drivers of the risk. fail
Encourage your employees or users of your product to spread the
word of your product • Secondary risks are a direct result of implementing a risk response
• Risk acceptance – don’t take any action with regard to positive risk.
Assume the product will speak for itself
• Using stable h/w may have caused a risk of
peripheral devices failing to function properly

59 60
 MEDIA SNAPSHOT RISK MONITORING AND CONTROL
• Involves executing the risk management process to
• A highly publicized example of a risk response to respond to risk events
corporate financial scandals, such as those affecting Enron, • This is an ongoing activity – new risks identified, old risks
Arthur Andersen, and WorldCom, was legal action disappear, weaken or get stronger
• The Sarbanes-Oxley Act is considered the most significant
• Workarounds are unplanned responses to risk events
change to federal securities laws in the United States since
the New Deal that must be done when there are no contingency plans
• Fines, prison sentences up to 20 years for anyone who knowingly alters or • Main outputs of risk monitoring and control are:
destroys a record or document with the intent to obstruct an investigation
• Requested changes
• This Act has caused many organizations to initiate projects
and other actions to avoid litigation • Recommended corrective and preventive actions
• Updates to the risk register, project management plan, and
organizational process assets
61 62

USING SOFTWARE TO ASSIST IN RESULTS OF GOOD PROJECT RISK

PROJECT RISK MANAGEMENT MANAGEMENT

• Risk registers can be created in a simple Word or Excel file or as part • Unlike crisis management, good project risk management often goes
of a database unnoticed

• More sophisticated risk management software, such as Monte Carlo • Well-run projects appear to be almost effortless, but a lot of work
simulation tools, help in analyzing project risks goes into running a project well

• The PMI Risk Specific Interest Group’s Web site at www.risksig.com • Project managers should strive to make their jobs look easy to reflect
has a detailed list of software products to assist in risk management the results of well-run projects

63 64

Any Questions?

65
Student Assessment Information
The process you will be following is known as competency-based assessment. This means that
evidence of your current skills and knowledge will be measured against national and international
standards of best practice, not against the learning you have undertaken either recently or in the
past. (How well can you do the job?)

Some of the assessment will be concerned with how you apply the skills and knowledge in your
workplace, and some in the training room.

The assessment tasks utilized in this training have been designed to enable you to demonstrate the
required skills and knowledge and produce the critical evidence required so you can successfully
demonstrate competency at the required standard.

What happens if your result is ‘Not Yet Competent’ for one or more assessment tasks?

The assessment process is designed to answer the question “has the participant satisfactorily
demonstrated competence yet?” If the answer is “Not yet”, then we work with you to see how we can
get there.
In the case that one or more of your assessments has been marked ‘NYC’, your Trainer will provide
you with the necessary feedback and guidance, in order for you to resubmit/redo your assessment
task(s).
What if you disagree on the assessment outcome?

You can appeal against a decision made in regards to an assessment of your competency. An appeal
should only be made if you have been assessed as ‘Not Yet Competent’ against specific competency
standards and you feel you have sufficient grounds to believe that you are entitled to be assessed as
competent.
You must be able to adequately demonstrate that you have the skills and experience to be able to
meet the requirements of the unit you are appealing against the assessment of.
You can request a form to make an appeal and submit it to your Trainer, the Course Coordinator, or
an Administration Officer. The RTO will examine the appeal and you will be advised of the outcome
within 14 days. Any additional information you wish to provide may be attached to the form.
What if I believe I am already competent before training?

If you believe you already have the knowledge and skills to be able to demonstrate competence in this
unit, speak with your Trainer, as you may be able to apply for Recognition of Prior Learning (RPL).
Credit Transfer
Credit transfer is recognition for study you have already completed. To receive Credit Transfer, you
must be enrolled in the relevant program. Credit Transfer can be granted if you provide the RTO with
certified copies of your qualifications, a Statement of Attainment or a Statement of Results along with
Credit Transfer Application Form. (For further information please visit Credit Transfer Policy)

88 | P a g e
LEARNING OUTCOMES
The following critical aspects must be assessed as part of this unit:

1. Interact with customers, collect the necessary information and match customers' needs to company
products or service
2. Sell products and services including matching customers' requirements to company products and
services and finalise and record the sale

LEARNING ACTIVITIES

Class will involve a range of lecture based training, activities, written task, case study and questioning.

STUDENT FEEDBACK

We welcome your feedback as one way to keep improving this unit. Later this semester, you will be
encouraged to give unit feedback through completing the Quality of Teaching and Learning Survey

LEARNING RESOURCES
Other Learning Resources available to students include:

 Candidate Resource & Assessment: BSBPMG517 - Manage project risk

 Presentation handout
 PPT Presentation

TEXTBOOKS

You do not have to purchase the following textbooks but you may like to refer to them:

Unit Code(s) Unit Title Reference Book/ Trainer & Learner Resource

BSBPMG517 Manage project risk  The Business Communication Handbook 7th

edition
 The Principles of Project Management (Merri
Williams)
 Project Management in Practice by Neil D.
Pearson
89 | P a g e
  Trainer and Learner Resources by LRES
Training Management

Additional Reference Texts  The Business Communication Handbook 7th

edition
 The Principles of Project Management (Merri
Williams)
 Project Management in Practice by Neil D.
Pearson
 Trainer and Learner Resources by LRES
Training Management

ASSESSMENT DETAILS

Assessment Summary
The assessment for this unit consists of the following items.

Knowledge Assessment

Task 1 – Managing Project Risk

Formative Activities
In addition to the two assessment tasks, students will be required to complete activities as outlined
by their trainer/assessor – these will be taken from class resources, Enhance Your Future Learner
Guides.

Referencing Style
Students should use the referencing style outlined by the Trainer when preparing assignments. More
information can be sought from your Course Trainer.

Guidelines for Submission

1. An Assignment Cover Sheet (or cover page) must accompany all assignments at front to
confirm it is your own assessment/ work.

2. All assignments must be within the specified timeframe (please refer to Due Date).

90 | P a g e
Assignment Marking
Students should allow 14 days’ turnaround for written assignments.

Plagiarism Monitoring
Students should use the referencing style outlined by when preparing assignments. More information
can be sought from your Trainer.

Marking Guide
C Competent: for students who have achieved all of the learning outcomes specified for
that unit/module to the specified standard.

NYC Not Yet Competent: for students who are required to re-enrol in a unit/ module in their
endeavour to achieve competence

S Satisfactory: has achieved all the work requirements

NS Not Satisfactory: has not achieved all the work requirements

Every student at Danford College can expect to have “timely fair and constructive assessment of
work.” Assessment tasks must be marked in such a way that the result reflects how well a student
achieved the learning outcomes and in accordance with the assessment criteria. In addition to the
final result, returned assignments must be accompanied by feedback that clearly explains how the
marking result/s was derived (summative), as well as how the student can improve (formative).

Refer to observation checklist below and/or consult your trainer/assessor for marking criteria for
this unit.

STUDENTS’ RIGHTS AND RESPONSIBILITIES

It is the responsibility of every student to be aware of all relevant legislation, policies and procedures
relating to their rights and responsibilities as a student. These include:
 The Student Code of Conduct
 The College’s policy and statements on plagiarism
 Copyright principles and responsibilities
 The College’s policies on appropriate use of software and computer facilities

91 | P a g e
 Students’ responsibility to attend, update personal details and enrolment
 Course Progress Policy and Attendance
 Deadlines, appeals, and grievance resolution
 Student feedback
 Other policies and procedures.
 Electronic communication with students

International Students Please also refer to ESOS framework for further details
https://internationaleducation.gov.au/Regulatory-Information/Education-Services-for-Overseas-
Students-ESOS-Legislative-Framework/ESOS-Act

ADDITIONAL INFORMATION

Contacts:
If you have a query relating to administrative matters such as obtaining assessment results, please
contact your Course co-ordinator.

Deferrals/Suspensions/Cancellations
Danford College will only allow deferrals/student requested suspensions under exceptional
compassionate circumstances. Once a student has commenced studies, students are not allowed to
take leave unless there are compelling and compassionate reasons. Please refer to the College’s
Deferment, Suspension and Cancellation Policy available in the Student Handbook and at Student
Administration. This policy has been explained to you at Orientation.

Course Progress Policy

You are expected to attend all classes and complete your units of study satisfactorily, within your term.
Your Course Trainer will make a report to the Course co-ordinator if there are any concerns about your
progress. The Course Progress Policy is available to you in the Student Handbook and at Student
Administration or on college website www.danford.edu.au.

Assessment Conditions

Assessment must be conducted in a safe environment where evidence gathered demonstrates

consistent performance of typical activities experienced in the management and leadership – project
management field of work and include access to:
 workplace risk management documentation

92 | P a g e
  feedback from project stakeholders about how risks were managed.

Assessors must satisfy SRTO2015/AQF assessor requirements.

93 | P a g e
Lesson/Session Plan
For face-to-face classroom based delivery as per timetable.

Delivery Day Delivery Topics Activities to be undertaken

1 Introduction to BSBPMG517 Manage Work through corresponding sections
project risk and Assessment of Learner Materials and Assessment
Requirements Overview (Page4) Tasks
Determine risk objectives and Activity 1 (Page 11)
standards, with input from Commence Written Questions
stakeholders (Page 8) PowerPoint Presentation – Slides 1 –
25

2 Establish project risk context to inform Work through corresponding sections

risk management processes (Page 15) of Learner Materials and Assessment
Tasks
Activity 2 (Page 17)

3 Identify project risks using valid and Work through corresponding sections
reliable risk identification methods of Learner Materials and Assessment
(Page 21) Tasks
Classify project risks within agreed risk Activity 3 (Page 23)
categories (Page 24) Activity 4 (Page 27)
PowerPoint Presentation – Slides 26 –
37

4 Determine risk analysis classification Work through corresponding sections

criteria and apply to agreed risk of Learner Materials and Assessment
ranking system (Page 28) Tasks
Activity 5 (Page 30)
5 Use risk analysis processes, within Work through corresponding sections
delegated authority, to analyse and of Learner Materials and Assessment
qualify risks, threats and opportunities Tasks
(Page 32) Activity 6 (Page 39)
Commence Task 1 – Managing Project
Risk
PowerPoint Presentation – Slides 39 -
60
6 Determine risk priorities in agreement Work through corresponding sections
with project client and other of Learner Materials and Assessment
stakeholders (Page 41) Tasks
Activity 7 (Page 45)
7 Document risk analysis outcomes for Work through corresponding sections
inclusion in risk register and risk of Learner Materials and Assessment
management plan (Page 47) Tasks
Activity 8 (Page 54)

94 | P a g e
Delivery Day Delivery Topics Activities to be undertaken
8 Identify and document existing risk Work through corresponding sections
controls (Page 56) of Learner Materials and Assessment
Tasks
Activity 9 (Page 58)
9 Consider and determine risk Work through corresponding sections
treatment options using agreed of Learner Materials and Assessment
consultative methods (Page 59) Tasks
Activity 10 (Page 64)
10 Record and implement agreed risk Work through corresponding sections
treatments (Page 65) of Learner Materials and Assessment
Update risk plans and allocate risk Tasks
responsibilities to project team Activity 11 (Page 69)
members (Page 70) Activity 12 (Page 70)
11 Establish regular risk review processes Work through corresponding sections
to maintain currency of risk plans of Learner Materials and Assessment
(Page 72) Tasks
Regularly monitor risk environment to Activity 13 (Page 74)
identify changed circumstances PowerPoint Presentation – Slides 61 -
impacting project risks (Page 72) 64
12 Determine risk responses to changed Work through corresponding sections
environment (Page 76) of Learner Materials and Assessment
Tasks
13 Implement agreed risk responses and Work through corresponding sections
modify plans to maintain currency of of Learner Materials and Assessment
risk treatments and controls (Page 76) Tasks
Activity 14 (Page 77)
14 Review project outcomes to Work through corresponding sections
determine effectiveness of risk- of Learner Materials and Assessment
management processes and Tasks
procedures (Page 79) Activity 15 (Page 85)
Identify and document risk Complete Written Questions
management issues and
recommended improvements for
application to future projects (Page
80)
15 ASSESSMENT Complete Task 1 – Managing Project
Risk

95 | P a g e
Knowledge Assessment (Written Tasks)

1. What does Risk identification entail?

2. Project managers document the possible project risks in the:

(a) Risk Register
(b) Project Charter
(c) Risk Management Plan
(d) Project Scope Statement

3. Qualitative risk analysis typically involves examining historical information to make informed
decisions while for each possible outcome, quantitative risk analysis identifies the:
(a) Cost and time
(b) Type and category
(c) Formal and informal
(d) Magnitude and probability

4. During risk management planning, team members identify the triggers associated with each risk.
These warning signs represent the:
(a) Budget allocated to managing the risk
(b) Resources assigned to handling the risk
(c) Events that result in the risk actually occurring
(d) Actions the team should take when the risk actually occurs

96 | P a g e
5. Project managers identify preventive actions for risks that represent threats. They also need to
prepare for events that represent:
(a) Strengths
(b) Weakness
(c) Opportunities
(d) Contingencies

6. To assign an owner to each risk identified for the project, develop a:

(a) Probability Impact Matrix
(b) Work Breakdown Structure
(c) Schedule Performance Index
(d) Responsibility Assignment Matrix

7. Which of the following tools and techniques are used in the Identify Risks process to identify
events that might impact the project and document their characteristics
(a) Brainstorming
(b) SWOT Analysis
(c) Expert Judgment
(d) All of the Above

8. Which of the following is not an effective risk management tool?

(a) Work Breakdown Structure
(b) Excel spreadsheets
(c) Cause and effect diagrams
(d) Decision tree models
(e) System failure models
(f) Cost and schedule simulations

9. During which phase does the project manager implement approved actions to minimise the
impact of negative events on the project?
(a) Initiation
(b) Planning
(c) Executing
(d) Monitoring and Controlling
(e) Closing

10. Your project sponsor has asked you to present your project’s high-level risk register to him in
the next project update meeting. Which of the following processes must be started to have your
high level risk register?
(a) Perform Qualitative Risk Analysis
(b) Plan Risk Management
(c) Identify Risks
(d) Control Risks

97 | P a g e
11. Andrew is a Project Manager for Green Valley project. A risk management plan has been
prepared for the project. Which of the following should Andrew do next?
(a) Perform Qualitative risk analysis
(b) Perform Quantitative risk analysis
(c) Identify Risks
(d) Plan Risk responses

12. Which of these is a valid response to negative risks and not positive risks?
(a) Exploit
(b) Mitigate
(c) Enhance
(d) Share

13. As the project manager, of a project to construct a city park, you have yourself identified 39 risks
on the project, determined what would trigger the risks, rated them on a risk rating matrix, tested
the assumptions and assessed the quality of the data used. You now plan to move to the next step
of the risk management process. What have you missed?
(a) Overall risk ranking for the project
(b) Involvement of other stakeholders
(c) Risk Mitigation
(d) Simulation

14. John Strauss is a Project Manager for a reforestation project. To identify the risks involved, John
sends a questionnaire to gather inputs from experts. Which technique is John using?
(a) Delphi technique
(b) Interviews
(c) Brain storming
(d) Documentation review

15. Mathew is a Project Manager for software migration at a bank. A major risk that has been
identified is attrition of resources. As a strategy to respond to this risk, Mathew, with support from
Senior Management, provides good increments to his team members. What type of risk response is
Mathew following?
(a) Accept
(b) Avoid
(c) Transfer
(d) Mitigate

16. Which of these are valid responses to positive risks?

(a) Exploit
(b) Mitigate
(c) Enhance
(d) Share

98 | P a g e
17. During which stage of risk planning are risks prioritised based on their relative probability and
impact?
(a) Plan Risk Responses
(b) Identify Risks
(c) Perform Qualitative risk analysis
(d) Perform Quantitative risk analysis

18. Which of the following is true about risks?

(a) Risk impact should be considered, but probability of occurrence is not important
(b) The risk register documents all the identified risks in detail
(c) Risks always have negative impact and not positive
(d) Risk Response Plan is another name for Risk Management Plan.

99 | P a g e
Task 1 – Managing Project Risk
This assessment task requires you to:

 conduct effective risk management for a project of sufficient complexity to demonstrate the
full range of performance requirements
 Apply risk management techniques, strategies and tools.

Assuming your organisation was awarded the following tender:

ATM ID: NAA RFT 20xx/1058

Agency: National Archives of Australia
Category: 81110000 - Computer services
Close Date & Time: 15-Aug-20xx 2:00 pm (ACT Local Time)

Publish Date: 15-Jul-20xx

Location: ACT Canberra
ATM Type: Request for Tender
APP Reference: NAA20XX-1
Multi Agency Access: No
Panel Arrangement: No
Description:

A service provider is being sought for the technical upgrade of the Archives’ website Destination:
Australia. In order to ensure the best value for money and optimal functionality (for the website
and related exhibition interactive) going forward, it is necessary for the website to be transferred
from a proprietary CMS to a commonly available CMS (including, but not limited to, an Open Source
CMS).

The website will enable the National Archives of Australia to collect user contributed data about
the photographic collection featured on the site. The interface must be modern, engaging and user-
friendly, designed to meet the needs of people of all ages, and differing levels of computer and
English literacy. The website must interact successfully with an exhibition interactive via an existing
API. There is an option for hosting, maintenance and support services to be provided from contract
execution until 31 December 2019.

Timeframe for Delivery: November/December 20XX with a possible extension of up to 3 years for
hosting and maintenance.

The Requirement
The National Archives of Australia (Archives) (the Customer) is responsible under the Archives Act
1983 (Cth) for the preservation and storage of Commonwealth records, including the archival
resources of the Commonwealth.

100 | P a g e
This procurement request relates to the website redevelopment and hosting and maintenance
services for website Destination: Australia. The current website is located at
https://www.destinationaustralia.gov.au

The photographs showcased on this website are part of the Immigration Photographic Archive
(Series A12111). This collection comprises more than 22,000 black-and-white and colour
photographs taken by government photographers between 1946 and 1999 to record the arrival and
settlement of migrants in Australia after World War II. The photographs were used in newspapers,
magazines, posters, brochures and displays to promote Australia as a prosperous welcoming nation
to potential migrants and to reassure the Australian public that new migrants would readily settle
into the Australian way of life.

In 2014, Destination: Australia was upgraded to encourage users to upload their own photographs
and stories to share their migrant experience, further adding rich personal context to the Archives’
collection. These ‘Feature Stories’ are also available (via an API) in a ‘Globe’ interactive in the
Archives’ exhibition A Ticket to Paradise? which is touring nationally from April 2016 to September
2019.

Required:
 Redevelopment of existing website Destination: Australia
 Software to be either open source or common-use proprietary Content Management
System (CMS)
 One website prototype round, with testing and feedback
 Website testing including content review
 Final revisions
 Final testing and bug fixes
 Website handover
 Final documentation including website style guides, master templates, admin user
guidelines, technical specifications. This must be written in English with clear instructions
for non-technical experts to operate the CMS.

Optional:
 External hosting and ongoing support with a service level agreement (3 years).
 Updates and post implementation changes in response to user feedback.

Required deliverables
API compatibility:
 The website must continue to work with the pre-existing API linking the content with an
exhibition interactive.
 The administrator account to the Destination: Australia CMS must have a check box
function that allows the administrator to select which feature stories will be published
through the API to the exhibition interactive.
 The API must be able to draw all user-added content in the selected feature stories,
including photographs, through to the linked exhibition interactive.

101 | P a g e
  The website will support sourcing and storing its data from the Archives’ API, according to
API calls provided by the Archives, to ensure valid, up to date data is displayed on the
website.
 The website must successfully GET, POST and PUT and DELETE data using the API within
agreed timeframes.
 Data from the API contains a mix of official records and user generated content.
 API compatibility and function must be maintained at all times until December 2019.
 The successful supplier will be provided with further documentation on the API.

Accessibility/compatibility:
 All elements of the solution must comply with the relevant Australian Government
mandatory criteria including meeting Web Content Accessibility Guidelines (WCAG) 2.0 –
to Level AA. Refer to the Australian Government Digital Transformation Office website for
more information – https://www.dto.gov.au/standard/design-guides/.
 Any online forms should include identifying mandatory fields, error validation and error
suggestion on input fields (e.g. include @ for email addresses), as per the WCAG 2.0 Level
AA.
 All elements of the solution must display consistently across popular Windows, Macintosh
and Linux browsers including Internet Explorer (V9 up), Firefox, Chrome, Safari and Opera.
 Code to ensure ease of use and accessibility from desktop, tablet and smart phone / mobile
platforms using responsive interface design.

Privacy, security and intellectual property:

 Data captured in online forms should reflect the Australian Privacy Principles (which unify
the National Privacy Principals and the Information Privacy Principles) and security
obligations of (ASD). Including any updates to how data should be stored according to the
Australian Privacy Principles or security obligations.
 Website security appropriate to support administration module, members’ pages, API
developer key hidden and enables encryption of stored data including indexes and
registered user’s personal details e.g. email address.

Hosting:
 The website application must be built to be hosted externally to the Archives’ IT
infrastructure taking into account data sovereignty, data protection controls (see the
Australian Government Protective Security Policy Framework (PSPF) and Information
Security Manual) and compliance with the Privacy Act.
 Please see ‘Optional Deliverables’ for information on the optional hosting component of
this procurement process.

Aesthetic design:
 The aesthetic design of the website must be maintained for the upgraded website.
 Style guides and other necessary components will be provided to the successful Supplier.

102 | P a g e
Content Management System:
 The website must support formats to enable crowd sourced data and display of collection
data including images.
 The solution must provide an easy way for administrators to view and record user-
generated activity across the site from within the administration CMS.
 The website’s supporting CMS or web application must have both a design and source
interface enabling recognition of user contributed data and has the ability to manage full
user administration and content moderation in-house. This must include tasks such as
updating all content (including descriptions on collection photographs), monitoring and
moderating user-generated data and where necessary, blocking, removing, editing and/or
extracting user-generated data.
 Administration module must be secure.
 Administration page displays name (as well as screen ID) of contributing users.
 The solution must support Google Analytics for website visitor statistics and pre-scripted
database reports for listing and exporting all user generated content.
 The website must comply with records management requirements to enable the website
to be archived with user-generated data extracted (e.g. XML, CSV format and image
formats) with relevant references for future re-purposing.

Email notifications to administrator:

 Email notification to be sent to destinationaustralia@naa.gov.au when a user adds a
comment, tag, person, location to a collection photograph, or adds a feature
story. Notifications should include a hyperlink to the new content in the CMS administrator
account.
 Email notification to be sent to destinationaustralia@naa.gov.au when a user reports
comments or other content. Notifications must include a direct hyperlink to the reported
content.

Public user login:

 Website users have the option of browsing and searching the website without registration.
Anyone wishing to input data to the website must register and login with a unique email
address and passphrase.
 Existing usernames and passwords must carry over to the redeveloped site.
 Profile must include an online form for users to contact Archives to remove or edit their
user-added content.
 Optional: ability for the user to ‘link’ together multiple stories that they have contributed
by the user, or to allow sorting by tag with user name. The published feature story page
would display a link to take viewers to the related stories.

Navigation:
 Website navigation must align with pre-existing information architecture for Destination:
Australia.
 Breadcrumbs must be added to the top of each page to enhance user navigation.

103 | P a g e
Search function:
 Ability to query search and return search results, this will be supported through the API
calls, and the interface will need to be configured to return merged search requirements
and apply search parameters (e.g. filters) for the Discovering Anzacs interface.
 Required: free text feature stories and comments contributed by users must be posted back
to the API to become searchable on Destination: Australia.
 User-added tags on stories must be posted back through the API to become searchable.
 User-added locations on stories must be searchable and clickable to sort stories by place.
 Adding terms to the search parameters should refine the search (it currently expands the
result field).
 The website must include all images within the A12111 series/collection, and search results
must display all relevant images. Check that search picks up all photographs in collection
(or that Destination: Australia captures all images in A12111) – e.g. searching for “Petrus
Mouwmans” does not give a result, although it is listed in RecordSearch: A12111,
1/1963/14/9.
 Results distinguish between feature stories, collection items and user added photographs.
 Results able to be sorted by category (feature story, collection item) or by date range
(earliest to latest or vice versa).
 Image title to appear at the top of the results display (currently “view this photograph”).
 Hit highlighting - the search interface will support search term (eg. keyword, name) hit
highlighting using bold or similar.

Updates/fixes to ‘add your story’ form (see Attachment B for images of changes):
 All free text fields must allow users to copy and paste text from other programs.
 The fields ‘Year’, ‘Country of origin’, ‘Theme’ and ‘Photos’ (at least one) must be
compulsory.

Adding images:
 ‘Add photos’ must be moved to location above ‘Add Your Story’.
 When adding an image from the website, the citation and image caption must also be
imported. The citation (e.g. NAA: A12111, 2/1969/4A/18) must be locked in, with the option
for the user to personalise the caption.
 When adding an image from the website, users must be able to search by collection control
symbols and non-consecutive key words.
 When adding an image from the website, user has the ability to refine the search using date
range.
 When adding an image from the website, clicking ‘enter’ after typing keyword must initiate
the search (currently takes user to blank error page).
 ‘Add image from website’ search must return all results available through Destination:
Australia.
 The website must perform checks to ensure the user is uploading an accepted size and
format (e.g. png, jpeg) and provide error messages where limits are exceeded.
 Optional: add a new function to allow users to select from their ‘Favourite’ images to add
to their story.
 Optional: users able to crop images before they upload.

104 | P a g e
Add your story:
 ‘Add your story’ text field must allow simple formatting: paragraph breaks, italics.
 Must display Latin diacritics (accents e.g. acute é, grave è, circonflex ê, caron č; dots e.g.
diaeresis ë; cedilla ç, ogonek ą).

Feature story publishing process:

 Selecting ‘Preview’ must save a copy that allows for the user to return and edit content.
This draft copy must not be publicly available at this stage.
 Selecting ‘Save your story’ (on contribution form page) or ‘Save and submit’ (on preview
page) submits the story to the CMS and publishes the feature story on the live website
 Stories are automatically published on submission.

Feature story display page (front end):

 On published feature stories, viewers must be able to click on categories (year, country,
tags, locations) to bring up a list of any other stories/images with the same user-added
metadata.
 Must display Latin diacritics (accents e.g. acute é, grave è, circonflex ê, caron č; dots e.g.
diaeresis ë; cedilla ç, ogonek ą).
 Must display simple formatting: line breaks, italics.
 Images must be able to open for larger display in a lightbox, with accompanying caption.
 Optional: where a user has added a photograph from the website, the image on the
published feature story page links back to the image display page for the particular record
(i.e. with metadata, comments, tags etc).
 Optional: if users add data to ‘location’, map with tagged locations should be shown on
published feature story page.

Record display page (front end):

 Required: create ‘order record’ button that takes the user through to PhotoSearch result
for that image and the associated ‘ordering images’ text box.

Home page:
 Optional: preview of ‘Feature stories’ displays feature stories at random.

Testing:
 The Supplier must outline the project plan and team roles and the testing strategy and plan.
It should also include any handover files and documentation to be provided for
implementation.
 Extensive testing will be required prior to the website launch. This includes iterative testing
during development, implementation of changes and subsequent re-testing.
 On implementation and handover the Destination: Australia website should be fully
functional and populated with relevant content and data. As part of the website handover,
training sessions and support documentation for nominated administrators will also be
required.

105 | P a g e
  Testing must include success of API calls to/from the Destination: Australia website for
creation, deletion, updates and retrieval of data in conjunction A Ticket to Paradise? ‘globe’
interactive.
 The National Archives will determine when the website is ready to be launched and the
date. However, the supplier must be able to meet the nominal launch date of 25 October
2016.

Acknowledgements:
The banner (visible on all pages) must include:

 Destination: Australia web tile

 Multi-agency logo for the National Archives of Australia and the Department of Immigration
and Border Protection (to be provided by the Customer)
 The following tagline:
o ‘The National Archives acknowledges the support of the Department of
Immigration and Border Protection for the Destination: Australia website’, with the
text ‘Department of Immigration and Border Protection’ hyperlinked to the website
https://www.border.gov.au/

Progress meetings and reports

The successful Supplier will be required to:

 Attend the project kick-off meeting (face-to-face / teleconference).
 Attend regular updates at an agreed time and day, at least fortnightly.
 Attend scheduled project meetings to report at key milestones or deliverables throughout
the project.
 Communicate any issues which may impact agreed project tolerances as they occur.
 Attend project wrap-up meeting with final deliverables and website handover including
report/documentation.
 Work collaboratively with National Archives staff and Suppliers to meet expectations and
resolve issues.

Optional:
 Should the option of host services be agreed to by the Customer, the Supplier must attend
ongoing support meetings or maintain regular communication as required, up until the end
of the contract.

Project Management Requirements

 The Archives will nominate a Project Manager who will be responsible for liaison with the
successful supplier in relation to management of the contract and overall service delivery.
 Potential Suppliers must specify all staff and subcontractors proposed to complete the
work.
 The successful Supplier will be required to nominate a Project Manager as the primary point
of contact for the Archives. This person will be responsible for the management of the
contract as a whole and for liaison with the Archives’ Project Manager.

106 | P a g e
 After delivery
The Supplier must commit to providing defect resolution in the post-launch period, up to 30 April
20xx, in response to Archives user testing and feedback. In this period the Supplier must complete
full internal testing and bug fixes before any solution release for publishing.

Optional deliverables

Hosting and maintenance:

The Potential Supplier should provide a response for an optional service level agreement, to host
the website externally to the Archives’ infrastructure, provide ongoing maintenance and support
until 31 December 2019.
 The website application must be hosted externally to the Archives’ IT infrastructure taking
into account data sovereignty, data protection controls (see the Australian Government
Protective Security Policy Framework (PSPF) and Information Security Manual) and
compliance with the Privacy Act.
 Quality of service requirement in order to maintain its effectiveness; available 99% of up
time annually and has appropriate back-up (with equal features to meet above-mentioned
data security and privacy requirements) scalability options and recovery processes.
 Response time for issues to be negotiated and confirmed with the successful Supplier.

Capability to function with future API’s:

Potential to link with National Archives’ and external sources’ collections and data, via API’s that
may be developed in the future.

Within your practice environment, complete each of the following parts (Note: Parts of this
assessment task, such as project execution, will be simulated in your practice environment):

Identify project risks, Analyse project risks and Establish risk treatments and controls

1. Describe the risk context in which the project is operating. The risk context may include
legislation and regulation controls, nature of the project, organisational risk policies and
procedures, project environment and/or stakeholder expectations (including risk appetite and
tolerances) :

107 | P a g e
 2. Describe your approach to identifying the risks on the project.

3. Complete a risk register for the project (including both positive/opportunities and negative
risks) and two action plans for the top two priority risks using the templates below. Risk
Register:
<The risk register should list all risks on the project – not just work health and safety risks. It should
include both positive and negative risks>

108 | P a g e
 RiskNo# Risk Risk Mitigation
Category Description Strategy/Response
including
existing

Likelihood

Likelihood
risk

Impact

Impact
Rating

Rating
controls

Initial Residual

1 <See <A <Describe the

Legend description strategy put in
below> of the risk place and also
and outline whether this is
any existing mitigation,
risk acceptance, exploit
controls in etc.>
place>

Legend for Risk Categories:

<Provide a list of all applicable categories>

Risk Rating Scales and Overall Rating:

<Provide the risk rating scales and overall rating for the above register>

Risk Action Plans for top two risks:

<The risk action plans must allocate responsibilities to team members>

109 | P a g e
Risk Action Plan #1

Item No: <Risk Risk Description:

No.>
<Risk description>

Risk Rating : <As Category: <Risk category> Risk Treatment:

per rating scales> <Accept/Mitigate/Avoid/Transfer>

Action Plan:

Proposed Actions:

<risk response>

Resource Requirements:

<resource requirements to put the risk response into place>

Responsibilities:

<who will be responsible for putting the risk response into place>

Scope Impact:

<scope impact of putting the risk response into place>

Time Impact:

<time impact of putting the risk response into place>

Cost Impact:

<cost impact of putting the risk response into place>

Reporting & Monitoring Required:

<reporting and monitoring required for this risk response>

Prepared by: Date: Reviewed by: Date: <DD/MM/YY>

<Name> <DD/MM/YY> <Name>

<Position> <Position>

110 | P a g e
Risk Action Plan #2

Item No: <Risk Risk Description:

No.>
<Risk description>

Risk Rating : <As Category: <Risk category> Risk Treatment:

per rating scales> <Accept/Mitigate/Avoid/Transfer>

Action Plan:

Proposed Actions:

<risk response>

Resource Requirements:

<resource requirements to put the risk response into place>

Responsibilities:

<who will be responsible for putting the risk response into place>

Scope Impact:

<scope impact of putting the risk response into place>

Time Impact:

<time impact of putting the risk response into place>

Cost Impact:

<cost impact of putting the risk response into place>

Reporting & Monitoring Required:

<reporting and monitoring required for this risk response>

Prepared by: Date: Reviewed by: Date: <DD/MM/YY>

<Name> <DD/MM/YY> <Name>

<Position> <Position>

111 | P a g e
Monitor and control project risks

1. What activities did you undertake to monitor the risk environment to identify changed
circumstances that would or did impact on your project?

2. What was the outcome of this review and how did you manage the changed risk responses to
maintain the currency of your risk register and action plans and responses?

Assess risk-management outcomes

112 | P a g e
1. Review your project performance in terms of risk management. Would your risk management
processes and procedures be considered effective? Why/why not?

2. List all risk management issues you may have experienced on the project (in the table below)
including a recommendation for future projects. Note: these are not issues with your risks but
how you managed the project risks.

Date Description of Recommended Action for next Lesson Learnt

problem/opportunity time/project Raised By

113 | P a g e
 Date Description of Recommended Action for next Lesson Learnt
problem/opportunity time/project Raised By

Task 2

Case Study

The following classwork may be completed in class in small groups or individually or at home
individually. 20 minutes will be allowed to complete this task. The answer will be assessed as
Satisfactory/ Not Satisfactory.

Criteria for competency

The student must satisfy the performance criteria listed in Assessment Task 1.

Instructions

For project of your choice (or using the Case Study below), outline:

 risk review processes to maintain currency of your risk register

 how risks may change over time in the execution of the project. Give specific examples of
how your risk responses change.
 describe what you would need to do to update your risk register given the above changes.

Write your answers on a piece of paper, clearly writing the contributors and describing the project.
Hand this to your facilitator on completion.

Case Study

Read Case Study 1 Tsunami Cricket Benefit Match (see embedded attachment below).

Asian Tsunami Benefit Cricket Match

On December 26th 2004, an earthquake measuring 9.0 on the Richter scale occurred in the Indian
Ocean just off the western coast of northern Sumatra, Indonesia. The sudden vertical rise in the
seabed by several metres displaced massive volumes of water, which resulted in a tsunami that
devastated the shores of Bangladesh, Burma, Indonesia, Malaysia, the Maldives, South India, Sri
Lanka, Thailand and as far away as Kenya and Somalia. The earthquake and tsunami were thought
to have caused over 200,000 deaths, while whole sections of coastline were devastated, destroying
the businesses and homes of millions, triggering a widespread humanitarian response. Throughout

114 | P a g e
Australia many appeals were launched to raise money for humanitarian agencies to provide relief
to the many injured and traumatized survivors.

The international cricket community launched one such appeal. With cricket being a popular sport
in many of the affected countries, especially India, Sri Lanka and Bangladesh, and several Sri Lankan
players’ families injured in the tsunami, the cricket community decided to organise a charity cricket
match to raise funds for the relief effort. The match between an Asian team and “Rest of World”
team, featuring some the world’s best players from Australia, New Zealand, Pakistan, India, Sri
Lanka, the West Indies, England and Bangladesh was played at the Melbourne Cricket Ground on
January 10, 2005.

Organising the charity match was a remarkable exercise in project management. With a busy
international cricket calendar, organising matches between international teams usually takes
approximately a year, yet this match was organised in the days immediately after the tsunami struck
and played just 15 days later. Cricket Australia, the governing body of cricket in Australia,
volunteered to organise and host the match and quickly set about the complicated process of
organising the match.

Among the many tasks that needed to be completed were gaining permission from cricket’s world
governing body, the International Cricket Council (ICC) to host the match, as well as the blessing of
the game’s regional governing body in Asia, the Asian Cricket Council (ACC), and the individual
cricketing authorities in each of the countries who provided players for the match.

The next step was to gain support from the International Cricket Players’ Association. This was
quickly obtained, as the players were keen to support the match. Organising the teams proved to
be a difficult exercise. Although Australia, Pakistan and the West Indies were playing in Australia at
the time, the New Zealand, Indian and Bangladeshi players were at home, as were Sri Lankan players
who had cancelled the remainder of their tour to New Zealand after the tsunami struck. The
majority of the English team and all of the South African players were engaged in a cricket series in
South Africa at the time, and unfortunately the best players from these two teams were unable to
participate.

Among the many other tasks that had to be completed were gaining permission from the
Melbourne Cricket Ground’s owners, the Melbourne Cricket Club, to use the stadium for the match
and arranging to get the players to Melbourne from all around the world at short notice.

Publicising the match via television and print media, preparing a pitch, issuing tickets, and designing
and making players’ uniforms, tasks that usually take months to prepare, were all accomplished
promptly. A wide range of sponsorships were organised, including a 1 million dollar naming rights
sponsorship, and hundreds of corporate boxes were sold at short notice during the traditional
summer holiday period.

Negotiations were also required to be undertaken with construction unions and building
contractors to stop work for a day, as the Melbourne Cricket Ground was in the middle of a
redevelopment in preparation for the Melbourne 2006 Commonwealth Games. In addition, enough
staff to run a match with a crowd of 70,0000, such as ground staff, curators, security personnel,

115 | P a g e
 catering staff and cleaners needed to be obtained. The match proved to be a tremendous success,
raising over $15 million for the relief agency World Vision’s Asia Tsunami Appeal.

The project team has identified the risks listed below.

Likelihood Scales
Very Low 1 Highly unlikely to occur; however, still needs to be monitored as certain
circumstances could result in this risk becoming more likely to occur during
the project

Low 2 Unlikely to occur, based on current information, as the circumstances likely to

trigger the risk are also unlikely to occur©

Medium 3 Likely to occur as it is clear that the risk will probably eventuate

High 4 Very likely to occur, based on the circumstances of the project

Very High 5 Highly likely to occur as the circumstances which will cause this risk to
eventuate are also very likely to be created

Impact Scales
Very 1 Insignificant impact on the project. It is not possible to measure the impact on
Low the project as it is minimal

Low 2 Minor impact on the project, e.g. < 5% deviation in scope, scheduled end-date
or project budget

Medium 3 Measurable impact on the project, e.g. 5-10% deviation in scope, scheduled
end-date or project budget

High 4 Significant impact on the project, e.g. 10-25% deviation in scope, scheduled
end-date or project budget

Very 5 Major impact on the project, e.g. >25% deviation in scope, scheduled end-date
High or project budget

Risk Matrix: Likelihood X Impact = Overall Level/Rating

116 | P a g e
 LIKELIHOOD Very Low Low Medium High Very High

IMPACT
1 2 3 4 5

Very Low Low Low Low Medium

Very Low 1
1 2 3 4 5

Low Low Medium Medium High

Low 2
2 4 6 8 10

Low Medium High High Very High

Medium 3
3 6 9 12 15

Low Medium High Very High Very High

High 4
4 8 12 16 20

Medium High Very High Very High Very High

Very High 5
5 10 15 20 25

Overall Level/Rating

0 – 1 = Very Low 2 – 4 = Low 5 – 8 = Medium 9 – 14 = High 15 – 25 = Very High

Risk Register
RiskNo# Risk Mitigation
Likelihoo

Likelihoo

Description Strategy/Response
Impact

Impact
Rating

Rating
d

Initial Residual

1 Rains on the 4 5 20 Accept 4 5 20

match day
2 Players get 3 2 6 Mitigate (impact) - 3 1 3
sick or More reserve players.
injured
3 Tickets are 2 5 10 Mitigate (probability) - 1 5 5
not sold one More marketing
week out

117 | P a g e
RiskNo# Risk Mitigation

Likelihoo

Likelihoo
Description Strategy/Response

Impact

Impact
Rating

Rating
d

d
Initial Residual

4 Tickets are 2 5 10 Mitigate (probability) - 1 5 5

not sold two Two for one deal
days prior
5 No sponsors 4 5 20 Reduce sponsorship 4 3 12
fees (mitigate
probability), increase
ticket costs (mitigate
impact)
6 Grand Prix is 2 2 4 Transfer – sign a 1 2 2
on – ground contract with a
staff may not staffing agency
be available
7 Crowd bad 2 2 4 Mitigate (impact and 1 1 2
behaviour probability) - Employ
more security

118 | P a g e
 BSB51415 –DIPLOMA OF PROJECT MANAGEMENT
College Copy

Unit Code and Title: BSBPMG517 - Manage project risk

Assessment task Due Dates

Assessment 1 Due Date:

Assessment 2 Due Date:

I Student ID acknowledge receiving the

Student Assessment Information Pack, which contains:

o Assessment Due Date Sheet

o Time table /Training Plan
o Lesson Plan
o Student Assessment Information Guide
o Assessment Cover Sheets
o Feedback form
o Student Resource
o Internet Access for online Business Environment Simulation with Login Key or access to college
simulated business documents on internal intranet.

Student Signature:

Date :

119 | P a g e
 BSB51415 –DIPLOMA OF PROJECT MANAGEMENT
Student Copy

Unit Code and Title: BSBPMG517 - Manage project risk

Assessment task Due Dates

Assessment 1 Due Date:

Assessment 2 Due Date:

I Student ID acknowledge receiving the

Student Assessment Information Pack, which contains:

o Assessment Due Date Sheet

o Time table / Training Plan
o Lesson Plan
o Student Assessment Information Guide
o Assessment Cover Sheets
o Feedback form
o Student Resource
o Internet Access for online Business Environment Simulation with Login Key or access to college
simulated business documents on internal intranet.

Student Signature:

Date :

120 | P a g e
 ASSESSMENT SUMMARY / COVER SHEET
This form is to be completed by the assessor and used a final record of student competency.
All student submissions including any associated checklists (outlined below) are to be attached to
this cover sheet before placing on the students file. Student results are not to be entered onto the Student
Database unless all relevant paperwork is completed and attached to this form.
Student Name:

Student ID No:

Final Completion Date:

Unit Code: BSBPMG517

Unit Title: Manage project risk

Unit
Assessors Name:
Outcome
C NYC
Result: S = Satisfactory, NYS = Not Yet Satisfactory, NA = Not Assessed
 Knowledge Assessment - Questions and Answers S | NYS | NA
 Task 1 S | NYS | NA
 Task 2 S | NYS | NA
Is the Learner ready for assessment? Yes No
Has the assessment process been explained? Yes No
Does the Learner understand which evidence is to be collected and
Yes No
how?
Have the Learner’s rights and the appeal system been fully
Yes No
explained?
Have you discussed any special needs to be considered during
Yes No
assessment?
I agree to undertake assessment in the knowledge that information gathered will only be used for
professional development purposes and can only be accessed by my manager and the RTO:
Learner Signature:
Date:
I have received, discussed and accepted my result as mentioned above for
this unit assessment and I am aware about my rights to appeal.
Assessor Signature:
Date:
I declare that I have conducted a fair, valid, reliable and flexible
assessment with this student, and I have provided appropriate feedback.

121 | P a g e
 ASSESSMENT COVER SHEET

Unit BSBPMG517 - Manage project risk

Course BSB51415 –DIPLOMA OF PROJECT MANAGEMENT

Student Name: Student ID:

Group: Date

Title of
Knowledge Assessment - Questions and Answers
Assignment:

Assessor Name:

This cover sheet must be attached to your assignment.

Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation
of documents and assignments.
3. I have retained a copy of my assignment.

Student Signature:___________________________

Date:________________________________________

122 | P a g e
 QUESTION & ANSWER CHECKLIST

S NYS
Learner’s name:

Assessor’s name:

Question Correct ()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Feedback to Learner:

Assessor’s Signature:
Date:

123 | P a g e
 ASSESSMENT COVER SHEET

Unit BSBPMG517 - Manage project risk

Course BSB51415 –DIPLOMA OF PROJECT MANAGEMENT

Student Name: Student ID:

Group: Date

Title of
Task 1
Assignment:

Assessor Name:

This cover sheet must be attached to your assignment.

Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation
of documents and assignments.
3. I have retained a copy of my assignment.

Student Signature:___________________________

Date:________________________________________

124 | P a g e
 TASK 1 CHECKLIST

S NYS
Learner’s name:

Assessor’s name:

Observation Criteria S NS
Determined risk objectives and standards, with input from stakeholders
Established project risk context to inform risk management processes
Identified project risks using valid and reliable risk identification methods
Classified project risks within agreed risk categories
Determined risk analysis classification criteria and apply to agreed risk ranking system
Used risk analysis processes, within delegated authority, to analyse and qualify risks,
threats and opportunities
Determined risk priorities in agreement with project client and other stakeholders
Documented risk analysis outcomes for inclusion in risk register and risk management
plan
Identified and document existing risk controls
Considered and determined risk treatment options using agreed consultative methods
Recorded and implemented agreed risk treatments
Updated risk plans and allocated risk responsibilities to project team members
Established regular risk review processes to maintain currency of risk plans
Regularly monitored risk environment to identify changed circumstances impacting
project risks
Determined risk responses to changed environment
Implemented agreed risk responses and modify plans to maintain currency of risk
treatments and controls
Reviewed project outcomes to determine effectiveness of risk-management processes
and procedures
Identified and documented risk management issues and recommended improvements
for application to future projects
Feedback to Learner:

Assessor’s Signature:
Date:

125 | P a g e
 ASSESSMENT COVER SHEET

Unit BSBPMG517 - Manage project risk

Course BSB51415 –DIPLOMA OF PROJECT MANAGEMENT

Student Name: Student ID:

Group: Date

Title of
Task 2
Assignment:

Assessor Name:

This cover sheet must be attached to your assignment.

Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation
of documents and assignments.
3. I have retained a copy of my assignment.

Student Signature:___________________________

Date:________________________________________

126 | P a g e
 TASK 2 CHECKLIST

S NYS
Learner’s name:

Assessor’s name:

Observation Criteria S NS
Determined risk objectives and standards, with input from stakeholders
Established project risk context to inform risk management processes
Identified project risks using valid and reliable risk identification methods
Classified project risks within agreed risk categories
Determined risk analysis classification criteria and apply to agreed risk ranking system
Used risk analysis processes, within delegated authority, to analyse and qualify risks,
threats and opportunities
Determined risk priorities in agreement with project client and other stakeholders
Documented risk analysis outcomes for inclusion in risk register and risk management
plan
Identified and document existing risk controls
Considered and determined risk treatment options using agreed consultative methods
Recorded and implemented agreed risk treatments
Updated risk plans and allocated risk responsibilities to project team members
Established regular risk review processes to maintain currency of risk plans
Regularly monitored risk environment to identify changed circumstances impacting
project risks
Determined risk responses to changed environment
Implemented agreed risk responses and modify plans to maintain currency of risk
treatments and controls
Reviewed project outcomes to determine effectiveness of risk-management processes
and procedures
Identified and documented risk management issues and recommended improvements
for application to future projects
Feedback to Learner:

Assessor’s Signature:
Date:

127 | P a g e
 Student Feedback Form
Unit BSBPMG517 - Manage project risk
Student Name: Date
Assessor Name:
Please provide us some feedback on your assessment process. Information provided on this form
is used for evaluation of our assessment systems and processes.
This information is confidential and is not released to any external parties without your written
consent. There is no need to sign your name as your feedback is confidential.
Strongly Strongly
Agree
Disagree Agree
I received information about the assessment
1 2 3 4 5
requirements prior to undertaking the tasks

The assessment instructions were clear and easy to

1 2 3 4 5
understand
I understood the purpose of the assessment 1 2 3 4 5

The assessment meet your expectation 1 2 3 4 5

My Assessor was organised and well prepared 1 2 3 4 5

The assessment was Fair, Valid, Flexible and Reliable 1 2 3 4 5

My Assessor's conduct was professional 1 2 3 4 5

The assessment was an accurate reflection of the
1 2 3 4 5
unit requirements
I was comfortable with the outcome of the
1 2 3 4 5
assessment

I received feedback about assessments I completed 1 2 3 4 5

Great
The pace of this unit was: Too Slow Too Fast
Pace
Comments:

128 | P a g e