Introduction
Any seasoned professional who has led or managed products, projects, programs, portfolios, platforms, or processes understands the value of disciplined risk management. Various frameworks, such as VRIO (Valuable, Rare, Inimitable, Organized), PESTLEED (Political, Environmental, Societal, Technical, Legal, Economical, Ethical, Demographic), and TECOP (Technical, Environmental, Commercial, Operational, Political), address the VUCA (Volatile, Uncertain, Complex, Ambiguous) world that leaders and managers navigate, regardless of whether they use planned, adaptive, or hybrid approaches in product development and support. Additionally, the rise of numerous standards and regulations and the challenges introduced by the latest technological advancements like artificial intelligence further emphasize the importance of effective risk management.
This whitepaper explains how to implement risk management with SpiraTeam and SpiraPlan’s - Inflectra’s enterprise-level software development and project management solution.
Are you keen to deepen your knowledge of risk management and learn about the various standards? Explore our risk management resources here!
If you're ready to experience the unparalleled capabilities of Spira, start your free trial today!
Section I: Why Think of Risks?
Risk management literature defines risks as any uncertain event that can positively or negatively impact outcomes. Although categorizing these uncertainties can be challenging, predicting incorrect assumptions or delivery constraints can help identify known risks. These risks can be related to variables such as scope, schedule, cost, quality, resources, procurement, communication, integration, stakeholders, and the rigor of the risk management process. These categories, known as the Risk Breakdown Structure (RBS), provide a framework for organizing risks.
Additionally, considering extreme uncertainties in these areas is essential. Examples include using outdated tools that lack traceability and auditability or facing external conditions like legalities, regulations, and compliance that may challenge the delivery of planned outcomes.
While product and project management often use earned value management to compare planned to actual performance with lagging indicators and forecast delivery issues with leading indicators, it's crucial to recognize that a lack of exposure and training in risk management can contribute to performance challenges. Understanding the various stages of risk management helps in selecting appropriate KPIs to measure the effectiveness of the risk management process itself
Overview of Risk Management Lifecycle
The risk management lifecycle outlines how risks will be managed throughout the project. This plan includes the risk management process, which defines how to conduct risk management activities. This approach is also applicable in agile frameworks, guiding agile teams in managing risks throughout an initiative. As a result, features and user stories can begin identifying risks, incorporating elements of the risk register, and addressing potential impediments to delivery within the product backlog.
Figure 1: Risk Management Lifecycle
Subsequently, the team can proactively categorize various risks in the risk register. These categories may include commercial or compliance risks, where external environmental factors are identified and assessed. This ensures that features identified for the release plan of the minimum viable product align with strategic, measurable organizational value. Identified risks can be measured to build contingency reserves at both iteration and release levels.
|
Contingency Reserves: Identified risks help build reserves at both iteration and release levels. |
Additionally, the number of risks (both threats and opportunities) can be tracked across iterations using a risk profile chart (also known as a risk exposure chart). This chart, represented in the information radiator/’big visible charts’ as a burndown chart, helps prioritize features and secure the necessary support from management in terms of resources and capital funding.
|
Risk Profile Chart: Tracks the number of risks (both threats and opportunities) across iterations, displayed as a burndown chart. |
Proactive risk identification enables the team to assess the essential support needed, such as process value and technical value stories, to support future features. This assessment also garners support from risk owners outside the agile team to help meet the team's objectives. Identifying and analyzing risks aids in prioritizing minimal marketable features during iteration planning and appropriately breaking down user stories, setting up iterations for success.
|
Iteration Planning: Prioritize minimal marketable features and break down user stories for successful iterations. |
Continuous monitoring of risks and identification of secondary risks during daily standups can help develop contingency plans, ensuring the team has the support needed to meet their commitments. This practice empowers the team to raise risks in advance, refining the product backlog to accommodate risk mitigation steps in subsequent iterations. Risk response steps can be included in task breakdowns during estimation exercises in iteration planning, helping the team maintain a sustainable pace with value-added user stories.
As demonstrated, risk management principles significantly impact agile approaches. To learn more about risk response strategies, categorizing risks, and increasing risk transparency in agile release plans, check out the Risk webinar archives.
KPIs to Evaluate Risk Management
One of the biggest risks in risk management is prematurely choosing metrics that don't align with a team's "ways of working" or an organization's "compliance considerations" for traceability and auditability. For example, the metric "Number of risks identified" is useful but similar to measuring product quality solely by the number of defects found. This approach can motivate testers to find more defects without necessarily improving quality. Likewise, focusing only on the number of identified risks doesn't fully evaluate the risk management process. It's also essential to identify risks missed in certain RBS categories and assess the effectiveness of the risk management process across its various stages
Table 1: Generic KPIs for Risk Lifecycle Stage
|
Risk Lifecycle Stage |
Generic List of Risk Key Performance Indices |
|
Risk Identification |
Number of risks identified by risk type |
|
Risk Analysis |
Number of risks that have been thoroughly analyzed Time taken to complete risk analysis activities |
|
Risk Evaluation |
Number of analyzed risks that have been evaluated and prioritized Alignment between risk evaluation and the organization's risk appetite/threshold/tolerance |
|
Risk Response |
Number of high-priority risks that have an assigned risk response strategy Effectiveness of risk response strategies (e.g., reduction in risk likelihood or impact) Time taken to implement risk response strategies |
|
Risk Monitoring and Control |
Frequency of risk monitoring and control activities Number of risks that are actively monitored |
Section II: Implementing Risk Management with Spira
Step 1: Decide on the RBS to Track
Similar to having a team charter to agree on the ways of working, the risk breakdown structure needs to be agreed upon. At a minimum, this RBS definition should include the types of risks, the explanation of the risk scales, and the numerical scores associated with them. Given below is an example of a 3-scale definition with numerical score associated with them.
Table 2: Example of a Risk Breakdown Structure (RBS)
|
Risk Type |
Low (1) |
Medium (3) |
High (5) |
|
People |
Recurrent project Schedule is predictable |
Some SMEs are loaded |
External contracting |
|
Budget |
Sufficient reserve is available |
Cost estimates are not quantified |
Contracting & Consulting |
|
Scope |
Similar projects have been done before |
Resources are on learning wheels |
Untested technology |
|
Quality |
Predictable Policies |
No clear definition of requirements or processes to use |
Not having an ALM to reuse test cases or perform regression |
|
Stakeholders |
Limited and few stakeholders |
Multiple stakeholders |
New and changing |
|
Risk and Change Controls |
Well established |
System is in place Unclear policies |
Non-existing system |
In Spira, you can use the templates section to establish the risk breakdown structure in terms of the risk types required to be considered.
Step 2: Set up Risk Properties
The next step is to set up the two essential properties of the risk: probability and impact. For both probability and impact, an ordinal scale frequently used with a numerical score needs to be agreed upon. These are illustrated in Figure 2 below. Please note that the color and position can also be updated as required.
Figure 2: Essential Risk Properties Setup
SpiraPlan also supports 99 custom properties for risks. So, if additional properties are required to make consistent definition to the risks, please evaluate them.
Step 3: Set up Risk Workflow
The next step is to set up the workflow for the risk management lifecycle. This workflow tells how the risks move through the lifecycle. Therefore, the exact workflow changes depending on the nature of the product, the process followed by the team based on the delivery approach followed, and the compliance considerations mandated by the standards and regulations binding the organization and the product. For example, Figure 3 describes the default Library Information Systems template workflow supported in SpiraPlan.
Figure 3: Risk Workflow
Step 4: Optionally Enable the SpiraApps for FMEA
The regulatory process followed within product delivery may mandate the use of Failure Mode Effects Analysis (FMEA). This process requires an additional property called detectability. Detectability uses a reverse scale: the less detectable a risk is, the higher its score; the more detectable a risk is, the lower its score. This ensures that the least detectable problems take higher precedence in establishing controls. An example of the FMEA detectability score is shown in Table 3. The product of probability, impact, and detectability is known as the Risk Priority Number (RPN) and is used to prioritize and treat risks.
Table 3: Example of the FMEA Detectability Score
Step 5: Establishing Reports and Graphs
The final step is to establish the reports and graphs to guide you in evaluating the effectiveness of the risk management process. While SpiraPlan gives detailed and summary reports and risk-related widgets in the product dashboard, some new custom reports and graphs may have to be established. Let us review them in Section III.
Convinced that this “risk lifecycle” process is a good fit for you?
Take the first step by signing up for a free trial. Experience firsthand how Spira can streamline your risk management.
Section III: Implementing Risk KPIs
Part 1: Risk Identification
Risk Identification is the first stage for risks. The goal of this stage is analogous to brainstorming where no idea is discarded but all ideas are entered for further consideration. A self-organized and high-performing team should be empowered to identify risks across the product delivery continuum and not based on domain knowledge alone.
Good Practices:
- Team and stakeholders agree collectively on the risk types and the probability and impact scores.
- Provide granular permission to allow everyone to create and view risks. Prioritization happens only at evaluation by people closer to delivery.
- Don’t just measure the number of risks but measure the number of risks by status or the risk types!
STEP-BY-STEP INSTRUCTIONS
Follow the steps in the Risk Identification article for more details.
Part 2: Risk Analysis
Applying the workflow operation, “Analyze Risks,” the next step involves the team members analyzing the risk. The analysis also does not immediately lead to prioritization or controls. This step is analogous to the “Expert Judgement” in project management, where the appropriate experts are consulted to qualitatively agree on the probability and impact of the specific risk being analyzed.
Risk Analysis Good Practices:
- Make sure that there is a responsible owner assigned to the risk
- Make sure that probability and impact scores are not arbitrarily selected but carefully weighed. So, add comments to make the reason behind the probability and impact selected transparent to others.
STEP-BY-STEP INSTRUCTIONS:
Follow the steps in the Risk Analysis article for more details.
Part 3: Risk Evaluation
Continuing with the “Evaluate Risk” operation further in the workflow, the risks can be evaluated. A prerequisite for this evaluation is that both the probability and impact scores are filled and are agreed upon for that risk. For regulatory processes following the FMEA approach, the detectability score is also filled and agreed upon for that risk. The risk exposure or the RPN is then used to evaluate which risks are urgent lists that need to be addressed or prompt lists that need to be monitored.
Good Practices:
- Make sure that there is a documented risk management process where the organizational risk appetite, project risk threshold, and stakeholder risk tolerance are available. Often, these details are not documented for every risk. So, avoid using the custom properties for these elements at the risk level. This information can be captured as custom properties at the product definition level.
- The risk summary widget can be used to prioritize the risks that need to be treated further. When FMEA is used, additional widgets in the product dashboard can be used.
- Due to the nature of the risk, don’t just focus on risks identified but also look for risks “not identified” or “not enough risks identified” against the risk types. Avoid surprises by questioning the team on these areas. This will help improve stakeholder satisfaction in the risk management process.
STEP-BY-STEP INSTRUCTIONS:
Follow the steps in the Risk Evaluation article for more details.
Part 4: Risk Treatment
In the "Treat Risk" stage of the workflow, risks can be effectively managed. It is crucial that each risk has a responsible owner at this point. Risk treatment often involves mitigating the risk by brainstorming ideas that collectively reduce the risk exposure or the Risk Priority Number (RPN). This reduction can be achieved by lowering the probability or impact of the risk, or by increasing its detectability when FMEA is used.
When mitigation reduces the risk's influence, it is essential to evaluate the controls associated with the risk. Additionally, it is important to ensure that tasks linked to the risk are listed and tracked, so their progress can be monitored and controls can be adjusted for better risk management.
Good Practices:
- Make sure that the risk treatment is measured against active priority risks. This means certain statuses like “Identified”, “Closed” and “Rejected” are removed from consideration.
- Watch out for anti-patterns during this monitoring stage by looking beyond the obvious. These patterns begin with the following:
- Mitigations Not Updated in 2 Weeks
- Mitigation Review Unaligned with Risk Review
- Mitigations with Past Review Date
- Risks without Control Tasks
- Risks with Unassigned Control Tasks
STEP-BY-STEP INSTRUCTIONS:
Follow the steps in the Risk Treatment article for more details.
Part 5: Risk Monitoring
Closely tied to the risk treatment stage is risk monitoring. Over time, some risks may be rejected or retired (closed), while others may escalate to active urgent lists due to increased priority or impact. New risks may also emerge. Additionally, changes in personnel (promotion, voluntary or involuntary departure) may leave certain risks unassigned. Therefore, it is crucial to constantly monitor risks to ensure they are properly managed and assigned.
Good Practices:
- Continuously assess risks in the urgent lists but establish a cadence to review the prompt list and other low-priority list.
- Never lose sight of the people and processes that play into the risk management lifecycle. So, look for additional patterns that may leave risks in a dormant state potentially impacting the outcome negatively. Some of these patterns include the following:
- Missed risks in the Risk Type (or the RBS)
- Unassigned owner for a Risk
- Missing Impact or Probability for a Risk
- Missing Review Date
- Long Review Cycle
STEP-BY-STEP INSTRUCTIONS:
Follow the steps in the Risk Monitoring article for more details.
Conclusion
Risk Management is an art! Dr. Sriram Rajagopalan, Inflectra’s Global Head of Agile Strategy and Training and Learning Services, says, “If one does not manage risks, risks will manage them.” (Rajagopalan, 2020). Risk Management is not an activity done at the early stages of a project but is constantly evaluated. It is a means through which ‘continuous learning’ improves the knowledge capital of the projectized organization.
It's time to elevate your approach to risk management!
Arm yourself with Inflectra’s technological edge and align your project outcomes seamlessly with business objectives. The result? A healthier bottom line, optimal resource utilization, and a culture of continuous improvement and excellence.
Take the first step by signing up for Spira free trial!
For more information on how to implement risk management in your organization using Spira, feel free to contact us sales@inflectra.com