Since projects build new products and services, it should be expected that they will encounter some surprises along the way. These might be pleasant surprises, but more often than not, they are undesirable.
Rather than just hope for the best, the responsible thing to do is to plan for these uncertainties. This is where risk management comes into play. Let’s start with some definitions.
Risk
A risk is an uncertain event or condition. If it occurs, it will have a positive (good) or negative (bad) effect on the project or a project objective. We call positive risks opportunities and negative risks threats. For example, if we were planning an open-air picnic for the grand opening of a petting zoo, we could have a negative risk (threat) that rain would lower attendance. However, pleasantly warm weather could attract a much larger than expected number of people, and we can make extra income selling ice cream (an opportunity.)
Risk Trigger
A risk trigger is an event or situation that indicates that a risk is about to occur or has occurred. We can think of risk triggers as warning signs or risk symptoms. For example, dark storm clouds gathering could be a risk trigger for rain at the petting zoo grand opening picnic.
Issue
An issue is a risk that has occurred. It is no longer a possibility of harm, loss or gain, so we cannot call it a risk anymore. Instead, it has converted from being a risk to being an issue. Issues are often recorded in the project Issue log. An example would be heavy rain at the picnic. Now the risk has moved from being a threat to something we have to deal with.
Risk Management Processes
The PMBOK® Sixth Edition outlines the following risk processes. These steps provide a valuable framework for reviewing risk management activities.
Plan Risk Management
The first step, Plan Risk Management, defines how we will conduct the risk management activities for our project. Since projects vary in size, complexity, importance and development approach, we should tailor the risk management approach to meet the project circumstances.
For example, the risk management process we create for a 6-person team erecting a big-top tent one afternoon will have a different level of detail and rigor than a 300-person project to develop and test a medical device over 18 months.
Risk Appetite. The amount of uncertainty an organization or person is willing to accept in anticipation of a reward. Some organizations have a low appetite for risk and prefer to pursue low-risk endeavors. Others are happy to pursue a variety of initiatives knowing full well only a small percentage will be successful.
Risk Threshold (used to be called Risk Tolerance). The measure of acceptable variation around an objective that reflects the risk appetite of the organization and stakeholders. For example, a 10% cost overrun is acceptable, but anything above that is not.
Risk Management Plan
An output of the Plan Risk Management process is the (imaginatively named) Risk Management Plan. This document describes how the risk management process will be tailored and undertaken for the project. It can be its own stand-alone document or a sub-section in the project management plan. Common sections include:
Risk Strategy – Describes the general approach to managing risk on this project.
Methodology – Defines the specific approaches, tools, and data sources that will be used to perform risk management on the project.
Roles and Responsibilities – Defines who will be responsible for each type of activity described in the risk management plan.
Funding – Identifies the funds needed to perform activities related to project risk management and describes any contingency and management reserves.
Timing – defines when and how frequently the risk management processes will be performed. It also identifies the risk management activities to be included in the project schedule.
Risk Categories – Outlines the groupings for individual project risks. There are many different ways we can categorize risk. Some common ones include:
- Technical – such as risks relating to the scope, technology or technical processes used
- Management – for example, risks relating to our organizational structure, recruiting or communications
- Commercial – E.G., suppliers and vendors risks, procurement and subcontractor risks
- External – Exchange rates, competition, regulatory
These risk categories and subcategories can be documented and visualized via a risk breakdown structure (RBS).
Stakeholder Risk Appetite – Description of the stakeholder risk appetites and the thresholds around what they are willing to accept for each project objective. For example, up to 2-weeks variance around scheduled release dates. These thresholds are used to inform the definitions of risk probability and impact.
Definitions of Risk Probability and Impact – These are unique to our project context and reflect our key stakeholders’ risk appetite and thresholds. We can generate our own definitions of probability and impact levels or start with the organization’s definitions.
For example, we may define the following values for Probabilities and Impacts to Schedule, Scope and Budget:
Probability and Impact Matrix – this table combines risk probability and risk impact for both threats and opportunities. It shows the severity of risks with various probability and impact scores.
For example, we might estimate the threat of heavy rain at the picnic to have an Impact score of Very High (0.8) and a Probability of Moderate (0.5). Severity is the product of Impact and Probability.
Severity = Impact x Probability
= 0.8 x 0.5
= 0.4
(Shown with the red ”R” above)
Likewise, we may rate the opportunity of “Warm enough to sell ice-cream” as Impact Moderate (0.2) and Probability Low (0.3), giving a Severity of 0.2 x 0.3 = 0.06 shown with “IC”.
Reporting Formats – This defines how the outcomes of the risk management process will be documented, analyzed and communicated. This includes the format and fields in the Risk Register, which is the risk list or catalog used to track our project risk.
Tracking – This final section in the Risk Management Plan documents how risk activities will be recorded and how risk management processes will be audited.
All of these sections collectively make the Risk Management Plan.
Some small agile projects do not produce a Risk Management Plan. Instead, they just create a risk list. By doing so, they accept any risk management approach described in the project charter (which for an agile project is likely brief also), or provided by the PMO or Agile Community of Practice. While agile methods may appear to not document their approach to handling risks, it is a core part of prioritizing work and evaluating progress.
Agile projects prioritize user stories based on business value and risk, aiming to drive down risk (avoid or mitigate threats) early in the life cycle. Practices such as risk-based spikes, risk-adjusted backlogs, and risk burndown graphs are used to address and monitor risks throughout the project life cycle.
Identify Risks
Identify Risks deals with finding individual project risks and sources of overall project risk, along with documenting their characteristics. The process combines the following activities.
- Expert Judgment – use individuals or groups who, based on their experience and domain expertise, can generate insights into individual activity risks and sources of overall project risks. Again, we should engage the team in this activity. The doer’s of the work often have better insights into what can go wrong than the coordinators do.
- Data Gathering – techniques for data gathering include:
- Brainstorming – facilitated workshops of multidisciplined participants to generate and record potential risks.
- Checklists – Using lessons learned documents, old risk registers and issue logs from similar projects. Sometimes generic industry lists of common risks are available to help prompt ideas.
- Interview – Risks can be identified by interviewing project participants beyond the immediate team, other stakeholders and subject matter experts.
- Data Analysis – techniques for analyzing the data we generate include:
- Root cause analysis with cause and effect diagrams – A technique designed to uncover the underlying risk. It often uses cause and effect diagrams such as fishbone diagrams.
- Assumption and constraint analysis – Project estimates of benefits and value delivered are based on assumptions and constraints. This activity examines these assumptions and constraints and asks what might jeopardize them or make them invalid. This can help identify risks.
- SWOT analysis – SWOT is an acronym for Strengths, Weaknesses, Opportunities and Threats. SWOT Analysis examines the project from each of these perspectives starting with the strengths and weaknesses of the project, organization and business area in general. From the strengths, opportunities are investigated, and the weaknesses examined as a potential source of threats.
- Document Analysis – Risks can be identified by reviewing project documents, such as plans, constraints, previous project files, contracts, agreements, and technical specifications. Uncertainty, ambiguity or inconsistencies may be indicators of potential risks.
Risk Register – After completing these activities to identify risks, they are documented in the Risk Register. The level of detail captured in the risk register will vary based on the size, complexity and criticality of the project. As a minimum, the risk register should contain:
- List of identified risks – an ID for unique tracking and a description of the risk.
- Potential risk owner – Someone identified to track, monitor and potentially help manage the risk
- List of potential risk responses – Where risk responses were identified they are recorded for consideration during the Plan Risk Responses stage.
Perform Qualitative Analysis
Perform Qualitative Risk Analysis is the process of categorizing and prioritizing the individual project risks for further analysis. It includes assessing their probability of occurrence and impact and other characteristics.
Risk Classification – There are several ways we can classify risks. Two popular approaches are effect-based and source-based. Effect-based classification looks at the effect of the risk on:
- Time
- Cost
- Scope
- Quality
- Resources
Source-based classification that looks at the risk origins, such as:
- Internal to the project
- External to the project
- Technical
- Non-technical
- Industry specific
- Generic
Assess Impact and Probability
For each risk identified, assess and assign impact and probability scores. These scores may be refined with numerical value within the next step, “Perform Quantitative Risk Analysis”, for now, we are just assigning basic scores such as High, Medium or Low.
For example, with a threat about having no experienced people to help put up the big-top tent for a launch event. We might assign the probability of that threat occurring as High on a (Low, medium, High scale) and the impact to the project also as High.
Some organizations also determine Severity or Risk Exposure score as the product of Impact and Probability.
Risks can be ranked by their severity (risk exposure) scores, and we may decide not to actively manage low probability, low impact risks.
Perform Quantitative Analysis
Perform Quantitative Risk Analysis is the process of numerically analyzing the combined effect of identified individual risks and other sources of uncertainty on the overall project objectives. It involves numerical analysis techniques such as:
- Expected monetary value
- Decision tree analysis
- Monte Carlo simulation
Expected Monetary Value – By assigning a financial value to a risk impact and a percentage to the probability scores, it is possible to calculate an expected monetary value for a risk. For example, if we assess the probability of a hot day at our picnic is 25% and our estimate for ice-cream sales at $2,000, then the expected monetary value would be:
Expected monetary value = probability x Impact = 25% x $2,000 = $500
Expected Monetary Value, Decision tree analysis and Monte Carlo simulation are discussed in more detail in task 3.2.5 Appraise Stakeholders of Value Gain Progress.
Plan Risk Responses
Plan Risk Responses is the process of developing options, selecting strategies, and agreeing on actions to address overall project risk exposure, as well as to treat individual project risks. It is the deciding what to do about the risks we have identified.
Expending the time and costs to undertake risk identification and analysis but then not doing anything (or enough) to avoid or reduce the threats, or exploit the opportunities, is wasteful to the organization. It is also demoralizing for the team. Instead, we should ensure the risk responses developed are added to the project plan or product backlog, so they can be implemented if/when the risk occurs.
For harmful risks (threats) we want to remove, avoid or reduce the likelihood of it occurring or its impact should it happen. For positive risks (opportunities), we aim to increase its likelihood and maximize the outcome. The common goal is to maximize value by eliminating or reducing losses and boosting gains.
Threat Response Strategies
Threats, the harmful risks, we want to avoid, side-step, reduce as much as possible. The generally accepted threat response strategies are shown below.
- Escalate – Transfer to someone outside the project. Convince the powers that be, that this risk is significant enough that it should be handled at the program or portfolio level.
- Avoid – take evasive action. Find a way to eliminate the source of the risk. Maybe use a different approach or technology that does not contain the risk.
- Transfer – Move the risk to a group better equipped to handle it. This can include taking out insurance which exchanges exposure for a known premium.
- Mitigate– Make the risk smaller. Through actions, reduce the probability of the risk occurring or the impact to the project should the risk occur.
- Accept – For low priority risks, or those we cannot avoid or reduce, we may have to accept the risk. Here the best thing we can do might be to create a contingency reserve to help deal with the risk should it occur.
Opportunity Response Strategies
Opportunities represent the positive things that can go in our favor. These we want to guarantee, make the most of and share with as many people as can benefit from them. Strategies include:
- Escalate – Transfer to someone better able to ensure the opportunity occurs. Maybe someone with more influence or authority at the program, portfolio and sponsor level.
- Exploit – Try to drive the probability up to 100% and maximize impact. Perhaps by assigning our best people to it early and giving them everything they need to ensure it occurs.
- Share – Transfer the opportunity to others, either inside our organization or outside to maximize the value derived and captured.
- Enhance – Similar to exploit, but to a lesser degree, try to increase the probability and impact. Focus attention on the causes and prioritize this work for early delivery.
- Accept – Sometimes, there is not much we can do to increase the likelihood of an opportunity occurring (such as good weather). All we can do is be ready and prepared to take advantage of it so it does not pass us by unrealized.
Implement Risk Responses
Implement Risk Responses deals with the process of implementing agreed-upon risk response actions and plans. It helps ensure the risk responses selected get actioned by generating change requests and adding work packages to the WBS or items to the product backlog.
Monitor Risks
Monitor Risks is the process of monitoring the implementation of agreed-upon risk response plans. It also includes tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project.
The effectiveness of the risk management process is monitored through techniques such as audits, meetings and data analysis of technical performance and reserves. Based on how the risk management activities are performing, updates to the project plan, or product backlog might be required. Change requests and updates to risk logs, issue logs and lessons learned register might also be necessary.
2.3.1 Determine Risk Management Options
Traditional predictive project management approaches typically contain defined risk management steps and specific risk-oriented deliverables and documentation. Risk management is a conscious, deliberate activity.
Agile approaches have less visible practices focussed on risk management. However, that is not to say risk management is absent from agile approaches. On the contrary, it could be argued that risk management is central to agile practices. By prioritizing the backlog based on business value and risk reduction, opportunities are exploited and threats avoided or mitigated.
Proof of concept spikes, short iterations, frequent customer demos and feedback gathering are also focused on risk management. There may be fewer artifacts and deliverables with “risk management” in their name, but risk management principles are central to agile, and many hybrid approaches.
2.3.2 Iteratively Assess and Prioritize Risks
Risk Management is always an iterative process. Even with traditional predictive projects the final Monitor Risks step includes the ongoing assessment and processing of risks. So, rather than viewing the risk management process as a linear, single-pass procedure, it can be more helpful to view it as iterative.
Now we see the Monitor Risks step links back into the ongoing process of Identify Risks that looks for new or escalating risks and runs them through the risk management process. The process is cyclical and iterative until the project completes. Then it can be handed to operations or program management to assist with long-term benefits management.
Within agile life cycle projects, these activities repeat every iteration.
Viewed with an eye towards risk management, the agile planning meetings and events can be used to ensure risk management activities are occurring on the project. Iteration planning sessions can be used to educate the product owner on selecting stories based on business value and risk reduction.
Daily stand-up meetings ask team members if they have any impediments or blockers that might be early warning signs of threats. Demo’s confirm the team is building the right product and it is fit for business purposes. Finally, retrospectives can be used to ask if we are managing our risks effectively and are there any new or escalating risks we need to take action. Also, what experiments or opportunities can we pursue?
Risk-Adjusted Backlogs
Risk-adjusted backlogs is the name given to backlogs that have risk response activities incorporated into them. They are created by working with the Product Owner to add threat avoidance and mitigation activities and opportunity enablement work into the backlog.
It is a collaborative discussion between the Scrum Master or team representatives and the product owner. The team can explain the risk impact, should it occur and the product owner estimates and compares the expected monetary value of a risk with the value of the stories in the backlog.
Ultimately it is the product owner who prioritizes the backlog. However, when they learn about the potential impacts of risks, they can decide if and where risk response action should be placed.
By avoiding or reducing threats closer to their identification, the horizon of risk that the project is exposed to shortens. In addition, by making changes earlier in the lifecycle, the costs of changes are reduced. On the flip side, capitalizing on opportunities is like getting investments done early; they have longer to accumulate. These are the compounding benefits of early and rapid risk & opportunity management.
Getting the risk response actions into the backlog is how these tasks are scheduled and undertaken. We want to ensure that all our risk management work is not supplemental to the project plan but baked right in. All too often, risk management is an activity done upfront or alongside the project but never really integrated into the day-to-day activities of the project. By inserting these new stories into the backlog, we drive risk management actions from analysis to action.
Deliverables and Tools
- Risk Management Plan
- Risk Register
- Risk-Adjusted Backlog
- Implement Risk Response Plan
- Organizational Process Assets
- Meetings
- Workshops
- Expert Judgement
- Risk Analysis Techniques
- Update Risk Register
- Risk probability and impact assessment
- Proactively tackle risks
- Risk based spike
- Monitor and manage risks
Related Topics
Further Reading
- Article: Agile Risk Management
- Article: Creating a Risk-Adjusted Backlog
Congratulations! You score 100% and won the 2.3 Manage Risk Badge.