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.
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.
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.
The following are some important information about risk and issue:
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.
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.
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.
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 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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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.
How about investing your time in our MSP Foundation and Practitioner Certification? Take a look at our MSP course preview.
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 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.
The following are a few facts about risk appetite and tolerance thresholds. Let us begin with 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.
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.
Following are some important information about assumptions, early warning indicators, and risk register. Let us begin with 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 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 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.
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.
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.
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 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.
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.
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.
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.
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.
Following are a few facts about proximity and progress reporting:
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.
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.
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.
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.
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 is similar to the risk management framework. The following are the five steps of issue management framework.
The first step is to 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.
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.
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.
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.
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.
Let us first understand 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.
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.
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.
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.
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.
This includes identifying all the assets created during the program and dependencies for which the configuration management is required. The third process is 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.
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.
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.
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:
Use coffee beans instead of cocoa beans because the former is easily available.
Put a clause in the contract that any delay in delivery will lead to a penalty for the vendor XYZ.
Ask a different vendor ABC to get cocoa beans from Brazil. The quality might not be the same though.
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.
Following are the risk responses that may be undertaken by the R&D department of Nutri Worldwide Inc.
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.
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.
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.
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.
The table shown depicts the relationship between transformational flow and risk and issue management.
Transformational flow |
Risk and issue management |
Identifying a program |
|
Defining a program |
|
Managing the tranches |
|
The following table depicts the relationship between transformational flow and risk and issue management:
Transformational flow |
Risk and issue management |
Delivering the capability |
|
Realizing the benefits |
|
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.
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-
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.
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.
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.
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.
Interested in taking up MSP course? Check out our course preview NOW!
Following are a few important documents used in the risk and issue management process. Let us begin with the 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.
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.
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.
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.
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.
With this, we come to an end to the tutorial on Risk and Issue Management. Next, we will learn about Quality and Assurance Management.
A Simplilearn representative will get back to you in one business day.