Learner Guide

BSBPMG632 –
Manage Program Risk
 Copyright and Disclaimer

No part of this resource may be reproduced, stored in a retrieval system or transmitted via any
electronic means or otherwise without the prior written permission of Lexis Training (LT).

LT gives permission to its students to reproduce in print format, one copy of this manual for their
own educational use.

Information contained in this resource is drawn from a number of different sources of information
believed to be reliable. LT and its employees do not warrant the correctness of the sources used
and accept no responsibility to any person for any errors or omissions or for any loss or damage
howsoever caused from the use of this resource.

Version Control and Amendment History

BSBPMG632 - Manage Program Risk

Reason for Review Release Date Version Details

Initial Release 02/09/2021 V1.04.22 Written in line with the

BSB Business Services
Training Package
Version 7.0, released
19/10/2020

BSBPMG632 Learner Guide V1.04.22 Page | 2

Table of Contents
Table of Contents ................................................................................................................. 3
This Learner Guide ................................................................................................................ 5
Introduction ......................................................................................................................... 6
1. Direct Planning of Program Risk Management ................................................................... 8
1.1 Identify Potential, Actual and Residual Risks ........................................................10
1.1.1 Establishing Risk Context ....................................................................................11
1.1.2 Potential, Actual and Residual Risks ...................................................................13
1.2 Select and Modify Program Risk Methodology to Match the Context for Risk ...21
1.2.1 Selecting Risk Methodologies to Match the Context for Risk ............................23
1.2.2 Modifying Risk Methodologies ...........................................................................25
1.3 Consult With Relevant Stakeholders and Identify, Document and Analyse Program Level
Risks 27
1.3.1 Stakeholder Consultations ..................................................................................28
1.3.2 Program-Level Risk Identification, Documentation and Analysis .......................35
1.4 Support and Mentor Project Managers in the Analysis, Evaluation and Treatment of
Risks 43
1.4.1 Risk Analysis, Evaluation and Treatment ............................................................44
1.4.2 Supporting Project Managers in Risk Analysis, Evaluation and Treatment ........45
1.4.3 Mentoring Project Managers in Risk Analysis, Evaluation and Treatment ........47
1.5 Confirm Risk Management Is Transparent and Dynamic Across the Program so That
Risks Are Assigned and Managed in a Timely Manner ....................................................50
1.6 Develop and Maintain a Program Risk-Management System for Effective Management
and Communication of Risks, Controls, Treatments and Outcomes to Stakeholders Across the
Program ...........................................................................................................................56
1.6.1 Develop a Program Risk-Management System for Effective Management and
Communication of Risks, Controls, Treatments and Outcomes ..................................56
1.6.2 Maintain a Program Risk-Management System for Effective Communication with
Relevant Stakeholders .................................................................................................58
Checkpoint! Let’s Review.................................................................................................60
2. Manage Program Risk ..................................................................................................... 61
2.1 Direct Management of the Program in Accordance With Agreed Program Risk-
Management Plans ..........................................................................................................62

BSBPMG632 Learner Guide V1.04.22 Page | 3

 2.2 Review Progress, Analyse Variance and Initiate Risk Responses to Achieve Program
Objectives in Dynamic Risk Environments ......................................................................65
2.2.1 Risk Reviews ........................................................................................................66
2.2.2 Analyse Variances ...............................................................................................68
2.2.3. Initiating Risk Responses ....................................................................................70
2.3 Confirm Risks are Monitored and Assessed Across the Program at Agreed Intervals 73
2.3.1 Circumstances That Need Monitoring and Assessment .....................................74
2.3.2 Confirming Risks are Monitored and Assessed at Agreed Intervals ...................75
2.4 Direct Response to Actuated Program Risk and Confirm Remedial Actions are
Authorised With Impact Analysis According to Program Objectives ..............................77
Checkpoint! Let’s Review.................................................................................................81
3. Assess Program Risk-Management Outcomes ................................................................. 82
3.1 Identify and Document Program Residual Risk and Communicate to Stakeholders any
Transferred Liability at Program Completion ..................................................................83
3.1.1 Identification, Treatment and Documentation of Residual Risks .......................84
3.1.2 Communicating Transfer Liability to Stakeholders .............................................86
3.2 Review and Analyse Program Outcomes to Assess the Effectiveness of the Risk-
Management Methodology.............................................................................................88
3.3 Seek Feedback and Respond to Relevant Stakeholders on Risk Management ....91
3.4 Analyse, Document and Recommend Lessons Learned for Application in Other
Programs ..........................................................................................................................94
3.4.1 Analysing Lessons Learned..................................................................................95
3.4.2 Documenting and Recommending Lessons Learned for Application in Future
Programs ......................................................................................................................96
Checkpoint! Let’s Review.................................................................................................98
References ......................................................................................................................... 99

BSBPMG632 Learner Guide V1.04.22 Page | 4

This Learner Guide
BSBPMG632 - Manage program risk
This unit describes the skills and knowledge required to manage risks that might affect program
deliverables and organisational objectives. It covers directing the planning and management of
program risks, managing risks to the overall program and assessing risk management outcomes for
the program and the organisation.
The unit applies to individuals who are program managers, managing or directing a suite of projects
(a program) and/or senior project managers.
No licensing, legislative or certification requirements apply to this unit at the time of publication.

A complete copy of the above unit of competency can be downloaded from the TGA website:
https://training.gov.au/Training/Details/BSBPMG632

BSBPMG632 Learner Guide V1.04.22 Page | 5

Introduction

Before going into the details of program risk management, you must first understand what risks are.
Risks at a program level are often defined as the likelihood and consequence of the occurrence of
any situation or object with future outcomes that might affect your overall program objective. A
program risk may stem from individual or cross-project risks that can impact your program, including
cost, performance and schedule. This can potentially expose your program to failure and losses. As
such, it is crucial to establish appropriate and reliable risk management processes. In essence, risk
management is a systematic process that aims to identify and evaluate risks to develop the proper
methods and techniques to respond appropriately to them.
Your focus as a program manager is to oversee and ensure individual projects related to the program
and other program tasks do not badly impact the organisation’s business goals and value. Your
responsibility in risk management is fundamentally to uncover risks before they occur and have a
plan for tackling them. Not addressing them will have significant consequences on your
organisation, including, but not limited to, lawsuits, financial losses, damaged reputation and
business failure. To avoid such consequences in your organisation, you must be able to gain the
knowledge and skillsets appropriate to manage program risks.

BSBPMG632 Learner Guide V1.04.22 Page | 6

Acquiring these involves three important phases in its life cycle, namely:

Planning
Phase

Implementati
Review Phase
on Phase

Each phase plays a different but essential role in the management of risks. The planning phase,
which seeks to uncover risks needing controls, will be the focus of the discussion in Chapter 1. The
implementation phase, which is the stage where you apply your planned risk management, will be
discussed in Chapter 2. Finally, the review phase, which is where you analyse program outcomes to
review the effectiveness of your planned strategies, will be discussed in Chapter 3.
This unit will help you gain all the essential knowledge and skills to make confident decisions in
performing all three phases in the context of your workplace or organisation's objectives in the
discussions ahead.
During the course of this unit, you are expected to demonstrate your ability to manage a program
risk on at least one occasion.
In this Learner Guide, you will learn about:
▪ direct planning of program risk management
▪ managing program risk
▪ assessing program risk-management outcomes.

BSBPMG632 Learner Guide V1.04.22 Page | 7

1. Direct Planning of Program Risk Management
In this chapter, you will be guided in planning for a program risk management. The Project
Management Body of Knowledge, or simply the PMBOK Guide, defines risk management planning
as the process of explaining how to conduct risk management activities for a program. These
activities may include but are not limited to:

establishing risk context

identifing risk

analysing risk

evaluating risk

assigning risk to owner

planning risk treatment

planning risk monitoring

documenting risk

Sourced from A Guide to the Project Management Body of Knowledge (6th Edition).

BSBPMG632 Learner Guide V1.04.22 Page | 8

Your role as a program manager is to direct the execution of such risk management activities
throughout the planning stage. You are to make sure that with every activity, all relevant data and
details are sufficiently recorded for inclusion in the program management plan. A program
management plan is a document developed in the planning phase that defines the program tasks,
stakeholder roles and proposed action plans (e.g., risk treatments) to meet your program’s desired
output. In other words, you are to oversee the development of an effective, transparent and
dynamic risk management plan for the implementation of your program. The benefits of having an
effective, transparent and dynamic risk management plan include, but are not limited to:

▪ More confident and rigorous decision-making

▪ Better identification of opportunities and threats

▪ Provide for a more confident implementation

▪ Pro-active rather than re-active management

▪ More effective allocation and use of resources

▪ Improved stakeholder confidence and trust.

The consequences of not knowing how to develop a system with adequate built-in risk management
measures from the beginning would lead to shaky planning and development of your program.

In this chapter, you will learn how to:

▪ identify potential, actual and residual risks

▪ select and modify program risk methodology to match the context of risk

▪ consult with relevant stakeholders and identify, document and analyse program-level risks

▪ support and mentor project managers in the analysis, evaluation and treatment of risks

▪ confirm risk management is transparent and dynamic across the program so that risks are
assigned and managed in a timely manner

▪ develop and maintain a program risk-management system for effective management and
communication of risks, controls, treatments and outcomes to stakeholders across the
program.

BSBPMG632 Learner Guide V1.04.22 Page | 9

1.1 Identify Potential, Actual and Residual Risks

None of the other risk management activities can start without a proper foundation on the identity
of risks. To manage risks effectively, you must first identify the risks that your organisation will face
regardless of the risk’s immediate probable impact. It is vital to ensure that accurate solutions will
be provided to properly identified problems.

Failing to identify risks at the planning phase or even during the actual management phase (as risk
identification is iterative) will create a disastrous domino effect on the other components of your
program risk management system. Risk identification is the first step that must be taken in risk
management. It is the process of recognising, describing and documenting risks that could disrupt
your program. It involves identifying the sources of risks, as well as the possible consequences.

BSBPMG632 Learner Guide V1.04.22 Page | 10

1.1.1 Establishing Risk Context

Before performing risk identification to uncover risks, establishing the risk context is essential to risk
management and should be done before identifying the risks. In essence, risk context is the
environment in which your risk is confined.

There are certain risks that you are required to manage. Here are examples of risks, as well as the
laws that require you to manage them:

▪ workplace-related accidents and injury under the work health and safety (WHS) laws

▪ customer complaints regarding fair treatment under the Australian Consumer Law

▪ employee injury or harm under the workers’ compensation insurance

▪ environmental damage under the relevant environmental laws in your state/territory.

Based on Business risks, used under CC BY 3.0. © Commonwealth of Australia 2020.

These factors can easily change. However, these changes generally cannot be controlled by the
organisation itself. For example, the organisation cannot affect the laws to change the legal
requirements that they have to comply with.

Knowing this helps you see the whole picture of your project by examining the wider internal and
external environment within which your organisation operates. This also defines the scope of your
risk management strategy and sets the criteria against which the risks will be measured and
assessed.

BSBPMG632 Learner Guide V1.04.22 Page | 11

The context can generally be broken down into two areas:

Organisational Context

Strategic Context

▪ Organisational Context

Organisational context is also called internal context. It refers to the factors within the
organisation, including:

o internal stakeholders

o organisational aims and objectives

o membership

o governance, including the structure, policies, objectives, roles, capabilities,

resources, and methods of an organisation

o organisational processes.

As these are factors within the organisation, these are easily changeable by the
management. For example, the management can easily approve and implement changes to
alter their processes (e.g. hiring and procurement processes), therefore changing the
organisational context in which they are working.

▪ Strategic Context

Strategic context, also known as external context, refers to the environment in which the
organisation operates. It includes factors such as:

o the perceptions and values of external stakeholders

o the legal frameworks and requirements

o the local, national, and international environment.

BSBPMG632 Learner Guide V1.04.22 Page | 12

1.1.2 Potential, Actual and Residual Risks

The next step that you should take after establishing the context of your risk is to identify the
program threats according to their category. The risk categories are often derived from risk sources.
Risk sources refer to data, events, or any points to be considered threats in your program. They can
either be in an organisational or strategic context.

Below are risks that you will typically encounter during the risk identification process.

▪ Potential Risks, as the name suggests, refer to all threats that stem directly from the risk
sources. All threats that will directly or indirectly affect the program, regardless of their
immediate effect, are identified as potential risks. Identifying potential risks enables you to
address program challenges in a proactive manner. It will help you prepare for every risk that
your program may face before such problems even begin to arise. Done right, you will be
able to spare yourself and the organisation from wasting more time, budget and effort
controlling unforeseen risks. In fact, potential risks are normally risks identified by asking:

o What if there is insufficient manpower to finish the task?

o What if the company computers get infected by malware?

o What if noncompliance with tax legislation happens?

BSBPMG632 Learner Guide V1.04.22 Page | 13

 ▪ Actual Risks refer to threats carried over after narrowing down the list of potential risks to
those only relevant to a project or a program. Identification of actual risks may take place
after much discussion with your stakeholders and after risks have been assessed against
methods and tools used to identify risks.

While potential risks are just perceived risks, actual risks are threats that should already
require an action of control from you and your organisation.

In other words, a potential risk can become an actual risk in the following situations:

o When an employee quits halfway, the completion of a program task can be

addressed by finding replacement staff.

o When a virus infects a company computer, this can be addressed by asking an IT

personnel for support.

o When enforced to settle civil penalty orders due to noncompliance with Payroll Tax
Act 2007 (NSW), this can be controlled by paying fines.

Note: Some potential risks will not need further action; they are filtered out when tallying
actual risks. However, they are still documented for reference purposes.

▪ Residual Risks refer to risks that remain after planned controls have been taken. Even after
filtering out all risks you deem unacceptable (e.g., mitigate risks and avoid risks), with the
help of risk treatment strategies, you will not be able to eliminate risks entirely because it is
simply impossible.

risks
risks
Controls

risks

Residual Risk

BSBPMG632 Learner Guide V1.04.22 Page | 14

 Illustrations of residual risks following the sample scenarios used for potential and actual
risks are as follows:

o Performance of replacement staff is not on par with the employee replaced.

o IT personnel was able to completely remove the virus, but files have already been
corrupted.

o Noncompliance with tax legislation violations was addressed. However, the amount
paid to settle the penalty was over the organisation’s budget.

Identifying and Documenting Potential, Actual and Residual Risks

There is no single best technique to risk identification. Still, there are various reliable tools and
techniques that you can use, either separately or collectively, to identify potential, actual and
residual risks. It is important to adopt the appropriate tools or techniques to identify these risks.
The risk management tools and techniques to identify risks will be shown below.

▪ SWOT Analysis

This technique involves looking at the internal and external factors affecting the organisation
or objectives following these aspects of a program: strengths, weaknesses, opportunities,
and threats. This is a risk identification technique for assessing these four aspects of your
program. It is useful in revealing potential and actual program risks. To use SWOT analysis to
uncover risks, you must:

1. Evaluate all your available resources (e.g., manpower and policies).

2. Hold a group session or brainstorm with stakeholders directly involved in the

program or who have previous experience with the program you are planning for.

3. Survey the strengths and weaknesses of your organisation to uncover potential

internal risks over which you generally do not have control.

4. Survey the opportunities and threats associated with the program to uncover
potential external risks over which you often do not have direct control.

BSBPMG632 Learner Guide V1.04.22 Page | 15

 For example, a clothing and textile manufacturing company wants to identify the potential
risks of producing twice the product output they made last year by using new high-speed
industrial sewing machines for the next batch of productions the following year. Their SWOT
analysis may reveal the following:

Strengths

• The new industrial sewing machines are proven to be five times faster than the
old heavy-duty models. It is said further to increase production time by a
minimum of 10 hours.

Weaknesses

• Only 42% of the employees know how to operate the new machines.

Opportunities

• Employing a trainer to educate employees on how to use the machines may

increase the number of employees who can operate the machines by 25%.

Threats

• The training could last up to 4 weeks, threatening manufacturing time and

decreasing productivity.

▪ PESTLE Analysis

PESTLE analysis is used to analyse the factors that influence a program externally. PESTLE
stands for Political, Economic, Sociological, Technological, Legal and Environmental. Each of
these serves as a factor for the program to gather ideas from external influences that may
impact the program strategies and decisions. Suppose the clothing and textile manufacturing
company wants to target to produce children’s clothing in addition to the maternity clothes
they made in the previous year. The table below shows how the PESTLE Analysis can be used
on the said program:

BSBPMG632 Learner Guide V1.04.22 Page | 16

 Political

• Due to the evolving trade policies, the company must keep the Care Labelling for
Clothing and Textile Standards in mind since it is an offence to supply goods that do
not comply with the mandatory standards.

Economic

• Lack of competition within the state for companies producing children’s clothes
means more opportunity to infiltrate the area, increasing sales.

Social

• Children's clothes distributors and sellers are wary of marketing Australian

manufactured children’s clothes because they want to be cautious not to sell non-
compliant children’s clothes. However, in the last few years, this trend is slowly
easing.

Technological

• Producing children’s clothes follow the same procedures as that of adults in the
manufacturing process. The need to avail new industrial sewing machines to execute
the program is no longer necessary.

Legal

• Manufacturing children’s clothes must comply with the safety regulations such as the
Consumer Goods (Children’s Nightwear and Limited Daywear and Paper Patterns for
Children’s Nightwear) Safety Standard 2017.

Environmental

• Opting to manufacture children’s clothes using organic cotton, which can be found in
areas in Western Australia, will not only comply with textile testing regulations but
would also be sustainable and safe.

BSBPMG632 Learner Guide V1.04.22 Page | 17

 ▪ Interviewing

Interviewing involves soliciting information from the people around you who are generally
concerned with the program and who you think can give valuable information on uncovering
potential risks, actual and even residual risks.

This technique typically involves the following steps:

Choosing a Choosing the Preparing the Running the

facilitator participants participants session

1. Choosing a facilitator

The facilitator must be someone who is currently overseeing a project or a program.

In other words, the facilitator could be you, the program manager, a project officer
or a team member overseeing a task related to the risk.

The facilitator is responsible for guiding the discussions (i.e., ensuring that all sources
of risk must be reviewed and keeping the conversation on track) and ensuring that
all participants' opinions are heard.

2. Choosing the participants

It is important to engage with a diverse set of individuals to ensure that you get
different perspectives on what could cause harm, delays and other factors that can
be categorised as potential and actual risks. The participants of your interview could
be:

▪ Other program managers or employees and project managers

▪ Program sponsors

▪ The management

▪ Subject matter experts (SME).

BSBPMG632 Learner Guide V1.04.22 Page | 18

 3. Preparing the participants

Like any other meeting or discussion, the interview participants must be notified
prior to the interview to ensure that everyone understands the objects, scenarios or
risks to be discussed and identified. It would also be helpful to send them the
materials that contain details about the risks to be identified ahead of the scheduled
discussion.

The following materials include, but are not limited to:

▪ Risk assumption log

▪ Lessons learned

▪ Risk register

▪ Project charter

▪ Other relevant documents.

Note: You must bear in mind the confidentiality of the documents that you will be
showing your participants as well. Certain documents can only be best shown to
stakeholders like project sponsors. (e.g. overall budget or expenses)

4. Running the session

You would need the help of your team members, program sponsors and other
relevant stakeholders to provide ideas for identifying potential, actual and residual
risks. To capture the ideas presented by the participants, it is recommended that the
proceedings are recorded. Records must be kept so that they may be used for future
programs. It would also be helpful to set a time limit for the session to ensure that
the interview does not take up too much time.

More tools and techniques used in risk identification and proper documentation of
identified risks as a basis for planning will be discussed in Section 1.3.

BSBPMG632 Learner Guide V1.04.22 Page | 19

Documenting Risks

A risk register is an important document that you will be accessing throughout the planning,
implementing, and reviewing stages of your program. The objective of a risk register in the risk
identification process is to obtain essential details of identified program risks that will be updated
throughout the different stages of the risk management process. Your risk register in the risk
identification process must contain at least the following fields or columns:

ID Date Risk Risk Impacts Likelihood Consequenc Risk Owner

Identified Description of the Risk e
Occurring if the Risk
Occurs

Some of the components in the risk register columns will be discussed below:

▪ Risk Impacts

The risk impacts are used to establish the potential severity of the risk and help define
appropriate risk treatments. They also identify who will be impacted and allows the
communication of the risks to relevant stakeholders that will or may be impacted by the
risks.

▪ Risk Ratings

Risk ratings are used to categorise risks into low, moderate, major, etc., and to prioritise risks
so that the most severe risks will be treated first.

▪ Residual Risk

The residual risk is used to identify whether or not the risk treatments were effective and
whether or not further action is required.

▪ Risk Owners

Risk owners are listed in the risk register against each risk to clarify risk responsibilities, and
so risks can be followed up with the correct stakeholders at regular intervals.

BSBPMG632 Learner Guide V1.04.22 Page | 20

1.2 Select and Modify Program Risk Methodology to Match the Context for Risk

Program risk methodologies give you and your organisation a better understanding of the identity,
impact, and nature of the risks in your program. More accurate than risk identification, program risk
methodology seeks to understand your organisation’s risks in-depth by stating:

the methods that

how risks should be
should be used for the
identified
identified risks

the documents and

the people who should
templates which are
be involved with the
appropriate for risks
management of risks
involved.

BSBPMG632 Learner Guide V1.04.22 Page | 21

In the previous section, you have learned that a risk context establishes the environment where
risks are confined. Your program risk context can either be:

▪ General (e.g., organisational risk and strategic risk)

▪ Category-based (e.g., potential risk, actual risk, residual risk)

▪ Specific (e.g., political, economic, social, technological, legal, environmental)

To be able to commence with your risk management planning, you must first select a methodology
that matches your risks according to the abovementioned contexts.

The components of a program risk methodology are as follows:

Risk Identification

Risk Analysis

Risk Treatment

Risk Tracking

Risk Review

While program risk methodologies are considered standalone components, the graphic above
presents the methodologies as a process because it runs parallel to the overall risk management
process.

There is no one-size-fits-all methodology that can be used to address all types of risks since risks are
different in every step of the risk management process. The approaches that correspond to risks for
each component greatly vary as well. It is up to you and your organisation to select and modify the
methodology according to your program needs or, more specifically, to the context of your risks.

BSBPMG632 Learner Guide V1.04.22 Page | 22

1.2.1 Selecting Risk Methodologies to Match the Context for Risk

Just like how a newborn child must not be fed solid food to avoid choking and other worst-case
scenario consequences, you must also only use appropriate methodologies for the context of your
risk. Carefully select the appropriate risk methodology to avoid critical errors in the risk
management process that can lead to unwanted outcomes.

To decide which risk methodology matches the risk context, you must first assess the program risk
methods. Assessing the methodologies could mean determining whether each of the methodology’s
components – tools, techniques and approaches – are appropriate for the type of risks at hand.
Below are the five methodologies you can select to match the context of your risks.

i. Risk Identification

You may select risk identification when you want to outline how program stakeholders are
identifying program risks. The methodology outlines the following:
o when to identify program risks (e.g., before program approval)
o how to identify those risks (e.g., consultation and review of lessons learned)
o what tools and templates to be used (e.g., risk register).

BSBPMG632 Learner Guide V1.04.22 Page | 23

 ii. Risk Analysis

You may select the risk analysis to outline how program stakeholders are analysing program
risks. The methodology outlines the following:
o how to assess risk likelihood of occurrence and severity of consequence
o how to categorise risks based on assessment outcomes
o what tools and templates to be used (e.g., risk assessment and risk matrix).

iii. Risk Treatment

You may select risk treatment to outline how program stakeholders are treating program
risks. The methodology outlines guidelines on the following:
o which risks need to be treated (e.g., high and medium)
o how to identify risk treatments (e.g., consultation, review of lessons learned and
previous program risk records)
o how to plan and implement risk treatments, and tools and templates to be used (e.g.,
risk treatment plan).

iv. Risk Tracking

You may select the risk tracking and risk monitoring process to outline how program
stakeholders are tracking program risks. The methodology outlines the following:
o how to monitor the effectiveness of implemented risk controls (e.g., regular risk
reassessments)
o how to identify the residual risk
o when additional risk controls need to be identified and implemented (e.g., for risks
that are medium and high)
o what tools and templates to be used (e.g. risk audit).

v. Risk Review

You will select risk review to outline how the effectiveness of the program risk management
is to be reviewed. The methodology outlines the following:
o when reviews should be conducted
o who are the personnel that should be involved
o how the review outcomes should be communicated
o how lessons learned will be passed on to future programs
o what tools and templates to be used (e.g., process review and lessons learned).

BSBPMG632 Learner Guide V1.04.22 Page | 24

1.2.2 Modifying Risk Methodologies

Risk context can be political, economic, social, legal, technological, etc. The process of selecting and
modifying program risk methodologies is done to match the established context of the risk as
established in Section 1.1.1.

Below are example scenarios that show when a risk methodology can be appropriately selected and
how you can modify it depending on the risk context.

▪ Scenario 1

A start-up delivery service company partnering with three local flower shops for a seasonal
sale wants to identify the risks and consequences such a collaboration would entail. They
find that due to the lack of delivery vehicles for despatch, delivery delays could occur during
the seasonal sale of their local shop partners. Complaints and dissatisfaction from the
customers and the local shop partners alike are expected and would go against their goal to
advertise their brand.

o Initially, they will use the risk identification methodology to employ risk identification
tools such as the SWOT analysis or others to identify detailed logistics and
operational risks.

o To manage the risks, they will discuss which risk treatment strategies to apply for the
identified risks. Since their goal is to advertise their brand, they may plan to
completely avoid or mitigate the logistics and operational risks identified by
developing appropriate solutions to address this.

o They will track the successes and failures of the business venture by employing risk
tracking methodology approaches to gauge their operations capacity further.

BSBPMG632 Learner Guide V1.04.22 Page | 25

 ▪ Scenario 2

A clothing and textile manufacturing company planned to produce twice the product output
they made last year using new high-speed industrial sewing machines for this year’s
productions. The new industrial sewing machines are expected to decrease production time
by a minimum of 10 hours. However, only 42% of the employees know how to operate the
new machines.

How will this impact the established objectives of the business program, especially in terms
of the production schedule?

o They will employ risk analysis approaches to measure the impact of possible delays
on the company’s schedule. The company will brainstorm the re-assigning of the
rating of the consequences of the new risks identified.

o They will measure the variance in productivity using risk review tools such as the
variance analysis before deciding on the new risk responses.

o They may set up internal audits to ensure the program complies with legal
requirements, especially on the safety of employees operating high-speed industrial
machines.

BSBPMG632 Learner Guide V1.04.22 Page | 26

1.3 Consult With Relevant Stakeholders and Identify, Document and Analyse Program
Level Risks

Stakeholders play a vital role in moving forward with your risk management planning. Since
stakeholders are composed of various people operating in different fields, it is best to consider their
ideas as you go about your risk management. Involving your stakeholders, especially in identifying,
documenting, and analysing program-level risks, will be beneficial in many ways. Some of the
benefits include:

▪ Encourages commitment and participation from stakeholders

▪ Urges stakeholder accountability on allocated tasks

▪ Gathers more data, therefore, reducing uncertainty

▪ Uncovers risks that could have been missed otherwise

▪ Meets the reporting and assurance needs of stakeholders

▪ Guarantees expert opinions of relevant stakeholders are heard and integrated

▪ Ensures productivity in identifying, documenting and analysing risks.

BSBPMG632 Learner Guide V1.04.22 Page | 27

1.3.1 Stakeholder Consultations

Consulting relevant stakeholders will help you gain their support and commitment so that
implementing the risk management plan becomes easier and, in turn, leads to a greater chance of
a successful implementation.

Stakeholders

They are defined as individuals, groups or organisations who either affect or are affected by the
program. The relevant stakeholders you may consult with are mainly the senior management team
because of the nature and complexity of program risks.

Communicating program level risks is often done through consultations. Consultation refers to the
process of seeking and sharing views and information regarding program risks and considering other
program stakeholders’ views as part of decision-making processes. Stakeholders are the drivers of
your risk management strategy and planning, especially in a program-level implementation. Taking
the stakeholder’s needs into account will make the planning of your risk strategy more cohesive and
coherent.

Setting up meetings is one effective way you can communicate with your stakeholders. Your role as
a program manager is to organise the details of the meeting, including:

The agenda

The time and place

The participants

The materials of the meeting.

BSBPMG632 Learner Guide V1.04.22 Page | 28

Since program-level risks are generally concerned with the overall objective of the program, you
must first establish the needs of your stakeholders in terms of:

▪ Stakeholder objectives – These are specific and realistic statements that describe the
desired outcome of your program, usually as tangible results (e.g., a product or service).

▪ Stakeholder expectations – This refers to a stakeholder’s belief of what a program can

achieve.

As you consult with your stakeholders with an established idea of their objectives and expectations,
you will be able to identify their risk attitude, composed of the following attributes:

▪ Risk Appetite is the level of uncertainty that a stakeholder is prepared to accept in

anticipation of a reward. It represents how much they are willing to take risks for the growth
of the organisation. It also indicates the amount of risk that they want to accept to achieve
their objectives. In a program situation, the level of risk appetite will vary greatly between
stakeholders. The table below shows the five levels of risk appetite:

Levels Definition

Averse Avoidance of risk and uncertainty is preferred.

Low-risk options which are considered ultra-safe but can only

Minimal
produce limited rewards are preferred.

Low-risk options which are considered safe but can only produce
Cautious
limited rewards are preferred.

All potential options are considered, but options that deliver

Open successful results and acceptable reward levels are chosen, even
if this means accepting higher levels of risk.

Options that potentially provide higher rewards, despite greater

Hungry
levels of risk are considered.

BSBPMG632 Learner Guide V1.04.22 Page | 29

 As seen in the table above, stakeholders and organisations are willing to take many risks if
the rewards are high (i.e., high-risk appetite). However, some prefer to play safe by accepting
only a few risks with relatively low rewards (i.e., low-risk appetite).

Risk appetite is affected by several factors, including, but not limited to the following:

o industry or sector

o organisational culture

o resources and capabilities of the organisation (i.e., the more resources that an
organisation has, the greater the risk appetite will be).

▪ Risk Tolerance refers to the readiness of an organisation to absorb the residual risk. Residual
risk is defined as the remaining risk after risk treatment – for a more in-depth discussion of
risk treatment, refer to Chapter 3 of this Learner Guide.

In other words, this involves accepting the outcomes of risk and having the appropriate
resources and controls to withstand the given risk.

▪ Risk Threshold is a project management tool used to measure the degree of uncertainty and
level of impact. It assigns a specific value to the amount of risk that stakeholders are willing
to accept. Simply put, it quantifies risk tolerance with a precise figure, which means that you
cannot calculate the risk threshold without determining the risk tolerance first.

The risk threshold indicates the level of uncertainty or impact at which a stakeholder will
accept the risk – below the risk threshold, the stakeholder will accept the risk, and above the
risk threshold, the stakeholder will refuse the risk.

Based on Risk threshold. © 2021 Project Management Knowledge.

Consulting With Stakeholders

Stakeholder consultations are an important part of the planning process of program risk
management. The stakeholders’ expertise is one reason why you must seek their opinion in
identifying and analysing program risks. Your knowledge of the program as the program manager
could be limited only to your previous experiences. However, seeking the expert judgment of
program sponsors, project team members and external contractors will make assessments simpler
and faster.

For example, consulting project team members and contractors would be useful since some have a
level of experience in their area far beyond yours, or anyone else for that matter. They will be able
to provide qualified advice on how to identify the potential risks, avoid the risk turning into an
incident, and manage it should they retain them as residual risks.

BSBPMG632 Learner Guide V1.04.22 Page | 30

Before kicking off with a consultation with relevant stakeholders in the planning phase, it is
important to ask:

▪ When should consultation with relevant stakeholders happen?

▪ How should consultations with relevant stakeholders be undertaken?

▪ Which workplace documents should you use to document consultation discussion?

When Should Consultation With Relevant Stakeholders Happen?

Consultation with relevant stakeholders can occur in several circumstances, including:

▪ when identifying potential risks

▪ when deciding whether potential risks are actual risks

▪ when making decisions about ways to avoid or mitigate risks

▪ when making decisions about whether to transfer or accept risks

▪ when proposing changes that may affect the overall status of the program.

The bottom line of this is that consultations must be tactical. The consultation should always happen
before doing a program activity or commencing with the program tasks. Otherwise, you could miss
some potential solutions you would only get from seeking other key stakeholders’ expertise. You
may repeat the consultation process at any given point in your program as needed.

How Should Consultations With Relevant Stakeholders Be Undertaken?

1. Preparing essential data

The first thing that you must do before commencing with the consultation is to prepare:

▪ the necessary data and/or resources

▪ the equipment (as needed)

▪ the questions to be raised during the consultation

▪ the notification to the persons to be consulted.

BSBPMG632 Learner Guide V1.04.22 Page | 31

 The consultation process may be held either in a face-to-face set-up or through an online
platform. Either way, the consultation must foster an environment that promotes the
welcoming of differing perspectives and requires active listening on your part. Below are the
ways in which consultations may be performed:

Face-to-face These provide an avenue to the effective building of relationships.

meetings Examples of these include public forums and house meetings.

These allow relevant stakeholder – not in the same region as the

Online other team members, to contribute their expertise. Telephone
meetings discussions can also be considered under this category.

Some examples of these are surveys or email exchanges. These

provide a great way of gathering relevant stakeholders’ responses,
Written especially if face-to-face or online consultations are not doable in the
responses organisation’s situation.

2. Commencing the consultation

The most common consultation techniques that you can use to extract information during
the consultation of relevant stakeholders include:

Personal interviews
• These are done when consultations must be done in private (e.g., Consulting
the program sponsor about the program budget is confidential.)

Workshops
• These are utilised when there is a need to engage stakeholders in intensive
discussions and activities. For example, allowing relevant stakeholders to
closely assess and test the new industrial sewing machine to further identify
threats by having the employees use it.

Focus groups
• These happen when a response from a departmentally similar group of
people is needed. For example, consulting only the people from the HR
department about the number of new hires they will likely onboard for
training for the upcoming months to identify if manpower is sufficient for the
next batch of program activities.

BSBPMG632 Learner Guide V1.04.22 Page | 32

 Public or ‘townhall’ meetings
• These occur when you wish to consult large and small groups of key people
involved in tackling various types of risks. For example, conducting an online
meeting where everyone can freely discuss their thoughts about the matter.

Surveys
• These are done when you want the stakeholder’s responses quick,
uniformed or short. For example, sending a survey on whether they agree
with the data that was uncovered using the risk matrix. Note that you must
ensure ample choices and enough fields are prepared for the respondents to
provide a more detailed explanation of your consultation questions.

3. Documenting the consultation

Consultations can be documented by recording the actual meeting, logging survey responses
and completing meeting minutes. A record of the meeting minutes is a common
documentation tool used in various industry consultations and meetings. It is a valuable tool
that logs the information discussed during the consultation process, which can be used as a
reference for the next steps in the risk management process.

Below is an example of a meeting minutes template. Make sure that you record the
discussion as detailed as you can, filling out all the required fields so that you can relay
information from the consultation to other program team members comprehensively as
needed.

Meeting Minutes

Team/ Program e.g., department, the specific program team

Meeting Date e.g., date, time, location of the meeting

Meeting Facilitator e.g., you, other program managers

Members Present e.g., program managers, other department stakeholders, SMEs

Minutes taker i.e., team member in charge or recording details of the discussion

Meeting Purpose e.g., agenda items

Resources e.g., risk register, lessons learned

BSBPMG632 Learner Guide V1.04.22 Page | 33

 Action Items From the Previous Meeting

Discussion Point Delegated to Deadline

Items for Discussion at This Meeting

Discussion point Delegated to Deadline

Further Reading

Bigger Than Big Corporation is a fictitious website of a business

that offers consultancy services. The said company tracks their
consultations through a document called Record of
Consultation, which is useful for keeping track of discussions
during consultation. A detailed example of this can be accessed
through the link below.

Sample Record of Consultation (Template)

BSBPMG632 Learner Guide V1.04.22 Page | 34

1.3.2 Program-Level Risk Identification, Documentation and Analysis

Program-level risks are on a larger scale than project risks when it comes to identifying risks, as they
are not confined only to projects or tasks. They are more concerned with the overall impact of
threats to the program's objectives, which is usually a collection of projects from either the same
organisational departments or different departments (e.g., purchasing, human resources, research
and development, finances).

Program-Level Risk Identification

Since program-level risks are more concerned with the threats associated with the overall program,
risk identification is normally performed by senior program team members. This is normally
performed through a lot of back and forth from key stakeholders through consultations, as
discussed in the previous section.

During consultations, risk identification can be made using the following tools and techniques with
the help of authorised and relevant stakeholders:

Informed Opinion

Delphi Technique

Risk Checklists

Risk Categorisation

▪ Informed Opinion

Any informed opinion from key stakeholders relevant to a specific subject matter of your
program, in this case, risk identification, is accepted as information. If you are a program
manager with a strong technical background, you will know from your own experience a lot
of the risks that could be encountered. Additionally, if you have experience in managing a
program, you will be able to draw from your own experiences the risks regarding the
integration and communication processes of the program.

BSBPMG632 Learner Guide V1.04.22 Page | 35

 ▪ Delphi Technique

The Delphi technique mostly used to identify potential risks involves getting a group of
experts to answer questionnaires anonymously. The responses are aggregated in the form
of statistical representation and then shared with the group. This process is repeated several
times. Each round aims to reduce the range of responses until a group consensus is reached.
The main benefit of using this technique is that the information obtained will come from
experts.

Based on Delphi Method. © 1994-2020 RAND Corporation.

▪ Risk Checklists

A risk checklist is a pre-made list of risks that persist in a specific program, an area in the
process, or the industry. You can access lists made by a different organisation or industry to
match and cross-check your list.

Note: They are recommended to be used after identifying the first pool of potential risks as
they tend to limit creativity in visualising risks if used prematurely.

▪ Risk Categorisation

This technique focuses on the risk categories, which tell you why or in what particular area
in your program an event occurs. You can use this to determine which potential risks under
each category require more attention and further checking. That way, you can control the
risks directly from their source. Otherwise, it will be difficult to control risks if different
categories are overlooked, given all categories directly affect the program as a whole. Here
are some categorisations of risks that you can use in identifying program risks.

communications compliance environmental finance

health and human

legal political
safety resources

project
quality social technology
constraints

Sourced from A Guide to the Project Management Body of Knowledge (6th Edition).

BSBPMG632 Learner Guide V1.04.22 Page | 36

 Further Reading

There are plenty of other ways to identify potential, actual and

residual risks in your organisation. It is important to utilise as
many as you can to avoid failing to identify risks that could
potentially harm the program overall. To learn more about
other ways how to identify potential risks, you can refer to the
link below that will direct you to a short YouTube lecture from
The University of Adelaide on how to Select and Use Methods
to Identify Risks.

RiskX: Select and Use Methods to Identify Risks

Program-Level Risk Analysis

Risk analysis separates the minor acceptable risks from the major, unacceptable risks and provides
data to assist in evaluating and treating risks. Risk analysis is especially concerned with examining
the likelihood of occurrence and the severity of consequences of risks identified in the beginning
stages of the risk management process. By measuring the likelihood of occurrence against the
severity of consequence, you will be able to assign a risk rating to the identified risks. The risk rating
then tells you how damaging can the present risks be to your program objectives. Risks may be rated
as low, medium, high and critical and prioritised accordingly. This process is performed using a risk
analysis tool called the risk matrix. The steps in doing risk analysis are as follows:

Determine the
Determine the Identify the risk
consequence of the
likelihood of the risk rating.
risk

BSBPMG632 Learner Guide V1.04.22 Page | 37

The severity of a consequence is usually determined using numbers in the range of 1 to 5. The
greater the negative impact on the program, the greater the severity. In other words, a rating of 1
could mean that the impact of risk is insignificant or low, while a rating of 5 could mean that the
impact of risk is extreme or critical. The severity of the consequence is determined by using the
following criteria:

Descriptor Scenario Severity of Consequence

Extreme Catastrophic business loss, multiple fatalities Level 5

Critical schedule/cost deviation, critical property

Major Level 4
damage, major injury or single fatality

Moderate schedule/cost deviation, limited property

Moderate Level 3
damage, reportable injury,

Minor schedule/cost deviation, slight damage to

Minor Level 2
property, non-reportable injury

Insignificant damage to property or equipment or a

Insignificant Level 1
single minor injury

The likelihood of an event occurring is determined by using the following criteria:

Descriptor Description Likelihood of Occurrence

Is expected to occur in most

Almost certain > 90%
circumstances

Likely Will occur in most circumstances Approximately 70–90%

Possible Might occur at some time Approximately 30–70%

Unlikely Not expected to occur. Approximately 10–30%

Rare May occur in exceptional circumstances < 10%

After determining the likelihood and the consequence of the risk, use a risk assessment matrix, such
as the one on the next page, to determine the type of the risk.

BSBPMG632 Learner Guide V1.04.22 Page | 38

Risk Matrix

The risk matrix is used to prioritise between potential risks or between actual risks by scoring the
likelihood and the severity of the consequence of each risk and then assigning a risk rating. The
likelihood and impact ratings are multiplied to produce the level of risk as detailed in the matrix
below.

Calculate the level of risk according to the following formula below:

Risk Rating = Consequence × Likelihood

By doing so, you are prioritising the risks into low, medium, high and critical. For example, a
consequence of 3 and a likelihood of 4 would result in a high risk (3 x 4 = 12).

This prioritisation will help you identify which risks need to be treated first. The higher the risk, the
more urgent is the treatment.

Below is an example of a risk matrix, a risk analysis tool that you can use to assess the risks of your
program.

Consequence Insignificant Minor Moderate Major Extreme

Likelihood (1) (2) (3) (4) (5)

Almost Certain Low Risk Medium Risk High Risk Critical Risk Critical Risk

(5) (5) (10) (15) (20) (25)

Likely Low Risk Medium Risk Medium Risk Critical Risk Critical Risk

(4) (4) (8) (12) (16) (20)

Possible Low Risk Low Risk Medium Risk High Risk High Risk

(3) (3) (6) (9) (12) (15)

Unlikely Low Risk Low Risk Medium Risk High Risk High Risk

(2) (2) (4) (6) (8) (10)

Rare Low Risk Low Risk Low Risk Medium Risk High Risk

(1) (1) (2) (3) (4) (5)

BSBPMG632 Learner Guide V1.04.22 Page | 39

Program-Level Risk Documentation

After using the techniques and tools appropriate for the assessment of risks, you and your team will
have identified and analysed a wide range of risks that will need further action. Documenting
gathered data after risk identification and analysis is crucial to the next processes that you will be
taking. Consider documenting output during this process in the planning phase on the basis of the
development of your program-specific tasks and action plans.

To ensure details are properly logged and specified in detail, you may use the following templates
as a reference to set the foundation of your competent risk management plan:

▪ Assumption Log

An assumption log’s objective is to list down assumptions that correspond to the question
‘What if?’. Assumptions that give rise to potential risks usually require some type of follow-
up or validation to determine whether they will impact the program significantly. You may
record identified potential risks using an assumption log.

Below is an example assumption log that you can use to pattern your program risks:

Assumption Log

Program Date 3/05/20xx

Person
ID Category Assumption in Due Date Status Actions
charge

J. Smith is to
make rounds
Health and
to make sure
safety
There are enough fire
enough fire extinguishers
129 (Can be a J. Smith 3/27/20xx Open
extinguishers are put in
potential
in place. place and
compliance
comply with
risk)
state
standards.

BSBPMG632 Learner Guide V1.04.22 Page | 40

 ▪ Risk Register

As established in Section 1.1.2, a risk register is an important document that you will be
accessing throughout the planning, implementing, and reviewing stages of your program.
Risk registers are dynamic and can be modified to fit programs according to their scale and
complexity. They are also often updated throughout the life cycle of the risk management
process to accommodate new information on risks.

Your risk register in the risk identification process must contain at least the following
information:

Likelihood
Date Risk Risk Consequence if the Risk
ID of the Risk
Identified Description Impacts Risk Occurs Owner
Occurring

Delays in the design

Consultant
delivery will directly Project
0001 21 May 20xx or contractor Medium High
cause a delay in the manager
delays
overall schedule.

A risk register must have the following characteristics to be considered dynamic:

o A dynamic risk register allows for continual review and improvement.

o In a dynamic risk register, risk treatments implemented are frequently reviewed for
their effectiveness in mitigating risks.

o In a dynamic risk register, risk impact, severity, and rating are continually reviewed
and updated.

The way a risk register would be used across a program would be any of the following:

o A dynamic risk register would be used to regularly monitor and update the risk rating
of identified risks.

o A dynamic risk register would be used to ensure that risks are assigned to their
respective owners and this ownership is regularly reviewed and updated.

o Since dynamic risk registers enable regular monitoring and updating of risk rating of
identified risks, risks are managed and mitigated in a timely manner.

BSBPMG632 Learner Guide V1.04.22 Page | 41

 ▪ Risk Report

Risk reports show information on the overall sources of program risk. The potential and
actual risks are often provided with the summarised information on identified individual
project risks that would affect the program overall. It is also updated with the results (i.e.,
residual risks) gathered throughout the different phases of the program. After identification
and analysis, the risk report may include the following:

o Sources of overall project risk

o Summary information on identified individual project risks (e.g., identified threats)

o Distribution of risks across risk categories, metrics, trends, etc.

BSBPMG632 Learner Guide V1.04.22 Page | 42

1.4 Support and Mentor Project Managers in the Analysis, Evaluation and Treatment
of Risks

Following the program management hierarchical structure, project managers are ranked directly
underneath program managers. This shows how closely they work alongside you to ensure the
completion of individual project tasks as part of the overall program. Supporting and mentoring
them in the analysis, evaluation, and treatment of risks will be beneficial for both you and the
project manager and the organisation.

Listed below are the benefits for a program manager who oversees the program.

▪ You can be confident that your project managers have the capacity to address risks that are
within their authority.

▪ This will make the analysis, evaluation, and treatment of risks on different individual projects
and various program activities harmonious.

▪ Project managers, in turn, would be able to support those who report under them (i.e.
program team members) as well.

By pairing a more experienced person (the mentor) with a less-experienced member (the mentee),
you can use mentoring:

▪ to equip newer and more inexperienced team members

▪ to provide moral support to project managers

▪ for succession planning in case program managers plan to leave or fail to do their duty as
program risk managers.

BSBPMG632 Learner Guide V1.04.22 Page | 43

1.4.1 Risk Analysis, Evaluation and Treatment

The end goal for every risk identified in risk management is for it to be addressed and controlled so
that it will no longer be a factor for your program to fail. The process of analysing, evaluating and
treating risks is vital to ensuring this. In the planning phase, together with the project managers,
you must do these steps hand in hand so that the consolidation of data you will be able to collect
and address will not be difficult.

As discussed in the previous section, risk analysis is a step in the risk management process that lets
you give risks a rating or a score. Priorities are established through analysing the relationship
between program outcome benefits and consequences. This is often done using the risk matrix, a
chart that follows the formula below to calculate the level of identified risks.

Risk Rating = Consequence × Likelihood

Risk Evaluation

The level of risk identified during risk analysis can be ranked and prioritised according to a consistent
overall ranking and rating system. After they have been ranked, the risk evaluation will now
determine the tolerability of each risk. The tolerability of each risk is normally determined by
comparing the risk analysis results against the risk criteria.

Risk evaluation is considered a passageway connecting the analysis and treatment planning of risks.
During risk evaluation, you may simply undertake further analysis to better understand risks. To do
this, you must access your updated risk register with the new risk ratings for each threat. From here
on, your team will be able to plot a risk treatment appropriate to the rating of each risk. You will
take no further action but record, communicate and validate the outcome of risk evaluation at
appropriate levels of the organisation if everything is all set.

Risk Treatment

The goal of risk treatment is to adequately address actual risks. In the planning phase, you must be
able to choose controls equal to the risks your organisation has already assessed. Remedial actions,
also called risk treatments, intend to remove, control, or lessen risk impacts on a program. See
Chapter 2, Subchapter 2.4, for further discussion on risk treatments.

BSBPMG632 Learner Guide V1.04.22 Page | 44

1.4.2 Supporting Project Managers in Risk Analysis, Evaluation and Treatment

It is important to give them the support they need as they perform their tasks to ensure that they
are done in line with the overall goals you have set up for your program. Supporting project
managers means being available to aid focused on providing their needs, such as:

▪ Ensure they have access to relevant data or resources to conduct risk assessments (e.g., risk
register, risk-related data and resources)

▪ Establish the project, deadlines and milestones so that confusion is avoided

▪ Hold meetings as needed to allow them to discuss what project managers can do to meet
program objectives

▪ Encourage project managers to ask questions and be available as needed,

The ways in which you can support a project manager in the analysis, evaluation and treatment of
a project risk will be discussed below.

Supporting Project Managers in the Analysis of Risks

How you can support the project manager in the analysis of a project risk include:

▪ Clarifying the nature of the project risk identified by the project manager

▪ Explaining the risk consequence to watch out for

▪ Giving guidelines on identification of the risk rating based on risk likelihood and consequence

▪ Guiding as needed to ensure outcomes are consistent with risk management frameworks
and standards. (e.g., referring to and following the organisation’s risk matrix, risk
management procedures, and standards).

Supporting Project Managers in the Evaluation of Risks

Since the purpose of risk evaluation is to push forward with the plan after the analysis of risks. It is
a great way to support project managers as it confirms how the team should go about the treatment
process of the risks. How you can support the project manager can include evaluating together the
possible impacts of this risk on the project.

BSBPMG632 Learner Guide V1.04.22 Page | 45

Supporting Project Managers in the Treatment of Risks

How you can support the project manager in the treatment of project risk include:

▪ Instructing how to identify effective risk treatments

▪ Explaining appropriate and effective use of risk prevention strategies. (e.g., avoiding,
accepting, mitigating, transferring risk)

▪ Instructing how to identify revised risk likelihood and revised risk consequence

▪ Giving guidelines on how to identify revised risk rating based on risk revised likelihood and
revised consequence

▪ Providing guidance as needed to ensure outcomes are consistent with risk management
frameworks and standards. (e.g., referring to and following the organisation’s risk matrix,
risk management procedures and standards).

BSBPMG632 Learner Guide V1.04.22 Page | 46

1.4.3 Mentoring Project Managers in Risk Analysis, Evaluation and Treatment

Mentoring project managers simply means influencing, guiding and directing them towards
effectively achieving objectives. In the risk management planning phase, mentoring could mean
imparting what you know, experienced or observed so that they will be able to conduct risk
assessments with confidence and map treatments with a sense of accountability for each risk. This
can be achieved by:

▪ Building rapport with project managers

▪ Being available and accessible for support as they take necessary actions for the project and
program-related tasks, as mentioned in the previous discussion of this section

▪ Having an open line of communication to aid them with their concerns and other areas of
difficulty

▪ Conducting training and walkthroughs for a better grasp of techniques, methods and
common practices

▪ Exposing them to internationally recognised risk management standards available to help

them conduct risk assessments and map treatments with tried and tested guidelines, such
as:

o PMBOK Risk Management Guide and Standards – This can be used as a reference
manual for program managers to assist project managers in identifying and treating
program risks. The standards outline seven proven risk management processes and
relevant tools and templates.

o AS/NZS ISO 31000:2009 Risk Management Principles and Guidelines – This can be
used as a reference manual for program managers to assist project managers in
identifying and treating program risks. It outlines the risk assessment and the risk
management process, from risk identification to monitoring and reviewing risks and
risk management processes.

BSBPMG632 Learner Guide V1.04.22 Page | 47

Mentoring Project Managers in the Analysis of Risks

The ways in which you can mentor the project manager in the analysis of a project risk include:

▪ Teaching them risk analysis techniques and methods for different contexts of risks
▪ Explaining why certain identified risk consequences must be avoided

▪ Expounding on how to categorise analysed risks to be avoided for documentation

▪ Giving opportunities for the project manager to identify risk ratings based on risk likelihood
and consequence on their own

▪ Providing walkthroughs on how to use internationally recognised standards for its

integration on the projects they are managing.

Mentoring Project Managers in the Evaluation of Risks

The ways in which you can mentor the project manager in the evaluation of the project risk impacts
on the program include giving project managers an opportunity to perform the evaluation of the
possible impacts of risks on the project or the program under your guidance and surveillance.

Mentoring Project Managers in the Treatment of Risks

How you can mentor the project manager in the treatment of project risk can be done by doing the
following:

▪ Equipping them on how to select appropriate and effective risk treatments using risk
management standards by conducting training sessions

▪ Familiarising them with the use of appropriate and effective risk prevention strategies by
giving them plenty of opportunities in being a part of those who decide in mapping risk
treatment strategies for certain risks

▪ Giving them an opportunity to show other team members how revised risk likelihood and
revised risk consequence are identified

▪ Providing training on how to use internationally recognised standards for identifying revised
risk rating integration on the projects they are managing.

Now that you know in which areas you can support and mentor project managers regarding the
analysis, evaluation, and treatment of project risks, it is essential that you run a support and
mentoring program that is fitting to your organisational needs. Below are some considerations to
take note of in running a mentoring program in your organisation.

BSBPMG632 Learner Guide V1.04.22 Page | 48

 Using plain English as appropriate to the audience

•For example, using layman’s terms rather than English terms used only by specialists.

Using industry-accepted terminology as appropriate to the audience

•For example, using work health and safety terminology when talking to an audience
comprised of WHS personnel.

Avoiding usage of verbose and convoluted language

•For example, when consulted through email, avoid wordiness. Using ‘in spite of that’
rather than ‘although’ is an example of this.

Including pertinent facts and details when presenting the information.

•For example, when asked for their desired engagement, they identify appropriate to
them and not just accept what is suggested to them, etc.

And finally, confirm understanding by:

Using active
listening in Using open- Probing
paraphrasing to Using ended questions (e.g.,
demonstrate nonverbal cues questions (e.g., you mentioned
they to demonstrate What do you earlier, can you
understand understanding, think? How do please
what the such as nodding you feel about elaborate on
speaker has just this?) that)
said

BSBPMG632 Learner Guide V1.04.22 Page | 49

1.5 Confirm Risk Management Is Transparent and Dynamic Across the Program so
That Risks Are Assigned and Managed in a Timely Manner

In directing the planning of a program risk management, you must ensure risks are assigned and
managed in a timely manner. In essence, identifying and addressing risks without delay means
managing risks in a timely manner. The benefits of carrying out these important steps in a timely
manner include, but are not limited to:

Preparing you in
Accomplishing results
Spotting concerns far dealing with more
in a shorter period of
earlier serious risks that
time
would need attention

Improving thew Making you proactive

productivity of the rather than reactive
team in addressing risks.

BSBPMG632 Learner Guide V1.04.22 Page | 50

To confirm that risk management is assigned and will be managed timely across the program, you
can ask program stakeholders if:

▪ Risk identification and analysis activities were completed

This can be done by checking in on the project managers or risk owners of your program via
email, calls or online group conferences. You can ask for a document containing all identified
and assessed risks via a risk checklist, the risk register or others.

▪ Risk management activities, such as risk reviews and audits, were completed as scheduled
or planned

This can be done by procuring relevant stakeholders’ or risk owners’ signatures or

confirmation that they have reviewed the latest project management systems, policies and
procedures or that they have received appropriate training to execute risk management
activities. Declaring projected delays and other issues that may warrant clarification or
further support must be formally made as well to adjust the schedule.

▪ Decisions regarding risk controls were made timely

This can be done by checking the risk register, particularly the risk owner and the planned
risk treatment strategy fields. Recording often requires inputting the time and date of
completion, so it will be easier for you to track if they were filled out on or before the set
deadline.

▪ Risk treatments were implemented as per the implementation schedule or plan.

In the implementation phase, confirming whether the risk treatment plan was executed on
time or not is crucial. You can do this by checking the updated risk register, directly speaking
to the risk owner or conducting group sessions to confirm the progress of each task or
activity.

Guidelines on Confirming Program Risk Management is Transparent

You can define transparency in a program risk management as a plan that:

▪ Allows for clear communication between relevant stakeholders throughout the different
phases of risk management (e.g., in risk identification, risk mitigation, addressing issues)

▪ Ensures company objectives are clear and available to all persons involved at the onset of
the planning

▪ Promotes an environment that takes responsibility when it is due (e.g., risk owners
escalating delays or mistakes to superiors).

BSBPMG632 Learner Guide V1.04.22 Page | 51

By conducting business transparently, a company can achieve their goals in a better way. To confirm
that risk management is transparent across the program, you may ask program stakeholders if:

▪ Risk management tools are accessible, well enough documented, and understood

Updating and accessing risk management tools such as your risk register lists and the risk
matrix alone can confirm that your risk management is available for all stakeholders to
access. This ensures stakeholders are up-to-date with changes and developments in the
program tasks, making it easy for them to perform necessary changes whenever needed.

Examples of risk management tools that you can take note of to confirm transparency of the
program risk management are:

o The risk register – lists all program risks and, for each risk, the ratings for risk
probability and impact, risk category and risk ranking, program impacts, residual risk,
and risk owners

o The risk matrix – prioritises risks by scoring the likelihood and consequence of each
risk and then assigning a risk rating. This document can clarify and prompt risk
owners to prioritise tasks in the program according to the risk rating for each risk.

▪ Risk management frameworks are accessible, well enough documented, and understood

Examples of risk management frameworks that you can take note of to confirm transparency
of the program risk management are:

o Risk Management Policy – generally outlines the objectives of the policy, the risk
management framework, and responsibilities. Access to clear and coherent policy
objectives promotes comprehensive components related to it will also be
communicated

o Risk Management Procedures – are used to standardise risk management processes,

such as risk assessments, audits, documentation, etc. These procedures outline
specific steps that must be taken by program managers and stakeholders to
efficiently and effectively identify and treat program risks.

▪ Risk management systems are accessible, well enough documented, and understood

Examples of risk management systems that you can take note of to confirm transparency of
the program risk management are:

o Risk Management Software – is an integrated method for documenting and

monitoring risks, risk controls, and residual risks. The software allows more efficient
management of risks and communicates risks to program stakeholders through a
shared platform

BSBPMG632 Learner Guide V1.04.22 Page | 52

 o Risks Management Templates – can be used to complete and document outcomes
of risk management tasks, such as risk audits, risk checklists, etc. The templates may
be used as printed hard copies or soft copies on a computer.

▪ Risk management methodologies are accessible and understood.

As established in Subchapter 1.2, risk management methodologies are vital components of

the overall risk management process. If each component that corresponds to a parallel step
in the risk management process is executed according to plan, confusion and instability in
the program management planning can be easily avoided. The following are considered risk
management methodologies:

Risk management planning

Risk identification

Risk analysis

Risk treatment

Risk tracking

Risk review.

Procuring Approval

To confirm risk management is transparent across the program, securing approval for the risk
management plans from relevant program authorities must also be procured. Doing this will signify
that everyone concerned with the program tasks and objectives is on board with where you and
your team are in the process so far. You can procure approval using the following steps:

Informal Formal
Agreement Agreement

BSBPMG632 Learner Guide V1.04.22 Page | 53

 ▪ Informal Agreement

These are agreements often communicated in person, through phone calls, text messages
and sometimes emails. They often do not involve signing and are considered less formal but
hold power in the decision-making changes and give instructions.

▪ Formal Agreement

These agreements refer to documents individuals need to sign to signify that they agree with
the steps you will be taking to implement the risk management process on the program
concerned. Below is a sample template for the risk treatment approval section of important
risk management documents, such as the risk management plan that will be discussed in the
next subchapter.

Approval

Full Name Role Date Signature

BSBPMG632 Learner Guide V1.04.22 Page | 54

Guidelines on Confirming Program Risk Management Is Dynamic

Subsequently, due to the unpredictable nature of risks, a dynamic program of risk management is
necessary. It needs to be dynamic to withstand and adapt to the changes that will occur throughout
the different phases of your program. A dynamic program of risk management means that it has the
ability to:

Decide on the
Detect potential new
Determine the appropriate risk-
risks and weaknesses
appetite for risk-taking management
in risk treatments
approach.

Below are guidelines by which you can ask program stakeholders to confirm that risk management
is dynamic:

Ask if risk management

tools, frameworks, systems,
Ask if risks are monitored methodologies, and
regularly standards are flexible
enough to be applied to all
types of program risks.

▪ Ask if risks are monitored regularly

You can do this by setting a set date to solicit the stakeholders’ responses. You can agree to
do it daily, weekly, bi-weekly and so on.

▪ Ask if risk management tools, frameworks, systems, methodologies, and standards are
flexible enough to be applied to all types of program risks.

This can be done through meetings, consultations, and/or email correspondence for a
straightforward approach. Another way to do this is by sending out surveys or feedback
forms so stakeholders' responses will be uniformed or narrowed down to your preferred
response choices. This way, you will have an idea of which aspects of your program to change
and which aspects of your program to improve constantly.

Note: Ensure you document the feedback and areas requiring improvement to make risk
management more dynamic. This can be done by updating program templates such as the risk
register or your organisation’s risk management plan.

BSBPMG632 Learner Guide V1.04.22 Page | 55

1.6 Develop and Maintain a Program Risk-Management System for Effective
Management and Communication of Risks, Controls, Treatments and Outcomes to
Stakeholders Across the Program

Developing a program risk management system consolidates all accomplished risk management
processes (e.g., risk identification and risk assessment) in the planning phase to ensure everything
is set before moving on to the next phase of the risk management, which is the implementation of
risk management plans. A program risk management system is maintained or sustained throughout
and across the program to involve, update and assist stakeholders in managing risks, their controls,
treatments and outcomes.

A system is a set of risk management components with different functions and agendas that, if put
together, have the chance to improve the quality and reliability of your team's approach to
managing and communicating your program risks.

1.6.1 Develop a Program Risk-Management System for Effective Management and Communication
of Risks, Controls, Treatments and Outcomes

Developing a program risk management system is like stacking blocks which will serve as steps for
you to reach the desired object. In the case of your program risk management planning, you are
stacking up risk strategies, techniques and many other risk management components together to
achieve effective management and communication of risks across your program. By developing a
program risk management plan, you can mix and match risk management components to create a
suitable system to suit your organisational needs. A risk management plan is a document that
defines exactly how risks should be controlled and treated and tracks risk management outcomes
on any given program throughout the organisation.

BSBPMG632 Learner Guide V1.04.22 Page | 56

The relevant key elements of a risk management plan are as follows:

• This refers to the general approach to risk

Risk strategy
management.

• This defines how risk management will be

performed on the program. It involves specific
Methodology
approaches, tools, and data sources to be used as
part of the overall program risk management.

• This involves the lead, support and risk

management team members per activity and their
Roles and
corresponding responsibilities. In other words, the
responsibilities
delegation of tasks concerning relevant
stakeholders.

• This defines the schedule and frequency of the

Timing implementation of risk management processes
throughout the program life cycle.
• This refers to the means for categorising each
Risk categories
program risk.
Definitions of risk
• This defines the different levels of risk probability
probability and
and impact as relevant to the program context.
impact
• This maps the probability of each risk occurrence
Probability and
and its impact on project objectives if such risk
impact matrix
occurs.

Revised • This defines the stakeholders’ tolerances (the

stakeholders' degree of uncertainty that a stakeholder can accept
tolerances in relation to the project risk assessment).

• This defines how the outcomes of the risk

management processes will be documented,
Reporting
analysed, and communicated. It describes the
formats
content and format of the risk register as well as any
other risk reports required.

• This defines how risk activities will be recorded and

Tracking
how risk management will be audited in the project.

Sourced from A Guide to the Project Management Body of Knowledge (6th Edition).

BSBPMG632 Learner Guide V1.04.22 Page | 57

 Note: The key elements of the risk management plan discussed must be completed in detail
in accordance with your program objectives before finally endorsing the relevant action
items to the stakeholders concerned.

Awesome Landscapes

Awesome Landscapes Pty Ltd is the simulated business referenced

in our learning resources.

Awesome Landscapes Pty Ltd provides landscaping solutions in

large-scale commercial and residential developments.

They use a risk management plan document to develop their

implementation of risk management plans. Their risk management
plan is published on their site. You can access them through the link
below:

Awesome Landscapes Risk Management Plan

Username: lexislearner

Password: lexis@123

1.6.2 Maintain a Program Risk-Management System for Effective Communication with Relevant
Stakeholders

If developing a program risk management system is to stacking up blocks to reach a goal,

maintaining a program risk management is to fortify the blocks you have set up to prevent them
from crumbling down. To maintain effective management and communication of risk controls,
treatments and risk management outcomes in your system, you must see to it that your program
risk management system is:

▪ Accessible

All relevant data about the program risk management must be accessible to relevant
stakeholders of the program. This can be done by employing risk management systems that
are readily available and are able to be modified to suit your organisational needs.

For example, employing a cloud-based project management solution software that will allow
all your program data to be in one space. Therefore, making it more accessible and available
to anyone who needs access to your program risk management data.

BSBPMG632 Learner Guide V1.04.22 Page | 58

 ▪ Up-to-date

All documents that play a crucial role in all the different phases of the program risk
management process must be updated periodically to ensure no information, tools, or
strategies are missing, obsolete or no longer usable.

▪ Always in motion

It is necessary to keep tabs on the progress of the ongoing tasks or activities by asking for
and responding to feedback. This can be done through verbal and nonverbal forms of
communication via either email, calls or in-person question and answer. This is done to
ensure program tasks are being completed.

▪ Adaptable to change

You must record and log minor and major changes that have transpired throughout the life
cycle of your program in order to keep track and understand how your program has
progressed. Above all, you must ensure to have a plan to address any notable changes in
your program by having a contingency plan (i.e., a fallback plan) that will be referred to as
necessary.

BSBPMG632 Learner Guide V1.04.22 Page | 59

 Checkpoint! Let’s Review
1. Risk identification must be performed regardless of the risk’s
immediate probable impact as it is vital in ensuring that
accurate solutions will be provided to properly identified
problems.

2. Task delegation ensures all relevant stakeholders have a

sense of ownership in their responsibilities and tasks in the
program.

3. Some benefits of Involving stakeholders in identifying,

documenting, and analysing program-level risks urge
stakeholder accountability on allocated tasks, guarantee
expert opinions of relevant stakeholders are heard and
gather more data, therefore, reducing uncertainty.

4. Supporting and mentoring project managers assure you that

they have the capacity to address risks that are within their
authority. This will make the program management process
seamless and less stressful for you, who oversees the
program as a whole.

5. Identifying and addressing risks without delay is what it

means to manage risks in a timely manner.

6. Developing a program risk management system means

completing a risk management plan. This document defines
exactly how risks should be controlled and treated and tracks
risk management outcomes on any given program
throughout the organisation.

BSBPMG632 Learner Guide V1.04.22 Page | 60

2. Manage Program Risk
In the previous chapter, you were guided on how to plan a program risk management strategy. You
were able to learn the three important processes involved in planning for a program risk that is
comprehensive and concrete enough for the actual management of program risks, also the
implementation phase.

The implementation phase refers to the actual management of the program risks using the planned
program risk management strategy. In the implementation phase, your goals are to:

▪ monitor progress on deliverables

▪ supervise program activities in conjunction with program objectives

▪ communicate management plans or strategies to relevant stakeholders

▪ assess risk controls applied for any changes

▪ perform necessary treatments to control risks.

In this chapter, you will learn more about how to perform the above-mentioned responsibilities
using your planned program risk management strategy so that your organisation can impose timely
solutions in managing risks. Not knowing how to manage a program risk would lead to terrible
consequences for your organisation, such as lawsuits, financial loss, damaged reputation, business
failure and more.

The following topics will be covered in Chapter II:

▪ direct management of the program in accordance with agreed program risk-management

plans

▪ review progress, analyse variance and initiate risk responses to achieve program objectives
in dynamic risk environments

▪ confirm risks are monitored and assessed across the program at agreed intervals

▪ direct response to actuated program risk and confirm remedial actions are authorised with
impact analysis according to program objectives

BSBPMG632 Learner Guide V1.04.22 Page | 61

2.1 Direct Management of the Program in Accordance With Agreed Program Risk-
Management Plans

Once you have finalised your program risk management strategy and gained approval from the
relevant stakeholders of the program, you are now ready to put your planned strategy into action.

As a program manager, your main task in the implementation phase is to ensure program activities
are running following the agreed-upon program risk management strategies developed in the
planning stage.

The biggest advantage of a comprehensive and concrete risk management strategy agreed upon by
relevant stakeholders is that you gain assurance in how you and your team can direct your program
risk management towards achieving your organisation’s objectives.

Agreed program management plans can be obtained by constant brainstorming and meeting with
the stakeholders involved in the program. There are many ways to confirm agreed-upon program
management plans. Fundamentally, they are put in place to prevent misunderstandings and
disputes by clarifying the expectations of the stakeholders in the overall process of risk
management. To confirm approval of your management plans, you may access the following
documents in your organisation.

▪ Risk management plan

This document serves as a mechanism to collate the identified risks and map out the plan to
get the project back on track in case these risks occur. It is comprised of many sections,
including an approval page where you will see the list of authorised stakeholders’ signatures
indicating their agreement of the management plans.

▪ Memorandum of understanding

This is a written agreement which is not a legally binding document used for negotiating
terms to express understanding between involved parties. Usually, this is done to ensure
program sponsors and other interested parties agree with the management plans.

Further Reading

There are many ways how to write and fill out the memorandum of
understanding based on the industry or the context of the needs of
both parties. However, to give you an idea about what are the
components that make up a memorandum of understanding, below
is a link to a sample document.

Sample Memorandum of Understanding

BSBPMG632 Learner Guide V1.04.22 Page | 62

To oversee your risk management in accordance with the agreed-upon risk management plans,
consider the following guidelines:

▪ Communicate approved risk program plans

The first thing that you can do is relay approved program risk management plans to relevant
stakeholders. If it is for a risk treatment plan, for example, you will have to relay the following
information:
o the identified risks
o the risk impacts, including:
̶ likelihood
̶ consequence
̶ risk rating
̶ risk impacts (e.g., impact on the budget, timeline, quality, etc.).

▪ Assign responsibility for implementation

Next, you can now assign responsibilities to stakeholders for the implementation of the plan.
Locate the risk owner or the key person designated to perform the task to assign tasks,
program activities and so on.

What you need to keep in mind when assigning responsibilities for implementation are as
follows:
o Remedial actions to be put in place
o Actions
o Responsibilities
o Due dates.

▪ Ask for and respond to feedback and/or update

Periodically, feedback and/or update must be obtained from all relevant stakeholders,
especially those directly associated with tasks related to the management of risks. This way,
you will be able to track which aspects or specific tasks of your program risk management
will need further assistance. This can be crucial, especially in time management and
addressing risks promptly. You may ask for feedback on the following examples:
o shared risks
o risk impacts
o treatment plans
o responsibilities.

BSBPMG632 Learner Guide V1.04.22 Page | 63

 Note: It is important that you respond appropriately to feedback and answer any questions
raised to support team members carry out tasks effectively.

▪ Document changes

Lastly, you will record and log any suggested changes that have transpired during the course
of implementing managing or program risks.

The following templates can be used to document changes throughout the management of
program risks.

o Risk register
o Risk treatment plan
o Risk treatment implementation review.

Note: A risk treatment plan is attached together with this learner guide. Make sure to
browse it to get a clearer picture of how changes are properly documented through the use
of a risk management plan.

BSBPMG632 Learner Guide V1.04.22 Page | 64

2.2 Review Progress, Analyse Variance and Initiate Risk Responses to Achieve
Program Objectives in Dynamic Risk Environments

The identity of risks often does not stay the same throughout the life cycle of a program risk
management. Depending on which phase you are in in the overall process, it is likely that new risks
would arise, low-level risks will escalate, and high-level risks would downgrade. This happens
because unpredictable events will continue to occur that could indirectly or directly affect your
program as you continue to manage risks.

In risk management, changes are always to be expected. To ensure your program risk management
can withstand such changes, consider contingency plans, especially for risks within complex
programs subject to unpredictable contextual pressures.

The common types of risks that can be subjected to unpredictable contextual pressures will be
discussed below:

Natural Human Regulatory Commodity

Disasters Error Risk Price Risk

▪ Natural Disasters – that threaten businesses include typhoons, earthquakes, landslides,

forest and grassland fires, pandemics, floods and etc. They impact negatively on
infrastructure and business operations leading to huge losses. Not only is it a threat to
infrastructure and business operations that create huge losses, but it also has a great impact
on market shares globally.

▪ Human Error – includes the collapse of infrastructures, oil spills and nuclear disasters. This
could potentially harm people inside and outside an organisation and could lead to the
tarnishing of a business brand or reputation. Such disasters are often due to non-compliance
with rules, regulations, and standards.

▪ Regulatory Risk – includes a change in regulations and laws such as tax policies or banning
of certain substances.

BSBPMG632 Learner Guide V1.04.22 Page | 65

 ▪ Commodity Price Risk – includes fluctuations in the prices in the market that could
potentially result in financial losses for either commodity buyers or the producers.

Due to the dynamic risk environment in the implementation of risk management, it will always be
beneficial to look back at your plans and program objectives. This way, you will be able to anticipate
how much further damages can affect your program or how much of your program you are still
likely to save by taking a different course of action.

Reviewing progress, analysing variances and initiating risk responses are risk management
components that will be able to help you and your team anticipate and address such changes.

2.2.1 Risk Reviews

As the program manager, you must conduct risk reviews regularly with the risk owners, program
team and other relevant stakeholders to review progress. This is because changes will occur as you
implement your program. As such, risk reviews are essential to the success of the program because
they involve establishing proactive (as opposed to reactive) processes that aim to constantly
monitor current and emerging risks to ensure that you are taking the right route. Other goals of risk
reviews include, but are not limited to the following:

determine whether the established risk management process remains sufficient,

suitable and effective in both design and operation

determine whether the agreed risk treatments resulted in what was planned

obtain further information to improve risk assessment

analyse and learn lessons from events, changes, trends, successes, and failures

detect changes to the nature of risks

reveal which risks will require further action

identify emerging risks

identify lessons and knowledge that can be carried over for managing risks in future
programs.

BSBPMG632 Learner Guide V1.04.22 Page | 66

Risk review processes tend to vary across different programs and organisations. Here are some of
the tools and techniques that you can use to establish your risk review process, depending on the
needs of your organisation:

▪ Risk reassessment – involves updating the risk register by evaluating current risks and
determining which of these risks are already outdated, meaning that they are no longer
threatening the program and should, therefore, be closed. In this technique, new risks and
their associated impacts on the program are also identified.

▪ Risk audit – is an exhaustive review that involves a task-by-task or risk-by-risk analysis. It is

mainly concerned with documenting risk treatments and determining whether they are
effective in managing the risks and their root causes. To do this, you need to come up with
the assessment criteria and a scoring system, such as a range of one to ten or excellent to
inadequate. In some cases, interviews with program team members and stakeholders may
be conducted to gather evidence.

▪ Trend analysis – involves quantitatively reviewing what occurred over a specific period and
forecasting future outcomes based on the results. This helps to determine whether
performance is improving or deteriorating with the current risk treatments. Trend analysis
is commonly used together with variance analysis, often using the same metrics and
standards.

▪ Technical performance measurement – is used to measure risks by analysing the technical

measures of performance that could affect your project and then comparing them to the
actual results during project implementation. If the actual results fall below the expected
performance, then there might be a need to assess the reasons behind these and determine
if an alternative approach is needed. When selecting technical measures, remember that
these should be objective and quantifiable. Examples include transaction times, response
time, and the number of errors per a thousand entries.

Based on Technical performance measurement. © 2021 Project Management Knowledge.

▪ Reserve analysis – involves examining the two kinds of reserves:

o Contingency reserve– is the amount reserved to address identified risks. For

example, a project team member might estimate that certain program activity will
take five days but would state that it might take nine days to account for risks. In this
case, the extra four days are considered the contingency reserve.

o Management reserve is the amount reserved for unidentified risks that still fall
within the scope of the project. Typically, the management is responsible for
controlling the management reserve. As such, as the project manager, you must seek
permission to use this reserve when unidentified risks occur.

Based on Contingency reserve vs management reserve. ©© 2020 PM Study Circle.

BSBPMG632 Learner Guide V1.04.22 Page | 67

2.2.2 Analyse Variances

Variance analysis involves quantitatively determining the degree of difference between the actual
outcomes against perceived (planned) results. For instance, if you want to analyse cost variance in
your program, you need to compare the planned activity cost with the actual cost incurred.
Analysing or examining the outcomes of the risk treatment implementations will help you
understand any variances between the before and after treatment state of the risks.

Variance analysis is commonly used to perform the following:

▪ examine if the implementation of the risk treatments was as per the plan

▪ determine the timeliness of the implementation of risk treatments

▪ ensure the effectiveness of the implementation of the risk treatments

▪ determine the new risk rating of residual risks based on the current state of implementation

▪ determine the variance against the revised risk rating.

It is important to keep in mind that there is no single variance analysis formula for all examinations
because it will highly depend on the type of variable you will be analysing.

The main variance analysis formulae that you can use for different program risk scenarios are as
follows:

Variance Variance Formula

Standard Cost – Actual Cost = (Standard Quantity x Standard

Material cost variance
Price) – (Actual Quantity x Actual Price)

Standard Wages – Actual Wages = (Standard Hours x

Labour variance
Standard Price) – (Actual Hours x Actual Price)

Fixed overhead variance (Actual Output x Standard Rate) – Actual Fixed Overhead

(Budgeted Quality x Budgeted Price) – (Actual Quality x

Sales variance
Actual Price)

Note: Variance analysis can be used in many aspects of the program, but variances are most likely
found in budget and productivity risks.

BSBPMG632 Learner Guide V1.04.22 Page | 68

In your workplace, the above variances and variance formulas can be done using software like Excel.
However, suppose you and your organisation wish to analyse variance without the help of any
software. In that case, you can always opt for the standard Analysis of Variance method, widely
known as the ANOVA test, by simply doing the following:

1. Find the mean for each group that you are comparing.

2. Calculate the overall mean, which is the mean of the combined groups or variables.

3. Calculate the within-group variation or deviation of each score from the group mean.

4. Find the between-group variation or deviation of each group mean from the overall mean.

5. Find your F-ratio, or ratio of between-group variation to within-group variation.

Further Reading

Investopedia is a financial website from New York City. They have

already released more than 32,000 articles covering business
insights, investments, advice and more business-related articles.
Below is a link to an Investopedia article that outlines what ANOVA is
and how it is done. You can use this information as a reference for
reviewing progress using the ANOVA analysis tool in your
organisation.

Analysis of Variance (ANOVA)

BSBPMG632 Learner Guide V1.04.22 Page | 69

2.2.3. Initiating Risk Responses

Changes in your risks mean initiating new appropriate risk responses that match the situation of the
new risk environment. If the changed environment results in a higher risk, you may have to treat
the concerned risk once more depending on the threat it still poses to your program. On the other
hand, if it results in a lower risk, you may have to examine whether there is still a need to continue
responding to that risk.

Initiating a risk response simply means creating a risk response plan. A risk response plan involves
the process of:

▪ risk identification

▪ risk analysis

▪ assigning risk controls or risk treatment.

In other words, you will be simply identifying and assessing the risks once more to assign a new risk
treatment plan for the risk that has already gone through previously planned controls. You may
review Chapter 1, Section 1.1, on which techniques and tools to use to identify risks and revisit
Section 1.4 for the discussion on how to analyse risks.

In general, below are steps to undertake to initiate a risk response:

Examine the existing risk responses.

Decide on the next step according to the results of the examination.

Submit the decision to the management for final review and approval.

BSBPMG632 Learner Guide V1.04.22 Page | 70

 1. Decide on the next step according to the results of the examination.

The existing risk responses in your organisation may involve any of the following risk
treatments:

Escalating Avoiding Transferring

Mitigating Accepting

▪ Escalating – involves passing the responsibility to a higher position or expert. No

future actions will be required from you except to record the changes in the risk
register.

▪ Avoiding – involves completely removing the risk from a project.

▪ Transferring – involves shifting the impact of the threat and ownership of the
response to a third party, usually in the form of premiums or insurance.

▪ Mitigating – involves reducing the probability of the risk and its negative impacts
until the acceptable risk threshold is achieved.

▪ Accepting – involves implementing either a passive risk acceptance which requires

no further action aside from documenting the risk, or an active risk acceptance
which requires further action, such as developing a contingency plan.

BSBPMG632 Learner Guide V1.04.22 Page | 71

 2. Decide on the next step according to the results of the examination.

Once you have examined your current risk responses, you must now identify the
appropriate step to take next. You may choose any of the following:

▪ Make no changes to the risk responses if they are still considered suitable for the
changed environment

▪ Change some aspects of the risk responses following certain conditions.

▪ Change the risk response completely.

3. Submit the decision to the management for final review and approval.

You must submit the proposed decision to the management for final review and approval.
The management may come to any of the following resolutions:

▪ Reject the decision.

▪ Request more information regarding the decision.

▪ Approve the decision in its entirety.

▪ Approve the decision subject to conditions specified by the management.

▪ Approve certain aspects of the decision and reject the others.

BSBPMG632 Learner Guide V1.04.22 Page | 72

2.3 Confirm Risks are Monitored and Assessed Across the Program at Agreed
Intervals

As established in the previous section, it is inevitable for new risks to emerge and existing risks to
disappear throughout the life cycle of a program. You must monitor and regularly assess records
and documents that contain identified risks to guarantee that you can keep track of all information
regarding the program risks and communicate this information to the rest of the team.

As the program manager, you are also responsible for ensuring monitoring and assessing risks across
the program is at an appropriate frequency. Consider your relevant stakeholders’ opinions on this
matter and decide on an agreed interval for monitoring and assessing risks in your program. Set
deadlines and fixed dates (e.g., weekly, monthly, quarterly reporting) to report and update
documents. For example, a program manager may ask the team members to report their daily
accomplishments using a spreadsheet, email, or even filing a specific organisation-tailored
document. Generally, risk monitoring and assessment are conducted:

▪ at the beginning of the program’s life cycle

▪ after risks have been identified and assessed

▪ specific times throughout the program as needed to track new risks

▪ at the end of the program’s life cycle.

BSBPMG632 Learner Guide V1.04.22 Page | 73

2.3.1 Circumstances That Need Monitoring and Assessment

Systematic risk monitoring and assessment are crucial to an effective program of risk management.
Doing this will keep you, your team members, and stakeholders up to date with the essential
changes as you move forward in different management process phases. It is important to recognise
when monitoring and assessment are needed as the nature of your risks changes. Below are
examples of circumstances that may prompt assessment and monitoring:

▪ The risk no longer exists

Monitoring and assessment must be done periodically because the risk might no longer be
present. This can occur if the resources to be used or the processes to be followed are
changed. For example, choosing to source a certain material from outside the state will cause
delays in the delivery, so the material was sourced locally instead.

▪ The probability of the risk turning into an incident has changed

Monitoring and assessment must be done periodically because the risk always changes. For
instance, the cost of resource X at the project's planning stage was stable and, therefore,
easy to predict. However, as the program has progressed, global resource X prices have
become very volatile. This increases the probability of the risk occurring.

▪ The risk may not have been relevant in the earlier stages of the program but will be critical
in a later stage

Monitoring and assessment must be done periodically because the risks may appear without
you noticing. For instance, you may not have to worry about the risks of working under
extreme conditions (e.g., dehydration and heatstroke of workers) during the summer now.
Still, you will have to consider these later on as the project proceeds and the season changes.

▪ The people responsible for the risks may have changed

Monitoring and assessment must be done periodically because the owners of risks also
change or risks get transferred. For instance, a project team member may have left and have
been replaced, or the assignment of responsibilities may have changed within the team.

▪ A better solution for managing the risk has been found

Monitoring and assessment must be done periodically because the solution for the risks may
also change. For instance, a risk that has been managed through the use of PPE can now be
managed through substitution by replacing the old equipment with a new machine that has
only very recently become available. Aside from this, better processes may have also been
adapted by the organisation.

BSBPMG632 Learner Guide V1.04.22 Page | 74

2.3.2 Confirming Risks are Monitored and Assessed at Agreed Intervals

Normally, risk monitoring and assessments are conducted using either:

▪ face-to-face meetings

▪ written correspondence (e.g., emails).

In any way, the steps on how you can confirm risks are being monitored and assessed at agreed
intervals will be discussed below.

Gather evidence of risks monitored and

assessed

Review evidence

Confirm whether risks were monitored and

assessed

Respond to findings and document outcomes

1. Gather evidence of risks monitored and assessed

The first thing that you can do is refer to the risk register to identify the owner of risks in the
risk register. You may also confirm whether the risk owner remains the same or if the
ownership has been delegated to a new risk owner. Then, you can start asking the
appropriate stakeholder for evidence of risks being monitored at agreed intervals. For
example, you can ask your project officer for the updated risk audit on a monthly basis to
review changes that would require further action plans to be applied.

2. Reviewing evidence

Next, review the evidence from relevant documents (e.g., risk audit, risk assessment) so that
you can act promptly if the nature, potential impact, or likelihood of the risk goes outside
the organisation’s risk tolerance level.

BSBPMG632 Learner Guide V1.04.22 Page | 75

 3. Confirm whether risks were monitored and assessed

Then, confirm the progress and development of tasks using various platforms to
communicate with the relevant stakeholders. For example, you respond appropriately to
feedback and answer any questions raised to support team members carry out tasks
effectively.

4. Respond to findings and document outcomes

Then, you will respond to the findings of reviewed relevant monitored and assessed risks at
agreed intervals. For example, you will praise relevant stakeholders for monitoring and
assessing risks during designated house meetings or clarifying the requirements with
stakeholders weekly through stand-up meetings. Lastly, record outcomes of the review
relevant to risks being monitored (e.g., meeting minutes) to document what has transpired.

BSBPMG632 Learner Guide V1.04.22 Page | 76

2.4 Direct Response to Actuated Program Risk and Confirm Remedial Actions are
Authorised With Impact Analysis According to Program Objectives

Actuated program risks refer to those that have gone through the initial application of agreed-upon
risk management controls. Many things can happen after the implementation of the planned risk
controls. Ideally, you will want risks to be avoided or mitigated after the application of controls.
However, it is also possible that the risks remain or even change in nature. Either way, the course
of action on actuated program risks is generally divided into two: to apply further remedial actions
or to close the program task because the initial risk control proved to be effective.

To help you and your stakeholders decide which risk treatment would be most suitable for the new
nature of the risk, bear the following in mind:

▪ program objectives

▪ organisation’s risk tolerance and appetite.

Meanwhile, the following are considerations when applying a response to program risks:

▪ due date for implementation of remedial action

▪ risk owner for each risk

▪ initial rating of risks before actions are implemented

▪ estimated revised risk rating after remedial actions are in place

▪ remedial actions to be implemented.

BSBPMG632 Learner Guide V1.04.22 Page | 77

Remedial Actions (Risk Response)

Remedial actions are risk response strategies commonly used to control actuated. These actions
intend to remove, control, or lessen the impact of actuated risks on a program. Generally, you can
apply remedial actions to address risks as you deem fit so that the risks no longer pose an immediate
threat to the established objectives of your program. Just like your initial risk response plan to newly
identified and assessed risks, your remedial action plan will also employ risk treatments to control
risks further. Below are the risk treatments you can use to respond to actuated program risks as
part of your remedial action.

Escalate Mitigate Transfer

Avoid Accept

▪ Escalate

Risks beyond your knowledge, means and control would require you to use the escalate
response strategy. You normally pass the responsibility to a higher position like your project
sponsor or expert. It is important that you report risks that are beyond your control early
and often so that the people who will be taking responsibility for the risk can be given extra
time to react to the threat. No future actions will be required from you nor from your
subordinates except to record the changes in the risk register.

An example of a risk that may need escalation would be a newly passed government law that
you know you and your immediate team have no jurisdiction over.

▪ Mitigate

Moderating the severity of risk would require you to use the mitigate response strategy. For
example, a supplier backs out near the execution date of your program. To reduce the impact
of the unfortunate occurrence, you find a new supplier that provides the same quality of
products for a slightly higher price. The new supplier may be more costly, but it will be cost-
effective to ensure you have a supplier than lose customers because of failing to provide
orders.

BSBPMG632 Learner Guide V1.04.22 Page | 78

 ▪ Transfer

On the occasion that you find yourself not suited to manage risks because you either lack
the skills, resources, or time to do it, you could use the transfer response strategy. As the
name implies, you simply transfer the action that needs to be done of the risk to a third party
without eliminating the risk.

The common examples of this are insurance. An organisation may purchase property
insurance to gain financial protection over resources or equipment damages in the event a
fire breaks out.

▪ Avoid

Completely eliminating the risk and its impact would require you to use the avoid response
strategy. You normally resort to this strategy for risks that would cause grave damage to
your program or organisation.

▪ Accept

The accept response strategy does not require you to do anything but acknowledges minor
risks, positive or negative. This is only done if there are no practical responses to the risk.

Sourced from A Guide to the Project Management Body of Knowledge (6th Edition).

Impact Analysis

Impact analysis seeks to illuminate the pros and cons of the changes in your program. It is performed
to review your actuated risks against your overall program objectives. In your workplace, it is done
through discussions or brainstorming meetings together with relevant stakeholders.

In general, the steps on how you can perform impact analysis are listed below.

Review the change

request and check its Identify the effects of Identify the change
feasibility in yuor the change request. request’s priority.
current system.

Identify the sequence

Analyse further and
to perform the task
document the
and how to relate it
outcome.
with the current one.

BSBPMG632 Learner Guide V1.04.22 Page | 79

 1. Review the change request and check its feasibility in your current system.

A change request is a document normally used to present the changes you or other
stakeholders want to implement for remedial actions on the current plan. This document
must be pulled up and discussed with relevant stakeholders to check if the proposed changes
are achievable within your system’s capacity.

2. Identify the effects of the change request.

Run a risk assessment on the change request together with relevant stakeholders.

3. Identify the change request’s priority.

Review your program objectives to confirm whether the change request’s goal is considered
a priority in your set objectives.

4. Identify the sequence to perform the task and how to relate it with the current one.

Prioritise which tasks must be done first and ensure it does not overlap with the current
action plans.

5. Analyse further and document the outcome.

Ensure the change request has been properly reviewed and assessed, then document the
outcome using your organisation’s preferred logging document. An example document that
you may use is the change register.

Awesome Landscapes

Awesome Landscapes Pty Ltd completes a change request

document to appeal for changes in the current plan and a change
register to record all the changes that transpired after much
discussion with relevant stakeholders.

Access and review Awesome Landscape’s change register through

the links below:

Change Request Document

Change Register

Username: lexislearner

Password: lexis@123

BSBPMG632 Learner Guide V1.04.22 Page | 80

Lastly, you must submit the proposed decision to the appropriate stakeholder for final review and
approval to confirm whether remedial actions are authorised and approved by relevant
stakeholders. An authorised and approved remedial action may possess any of the
recommendations listed below:

▪ Contains action plans that authorised stakeholders have reviewed

▪ Endorses action plans that authorised stakeholders have collectively agreed with

▪ Clearly states the action plans that must be performed confirmed via written or verbal
confirmation

Checkpoint! Let’s Review

1. The biggest advantage of a comprehensive and concrete risk
management strategy agreed upon by relevant stakeholders
is that you gain assurance in how you and your team can direct
your program risk management towards achieving your
organisation’s objectives.

2. Due to the dynamic risk environment in the implementation

of risk management, it will always be beneficial to look back at
your plans and program objectives. This way, you will be able
to anticipate how much further damages can affect your
program or how much of your program you are still likely to
save by taking a different course of action.

3. It is inevitable for new risks to emerge and existing risks to

disappear throughout the life cycle of a program. You must
monitor and regularly assess records and documents that
contain identified risks to guarantee that you can keep track
of all information regarding the program risks and
communicate this information to the rest of the team.

4. It is likely that risks remain or even change in nature while

implementing the planned risk controls. Risks are then
addressed either by applying further remedial actions or
closing the program task because the initial risk control proved
effective.

BSBPMG632 Learner Guide V1.04.22 Page | 81

3. Assess Program Risk-Management Outcomes

In the previous chapter, you have learned how to put your plan into action. You learned how to
monitor and respond to program risks in real-time using an established risk management system
backed up by your risk management plan so that your organisation can impose timely solutions in
controlling risks.

After actuated risks have been identified and assigned a new remedial plan, it is recommended to
review and monitor risks continuously. The review and monitor phase aims to put together all
relevant data employed and acquired during the entire risk management process to produce a string
of documented data that can be used for future programs.

In this chapter, you will learn to review feedback on the risk-management methodologies used to
manage program risks so that the organisation can draw lessons from the effectiveness of the tools,
techniques or methodologies used in your program. Doing so will allow you to develop insights into
the strengths and weaknesses of your risk management process. The knowledge that you gain from
assessing the risk management outcomes is essential in ensuring the success of the projects that
you will undertake in the future.

This chapter will give you a clearer idea of assessing program risk-management outcomes through
the following measures:

▪ identify and document residual program risk and communicate to stakeholders any
transferred liability at program completion

▪ review and analyse program outcomes to assess the effectiveness of the risk-management
methodology

▪ seek feedback and respond to relevant stakeholders on risk management

▪ analyse, document and recommend lessons learned for application in other programs.

BSBPMG632 Learner Guide V1.04.22 Page | 82

3.1 Identify and Document Program Residual Risk and Communicate to Stakeholders
any Transferred Liability at Program Completion

As mentioned in Chapter 1, Section 1.1, residual risks are simply risks that remain after planned
controls have been taken. Even after filtering out all risks you deem unacceptable (e.g., mitigate
risks, avoid risks), with the help of your risk treatment plan, you will not be able to eliminate risks
entirely because it is simply impossible. It is important to identify them so you can further assess if
such risks still pose a threat to your program or not. Assessing residual risks will once again require
employing a risk management process that you may or may not have used in the early stages of the
overall risk management. It is vital that residual risks are properly documented and updated to avoid
confusion or mixing up residual risks with the new potential risk that have possibly shown up only
later in the process.

BSBPMG632 Learner Guide V1.04.22 Page | 83

3.1.1 Identification, Treatment and Documentation of Residual Risks

Residual risks are easy enough to identify. They are simply risks that remain after risk controls have
been implemented. In essence, the tools and techniques often used to identify general types of risks
can also be utilised to identify residual risks. What is vital in managing residual risk is the assessment
of whether it is still an immediate threat to your program and therefore needs further action. Your
goal is to assign a new risk impact on the residual risk because only then will you be able to decide
on an action to address it again.

To assign a new risk impact on the residual risk, you may use a risk matrix again. See Chapter 1,
Section 1.3.2, to review the discussion on the use of the risk matrix.

Treatments for Residual Risks

After new risk ratings are assigned to residual risks, you will be able to tell which ones to prioritise
and which ones need further treatment. You will assign a new risk treatment that you and the
organisation believe is the most suitable solution to the risk. Review Chapter 2, Subchapter 2.4 for
the discussion on risk treatments, which are namely:

Escalate Mitigate Transfer

Avoid Accept

BSBPMG632 Learner Guide V1.04.22 Page | 84

Documenting Updates on the Risk Register

Finally, log every minor and major change to the risks in the risk register. As established in the previous chapters, a risk register is an important
document that you will be accessing throughout the planning, implementing, and reviewing phase of your program. To ensure your risk register
is dynamic, you must keep it updated each time new developments to the program risk management arise. Below is an example risk register
template with updated fields to accommodate new information.

Revised Revised
Likelihood of Consequence Risk Risk
Date Risk Risk Risk Likelihood of Consequence of Revised New Risk New Risk
ID the Risk if the Risk Treatments prevention
Identified Description Impacts Owner the Risk the Risk Risk Rating Treatments Owner
Occurring Occurs strategies
Occurring Occurring

Now, these are the following components that need updating:

▪ New risks identified

This could mean either new potential risks arising from an unforeseen and unplanned situation or residual risks have adapted to a new
risk level because it has been mitigated or previously addressed.

▪ Risk treatments

Update the risk treatment of the identified residual risks that all relevant stakeholders have decided on.

▪ Revised likelihood of the risk occurring

This means that the possibility of the risk happening may have changed and would need to be updated accordingly.

BSBPMG632 Learner Guide V1.04.22 Page | 85

 ▪ Revised consequence if the risk occurs

The impact or consequence of the risk occurring may have changed. The impact may have
changed to negligible, minor, major or even catastrophic.

▪ Revised risk rating

The assessment of the risk may have been changed to either low, medium, or high risk

▪ Risk Owner

It will help clarify risk responsibilities so that risks can be followed up with the correct
stakeholders at regular intervals. This is only updated when there is a need to transfer the
liability to a different stakeholder.

▪ Use a new version number

It will be helpful to use a different version number to help you distinguish the updated risks
from the older identified risks. Or you can also put the date of the latest revision to
distinguish versions.

Note: You may opt not to include all the components listed above. However, it is a given that once
new risks are identified, all the other columns or details that a risk register demands from a risk
must also be filled up (e.g., risk owner, risk description, etc.) and should not be limited to updating
the risk level only.

3.1.2 Communicating Transfer Liability to Stakeholders

In some cases, residual risks are instead transferred. It could be transferred in the essence of:

transferring risk transferring liability of transferring liability of

ownership and risk to a different risk to a third party due
responsibility to another organisational to the lack of expertise
stakeholder department in the organisation.

Either way, it is important to communicate the updated residual risk solution, especially transferring
of liability, to the relevant stakeholders. Doing this will keep them abreast with the changes in the
risk management plan.

BSBPMG632 Learner Guide V1.04.22 Page | 86

The implications of transferred liability will be different for every stakeholder. Just like how you have
been open and transparent to the stakeholders in the planning and development stage of the risk
management system, you should be honest and communicate with your stakeholders regarding
transferred liability. Doing this will be beneficial to your program as this would promote
transparency and foster a good relationship among the program team members and relevant
stakeholders.

Generally, the stakeholders concerned with the transfer of risk liability are:

program participants
program sponsors and
(team members and
company owners
project officer).

Ways in which you can communicate with your stakeholders include:

scheduling a face-to- sending out a

face or online meeting newsletter.

The ways in which you can communicate transferred liability to stakeholders include:

spending sufficient time communicating

managing expectations

accepting feedback graciously (See Section 3.3 for further

discussion on seeking and receiving feedback.)

giving feedback constructively

asking and listening

BSBPMG632 Learner Guide V1.04.22 Page | 87

3.2 Review and Analyse Program Outcomes to Assess the Effectiveness of the Risk-
Management Methodology

The common misconception about risk management is that the process ends when all of the steps
— from risk management planning and risk identification until risk monitoring and controlling —
have been implemented. Reviewing the project outcomes once the program ends is a part of the
process that is usually forgotten. However, this step must be undertaken because this will help you
determine whether your approaches were able to give you the results you want and identify the
issues and problems you encountered in implementing these approaches. This will guide you in
developing a better risk management plan for your future programs, as discussed in the next
subchapter of this Learner Guide.

Analysing Program Outcomes

There are various considerations to take note of in analysing program outcomes. Different
organisations employ different strategies, methods and techniques to do this. Regardless of how
different industries and organisations perform it, you can analyse program outcomes by following
the generic process below. The list of considerations for analysing program outcomes is as follows:

1. Defining objectives involves reviewing your goals and objectives so that you will be able to
ask the right questions when setting up a discussion or meeting with your stakeholders to
understand if the processes and procedures you have used for your program are effective.

Note: You can start reviewing the objectives of our organisation per category or department
so that it will not be overwhelming as opposed to reviewing everything at once.

2. Data gathering aims to answer the questions you have previously set up in the first step.

3. Data analysis can be done by inputting data gathered and measuring it against the defined
objectives.

4. Data evaluation aims to examine through data that the processes and procedures used are
effective and continue to promote growth. That is why it is always recommended to regularly
perform an analysis of program outcomes.

BSBPMG632 Learner Guide V1.04.22 Page | 88

Reviewing Program Outcomes

Ultimately, risk management aims to allow the program to most efficiently and effectively progress
toward its target outcomes. As such, one way by which you can determine the effectiveness of your
risk management methodology is to measure the program outcomes against the agreed key
performance indicators (KPIs). The KPI is a type of measurement that reveals whether an
organisation, a program, or a task has successfully achieved its objectives. Like variance analysis, it
helps you determine your progress toward achieving program goals (See Chapter 1, Subchapter 1.6
for a review on variance analysis.) They are typically found in the risk management plan. However,
in some cases, they are created separately from these documents.

The KPIs will differ according to what was agreed upon by the program team members,
management, and stakeholders. However, to determine the effectiveness of your methodologies as
accurately as possible, the indicators that you choose must generally be:

clear

well-defined

measurable

achievable

Although KPIs can be used to measure other factors other than those shown below, you can
generally categorise them into the following to review and determine whether the processes used
were sufficient:

▪ Timeliness

This involves comparing the estimated time of completion of each program activity and the
actual time taken. One example by which timeliness can be measured is by looking at the
deviation from the schedule (e.g., number of days of delays or number of days of lead time).
A program can be said to be successful in terms of timeliness if there is little to no deviation
from the projected schedule. Another example is by looking at the percentage of activities
that were completed on time.

▪ Budget

This involves a comparison between the estimated cost of the program and the actual cost.
If the deviation from the expected cost is huge, then this may be a sign that there were
additional costs due to risks that you were not able to anticipate.

BSBPMG632 Learner Guide V1.04.22 Page | 89

 ▪ Quality

This involves looking at how well the program has progressed in accordance with the goals
that your organisation set. This covers a wide range of indicators, depending on what is
being measured, such as:
o number of complaints to determine customer satisfaction
o number of regulatory requirements complied with
o number of errors committed to determining the quality of work of employees

▪ Effectiveness

This involves looking at how the resources are being used in your program and whether
they are being managed properly to achieve your goals.

Some examples include:

o number of encountered risks that you were able to identify versus those that you
were unable to identify to determine the effectiveness of your risk identification
method
o number of project milestones completed
o number of change requests from the clients.

Reviewing Program Outcomes With Relevant Stakeholders

When reviewing the program outcomes using the KPIs, you must remember to communicate and
consult with the program team members, including the relevant stakeholders and risk owners.
They will bring with them their personal experiences and insights during the implementation of the
project, which will help you get a better picture of the risk management processes and procedures.

Aside from helping you track the progress of your project, KPIs also identify which aspects of the
program you have done well in and which ones you need to improve on. For example, a large
deviation from the expected deadline will tell you that your program encountered issues in terms
of timeliness. On the other hand, if you only had a few client complaints, then this indicates that
you were successful in keeping your clients satisfied.

Once you have identified the issues and problems you encountered in your program, you can
consult with your team to discuss the reasons behind the issues and problems you encountered in
your program. For example, the reason behind the delays in your program tasks may be due to the
lack of an efficient communication system or an unreliable supplier of resources.

Consulting with your team will help you get different perspectives that will allow you to develop
your recommendations better. These recommendations can be used as references for future
programs.

BSBPMG632 Learner Guide V1.04.22 Page | 90

3.3 Seek Feedback and Respond to Relevant Stakeholders on Risk Management

Feedback is a response to an outcome or an individual’s performance of a task that is normally used

as a basis for improvement. Seeking feedback is a good way to gauge whether expectations have
been met or if there are areas that might still need further improvement. Feedback can either be
received or given in the following ways:

conversations; both formal and informal

issue identification and discussion

meetings

progress reporting

surveys

Sourced from A Guide to the Project Management Body of Knowledge (6th Edition).

BSBPMG632 Learner Guide V1.04.22 Page | 91

When seeking feedback, it will be beneficial to reach out to the relevant stakeholders of your
program, such as your program sponsors, project managers and the team members who are also
the risk owners. This will help you get a good grasp of the program’s risk management effectiveness
in managing your organisation’s program risks. Most of the time, you get feedback to gain insight
on the following:

▪ risk management methodologies used

▪ risk assessment tools used

▪ risk management standards used

▪ risk management frameworks used

▪ risk management systems used.

Guidelines on Seeking Feedback From Relevant Stakeholders on Risk Management

The end goal of seeking feedback from relevant stakeholders on risk management outcomes is to
assess whether the program risk methodologies, tools, frameworks, systems, and standards used
were appropriate and adequate for your program.

You can ask stakeholders to share their experience of using the following risk methodology tools or
documents:

risk
risk analysis
risk register risk matrix management
process
systems

risk organisational
risk treatment
identification Internal
process
process standards

Then seek feedback by following the guide questions below:

▪ Were they suitable?

▪ Were they fair and reliable?

▪ Were they relevant? Were they useful?

▪ Were they effective?

BSBPMG632 Learner Guide V1.04.22 Page | 92

Finally, you can ask participating stakeholders to relay feedback:

▪ verbally (e.g., stand-up meetings and house meetings)

▪ non-verbally (e.g., feedback with rating systems).

Responding to Feedback

Seeing as you will be speaking to different stakeholders from different departments, it is important
to keep in mind to always be courteous when giving feedback. For more information on how you
can go about giving feedback, bear the following steps in mind when you receive feedback:

Acknowledge the feedback.

Respond to feedback using industry-accepted

terminology as appropriate to the stakeholder.

Respond to feedback by asking follow-up

questions.

▪ Acknowledge the feedback.

For example, thanking the individual for sharing their experience regarding the risk
identification process is one way of acknowledging feedback.

If in another scenario where a team member is expressing their frustration with you because
of program activity, still acknowledge this feedback and do so politely.

▪ Respond to feedback using industry-accepted terminology as appropriate to the

stakeholder.

This is because the terminology that you will be using to explain concerns to the IT staff will
not be the same as when you explain plumbing concerns to the plumbing crew.

▪ Respond to feedback by asking follow-up questions.

Some feedback can be vague. It is important that you ask questions so that you will be able
to determine the root cause of the issue. This is also so that you can respond to the feedback
with the necessary details as well.

BSBPMG632 Learner Guide V1.04.22 Page | 93

3.4 Analyse, Document and Recommend Lessons Learned for Application in Other
Programs

Before programs come to a close, a lessons learned register must be completed. The lessons learned
register is a document that collects all the learnings you and your team have gained from performing
the program. Even though the lessons learned report is officially done near the completion of the
program, collection and documenting of important information regarding methodologies,
techniques and tools used may be done throughout the program risk management process.

The importance of documenting such learnings is to:

▪ show the commitment of the management to developing a better risk management plan for
the organisation to prevent the recurrence of undesirable outcomes

▪ ensure that the information regarding processes and policies is accessible to future project
managers

▪ prevent the same mistakes from being committed

▪ ensure the continuity of the best risk management practices of the organisation

▪ serve as the basis for the improvement of risk management of future programs.

BSBPMG632 Learner Guide V1.04.22 Page | 94

3.4.1 Analysing Lessons Learned

The analysis of lessons learned is simply a discussion of the learnings acquired throughout the life
cycle of the program. This discussion will no longer be of any effect to the current program as this
is normally done before the program brings to a close. This is formally done in order to talk about
improvements or change initiatives for the upcoming programs instead.

Discussions in the analysis of lessons learned are normally headed by program managers together
with other stakeholders. You, as the program manager, will be the one facilitating the meeting,
which seeks to ask the following common questions asked during lessons learned analysis:

What did we expect What actually What worked well

to occur? happened? and why?

What did not work What needs to be

and why?. done differently?

During the discussion, your main goal is to:

▪ Identify program successes.

This involves the program or organisational objectives that were successfully met by the
end of the program.

▪ Identify program failures.

This involves the program or organisational objectives that were not successfully met by
the end of the program.

▪ Identify recommendations for future improvement.

This involves the experience-derived opinion of stakeholders regarding what they think
must be done if a similar occurrence in a different program transpires.

BSBPMG632 Learner Guide V1.04.22 Page | 95

3.4.2 Documenting and Recommending Lessons Learned for Application in Future Programs

The goal of documenting a lessons report is for it to be recommended for future use. The format
of the documentation depends on the needs of the organisation. However, the documentation
must be clear and as detailed as possible. Below are the components of a generic lessons learned
template that you must note when documenting program learnings.

▪ Program identification – includes the program name, program ID, program start and end
date, and other important information on how you can identify this program the next time
you pull it up as a reference for future programs.

▪ Lessons learned identification – contains the name of the specific lessons you have gained
in implementing the program risk management plan. For proper recommendation of these
documents, the naming convention of the lessons learned must be in a way connected to
the program it is derived from. That way, lessons learned documents would not be mixed
up and mistakenly associated with an entirely different program. The date when the lessons
learned document was completed must also be provided.

▪ Process group – is normally presented in boxes that you can tick. You must specify whether
the lessons learned are documented in the planning, implementing or controlling or
concluding phase of the risk management.

▪ Risk management components – refer to all the risk management methodologies,

frameworks, tools, systems, techniques, etc. In documenting the risk management
components, you have used, be as detailed and specific about it. For example, If you used
a combination of tools for a certain risk management process, be sure that it is properly
logged in the lessons learned document.

▪ Relevant stakeholders – refer to who should be informed about the lesson log for future
programs. It can be addressed to the program executives, program managers, project
officers, or staff.

▪ Successes and failures – in essence, is a summary of the successes and failures that must
also be properly logged. This is for reference to the future stakeholders being addressed by
the documented lessons learned should they encounter a similar situation in the future.

BSBPMG632 Learner Guide V1.04.22 Page | 96

After completing this document, you can choose to upload the file in a workplace software where
relevant stakeholders will have access to it for proper recommendation and endorsement of the
document for application in future programs. Doing this is important because it emphasises a
commitment to the continuous improvement of risk management. Generally, when developing
recommendations, you must:

Identify which risk management approaches should be embraced or followed.

Identify which risk management approaches should be discontinued.

Identify which risk management approaches should be modified for

improvement.

Like in the previous section, this step must be undertaken together with the program team
members, relevant stakeholders, and risk owners to gain their perspective. This can be done through
meetings and consultations.

The recommended improvements must also be presented to the management for review and
approval. The management will ensure that the recommendations are still aligned with the
organisation’s current and future goals.

Awesome Landscapes

Awesome Landscapes Pty Ltd keeps a lessons learned document to

review whether previous risk management methods they used
were effective. Access and review Awesome Landscape’s lessons
learned document through the link below:

Lessons Learned Document

Username: lexislearner

Password: lexis@123

BSBPMG632 Learner Guide V1.04.22 Page | 97

 Checkpoint! Let’s Review
1. Residual risks are identified as the risks that remain after
planned responses have been taken. It is important to
identify them so you can further assess if such risks still pose
a threat to your program or not. Assessing residual risks will
once again require employing a risk management process
that you may or may not have used in the early stages of the
overall risk management.

2. Reviewing the project outcomes once the program ends is a

part of the process that must be undertaken because this will
help you determine whether your approaches were able to
give you the results you want and identify the issues and
problems you encountered in implementing these
approaches.

3. Seeking feedback is a good way to gauge whether

expectations have been met or if there are areas that might
still need further improvement.

4. An important document that must be completed towards

the end of the program is the lessons learned report, which
collects all the learnings you and your team have gained from
performing the program.

BSBPMG632 Learner Guide V1.04.22 Page | 98

References
Awesome Landscapes. (n.d.). Awesome landscapes. Retrieved August 12, 2021, from
https://compliantlearningresources.com.au/network/awesome-landscapes/

Bigger Than Big Corporation. (n.d.). Bigger Than Big Corporation. Retrieved August 12, 2021, from
https://compliantlearningresources.com.au/network/biggerthanbig/

Commonwealth of Australia. (n.d.). Risk management. Support for businesses in Australia. Retrieved
August 12, 2021, from https://business.gov.au/Risk-management/Risk-assessment-and-
planning/How-to-manage-risk

Piney, C. (2003). Risk identification: Combining the tools to deliver the goods. Paper presented at
PMI® Global Congress 2003—EMEA, The Hague, South Holland, The Netherlands. Newtown
Square, PA: Project Management Institute.

Project Management Institute. (2017). A guide to the project management body of knowledge
(PMBOK guide) (6th ed.).

Project Management Knowledge. (n.d.). Risk appetite. Retrieved August 12, 2021, from
https://project-management-knowledge.com/definitions/r/risk-appetite/

Project Management Knowledge. (n.d.). Technical performance measurement. Retrieved August 12,
2021, from https://project-management-knowledge.com/definitions/r/risk-appetite/

RAND Corporation. (n.d.). Delphi method. Retrieved August 12, 2021, from
https://www.rand.org/topics/delphi-method.html.

Shuttleworth, M. (2017, November 5). Risk prioritisation factors and considerations. Project Risk
Manager. https://www.project-risk-manager.com/blog/risk-prioritisation/

Thomas, N. (n.d.). What is a program risk methodology. Scope Training. Retrieved August 12, 2021,
from https://scopetraining.com.au/project-management/program-risk-methodology/

Usmani, F. (2021, July 18). Contingency reserve vs management reserve. PM Study Circle.
https://pmstudycircle.com/contingency-reserve-vs-management-reserve/

End of Document

BSBPMG632 Learner Guide V1.04.22 Page | 99