WEEK 2 Module - Project Risk Text

Developed by Cynthia Smethers for Oklahoma Christian Risk Management Course

In week 1 of our course, we learned about the concepts of risk, risk identification and
mitigation. In Chapter 4 of our textbook, we also learned about Enterprise Risk Management
which seeks to identify all risks that could negatively impact the organization as a whole.

In week 2 of our course, we will focus on Project Risk. Project Risk is one type of risk that is
under the umbrella of Enterprise Risk. The organization can be negatively impacted if its
projects are misaligned with corporate goals, underfunded, poorly led, or otherwise fail to be
successful. The failure of a project may negatively impact the organization’s ability to succeed or
capitalize on emerging opportunities.

In the readings below in this week’s text, you will find an in-depth review of the material related
to risk and uncertainty as covered in the Project Management Institute’s Project Management
Professional (PMP) exam and the Risk Management Professional (PMI-RMP) exams. If you plan
to take either of these exams, keep a copy of this material as a study guide aide for you.

Relationship between Enterprise Risk Management and Project Risk Management:

Ensuring that the project team is aligned with the corporate strategy and has corporate
approval is imperative prior to starting any project. Within the corporation, there are usually
levels of risk:

o Enterprise Risk
o Program Risk
o Portfolio Risk
o Project Risk

Enterprise Risk is usually focused strategic big-picture risks that could impair the company or
keep the organization from being successful. Programs are focused on certain areas or
segments of the company’s capability or strategies. Portfolios are grouping of projects that are
inter-related or otherwise similarly designed to address the program’s overall objectives. And
then each project is designed to support the portfolio and program objectives.

For any project to be successful, that project team must understand the goals of the project
itself, and how the project ties into the portfolio and program’s objectives and strategies. The
enterprise, program and portfolio risk tolerances and inter-dependencies will often be used to
By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 1 of 36
determine the project’s tolerances and dependencies. Stakeholders from the entire upline of
the project should be included in the risk identification process since they will view the risks
through different lenses. Enterprise and Program stakeholders may more readily think of long
term risks and threats to the corporate level, while project members will more readily address
short term risks at a more tactical level.

Risk: Key Concepts and Definitions in Project Management Context

Risk can be defined as an uncertain event or condition that, if it occurs, can have a negative
effect on the project objectives. Some uncertainty may also create an opportunity (positive
effect) on the project. Risk arises from uncertainty, or lack of awareness of potential outcomes
and likelihood of occurrence.

Risk Probability is the likelihood that the risk could occur.

Risk Impact or Severity is the amount at stake, or most probable amount of the loss. This could
be expressed qualitatively (low, medium, high) or qualitatively in terms of dollars or time or
quality measurements.

Risk Attitude is defined as a disposition toward the uncertainty. Risk attitude will influence the
organization’s choices on risk mitigation strategies, and is a function of risk appetite and risk
threshold. Risk attitude reflects the level of adaptability and resiliency of the team in relation to
that particular risk. In project management, it is important to know the risk attitude of the
organization towards the project. If the project is highly critical to organizational strategies, the
risk attitude will be more risk adverse and thus will require a higher level of diligence and
communication from the project manager during the course of the project.

Risk Appetite is how much uncertainty an organization will accept. The appetite for risk is
measured by risk tolerances and thresholds. A project risk manager needs to fully understand
the risk appetite and tolerances of the organization prior to starting the project. Where the
tolerance is small, the risk management plans around that aspect need to be the most robust.
Different stakeholders will have different appetites for risk, and the project manager needs to
take them into account. Risk-reward considerations heavily impact the tolerances of the
stakeholders. Risk appetites may be described as risk-seeking, risk-tolerant, risk-neutral or risk-
adverse.

Risk Tolerance is the objective measurement of risk appetite and is the maximum acceptable
amount of variability in the project, such as 5% budget tolerance, or 10% time overrun. When a

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 2 of 36

tolerance is hit, the project may be forced to stop or be reconsidered. Tolerances are usually
determined by the stakeholders and decision makers on the project.

Risk Threshold. Thresholds may be expressed in terms of budget, deadline and/or quality of
project deliverables. Risk thresholds will define the minimum amount of risk for it to be
included in the risk register, and the maximum amount of risk exposure that can be managed
before an escalation is required.

Risk Trigger: A warning sign that a threshold is close to being violated. Upon a risk trigger
event, the team’s behavior must change or mitigating action must be taken to avoid hitting a
threshold that could harm the project’s success. For example, if a threshold is that project
cannot run more than 4 weeks late, then a trigger may be at a time where the project is 2 weeks
behind. Stakeholders often have a say in what the trigger should be, in relation to the tolerance
that they have established.

Uncertainty: state of not knowing. Uncertainty (not knowing what will or could happen) causes
risk (the potential negative outcome).

Ambiguity: State of being unclear about current or future conditions. For example, the
solution to problem at hand may be unclear and undefined at the start of the project.

Complexity: state of being difficult to manage due to system behavior, human behavior, or the
number of interdependencies.

Volatility: possibility of rapid and unpredictable change

Issues: In the context of a project, an issue is a risk that has now occurred. The occurrence of
an issue requires a contingency plan or workaround to be implemented. Issues may be referred
to as impediments, obstacles or blockers. An impediment slows down or hinders the project.
An obstacle prevents work from starting, and a blocker causes work to stop.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 3 of 36

Risk Classification:
Classification of risks can be helpful to visualize the available information and organize a vast
number of risks. Within the project management plan, identified risks are assigned a type. Then,
types will be collected into a category (or group). The usage of categories and types is called a
risk based structure. An example risk breakdown structure (RBS) is shown later in this document
under Identification of Risks.

With categories and types, the project team can prioritize large grouping of similar risks rather
than each individual risk. An integrated risk management approach can then determine which
categories/types of risk can be handled by the project team or need to be escalated or
delegated elsewhere.

Risk types and categories often vary by industry and type of project, and there is not one
method of categorizing that fits all projects.

One common method is to split the risks into 4 main types: Technical, External, Organizational,
and Project Management.

• Technical items would include software, hardware, digital network, digital assets, system
security, and new and changing technology, changing regulatory requirements, data
breach, data corruption, security, licensing, etc.
• External risks exist outside of the project’s organization and are usually beyond the
control of the organization, such as political, governmental, climate, weather,
competition, supply chain, or economic changes.
• Organizational risks occur from breakdowns in internal procedures and processes,
people and systems. Resistance to change is an example of an organizational risk. Other
risks include prioritization, access to funding and resources, project dependencies,
culture, governance, requirements, or quality thresholds.
• Project Risk includes all the efforts to manage the project, including communication,
estimating, planning, contracting, and scoping of the project. Project risk also includes
quality control, personnel and risk management.

Another common structure uses types of: operational, financial, technical, social/reputation,
environmental, market condition, physical environment, political (both internal and external),
economic, and compliance/legal.

The project manager, in collaboration with the stakeholders and the team members, will
determine what categories work best for the project.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 4 of 36

These types can be grouped into Categories. There are two common methods to determine
Categories: Source-Based Risk and Effect-Based Risk. Each project may elect to use one or both
of the category methods.

• Source Based Risk means that we categorize the risk types based on the source of the
risk. This Source Based Risk uses the same list of sources of project risks as the Risk
Based Structure (RBS), such as categories of technical, internal, external, generic or
industry specific items.
• Effect Based Risk groups risks based on the impact on the project, and include categories
of : schedule, cost, quality, scope and resources.

Risks and risk types are also categorized as:

• Individual: risks that impact one or more of the project objectives, and an area of focus
by the project manager
• Overall: risks that impact the entire project, which represent the exposure the
stakeholders have to the project outcomes

Another way that risks can be classified is in the four quadrants of known and unknown risks.

1) Unknown-Known (Hidden Fact): knowledge exists in the community but not with
the entity working on the endeavor. These are ideas that we forgot to include in our
lists of risks.
2) Unknown-Unknown (Emergent Risk) : knowledge does not exist within the sphere of
influence. These cannot be predicted.
3) Known-Known (Facts and Requirements) : managed as part of the scope. Not a risk
4) Known-Unknown (Classic Risk): there is knowledge that the risk may exist but no
specific information to identify probability and impact

The project manager and team will determine which types and categories should be used in the
RBS (risk breakdown structure) and risk register for the project. Affinity diagrams can be helpful
here to see which risks are related and can be combined into broader categories. Categories
may have a broad over-arching solution to the risks that were correlated within that category.
For example, if a risk category is ‘Schedule’ with several risks within that category, a shared
solution would be to extend the project timeframe and add some contingency into it.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 5 of 36

Risk Responses: Options to consider for negative outcomes of risk include:

1) Accept (retain). This includes passive or active retention. With an active retention
method, a contingency plan is developed to cover the loss of time, money or
resources. This may include a contingency reserve fund for budget overruns.
2) Avoid. Avoid exposure to the risk altogether
3) Mitigate. Reduce the threat’s probability of occurrence and/or reduce the threat’s
impact.
4) Transfer. In the context of project management, this may be an escalation to
management when the proposed response falls outside the authority of the team.
This may also include insurance, third party agreements, surety and other solutions
which transfer the negative outcome to a third party.

Occasionally, when a risk is identified, an opportunity also emerges. Opposite of negative

outcomes, the project may plan for the opportunity to be accepted, exploited (a response is
developed to ensure the opportunity can be seized) , enhanced (increasing probability or
impact), shared across the organization, or escalated to a higher level of management to take
advantage of the opportunity.

Strategies for addressing general uncertainty may include gathering more information,
preparing for multiple outcomes, exploring multiple approaches, and building in resilience.

- Gathering more information can often resolve much uncertainty.

- Prepare for Multiple Outcomes means that developed of contingency and backup plans
should the primary plan prove ineffective or not viable.
- Prepare of multiple approaches includes leveraging a set-based design. In this case, the
project team can investigate multiple designs and alternative solutions before selecting one
to implement. This may be effective where no clear priority, budget, or schedule are
imposed on the project.
- Resilience, the ability to successfully adapt to an issue when it arises, can be addressed in
the project planning by adding a cushion in budget and timeline, augmenting staff, or
reverting to a minimal viable deliverable if the risk were to occur.

Strategies for addressing general Ambiguity are similar and include:

- Progressive elaboration is the process of continuing to refine details as more information is

received. Agile/adaptive processes use progressive elaboration to refine requirements
through each iteration

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 6 of 36

- Experiments can be used to better understand cause and effect relationships and gaining
better information to reduce ambiguity. This situation may be referred to as a risk spike and
is common in adaptive methodologies.
- Prototypes to evaluate and receive feedback can bring clarity to stakeholder desires.

Strategies to address Complexity:

- Select the appropriate project management approach. A common model regarding

complexity is the Stacey Complexity Model, which accounts for two sources of uncertainty,
requirements (what to do) and technology (how to do it). When requirements are known
and technical capacity is certain, then predictive linear approaches are suited for the
project. When requirements are far from known and technology is far from certain, the
project should be abandoned. Between these extremes for complicated and complex
projects, adaptive approaches are better suited.
- Seek diverse perspectives and use balanced data to see project from multiple points of view
- For system-based complexity, decoupling (breaking down into separate parts) allows each
part to be modified and tested without impacting the other parts. Simulations can also be
used to test system components and expected behavior.
- For process-based complexity, use iterative builds, frequent stakeholder engagement and
built-in redundancy for critical system components.

Strategies to address Volatility:

- Volatility may arise from fluctuations in resources or materials, or from scope creep and
changing requirements. These can be handled by leveraging an adaptive approach,
analyzing alternatives, and allocating contingency and management reserves (money and
time). Contingency reserves are for known risks and management reserves are for
unknown risks.

Project Risk Management Process

The objective of project risk management is to increase the probability for success and to
decrease threats to the project. When unmanaged, risks can cause the project to deviate from
plan and fail to meet project objectives. Project risk management supports the project by
adapting and implementing courses of action to prevent or address risks. The project baselines
of scope, schedule and costs are established based on identified risk exposure and preemptive
mitigation strategies. In other words, once the team has identified the risks that should be
proactively avoided, the project’s plan should include those action steps in the overall project
plan and include the time/budget needed for those risk prevention activities in the planning
phase.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 7 of 36

Project risk managers are accountable for evaluating, reporting, and managing project risks,
proactively anticipating threats and understanding the consequences of issues when they arise.
The project manager may escalate certain risks to higher level management within the
organization depending on the complexity and impact of the risk.

All project team members have responsibility for managing risks, including helping to identify
risks and triggering events, and implementing strategies to respond to uncertainty. In most
cases, the project manager is also the risk manager; however, some projects may have a
separately designated risk manager assigned to the project. A successful risk manager will be
able to rally the team around a risk management culture and help the team see risk mitigation
as an important valuable aspect of the project. A Risk Alliance can be built between project
leadership and team members where there is a culture of teamwork around risk management.

The project manager should continuously evaluate events that may occur in the future that can
expose the project to risk, assess the probability and impact of the risk, understand the risk
appetite and thresholds of the project, determine risk response, and manage identified risks.

The risk management process should continue throughout the course of the project and include
frequent review and feedback sessions for team members to navigate risk, identify new risks,
and proactively manage and mitigate risks that might endanger the success of the project.

The specific steps in risk management are illustrated in the diagram below:

We will be exploring each step in more detail. Discussion of each step is below in this text, and
supplemental templates and examples will also be provided and reviewed in Week 2 materials.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 8 of 36

Step 1: Risk Management Planning
A Risk Management Plan describes how risk management activities will be structured and
performed. A risk management plan is the planning of how and when risks will be managed; it is
not the risk mitigation itself, but instead the plan on how the risks will be managed as part of
the project.

Having a plan for risk management can move the team towards proactive risk mitigation instead
of reactive risk correction, allowing for the team to stay on time and on budget with built in
contingency margins that improve the teams’ resiliency when an issue arises.

The risk management plan should be updated throughout the project at regularly scheduled
intervals.

Organizations often have their own risk management plan template. In general, the risk
management plan may include some of the following items:

• Introduction and project charter, project description and objectives

• Criteria for success
• Project Management Plan
• Project methodology and inherent risk
o Waterfall (predictive) methods minimize risk in situations where many
variables are well known
o Agile (adaptive) are better suited in new or unknown conditions
o Each method introduces its own unique risks
• Risk Strategy – general approach to managing risk on the project, based on risk
appetite of the stakeholders
• Risk management methodology intended to be used
o How risks will be identified and definitions of risk labels ( for example, a
high risk may be defined as anything with >70% probability, and/or >3
month delay, and/or lack of key functionality)
o How risks will be assessed for probability
▪ Definitions of measurements ranging from unlikely to very likely
for qualitative analysis
o How risks will be assessed for impact
▪ Definitions of measurements ranging from low to severe for
qualitative analysis
o Other items used to rank risks, such as urgency or detectability
o How risks will be scored and overall priority determined

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 9 of 36

 • Timing: How often the risks will be reassessed. At a minimum, this should be
when change is planned or occurs, and at regular intervals.
• Risk Reporting: structure and timing of report to provide management summary
of project’s risk profile throughout the project
• Risk Breakdown Structure - risk categories and types
• Risk Tracking: how risk activity will be recorded and audited
• Enterprise Environmental Factors - regulatory environment, strategic decisions,
market positioning and competition, and strategic objectives
• Organizational Process Assets - standard operating procedures or organizational
policies
• Roles and responsibilities and authority of team members and stakeholders in
managing risk (RAM or RACI, see below)
• Risk owners
• Risk policy
• List of stakeholders and their risk thresholds/tolerances
• Risk management techniques and templates intended to be used
o How each risk will be tracked
o How each risk will be addressed if it occurs
• Agreed-upon tolerances on time, cost and quality
• Triggering rules and escalation rules
o Triggers that force remediation or escalation based on shifts in probability
or impact of risks
o Which risks and when to go to management
• Communication plans of risk status to stakeholders
o Daily scrums, emails, update meetings, etc.
• Assumptions and Constraints
• Budgeting: identifies funds needed to perform the risk management activities
and outlines how the contingency reserve will be determined

A Responsibility Assignment Matrix (RAM) in risk management is a simple tool that lists the risk
processes to be implemented and who is responsible for getting that done. For example:

Data Capture Team Member A

Archiving Team Member B
Risk Register Project Risk Manager Name
Escalation Executive Sponsor

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 10 of 36

A RACI (Responsible, Accountable, Consult and Inform) chart is similar to a RAM chart, but it
details the roles and level of authority members have on each process. For example, Team
member A may be responsible for the data capture, but the project manager is accountable to
ensure it is done, and the executive sponsor may wish to be consulted.

Responsible = person actually performing

Accountable = person held liable for this step
Consult = person who can provide supplemental information or nuances
Inform = person apprised of the progress and status

To get started developing the risk management plan, the project risk manager will gather
documentation and available data. This will include:

• industry benchmarks,
• project plans at as much specificity as possible (requirements, user stories, deliverables)
• project management plan (integration management, procurement plan, etc)
• stakeholders
• lessons learned from previous projects
• risk registers from previous projects
• customer agreements – contracts, terms and conditions
• project assumptions and constraints
• project charter, scope, resources, location, timing, and associated budget and deadlines.

Risk Assumptions will be documented as part of the risk management plan and risk register.
Assumptions are items that could impact the project but are believed to be true when planning
the project. For example, ‘weather will only stop construction 10% of the time’, or ‘resource
with expertise will be available throughout the project’. Within the risk register, a risk will be
identified to document the risk that the assumption is false and any mitigating action plans that
can be taken to prevent or reduce the impact of the inaccuracy of the assumption.

Constraints represent the hard and fast rules that the project must operate within, such as legal
considerations, cultural norms, ethics, physical limits (size or weight), or technical capabilities. A
project that does not meet the constraints cannot be implemented.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 11 of 36

Stakeholders are individuals or areas that will be impacted by your project or have decision-
making authority or other influence over the project. A stakeholder register can be a helpful
tool to maintain a list each stakeholder, their area of interest/impact, level of engagement
(unaware, resistant, neutral, supportive, and leading), salience (level of interest and level of
power), and tolerances that could stop the project from proceeding. Stakeholders determine
their own tolerances which are gathered and documented by the project manager from
conversations and interviews prior to the project. Stakeholders with high salience (high power-
high interest) should be given the most consideration in establishing the overall tolerances of
the project.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 12 of 36

Step 2: Risk Identification
Inclusion of all team members, subject matter experts and stakeholders in the risk identification
and analysis process is highly beneficial for project success. Best practices require the use of
multiple techniques to identify all the risks and overcome human tendencies to overlook or mis-
prioritize risks. Risks can be identified using checklists, prompts, templates, individual and group
brainstorming, and external sources such as ERM or external suppliers.

Risk descriptions in the form of Cause-Risk-Effect are helpful to ensure that mitigation plans are
addressing the actual cause of the risk. The risk description is stated in these terms: “ if ‘cause’,
the ‘risk’ may occur, leading to ‘impact’.” For example, “Due to shortage of programmer
resources, a delay in the timeline may occur, leading to missed deadlines and additional costs. “
In this case, mitigation plans should be centered around a shortage of programmers.

Risk Owner are individuals assigned to individual risks or risk types to track the risk and
implement the risk responses when needed. Risk owners need to have a clear understanding of
their assigned risks, including the probability, impact and strategies for mitigation, tolerances,
and timing for review. Risk owners should have the responsibility and authority to act on their
risks.

The most important document in risk management is the Risk Register. All risks that are
identified are captured in a Risk Register by the project manager. This register is the tool that
will be used to track and document the risks going forward. The risk register is a central
repository for all identified risks and is shared with all the participants throughout the project.
Because risks evolve over time, the register will have new risks and modifications as new
information becomes available.

The information in a risk register may vary by organization or project, but at minimum contains
the risk event, probability and impact, and the response. For each risk, the Risk Register will
include some or all of the following:

- Risk ID
- Risk description in Cause-Risk-Effect format
- Risk Category and Type
- Qualitative Assessment: Probability and Impact, and priority score
- Quantitative Assessment: Probability. Impact and Score
- Risk Urgency – how soon a risk could impact the project meaningfully
- Risk Propinquity – how important is the risk to the team; level of interest
- Risk Proximity - nearness of the risk to the project team
- Risk Dormancy – nature of the risk to avoid detection before it becomes an issue
- Risk Detectability - risk triggers can be seen coming in the future with time to act.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 13 of 36

- Risk Manageability - how readily can the risk be corrected if it occurs
- Risk Connectivity – propensity for the risk to cascade into other risks downstream
- Strategic Impact – high/medium/low assessment of impact to corporate strategy
- Overall Risk Priority
- Risk Response strategies to reduce likelihood or impact
o Strategy Type: Avoid, Mitigate Probability, Mitigate Impact, Mitigate both, Transfer,
Escalate, or Accept Passively, Accept Actively
o Narrative description and Detailed plans outlining specific actions,
o Implementation schedule and responsibilities
o Follow-up dates for review
o Impact of plan on budget and timelines
- Contingency Plans for risks that materialize despite mitigation efforts
o Implementation timing of risk response
o Triggering event
o Impact of plan on budget and timelines
- Escalation requirements and timing
- Followup
- Risk owner who understands the risk and can monitor it appropriately
- Areas Impacted by risk and mitigation
- Assumptions and Constraints
- Date Risk was added to register
- Retirement criteria
- Risk Status – open, in progress, closed
- Risk Update Date – date the register was last updated for this risk
- Outcomes that eventually occurred from prevention or contingency plans
- Additional Notes
- Archival location

A sample risk register template is available in this course’s materials, and an example is shown
below. The project manager will complete the risk register information during the next few
steps in the risk management process. Initially, only the risk description and some notes may be
available, and the rest of the columns will be completed in the upcoming steps in the process.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 14 of 36

Additional risks will be added and existing risks modified on the risk register through the
process.

Common techniques for risk identification are described below.

1) Assumptions and Constraint Analysis – if a assumption could be false and could impact
the project negatively, it is a risk. For example, if we assumed that our project would
have funding and needed resources, we have a risk if this assumption fails to occur.
Constraints are must-do conditions that can shut down the project, therefore these can
be analyzed to determine what risks might result in violation of that constraint.
2) Brainstorming – gather ideas from individuals and groups
3) Mindmapping – brainstorming with graphical representation. If an idea is related to a
previous idea, a line is drawn from the first idea to the next idea.
4) Conduct market research – on external issues such as supply chain, market conditions or
industry challenges
5) Checklists – based on previous projects. After the checklist is complete, it is imperative
to review for missing items that may not have been on a standard template.
6) Prompt lists using a risk breakdown structure (RBS) as a guide. An example RBS is shown
below. A wide variety of RBS Categories and Type lists exist and the project risk manager
will need to elect the one that is best for the particular project. Risk questions can be
then be asked for each element within the RBS, such as ‘What are the technical
complexity risks in our project’, or ‘what are the environmental risks that could impact
our project’.

Common Prompt lists/RBS categories for a framework to brainstorming and interviews

are shown below. Categories include Technical Risks, Operational Risks and External
Risks. Three common prompt lists are:
a. PESTLE – Political, Economic, Social, Technology, Legal, Environment
b. TECOP – Technical, Environment, Commercial, Operational, Political
c. SPECTRUM – Sociocultural, Political, Economic, Competitive, Technology,
Regulatory/legal, Uncertainty/Risk, Market

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 15 of 36

 From Project Management Professional (PMP)® Cert Guide by Gregory Horine and Asad Haque (9780137918935) Copyright © 2023
by Pearson Education, Inc. All rights reserved

7) Uncertainties arise from operational activities and contextual influences. Operational

risk identification can often be identified from the following inputs related to the project
itself.
• Project Scope Statement – risks related to the specifications and deliverables
expected
• Project Management Approach – adaptive, predictive and hybrid approaches
have different levels and types of risk
• Work breakdown structure, activity list or backlog – risks connected to the
decomposition of the project work and triggered by its execution
• Estimates – risk that the time, resource and budget, and velocity estimates are
inaccurate
• Dependency and sequence of work – risks related to the critical path and
external dependencies and sharing of resources, and interdependencies of epics
and user stories

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 16 of 36

 • Procurements – contracting risks
• Change Requests – may introduce new risks
• Historical Data – systemic risks across all projects

Contextual Risks include enterprise environmental factors (EEF), operational process

assets (OPA) and other strategic aspects influencing the project. Inputs to risk
identification include:

• Enterprise environmental factors of regulatory environment, strategic decisions,

market positioning and competition, and strategic objectives may be areas of risk
if the project failure may threaten corporate success.
• Operational Process Assets can introduce risk if standard operating procedures or
organizational policies are too restrictive and/or required extended approval
chains that may slow the project. Contracting negotiations with third parties may
also be a constraint.
• Stakeholder Analysis and Business Case – risks impacting the realization of
project goals
• Program or portfolio governance – risk that the priority level of the project may
vary over time

8) Delphi Technique - facilitated anonymous polling of experts to identify risks in their

areas of expertise. The group reviews the accumulated responses and often modifies
the output to form a consensus.
9) Document Review – review of plans, prior projects, quality of plans and assumptions
10) Historical information on common mistakes
11) Expert Judgement
12) Cause and Effect (Ishikawa), Fishbone diagrams or Root Cause Diagram – content is
organized in branching diagram. Can be used to illustrate causes that have multiple
sources, or locate quality related impacts. An example is shown below. This tool can be
used to predict risks that may occur in the future, or to identify root causes of issues that
have already arisen later in the project.

In the example below, questions captured may be

▪ What are the human reasons the deadline may be missed
▪ What are the process / method reasons the deadline may be missed
▪ Etc.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 17 of 36

 After each of these questions, a question of ‘why’ is to be asked until the root cause is
found. For example, we may not have enough staff… because we did not hire… because
we did not have the budget… because… etc. until the root cause is found.

From Project Management Professional (PMP)® Cert Guide by Gregory Horine and Asad Haque (9780137918935) Copyright © 2023
by Pearson Education, Inc. All rights reserved

Here is an example for a construction project:

13) Interviews of experienced project managers, stakeholders, and participants

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 18 of 36

 14) Questionnaires
15) SWOT (Strength, Weakness, Opportunity, Threat) – examine the initiative from both a
threat and opportunity perspective, from internal and external sources to form a
broader set of risks. An example is shown below. Strengths and Weaknesses are external
to the project while Opportunities and Threats are project-driven.

From Project Management Professional (PMP)® Cert Guide by Gregory Horine and Asad Haque (9780137918935) Copyright © 2023
by Pearson Education, Inc. All rights reserved

16) Fault Trees – diagram that highlights all underlying conditions that need to exist for a risk
to actually occur. In an all-condition fault tree, all conditions must happen
simultaneously for the risk to occur. In a or-gate or multiple-gate fault tree, only one or
more conditions will trigger the risk.
17) Premortem – envision the project’s hypothetical failure and work backwards to identity
possible causes, creating a comprehensive list of vulnerabilities and preemptive
measures

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 19 of 36

Step 3: Qualitative Risk Analysis
Qualitative Risks are analyzed in terms of probability of occurrence (likelihood) and impact if the
risk were to occur. The resulting score will determine a risk rating. The organization will usually
apply resources and risk mitigation plans to those risks designated as medium or high risks.

For example, a simplified rating scheme chart may look like the example below. Likelihood and
severity of impact run across the vertical and horizontal axis respectively. The resulting
qualitative scores are in the colored boxes. For example, a risk that is unlikely to occur but
severe in impact will have a score of High.

Common techniques for qualitative risk analysis include:

1) Affinity Diagrams – sorts risks by similarities or generic risk categories, to organize

specific factors that contribute to risk. The largest categories with the most similar risks
may indicate a higher level of priority. Affinity diagrams may be used in the risk
identification process, and/or used in the determination of priority also.
2) Analytic Hierarchy Process (AHP) - matrix based method to rank risks based on multiple
categories. For example, the risk manager may gather leadership’s preferences when
weighing the four desires of cost, time, scope and quality on a scale of 1-4, and use this
to rank the various risks that impact those four categories.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 20 of 36

 3) Influence Diagram – visual representation showing main entities, decision points,
uncertainties and outcomes, indicating relationships among them to identify risks’
sources. An example diagram is shown below.

From Project Management Professional (PMP)® Cert Guide by Gregory Horine and Asad Haque (9780137918935) Copyright © 2023
by Pearson Education, Inc. All rights reserved

4) Nominal Group Technique – Individuals respond to the risk questions independently

first. The responses are then documented for group discussion and consensus on
ranking.
5) System Dynamics – uses influence diagrams of entities and information flow to reveal
feedback loops that lead to uncertainty. Also shows the impact of risk events on overall
system results, and overall sensitivity to specific risks.
6) Probability and Impact Matrix- classify risks on a scale of probability and on a scale of
impact. Risks that are high on both probability and impact would garner the most
attention in risk mitigation and are candidates for risk transfer where possible. An
example is shown below.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 21 of 36

 From Project Management Professional (PMP)® Cert Guide by Gregory Horine and Asad Haque (9780137918935) Copyright © 2023
by Pearson Education, Inc. All rights reserved

7) Assessment of other risk parameters in addition to probability and impact, including

a. Urgency – speed at which the risk response must be implemented
b. Proximity – period of time before a risk will have an impact on objectives
c. Detectability – ease with which the risk can be recognized as occurring
d. Dormancy - period of time after risk has occurred before impact is discovered
e. Manageability – ease of managing the impact of the risk
f. Controllability – degree the risk owner can control the risk outcome
g. Connectivity – extent risk is connected to other risks
h. Strategic Impact – impact on corporate strategy goals
i. Stakeholder impact – perception of stakeholder of the risk importance
j. VUCA: Volatility, Uncertainty, Complexity, Ambiguity

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 22 of 36

Step 4: Quantitative Risk Analysis
Quantitative risk analysis is used to determine the overall financial impact to the project when
one or more risks occur. Risks with higher costs will require the most risk mitigation attention.
Because a proper quantitative analysis does take a lot of time and effort, the project manager
may wish to focus this effort only on the risks labeled medium or high on the qualitative
measurement scale. The quantitative measurements should be updated on a periodic basis as
things change during the course of the project.

Quantitative Analysis can be done at the whole-project level or detailed risk-by-risk level. On a
whole-project basis, the goal is to generate information about the expected range of outcomes
for the project as a whole.

Commonly used techniques for quantitative risk analysis at a risk-by-risk (or risk category) level
include:

1) Contingency Reserve Estimation - an amount of dollars and time to set aside for the
risks that eventually occur. This reserve is made of two components: amounts to cover
specific approved contingency plans, and amounts to address unspecified or passively
retained risks. These reserves will be managed as part of the Monitor Risks step. The
amount of the reserve will be determined by quantitative measurements.
2) Decision Tree Analysis - to determine probability of occurrence and calculate the
expected monetary value (EMV) of different possible outcomes. The Expected Monetary
Value is a calculation of the weighted average or expected cost/benefit when the
outcomes are uncertain. EMV=probability*impact. All reasonable outcomes are
assigned a probability, which add back up to 100% across all outcomes. The monetary
value of each outcome is estimated. The EMV is the sum of each outcome’s probability
multiplied by its monetary value. Estimating techniques for probability and impact are
often used as the exact value may not be known.
An example of a decision tree is shown below.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 23 of 36

 From Project Management Professional (PMP)® Cert Guide by Gregory Horine and Asad Haque (9780137918935) Copyright © 2023
by Pearson Education, Inc. All rights reserved

3) Failure Modes and Effects Analysis/ Fault Tree Analysis – to identify elements that can
cause system failure, by themselves or in combination. Analyzes how risks arise, impact
of quality, and the probability of failure. This method is often used in engineering
contexts. Failure Mode Effects Analysis (FMEA) outlines where failures may occur (risk
event), the mode outcome (impact), probability, and detectability.

Commonly used techniques for quantitative risk analysis at an overall-project level include:

1) Monte Carlo Simulation – A series of theoretical simulations of the risk will show the
range of outcomes likely to occur as a result of that risk. The simulations take into
account a variety of different data points regarding outcomes and simulates how any
given scenario will turn out. The simulations rely on range estimates for each work
element in a project, and then displays how one version of combinations of those ranges
may turn out. The process is repeated hundreds or thousands of time, each time
reflecting randomly selected different combinations of the time-estimate-ranges for all
the different work elements. An example output of the monte carlo simulation is shown
below. In this case, the multiple simulations showed that the project was expected to
last 23 weeks on average but 40% of the simulations showed a longer timeframe would
be needed.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 24 of 36

 2) Project Evaluation and Review Techinique (PERT) – time based technique that can be
used to quantify risks at certain points in the project. This technique can be used for the
overall project and/or a risk-by-risk basis. PERT provides a quick calculation for the best
and worst case outcomes, with a heavy emphasis on the most likely outcome.

The formula for the Mean is PERT Mean=[Optimistic + (4*Most Likely) + Pessimistic ] / 6
The formula for Standard deviation is PERT SD=[Pessimistic-Optimistic]/6

Using these figures, the project manager can assume that 68% of all possible outcomes
will be within one standard deviation from mean. 95% of all possible outcomes will be
within two standard deviations from mean, and 99% will be within three standard
deviations from mean.

Similar to PERT, VERT (venture evaluation review technique) and GERT (graphic
evaluation review technique) are available but not as common. Both are based on
probability network diagrams with branches.

3) Sensitivity Tornado – visualization to show the sensitivity of the project to individual

risks. The risks with higher sensitivities will be given the most risk mitigation attention.
An example is shown below. These sensitivities are derived by running Monte Carlo or

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 25 of 36

 PERT analysis on each risk.

From Project Management Professional (PMP)® Cert Guide by Gregory Horine and Asad Haque (9780137918935) Copyright © 2023
by Pearson Education, Inc. All rights reserved

4) Network Diagram Sensitivity Diagram (Critical Path)

A critical path work-flow diagram can help identify the relative impact of shifts in
duration for any given task or risk in the project.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 26 of 36

Step 5: Risk Response Planning
Risk responses are planned before the risk occurs and are integrated into budgets and timelines.
The time and effort of development of risk responses should be focused on the higher priority
risks or risk categories first, then can move down to the lower risks. Therefore, the prioritization
of risks should be known before the development of risk responses begins.

Prioritization methods may include rankings by categories/types of risks, individual rankings of

individual risks, or a combination.

Methods of ranking can be based on Qualitative Score, Quantitative Score, Team scoring based
on votes or consensus, and/or stakeholder ranking. Nominal Group Technique can also be used
which has each team member develop their scores independently first, then a consolidated
view is shared back out to the team for final refinement.

Once a priority list has been established, the team can begin working on responses to the risks.

The risk responses must be in line with the risk appetite and risk thresholds established for the
project. Potential risk responses are often identified in the risk identification phase, or can be
determined in this step using many of the same techniques that were used to identify the risks
themselves. After potential responses are identified, the team will decide upon the best risk
response for that risk and document this in the risk register.

Decision support techniques may be useful in measuring different risk responses and choosing
the desired course of action. Some decision support tools include:

1) Contingency Planning – For high risks, the project manager may assemble a team to
develop a risk response as if the risk had actually already occurred. The plan is then
documented and approved by the project sponsor, including authorization to deploy the
resources if the predefined triggering event of the risk occurs.
2) Force Field Analysis – Identifying driving forces for and against change that affect the
successful implementation of the project. Resistance to Change within the organization
and externally can be a risk that is addressed in the risk register and analyzed using this
tool. Change Management techniques can be used to preemptively mitigate these risks
and/or reduce the impact of resistance during the process.
3) Multi-criteria Selection Process – deriving a weighted score for each risk response option
based on the relative importance of our selection criteria. For example, if our criteria
are cost, time, and quality, then we could use a factor of 40% cost, 10% time and 50%
quality as our measures of importance, for example. Then each option is scored on
those three criteria and a weighted average is derived for each option.
4) Scenario Analysis – evaluate different risk response options in terms of cost and
effectiveness based on defined predetermined scenarios. Scenarios usually include
By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 27 of 36
 optimistic, best estimate and pessimistic assessments. This will demonstrate the
sensitivity of the project to the risk.
5) Simulations - to estimate to benefits and implications of different response plans versus
the effort and costs required to implement them. Simulations are useful to analyze the
impact to the critical paths within the project.
6) Stakeholder Tolerances
7) Residual Risks – the amount of risk left after risk response is implemented. For risk
transfer, this may be the insurance deductible or uninsured amount, for example. For
passive responses, this is the entire amount of the risk.

Once a risk response has been selected, the risk responses and response types are recorded in
the risk register. Risk response types are:

1) Avoid - Avoid exposure to the risk altogether

2) Passively Accept – do nothing
3) Actively Accept – do nothing to mitigate, but have a contingency plan and fallback
plan in place if the risk actually occurs
4) Mitigate.
a. Minimize the probability
b. Minimize the impact
c. Minimize both
5) Transfer.
a. Escalation to management when the proposed response falls outside the
authority of the team.
b. Third Party Transfer - Insurance, third party agreements, surety and other
solutions which transfer the negative outcome to a third party.

Several layers of risk responses can be developed for meaningful risks:

1) Risk Response - accept, avoid, mitigate, etc as decided at the start of the project
2) Reactive Contingency Plans - to be triggered if the risk occurs
3) Fall Back Plans – in case the contingency plan is ineffective
4) Continuity of Operations Plans (COOP) – disaster recovery

Risk Responses may include adding activities and updating the project scope, or removal of
activities from those same baselines.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 28 of 36

With active acceptance and mitigation plans, a contingency plan is also developed to cover the
loss of time, money or resources should the risk actually occur. This may include a contingency
reserve fund for project overruns. Escalation of risks to a higher-level governance is always an
option as a contingency plan, as is seeking guidance and decisions (such as a go/no-go decision).
Responses that require escalation include modification of project scope or budget, project
cancellation, or exceeding contingency reserve.

As a final step after mitigation plans have been decided, the proactive mitigation risk responses
are then captured as work to be done as part of the project. In an Agile project, the work would
be cataloged as a user story. In a waterfall project, the work would be captured in a work
breakdown structure. For example, a user story may be “the client needs our organization to
have a liability policy because of their corporate risk tolerance”. The action here is to get the
insurance policy; the project timelines and budget are adjusted to include this item as a part of
the project. The risk owners may be accountable for ensuring their respective work items get
completed.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 29 of 36

Step 6: Implement Risk Responses
Preemptive risk responses identified in the prior steps should be included in the project
planning itself as action steps to be taken as part of the project. Further action is guided by the
risk response plan and funded by the contingency reserve as appropriate.

Preventative and contingency plans should always be communicated to and agreed upon by the
stakeholders and decision makers prior to implementation. Even if the risk response is to accept
the risk, the organizational leadership needs to be aware of the risks being taken.

When a risk occurs in spite of mitigation and a contingency plan must be triggered, this also
should be communicated to the stakeholders during the project. The communication plan was
part of the Project Risk Management Plan and should be followed as the triggers occur.

When a contingency plan is implemented, new Secondary risks may be introduced. Secondary
risks are risk introduced because a contingency plan is now being implemented and may impact
or create risks. At this time, the risk manager will go through the steps above to identify the
new risks, measure them and mitigate them where possible.

Step 7: Monitor Risks

This step includes checking status of identified risks and monitoring the status of all action plans
implemented to avoid or to respond to the detection of a risk. This step also includes
monitoring the contingency reserve, assessing the projects’ performance indicators, and
effectively communicating with team and stakeholders.

New risks may also be identified and documented in the risk register at any time. Additionally,
as the project moves forward, the team’s assessment of probability and impact of existing risks
may change and this would be reflected in updates to the register. If the team now views a risk
as higher, this may cause an escalation or trigger a risk response. If the team views a risk as no
longer valid, the risk may be closed and retired.

A frequent, open discussion about risks on a routine basis is the best way to quickly identify
risks and issues as they occur. In daily Agile Scrum meetings for example, the most important
question to identify risks is ‘What is standing in your way?”. At the daily meetings, issues
(impediments, obstacles, and blockers) can be identified for further discussion and resolution.

The risk register should be updated and reviewed on regular intervals, and at any time a change
to scope occurs, or when a contingency plan has to be implemented.

The project manager may wish to log Issues separately from Risks. In other words, an Issue is a
risk that has already occurred despite mitigation strategies. An issue is a current event that
requires current and immediate action, while a risk is still pending and can have proactive

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 30 of 36

mitigation strategies. For example, system bugs are current issues that can be tracked
separately as they are discovered.

The project manager will track and report risk status on a risk-by-risk basis on the risk register.
The project manager will also track and report risks on a project-wide basis. On the project
wide basis reporting, the project manager can track the risk-based user stories, completion rate,
and number of user stories remaining. As new user stories are added to the backlog to mitigate
risk, these will be added to the reporting. The project manager may also want to update
Monte-Carlo simulations or PERT calculations to quantify what risks still remain.

Some tools that are commonly used to monitor risks include:

1) Data Analytics – explore known risks by reviewing documentation or data, identify

emerging risks and their causes/effects.
2) Reserve Analysis – During the earlier phases of the project, a contingency reserve for
time and budget was likely established. During the Monitor Risk phase, this reserve is
monitored as is the status of the corresponding risks. Once a risk occurs and is
addressed, the remaining reserve needs to be reviewed to ensure it still provides the
appropriate level of confidence.
3) Residual Impact Analysis - a response implementation plan may introduce new risks of
its own that need to be added to the risk register and addressed.
4) Review Risk Breakdown Structure (RBS) – The RBS is a hierarchy of potential sources of
risk that was likely used in the Identification of Risks Step early in the project. A review
of the RBS list may be helpful to continually identify new risks.
5) Risk Reassessment - repeat previous steps to identify new risks, evaluate current risks
and the risk management process, including updating sensitivity analysis results.
6) Status Meetings – review all open risks and trigger conditions, and action plans in
progress.
7) Trend analysis – how the risk profile changes over time and whether or not additional
actions are required.
8) Variance Analysis – compare actual outcomes to expected results. Increasing variances
warn of increasing risk, and may indicate that the baseline expectation will not be met.
For example, if a project is continuing to run further behind, this is an indication that
unmet deadlines is a real risk to be addressed.

Periodically throughout the project, the project manager will produce a Risk Report to keep
management informed on the project’s overall level of risk and individual project risks during
the project. Most risk reports include sections on:

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 31 of 36

 1) Overall project risk status
2) Sources of overall project risk
3) Planned risk responses for overall risk
4) Summary information on individual project risks
5) List of key prioritized risks with planned risk responses
6) Total threats and opportunities
7) Totals by risk category
8) Key metrics (such as number of risk tasks completed and outstanding, and summary by
risk status)
9) Contingency reserve status
10) Key trends
11) Summary and conclusion

At least once during the project, a Risk Audit is performed to review all risks and determine if
the risk management rules are being carried out as outlined in the risk register, and to assure
that the rules and triggers are still adequate for controlling the risk. A Risk Audit may occur
more than once for longer projects. The Risk Audit is the examination and documentation of
the effectiveness of risk responses in dealing with identified risk and their root causes, as well as
the effectiveness of the risk management process. All risk responses, effectiveness, impact and
lessons learned should be documented for future reference in this project and projects that
follow.

Project Managers should include Risk Audits in the overall Risk Management plan and include
the risk audit in the action steps and timeline of the overall project. The size and complexity of
the project will determine the frequency of risk audits.

To perform a Risk Audit, the following steps are taken:

1) Identify the risk auditor. The auditor is commonly the project manager but can be
someone else with a strong background in the project itself.
2) Interview of team members.
a. Ensure team is using the risk management plan
b. Effectiveness of risk responses and mitigations thus far
c. Identify any new risks
d. Reassess and validate the estimates of probability and impact and risk scores
3) Assess success of risk process – score answers from interviews

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 32 of 36

 4) Gather documentation including risk register, risk management plan, process
documentation, Q&A logs, issue logs.
5) Analyze data
a. How many of success criteria are being met
b. How close is the project staying to the original plan
c. Is the project on budget and on time thus far
d. What, if anything, needs to change to keep the project on schedule and budget
6) Generate report with conclusion
7) Conduct scheduled future audits and compare results

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 33 of 36

Final Wrap-up: End of Project Documentation
The project manager and risk owners are responsible for completing the risk register
documentation, documenting effectiveness of risk responses, and outlining issues that occurred
during the project. The team should also complete a post-mortem to capture lessons learned
for next time.

These artifacts can be extremely useful for upcoming projects as reference material, and for any
questions that may arise after project completion.

Documentation should include the final risk register and artifacts surrounding the risk
strategies, outcomes and measurements. Documentation should also include:

1) Risk Outcomes and Response effectiveness

2) Ranking Approach Efficacy
3) Intended and unintended outcomes
4) Secondary Risks introduced in contingency plans or workaround plans
5) Residual Risks that persist after project ends
a. Financial – insurance premiums, deductibles, spending needs
b. Quality, Reputational, other
6) Lessons Learned
7) Change Logs
8) Project-wide remaining risks and intent

Risk response effectiveness can be challenging to measure, but may be cataloged using
outcomes such as:

1) Risk avoided with avoidance strategy

2) Risk passively accepted and occurred
3) Risk actively accepted and occurred
4) Risk actively accepted and did not occur
5) Mitigation probability strategy implemented – risk avoided
6) Mitigation probability strategy implemented – risk occurred
7) Mitigation impact strategy implemented – no impact occurred
8) Mitigation impact strategy implemented – some impact occurred but was reduced
9) Mitigation impact strategy implemented – nearly full impact still occurred
10) Transfer steps taken
11) Escalation steps taken
12) Contingency plans implemented and how effectively
13) Workaround applied - workarounds occur when risk was unforeseen and unplanned.

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 34 of 36

 Additional commentary about nuances, mitigation strategies effectiveness, contingency plan
effectiveness, and other knowledge should be documented in a respository.

Risk Approach Efficacy is the determination as to whether the risk rankings and priorities were
appropriate. Measuring efficacy can be somewhat subjective, since higher risks that were
mitigated may not have occurred or were smaller because of the mitigation. The project
manager can assess whether risks that were ranked as low had an unanticipated impact on the
project. Similarly, the project manager can determine if risks retained or partially mitigated
were more or less impactful than anticipated. Resiliency and contingency reserves can be also
addressed in the assessment of efficacy.

Project-wide Residual Risk: At the end of each project, project wide risks still remain and should
be included in the final wrap up materials. This may include items such as unresolved issues
that were encountered but out of scope, or follow-up projects that may be needed to take full
advantage of work, or quality risks in the application, or compromises that were made to meet
the deadlines, and other items similar in nature. After the project closes and ownership
transitions to the business owners, business use cases and alterations often occur; the project
manager can use this time prior to closure to make sure future users are aware of potential red
flags or limitations. Topics to consider including in the project final comments include :

• Unanticipated Overuse - document the intent of the project usage. If the project was
only intended to be a short term fix or handle low volume, this should be noted.
• Environmental/Technical/Organizational Change - document the nature of the
environment in which the project outcome will be applied and what it is and is not
expected to withstand, including technical and stakeholder requirements that were to
be met by the project.

Documentation of these items will avoid any misuse or misunderstandings of future

users or stakeholders.

Conclusion
According to the Project Management Institute, if the domain of “Uncertainty” is effectively
executed, the following outcomes can be expected.

1) Proactive exploration and response to uncertainty

2) Awareness of project environment (technical, social, political, market, and economic)

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 35 of 36

 3) Awareness of interdependencies of multiple variables on the project
4) Capacity to anticipate threats, opportunities, and understand consequences of issues
5) Deliver project with little to no impact from unforeseen events
6) Opportunities to improve performance and outcomes were realized
7) Effective utilization of cost and schedule reserves to maintain alignment with objectives

By Cynthia Smethers, FSA, MAAA, MBA. Rights Reserved. Page 36 of 36