RMP_ Risk Identification
Purpose risk identification
Project risk identification
Program risk identification
Portfolio risk identification
Techniques for risk identification
Success factor of risk identification
Domain 2 - Exam context outline
Questions and answers
Purpose risk identification
The purpose of risk identification is to:
Document all knowable risks, while recognizing that:
• Some risks are unknowable so we will know it through the project
Because risks may appear later, the risk management process should be:
• Iterative, Repeating the risk identification activities.
• Repeated in order to find risks that were not previously evident.
Risks can be identified through:
• A variety of risk identification techniques.
• Input from a wide range of stakeholders, because each stakeholder may have a
different perspective on the risks facing the portfolio, program, or project.
• Reviewing historical records and documents to help identify risks.
When a risk is first identified:
• Preliminary responses may be identified at the same time.
• These responses are recorded during the Identify Risks process.
• They may be considered for immediate action when such action is appropriate.
• If the responses are not implemented immediately, they should be considered during
the Plan Risk Responses process.
Recording Risks and Assigning Risk Owner
• All identified risks are recorded.
• A risk owner may be identified at the same time.
The Risk Owner
The risk owner is the individual responsible for:
• Monitoring the risk.
• Selecting and implementing an appropriate risk response strategy.
• Managing the corresponding risk throughout the subsequent risk management
processes. (Very Important)
• A sponsor can be a Risk Owner if they are the best person to manage that risk.
Golden Rules for primary risks
1. Identify Risks does not mean you will find all risks from the beginning.
2. Risk identification is iterative, because new risks may appear later.
3. All knowable risks must be documented.
4. Preliminary responses can be recorded during Identify Risks, but detailed planning
happens in Plan Risk Responses.
5. The risk owner is responsible for monitoring the risk and managing the response.
6. Each cause of risk has a degree of uncertainty. (Very Important)
7. Risk Management is based on uncertainty, so even risk causes may need validation and
analysis.
8. Do not always treat every cause as a confirmed fact.
9. A risk cause may be based on an assumption, an uncertain condition, or incomplete
information.
Golden Rules for secondary risks
1. Secondary Risk = a new risk that arises as a result of implementing a risk response.
2. Do not ignore a secondary risk, even if it affects only a small number of people.
3. A secondary risk should be assessed, documented, and managed like any other risk.
Summary of assumption and constraint (Very Important)
1. Identify assumptions and constraints.
2. Record them in the Assumption Log.
3. Analyze their validity and impact.
4. If they create risks, record those risks in the Risk Register.
Golden Rules of assumption and constraint (Very Important)
1. Assumptions and constraints go first to the Assumption Log.
2. Risks resulting from assumptions or constraints go to the Risk Register.
3. Do not treat every assumption as a risk immediately.
4. Wrong or unstable assumptions can create threats.
5. Don’t build assumptions based on only one previous project, especially if they are
overly optimistic.
Project risk identification
➢ Identification of risks at the project level is based on:
1. Operational inputs.
2. Contextual inputs.
Operational Inputs: Operational inputs come from the activities of the project itself.
• Project scope statement
• Dependencies and sequence of work
• Project life cycle
• WBS, activity list, or backlog
• Estimates
• Procurement plans
• Change requests
• Historical data
Contextual Risks: come from the surrounding environment, organization, stakeholders,
business case, and external/internal conditions.
• Stakeholder analysis: Stakeholder can create both opportunities and threats
• Business case: Business cases are important because they may affect benefits,
profitability, and return on investment
• Program or portfolio governance-level success factors
• Enterprise environmental factors and strategic or organizational aspects
Golden rules (Very Important)
• Risk identification needs project documents as references.
• Without Project Charter, WBS, and Scope Statement, it will be difficult to identify and
assess risks correctly.
• The Project Charter provides a high-level understanding of the project before starting
risk identification.
• At the beginning of the project, review the Project Charter to understand the
objectives, requirements, stakeholders, and initial risks.
• The Risk Management Plan explains how to manage risks, but the Project Charter
explains why the project is important and what needs to be protected.
• When the impact of a risk is unclear, and it may be significant or insignificant, the risk
manager should define the risk threshold with the stakeholders.
Program risk identification
Risk identification at the program level is focused on:
Identifying the risks that could have an impact on the delivery of expected benefits.
Levels of Program Risk Identification
1. Risks cascading from the portfolio or enterprise level that can affect the achievement of
program objectives.
2. Risks identified directly at the program level and triggered by:
• Program activities
• Program interdependencies
3. Risks escalated from the program components.
➢ Identification of risks at the program level is based on:
1. Operational risks
2. Contextual risks
Operational Risks: Operational risks are risks directly triggered by:
• Program activities.
• Change management
• Program components
Contextual Risks: Contextual risks are risks resulting from:
• The strategic and organizational environment of the program.
• The stakeholders.
• Variations in the strategy.
• The evolution of the business environment.
• The program’s business case.
Golden Rules
1. At the program level, always connect risks to the delivery of expected benefits.
2. Program risks may come from above, from the portfolio or enterprise level.
3. Program risks may be created inside the program through program activities and
interdependencies.
4. Risks can be escalated from program components when their impact becomes bigger
than the component manager’s authority or budget.
5. Operational risks come mainly from program activities.
6. Contextual risks come mainly from the program environment, stakeholders, strategy,
and business case.
Portfolio risk identification
Risk identification at the portfolio level is focused on:
1. Identifying the risks that have an impact on the delivery of the expected business
performance.
2. Identifying risks that impact the ability of the organization to implement its strategy and
achieve its strategic objectives.
➢ Identification of risks at the portfolio level is based on:
1. Strategic risks
2. Tactical risks
Strategic risks: are risks identified directly at the portfolio level and triggered by portfolio
activities.
Strategic risks include activities related to:
• The generation of business performance by the portfolio components.
• The ability of the organization to achieve its strategic objectives.
Tactical risks: are risks escalated from the portfolio’s components.
Portfolio Risk Categories
• Changing business needs and environment.
• Availability of resources.
• Interactions between components.
• Conflicting component objectives.
Golden Rules
1. At the portfolio level, always connect risks to business performance, strategy, and
strategic objectives.
2. Strategic risks are identified directly at the portfolio level.
3. Tactical risks are escalated from portfolio components.
4. Portfolio risks may come from business changes, resource availability, component
interactions, or conflicting objectives.
5. Project risk focuses on project objectives, program risk focuses on expected benefits,
and portfolio risk focuses on business performance and strategic objectives.
6. Key or major risks must be linked to the organization’s mission, vision, and strategic
objectives. (Very Important)
Techniques for risk identification
1. Risk Metalanguage
As a result of cause, risk may occur, which would lead to effect.
This means:
• Cause = fact or condition.
• Risk = uncertainty.
• Effect = possible result.
For example:
As a result of limited vendor resources, the software upgrade may be delayed, which would
lead to missing the approved MDT window.
2. Assumptions and constraints analysis
• Bad assumptions can create threats.
• Constraints are not always negative; if removed or relaxed, they may create
opportunities.
• For assumptions and constraints analysis, remember the three steps:
List → Test validity → Identify impacts
3. Brainstorming (Nominal group technique)
The goal of brainstorming is gathering ideas from the team and stakeholders to identify
• Obtain a comprehensive list of individual project risks.
• Identify sources of overall project risk.
4. Cause and Effect Diagram / Fishbone Diagram (Very Important)
Cause and effect diagram, also called fishbone diagram, is used to:
• Display the root causes of risk visually.
• Allow deeper understanding of the source and likelihood of potential problems.
5. Checklists (Very Important)
Risk identification checklists can be developed:
• Based on historical information might be relevant to our project also its fast techniques
• Based on knowledge accumulated from previous similar:
o Portfolios
o Programs
o Projects
o Other sources of information
Risk checklists are a historic list of risks identified or realized on past complete projects
6. Delphi Technique (Very Important)
Delphi technique uses a facilitated anonymous polling of subject matter experts to identify
risks in their area of expertise.
The process is:
• The facilitator gathers the experts’ initial responses.
• The facilitator circulates the responses without attribution to the entire group.
• Group members may revise their contributions based on the opinions of others.
• It is designed to gather information and build consensus without requiring face-to-face
meetings.
• Delphi technique gathers all stakeholder opinions.
• conflicts, uncomfortable speaking, influential stakeholder, bias, disagreement
7. Expert Judgment
Expert judgment is the contribution provided to risk identification based on expertise in a
subject area, industry segment, organizational processes and other relevant areas.
8. Historical Information
Historical records and data from past projects, programs, and portfolios help to identify
common risks and prevent repeating mistakes.
9. Interviews
Interviews can identify risks by interviewing experienced project, program, or portfolio
participants, stakeholders or subject matter experts.
Interviews are one of the main sources of risk identification data gathering.
When there are different stakeholder opinions about risks, start with Interviews → Identify
risks → Update Risk Register → Share with project team. (Very Important)
10. Questionnaire
Questionnaire techniques encourage broad thinking to identify risks.
However, questionnaires require quality questions to be effective.
11. Prompt Lists
Prompt lists enumerate risk categories with the purpose of detecting the risks most
relevant to the project, program and portfolio
A prompt list can be useful as a framework for brainstorming and interviews.
Categories of risks include:
• Technical risks.
• Organizational risks.
• External risks.
12. Root-Cause Analysis
Root-cause analysis helps to:
• Identify additional dependent risks.
• Identify risks that may be related because of common root causes.
• Support the development of preventive and comprehensive responses.
• Reduce apparent complexity.
13. SWOT Analysis (Very Important)
SWOT means:
1. Strengths.
2. Weaknesses.
3. Opportunities.
4. Threats.
Note: Do not copy SWOT elements into the Risk Register as they are; convert them into
risk statements (Opportunities and Threats) (Very Important)
SWOT analysis examines the initiative from each SWOT perspective to increase the breadth
of considered risks.
It ensures equal focus on threats and opportunities.
This technique focuses on:
1. Internal factors: Strategic organizational strengths and weaknesses.
2. External factors: opportunities and threats
Note: Identify Risks needs the right people + the right information which mean as project
manager you need to ensure that all the relevant stakeholders participate and Ensure
participants review relevant documents before attending the meeting (Very Important)
Output of Risk Register
The main output required to identify risks is the Risk Register and must include the risk
description, probability, and impact
The risk register captures details of identified individual project risks.
It is developed along with all processes of risk management. It contains the results of the
1. Perform Qualitative Risk Analysis.
2. Plan Risk Responses.
3. Implement Risk Responses.
4. Monitor Risks.
Completion of the Identify Risks process, the risk register may include, but is not limited to:
1. List of identified risks.
2. Potential risk owners.
3. List of potential risk responses.
4. The risk register is considered a project document and should be reviewed to identify
opportunities that may be realized if the project is completed early. (Very Important)
Success factor of risk identification
The success factors for the Identify Risks process are:
1. Early identification
Risks should be identified as early as possible.
2. Iterative identification
Risk identification should be repeated throughout the project, program, or portfolio.
3. Emergent identification
New risks may appear later, so the team should continuously look for emerging risks.
4. Comprehensive identification
Risk identification should be broad and complete, not limited to obvious risks only.
5. Explicit identification of opportunities
Opportunities should be clearly identified, not only threats.
6. Multiple perspectives
Risk identification should include different viewpoints from stakeholders, experts, team
members, and other relevant parties.
7. Risks linked to objectives
Each risk should be connected to project, program, portfolio, business, or strategic
objectives.
8. Complete risk statement
Risk statements should clearly include the cause, the risk, and the effect.
9. Ownership and level of detail
Risks should have appropriate ownership and enough detail to allow proper analysis
and response planning.
10. Objectivity to minimize bias
Risk identification should be objective and should avoid personal assumptions, bias, or
one-sided opinions.
Golden Rules
• Identify risks early, but remember that risk identification is also iterative.
• Do not focus only on threats; identify opportunities as well.
• A good risk must be linked to an objective.
• A complete risk statement should follow: Cause → Risk → Effect
• Use multiple perspectives to avoid missing risks.
• Be objective to minimize bias.
Domain 2 - Exam context outline
Questions and answers