Overview of Risk and Issue Management Tutorial

Welcome to the Risk and Issue management tutorial offered by Simplilearn. The tutorial is a part of the MSP® Foundation and Practitioner course.

In this lesson, we will look into the governance theme, risk and issue management. Successful program management needs to manage uncertainty, complexity, and ambiguity, which is achieved through risk and issue management. We will also focus on risk management and issue management, the relationship between risk and issue management and transformational flow. It also covers the various roles and their areas of focus in risk and issue management. Let us begin with the objectives of this lesson in the next section.

Objectives

By the end of this tutorial, you will be able to:

• Define risk and issue

• List the sources of risk identification

• Explain the risk management perspectives

• Describe the steps involved in risk management framework

• Describe the various arrangements used in managing risks in a program

• Describe issue

• Identify the steps involved in the issue management framework

• Discuss threat and opportunity responses

• Explain configuration management

• Explain the relationship between transformational flow and risk and issue management

• Describe the roles of the Senior Responsible Owner, Program Manager, Business Change Manager and Program Office in risk and issue management

• Identify the documents used in the risk and issue management process

Let us move on to the next section to discuss the MSP® framework.

MSP Framework

In the MSP Framework diagram shown below, Risk and issue management is a part of governance theme and is positioned in the middle circle of the MSP® framework.

Risk and issue management ensure that the program can manage and tolerate uncertainty, complexity, and ambiguity.

It also helps in the achievement of program objectives. Let us look into the definitions of risk and issue in the next section.

Risk and Issue

The following are some important information about risk and issue:

Risk

Risk can be defined as an uncertain event or a set of events which have an impact on the achievement of the objectives. This effect need not be detrimental.

A risk can either be a threat, an uncertain event with a negative impact on benefits, or an opportunity, an uncertain event that could have a favorable impact on the objectives or benefits.

Risk should be described by including the cause of the risk, the event, which is the description of the threat or the opportunity and its effect which provides the summary of the likely impact on the program and its projects.

Issue

The issue can be defined as an unplanned event that has happened, which requires management actions. When risks actually happen, they become issues.

The aim of program risk and issue management is to support better decision-making through a good understanding of risks and issues and their likely impact.

In the next section, we will discuss the sources of risk identification.

Sources of Risk Identification

Risks can be identified from multiple sources. Some of the sources of risk identification are:

• Benefits management and transition activities, costs, scope, and timescales;

• Dependencies, constraints, assumptions, quality of operations, resources and program deliverables;

• Anything that cannot be resolved by the project, or issues common to more than one project, stakeholders, organization, program staff and third parties;

• Degradation of operational performance staff and third parties;

• Degradation of operational performance beyond acceptable levels.

• Risks can also occur due to the lack of knowledge of the team about the “as-is” or the current state, interim state and the desired end state of an organization.

• In addition, the risk may arise from organizational strategies, other projects and influence of external programs.

In the next section, we will understand the risk management perspectives.

Risk Management Perspectives

Programs also interface with other organizational perspectives like strategy, programs, projects and operational. To anticipate risks at an early stage and tackle issues appropriately, it is important to understand these perspectives and continuously evaluate them during a program’s life.

Following are some risk management perspectives; Let us begin with the strategic level perspective.

Strategic level

Strategic level changes can affect the program, its interdependencies with other initiatives, its outcomes and benefits realization.

The strategic level changes are driven by:

• The external factors, such as political, economic, social, legislative, environmental and technical,

• Inter-program dependencies,

• Internal political pressure, and

• Cross-organizational initiatives, including working with third party suppliers, can be grouped under this level.

The next perspective of risk management is program level.

Program Level

A program focuses on delivering benefits to the organization, which affects both internal and external stakeholders in a positive or negative way.

Risk management for a program must be designed to work across organizational boundaries in order to ensure that all different interests are accommodated and stakeholders are engaged effectively.

The principal areas of risk and issues within a program are driven by:

• Aggregating threats from projects,

• Lack of direction from leadership group,

• Lack of clarity about expected benefits and buy-in from stakeholders,

• The complexity of the outcomes,

• The complications associated with working across the organizational boundaries are also factors to be considered,

• Resource availability,

• Lack of certainty about funding and

• Unrealistic timelines that are risks to program delivery are included as well.

The third perspective of risk management is project level.

Project Level

Project outputs within a program help in delivering the program outcomes and benefits.

• It is important to focus on the risk and issue management on project perspective.

• Areas, where project risks and issues arise, include resource constraints, scheduling issues, and scope creep.

• If the project is unsure of what it is delivering, it may lead to risks and issues.

The fourth perspective of risk management is the operational level.

Operational Level

As projects deliver the outputs, the transition to new ways of working and new systems can lead to further sources of risk.

Areas that can be included in the operational level perspective are:

• The quality of benefit-enabling outputs from projects within program,

• Organisational and cultural issues,

• Transfer of outputs to operations and ability to cope with new ways of working.

• Further, risks can be identified in stakeholder support,

• Industrial relations and

• Resource availability to support changes.

In the next section, we will introduce the risk management process.

M_o_R risk management principles

The following are the M_o_R (read as M-o-R) risk management principles at a program level.

• Aligns with objectives, which means that risk management should be aligned with the strategies and objectives of the organization.

• Fits the context, which indicates that risk management should fit the context in which it is being applied.

• Engages the stakeholders, which helps in risk identification and mitigations.

• Provides clear guidance, as in, the risk management should provide clear guidance on how to manage risk.

• Risk management should inform the decision-making group about impending risks and their impact.

• Facilitates continual improvement, which means that risk management should be able to facilitate continual improvement in the way risks are identified and managed.

• Creates a supportive culture, that is, instead of blaming ‘who’ the emphasis should be more on ‘why’.

• Achieves a measurable value, which indicates that risk management should be able to return the measurable value in terms of benefits or avoid loses due to risks.

Application of these principles is necessary for the implementation of a good program risk management principle. These are informed by proven corporate governance principles and the international standard for risk management, that is, ISO 31000:2009(read as I-S-O Thirty-one thousand - Two thousand nine).

In the next section, we will focus on the risk management framework.

Risk Management Framework

Risk management framework comprises a cycle of steps that are repeated throughout the life of the program.

The following are the steps involved in the risk management framework. Let us begin with the first step, that is, identify.

Identify

Program risk management starts with the identification of uncertain events which are either threats or opportunities.

• The first activity is to explore the program context in an effort to understand the scope, objectives, assumptions, stakeholders and internal and external environment.

• This knowledge helps to identify risk methodically and devise the best possible countermeasures.

• The second activity is to identify risks, both threat, and opportunities and enter them in the risk register.

The second step is to assess.

Assess

Assessment of risk can be done in two steps:

• The first step is to estimate the threats and opportunities in terms of probability, impact, and proximity.

• The second step is to evaluate the net aggregated effect of identified risks on the program.

Evaluation is important for programs, where the risks in smaller projects can quickly aggregate to risks at the program level.

The next step is to plan.

Plan

The primary goal of this step is to prepare specific management responses to threats and opportunities that have been identified with an attempt to remove or reduce their impact.

• It is common for risk responses to be only partially effective and leave residual risk.

• It is important to analyze the impact of the residual risk as well, as the impact can be considerable.

The fourth step is implemented.

Implement

The goal of this step is to ensure that the planned actions for managing risks have been implemented and monitored to ensure their effectiveness. In case the responses are not as effective as planned, corrective measures need to be taken.

This step also has to ensure that risk owner and risk actionee should be identified in advance.

• The risk owner is responsible for management and control of all aspects of risks assigned to them including managing, tracking and reporting the implementation of selected actions.

• The risk actionee is responsible for implementing the risk responses. They support and take directions from the risk owner.

All the above-mentioned steps are supported by communicating and embed and review activities. Let us look into communicating first. The fifth step is to communicate.

Communicate

Effective communication is important for the identification of new threats and opportunities.

• This is an activity which is carried throughout the risk management cycle.

• Implementation of risk management is dependent on participation and participation, in turn, is dependent on good communication.

The final step is to embed and review.

Embed and Review

This step ensures risk management is appropriately and successfully handled within the program and across the organization. It must also ensure that the risk management strategy is being followed.

• It looks at each step of the framework to determine its contribution to the overall quality or risk management.

• It provides controls over the process with reviews and health checks to gain maximum value for the investment in risk management.

Managing Risks in a Program

Before the risk management cycle can operate, specific arrangements are made for managing risks.

Arrangements to manage risks in a program –

The following are the various arrangements used in managing risks in a program:

• Risk management strategy

• Risk appetite

• Tolerance thresholds

• Assumptions

• Early warning indicators

• Risk register

• Threats and opportunities

• Evaluating risks

• Risk aggregation

• Proximity and

• Progress reporting.

These are explained in detail in the forthcoming sections. Let us begin with the risk management strategy in the next section.

Risk Management Strategy

Risk management strategy is created and approved in ‘defining a program’ and describes the approach to risk management in a program.

The following are a few functions of risk management strategy:

• The risk management strategy should reflect the organization’s risk policies and process guidance. These may define the priorities to be observed by the program to ensure it is compliant with the organization’s risk governance arrangements. Building on corporate standards, the program has to set its own risk appetite and culture for managing risks.

• Risk management strategy should clarify how opportunities will be managed

• Describe how the interface with benefits management approach will be handled as defined in the benefits management strategy.

• Risk management strategy should clarify and explain how information flows will work in the program.

• It also manages project assumptions by defining how projects will manage their risks.

• It also defines how project, program, and operation work together to manage risks as described in risk management strategy, and ensures awareness of the risk impact and its response.

In the next section, we will discuss risk appetite and tolerance thresholds.

Risk Appetite and Tolerance Thresholds

The following are a few facts about risk appetite and tolerance thresholds. Let us begin with risk appetite.

Risk Appetite

It is the amount of risk that an organization is willing to accept. It helps in defining the tolerance levels. It is essential for a program to understand the corporate risk appetite to devise a successful risk management strategy, steer project risk activities and define aggregation and escalation rules.

Now, let us understand tolerance thresholds.

Tolerance Thresholds

It translates the risk appetite into guidelines that steer program and project behavior. Tolerance thresholds define the exposure to risks on one level that, if exceeded, requires escalation and reaction from the higher hierarchy.

In the following section, we will discuss assumptions, early warning indicators, and risk register.

Assumptions, Early Warning Indicators and Risk Register

Following are some important information about assumptions, early warning indicators, and risk register. Let us begin with assumptions.

Assumptions

Assumptions can be defined as-

• The boundary of the program or the projects in the business case and provide for uncertainties outside its immediate area of influence.

• Assumptions are the result of an uncertainty and should be treated as sources of risk.

• A false assumption can have serious effects on the program

• Each assumption should be recorded as a risk in the risk register

• It is always advisable to review project assumptions at the program level to ascertain if they should be treated as risks.

Next, let us discuss early warning indicators.

Early Warning Indicators

Early Warning Indicators can be defined as-

• Risk management needs to be proactive to anticipate potential problems. Early warning indicators provide advance warning of trends or events that can adversely affect the program’s outcomes.

• These indicators can be used to track sensitive risks.

• Some examples of these indicators are requests to change key program information, delays in delivery of expected or planned benefits, increase in aggregated risks, changes to organizational structure, services, and processes.

• Early warning indicators should be able to measure valid indicators, reviewed on a regular basis and they should use accurate information. This ensures that the early warning indicators are working effectively.

Next, let us discuss the risk register.

Risk Register

Risk Register can be explained as-

• A repository used to capture information on risks in a consistent and structured manner. It is created during ‘defining a program’.

• The risk management strategy defines the content and purpose of the risk register.

• Projects maintain their own repository

• Programs coordinate the activities with a separate register.

• The risk management strategy also defines how risks will be escalated from the project to program level.

In the next section, we will focus on threats and opportunities.

Threats and Opportunities

The following are a few facts about threats and opportunities:

• Risks are normally threats or negative impact on a program but some risks actually provide opportunities to improve a program’s outcomes. It means that such risks have a positive impact.

• The same event can have a different impact on different constituent projects.

• Also, the aggregation of threats or opportunities at the program level may change the resulting effects again.

• There can be multiple triggers for a single threat or opportunity. It is important to differentiate between the threat and opportunity to focus on risk response as both will have a different type of response.

• Risk management and benefits management can overlap in a scenario, where an opportunity becomes a potential benefit.

• It may not be possible to remove the threat or opportunity always, however, it might be possible to avoid or remove events that will trigger the risk.

Let us next focus on risk evaluation in the subsequent section.

Evaluating Risks

The uncertainty associated with risks is expressed as their probability of becoming issues that can potentially impact a program’s cost, time and benefits. Probability is defined as the chances of risk occurrence.

The following are different ways to evaluate risks in a program.

Probability Impact Grid

The main points under the probability impact grid are given as-

• The impact is the positive or negative effect of risk in a program.

• These impacts can be shown in the form of a probability impact grid, giving criteria to each level within a scale that is very high to very low.

• Probability and impact values can be attributed to these ratings so that the ranking values can be calculated for each cell of the grid.

Expected value

Expected Value is explained as-

• Expected value is a way of estimating the financial exposure of risks by discounting the total cost of their impact against the probability of their occurrence.

• It is calculated by multiplying the estimated average risk impact by the estimated probability to give a weighted risk.

Other Methods

The other methods that can be used to evaluate risk include:

• Estimated monetary value calculation, which records the weighted average of the anticipated impact;

• Net present value calculation, which uses an accepted discount rate and

• Risk model, which aggregates the risks together using a simulation technique.

In the following section, let us learn about the probability impact grid in detail.

Probability Impact Grid

The image below represents the probability impact grid.

The following are a few important information about the probability impact grid.

• Probability impact grid contains ranking values that may be used to rank threats and opportunities qualitatively.

• The probability scales are measures of the probability of occurrence of the risk, expressed in percentages, and impact scales reflect the level of impact on a project.

• The values within grids are multiplication values of probability and impact. These are used to provide an assessment of the severity of the risks and rank them accordingly to help the management in making an informed decision.

For example, the Program Board may set a tolerance of 0.18 (read as zero point one eight), so all risks below this level will be managed by projects while risks above this level are escalated to the program.

We will next discuss risk aggregation in the following section.

Risk Aggregation

Risks can be interdependent and have a cascading effect. They can grow and accumulate into a critical mass.

Following are the facts on risk aggregation:

• At the project level, a small risk can have a limited impact but if the risk is combined with other risks in adjacent projects, it can produce a significant impact at the program level. Also, in some cases, the sum of risks is smaller than the individual parts.

• Prepare a summary risk profile that provides a visual explanation of aggregations and interdependencies. When crafting a risk response, it is always useful to focus on the mitigation of the root cause so that it lessens more than one risk at once.

• To manage aggregation, the Program Manager should be aware of the level of risk impact on each operation or project. The Program Manager should have details of the cost of contingency that needs to be planned.

• Mitigation plan should be prepared to minimize the risk.

• The Program Office should play a central role in building and maintaining efficient, effective and consistent two-way flows of information between the program and its projects.

In the next section, we will focus on the summary risk profile.

Summary Risk Profile

The image below represents the summary risk profile.

A few facts about the summary risk profile are as follows:

• Summary risk profile helps to see the impact of project risks on a program.

• The transparent circles represent the project risks while the red circles represent the program risks.

• The grid provides the aggregation and interdependencies in visual representation. This shows how a particular risk can have an impact at the program level.

For example, risks related to interest rates may cancel out each other and reduce the program risk while in some scenarios, they might aggregate the risk for the program, such as stakeholder dissatisfaction.

In the next section, we will discuss the two final arrangements required for managing risks, which are proximity and progress reporting.

Proximity and Progress Reporting

Following are a few facts about proximity and progress reporting:

Proximity

Let us begin with proximity.

• It reflects the fact that risks will occur at particular times in the future and the expected value will vary according to their occurrence.

• It informs the management about when a risk will occur in future.

• This helps the management to realize the impending urgency of the risk and to formulate a timely response.

Next, let us understand progress reporting.

Progress Reporting

Let us now look into progress reporting:

• It monitors the evolution of overall risk exposure in a program.

• A progress report, whether as a separate document or incorporated in other documents, acts as a useful tool to monitor oversight.

• Programs should use progress report as an independent report aimed to monitor overall risk and issue trends across the program.

• A well-defined and maintained progress report is the main control tool for programs to manage their risks and issues.

• Typically, a progress report can include the progress of the planned risk management action, effectiveness of implemented actions, trend analysis of closed and new risks and issues, expenses against contingencies, emerging numbers in different risk or issue categories and projects, anticipated emerging or aggregated risks that require specific management attention and movement of risks against key program objectives and benefits.

In the next section let us discuss about issues.

Issues Introduction

The issue is a relevant and unplanned event that requires management action to prevent or reduce its impact on the program. The action may be required to fix the problem or to change the boundary of the program.

An issue can emerge from numerous sources such as:

• Constraints identified at the outset of a program,

• Stakeholders,

• Participating projects or operations and

• External sources, namely, corporate strategy and conflict with other programs.

Issues that occur in a project may need to be escalated if they fall outside the project’s tolerance levels set by the program. But otherwise, the program should not manage project issues directly.

Project teams can report to the Program Manager and keep him informed about the progress in managing issues.

We will discuss the threat responses in the next section.

Threat Responses

The following are the responses for threat:

Options	Use
Avoid	This option is about making the uncertain situation certain by removing the risk. This can often be achieved by removing the cause of the threat.
Reduce	This option chooses a definite action to change the probability or the impact of the risk. The term ‘mitigate’ is relevant when discussing the reduction of a threat; that is, making threat less likely to occur or reduce the impact of threat.
Transfer	This option aims to pass a part of the risk to a third party. Example: Insurance; where the insurer picks up the risk cost but the insured retains the impact on other objectives.
Share	‘Share’ is different from ‘transfer’ in the sense that it seeks multiple parties, typically within the supply chain, to share the risk on a pain or gain share basis. The primary risk taker will always need to protect their brand and reputation, however, they encourage collaboration on risk management activities.
Accept	The organization accepts that risk will occur with its full impact. There are no costs incurred in this option. Example: risk of profits due to currency fluctuations.
Prepare contingency plans	This option means that plans will be prepared, however, no action will be taken until risks occur.

All the responses for threat, other than “accept”, incur some cost and should ensure the return on investment.

In the next section, let us understand the opportunity responses.

Opportunity Responses

The following are the responses to opportunities:

 

Options	Use
Exploit	This option is about increasing and strengthening the cause of opportunity. This will ensure that the opportunity is better than when it was first identified.
Enhance	Organisation ensures that opportunity is more likely to occur and with greater impact.
Share	Risks are shared with a third party on a pain or gain basis.
Accept	It allows the opportunity to happen without any planned intervention, irrespective of whether it is a positive or negative opportunity.
Transfer	The third party gains a cost-benefit, however, the primary risk taker gets another benefit such as goodwill. Though, this is not usually a preferred option.
Prepare contingency plans	It is about preparing a fallback plan if exploiting the opportunities have not been as successful as expected.

All the responses for opportunities, other than “accept”, incur some cost and should ensure the return on investment.

In the following section, we will focus on issue management framework.

Issue Management Framework

Issue management framework is similar to the risk management framework. The following are the five steps of issue management framework.

The first step is to capture

Capture

Under capture, the initial analysis is undertaken to determine the type of issue that has been raised. The rules for this are laid down by the issue management strategy. The issues are categorized and their severity and impact are assessed.

Examine

The second step is to examine the issue using impact analysis, which analyses the impact of issues and options on the program’s performance and business case, risk profile, projects, objectives, blueprint, and operations.

Propose a Course of Action

In the third step, which is ‘propose a course of action’, all the alternative options are considered before choosing the most effective solution. The action chosen should maintain an acceptable balance between the advantage and the impact on time, cost and risk.

Decide

The fourth step is to decide. Issue management strategy defines who has the authority to make decisions about changes. The Program Manager should take decisions on minor issues without consultation.

Program change procedures defined in issue management strategy should be triggered to gain authority and control of change. It is important to plan the change with appropriate contingency measures.

Implement

The last step is to implement the decided change. The Program Manager will communicate the decision and response action to all stakeholders, including those who have raised the issue.

The issue register is updated and other documents are revised where the decision affects their content. It is essential to record lessons learned so that issues of a similar type can be avoided in future.

These steps are supported by ongoing activities, namely, ‘monitor and control’ and ‘embed and review’.

• Monitor and control process actively monitors the issue management actions to ensure the resolutions are achieved within the estimated time and the costs and without impacting other benefits.

• Embed and review process ensures that the issue management is successfully handled across the organization and conducts health checks to ensure returns on issue management.

In the next section, we will look into the issue management strategy and issue register.

Issue Management Strategy and Issue Register

Let us first understand issue management strategy.

Issue Management Strategy

Issue management strategy describes the program’s approach to issuing management and outlines how issues will be identified, categorized, severity-rated and managed. It also defines the change control procedure.

Now let us focus on the issue register.

Issue Register

The issue register is created during the process ‘defining a program’, and it helps to record issues. It includes former risks that have materialized. The design, content, and purpose of the issue register are defined in the issue management strategy.

Let us discuss change control in the following section.

Change Control

Programs deliver change but they cannot work in isolation. The changes that happen to the program environment will impact the program and need to be controlled. This can result in changing business requirements and reactions to unplanned events or failures.

Even small changes required in projects may result in conflicts with the program’s interests. To ensure good governance, a formal change control process is needed. The steps needed in the change control process are:

• Capture the change and define why it is needed,

• Allocate priority to indicate urgency,

• Authorize an agreed solution

• Assess the impact,

• Analyse all the options and test the potential solutions,

• Implement the change and monitor the effects of change for deviations from what is anticipated,

• Review effectiveness and update associated documentation.

All changes should be assessed based on their impact on the program plan, blueprint, benefits and projects dossier. We will now look into configuration management in the next section.

Configuration Management

Program changes are processed via issue management while configuration management provides the control for managing these changes.

Purpose of configuration management in a program is to control the development of and changes to, program management documentation and assets, products and services created by the program.

The following are the five basic processes involved in program-level configuration management. Let us begin with planning.

Planning

It includes decisions regarding what level of configuration management is appropriate based on blueprint and organization’s approach to configuration management.

The next process is identifying.

Identifying

This includes identifying all the assets created during the program and dependencies for which the configuration management is required. The third process is controlling.

Controlling

The configuration of the program is baselined once the definition of the program in the document is approved. As most programs change over time, version control changes are needed in the configuration document along with other documents.

The next process is the status accounting.

Status Accounting

This involves maintaining the current and the historical information concerned with each configuration, such as the configuration items and all dependencies including those external to the program as well as inter-project dependencies.

The fifth process is verifying.

Verifying

This includes auditing the program to ensure that there is conformity between the expected and actual status of the products and the configuration items before the delivery to operations.

In the next section, we will focus on an example based on the concepts discussed.

Risk Responses Problem

As part of the Nutri Snack, a program to create a healthy evening snack, the R&D department of Nutri Worldwide Inc. has decided to import the highest level cocoa beans from the Ivory Coast.

But the past experience with the vendor XYZ used by the organization suggests that the former does not have a good network in Africa and may delay the import.

Following are some of the risk responses under discussion:

1. Use coffee beans instead of cocoa beans because the former is easily available.

2. Put a clause in the contract that any delay in delivery will lead to a penalty for the vendor XYZ.

3. Ask a different vendor ABC to get cocoa beans from Brazil. The quality might not be the same though.

4. Ensure the consignment against the delay.

In the next section, let us see how to categorize these risk responses as Reduce, Accept, Avoid, Share and Transfer.

Risk Responses Solution

Following are the risk responses that may be undertaken by the R&D department of Nutri Worldwide Inc.

Avoid

Firstly, coffee beans should be used instead of cocoa beans because the former is easily available. This is the response named ‘avoid’ as the risk of delay is eliminated in this case.

Share

Secondly, a clause should be included in the contract that any delay in delivery will lead to a penalty for the vendor XYZ. This risk response is known as ‘share’ as a part of the loss is to be borne by the vendor as well.

Reduce

Thirdly, the vendor should be asked to get cocoa beans from Brazil. The quality might not be the same though. In this case, the organization would try to reduce the impact.

This risk response is known as ‘reduce’. So, even if the organization may not get the best quality seeds, they will have cocoa available for the recipe.

Transfer

Finally, the consignment should be insured against the delay. Insurance is similar to transferring the risk as it passes the risk to a third party.

Let us move on to the next section to discuss the relationship between transformational flow and risk and issue management.

Risk and Issue Management within the Transformational Flow

The table shown depicts the relationship between transformational flow and risk and issue management.

Transformational flow	Risk and issue management
Identifying a program	Risk management focuses on identifying and clarifying the ambiguity. The program brief includes an initial set of the identified program risks and issues. It will also include possible response actions.
Defining a program	Risk management and issue management strategies are created. Risk and issue register are set to record risks and issues are recorded. The continuity with the program will be influenced by the risks and issues of vision, blueprint, benefits profiles, program plan and business case.
Managing the tranches	All defined governance arrangements for risk and issue management are implemented. Active risk and issue management continue through every tranche. The effectiveness of these activities is measured at the end of tranche reviews.

Risk and Issue Management within the Transformational Flow (contd.)

The following table depicts the relationship between transformational flow and risk and issue management:

Transformational flow	Risk and issue management
Delivering the capability	The main deliverable is projected brief, which contains the guidance on risk and issue management. The program must pay attention to aggregated risks and issues as the total impact of the individual risks and issues can be greater than the sum of their individual parts.
Realizing the benefits	Risk management helps to avoid failure. If any tranche delivers below expectation, it is treated as an issue. Risk and issue management provide the Business Change Managers (BCMs) with means to anticipate and manage any deviation from the expected benefits realization process.
Closing the program	A program can be closed prematurely if it has major risks and issues that cannot be managed by the program.

In the next section, we will discuss the roles and their areas of focus in risk and issue management.

Roles and Areas of Focus in Risk and Issue Management

We will focus on the roles, namely, the Senior Responsible Owner or SRO, Program Manager, Business Change Manager and Program Office.

The roles and their areas of focus in risk and issue management are as follows-

Senior Responsible Owner (SRO)

The roles and areas of focus of an SRO are:

• The SRO authorizes the risk management and issue management strategies and their enhancements.

• He intervenes to control risks and issues

• Initiates assurance reviews of risk and issue management effectiveness.

• He also takes the ownership of strategic risks and issues, ensuring mitigation actions are dealt with, at an appropriately senior level.

Program Manager

Let us discuss the roles and areas of focus of the Program Manager-

• Develops and implements strategies for handling risks and issues,

• Designs and manages the risk and issue management cycle,

• Manages the aggregated levels of risks and issues,

• He also assures program adherence to risk management principles,

• Allocates risks and issues to the right individual as appropriate, and

• Ensures that change control is undertaken by individuals with the right authority.

The Program manager also-

• Ensures that impact of individual and aggregated risks is understood by relevant stakeholders,

• Defines clear rules for escalation, cascade, and threshold,

• Takes ownership of program level risks and issues.

• He also deploys a consistent language for risk management across all projects,

• Communicates the progress of resolution of issues in a clear and timely fashion

• Escalates items that cross program boundaries to the SRO for resolution.

• The responsibilities also include designing and implementing the configuration management system.

Business Change Manager or the BCM

Let us discuss the roles and areas of focus of the Business Change Manager or the BCM (read as B-C-M):

• The BCM manages and coordinates the resolution of risks related to the operational performances and benefits achievement,

• The ensures risk management cycle includes operational risks,

• Manages risks that impact on the business performance and transition.

• The Business Change Manager also identifies operational issues and ensures that they are managed by the program,

• Identifies opportunities from the business operations and raises them for inclusion in the program and contributes to the impact assessments and the change control.

• The responsibilities include monitoring and reporting on the business performance issues that may require the attention of the program during the transition.

Program Office

Now, let us understand the roles and areas of focus of the Program Office:

• It manages and coordinates the information and support systems to enable efficient risk and issue management,

• Maintains the program risk and issue register,

• Establishes, facilitates and maintains risk and issue management cycle.

• It also provides support and advice on risks and issues to the projects,

• Coordinates risk and issue management interfaces with projects and

• Maintains the configuration management systems.

• The responsibilities also include facilitating change control steps.

Risk and Issue Management Documents Information

Following are a few important documents used in the risk and issue management process. Let us begin with the risk management strategy.

Risk Management Strategy

The purpose of risk management strategy is to define program approach to the risk management. It mentions the following:

• Roles and responsibilities for managing risk in the program and

• The process adapted from the organization’s risk management standards.

• It also mentions the interface with the benefits management strategy on the approach to managing opportunities.

• It will also cover the scales for estimating the probability and impact along with the criteria for each level and

• Guidance on calculating the expected value and proximity.

• It will clarify the risk response categories including threats and opportunities,

• Risk templates including risk register and early warning indicators.

• It will also cover the timing of risk management activities and information flow and reports,

• The criteria for escalating risks and assessing the effectiveness and the risk management standards.

Next, let us discuss the risk register.

Risk Register

The risk register is used to capture and actively manage the risks for the program. Following are some important facts about risk register:

• It is used as a risk identifier that gives a unique risk id and description of the risk, such as, the cause of the risk, event which leads to the risk and effect of the risk on the program.

• It categorizes the risks as threats or opportunities;

• It calculates the probability and proximity of the risk occurring and its impact on the program.

• The risk register also provides a description of the proposed risk response and the residual risk after the risk response has been implemented.

• It also defines the risk actionee, an individual who is responsible for the implementation of risk.

• It also mentions the risk owner, who is responsible for the management and control of risk assigned to them and the current status of risk and progress of any action related to the risk.

• The risk actionee will be reporting to the risk owner to inform the progress of risk response actions.

• The risk register is a cross-reference to the program plan to identify where risk responses have been scheduled.

Now, let us discuss issue management strategy.

Issue Management Strategy

The purpose of the issue management strategy is to describe mechanisms and procedures for resolving issues. It contains:

• How issues will be identified, captured and assessed,

• How issues will be managed across program, projects, and operations and

• Responsibilities for effective management and issue resolution.

• It also explains the process and explanation of how change control will work in the program,

• What would be the change control procedures for authorizing changes resulting from issues and

• What procedures will be used for implementing and controlling the changes?

• It also explains how exceptions beyond tolerance levels will be managed,

• How responses to issues will be identified and by whom, and

• What would be the criteria for dividing the issues between project and program and allocating severity ratings?

• It also covers other strategies used to support issue management strategy and

• Monitoring and evaluating mechanism for issue response.

Finally, let us discuss issue register.

Issue Register

The issue register is used to capture and actively manage the issues in the program. Following are a few important facts about issue register:

• It includes a unique reference for each issue raised along with the date, who has raised the issue and description that includes the cause and the impact of the issue.

• It covers the severity rating and categorization and

• The description of issue response action to be undertaken and by whom.

• It explains who would be the issue owner, the one responsible for the management and

• Control of the issues and who would be issue actionee, the individual who is responsible for the implementation of the given issue response action, progress and status update.

• Issue register is used as a cross-reference to change control procedure.

• It contains the description of how the issue was resolved and what lessons were learned.

Summary

Let us summarize what we have learned in this lesson:

• The issue is a relevant and unplanned event that requires management action to prevent or reduce its impact on the program.

• The steps involved in the issue management framework are capture, examine, propose a course of action, decide and implement.

• The threat responses are avoided, reduce, transfer, share, accept and prepare contingency plans.

• The opportunity responses are exploited, enhance, share, accept, transfer and prepare contingency plans.

• Configuration management provides the control for managing the changes in a program.

• Risk can be defined as an uncertain event or a set of events which, should it occur, will have an impact on the achievement of the objectives.

• The issue can be defined as an unplanned event that has happened and requires management actions.

• Some of the sources of risk identification include benefits management activities, quality of operations, program deliverables, stakeholders, degradation of operational performance staff and organizational strategies.

• The various risk management perspectives are strategic level, program level, project level and operational level.

• The steps involved in the risk management framework are identified, assess, plan, implement, communicate and embed and review.

• Risk management strategy describes the approach that will be taken to manage risks in a program.

• Early warning indicators provide advance warning of trends or events that can adversely affect the program’s outcomes.

• The various methods used in evaluating risk in a program are probability impact grid, expected value, estimated monetary value, net present value calculation and risk model.

• Proximity informs the management about when a risk will occur in the future, which helps the management to formulate a timely response.

• The relationship between transformational flow and risk and issue management can be defined on the basis of identifying a program delivering capability and closing the program.

• The SRO intervenes to control risks and issues.

• The Program Manager manages the aggregated levels of risks and issues.

• The BCM ensures that the risk management cycle includes operational risks.

• The Program Office maintains the program risk and issue register.

• The documents used in risk and issue management are the risk management strategy, risk register, issue management strategy and issue register.

Conclusion

With this, we come to an end to the tutorial on Risk and Issue Management. Next, we will learn about Quality and Assurance Management.