Risk Lifecycle Management

Introduction

The absence of a disciplined and consistent risk management approach can lead to significant delays and even failures in enterprise transformations. When transformation risks are not properly assessed, scored, and mitigated, they can quickly escalate into issues that demand additional time, resources, and budget for corrective actions. The risk management lifecycle is often overlooked in audits, both internal and external, which contributes to the high percentage of transformation delays and failures.

Risk management is not just a process; it's a lifeline for enterprise transformations. It plays a pivotal role in identifying, assessing, and mitigating the potential threats and uncertainties that may affect the successful outcome of a product, program, project, or initiative. Risk management becomes even more critical in the context of enterprise transformations, which involve significant changes in the organization's structure, culture, processes, systems, capabilities, business partners, markets, etc. Its role as a lifeline provides a sense of reassurance and security in the face of uncertainty, making the stakeholders feel more at ease.

Risk management in transformations is not a solitary endeavor. It requires a systematic, proactive, and disciplined approach that covers all phases of the transformation lifecycle, from proposal planning to executing, closing, and post-evaluating operational results. This emphasis on a proactive and disciplined approach instills confidence in the audience about the robustness of the risk management process. More importantly, it necessitates a collaborative and cross-functional effort that engages all relevant stakeholders, including the transformation sponsors, leaders, teams, and beneficiaries. Their active participation and contribution are crucial in identifying, assessing, and mitigating the potential risks that could impact the transformation's success, highlighting the need for teamwork and shared responsibility.

Risk Management Origins in Transformations

Where does risk management originate? In my experience, transformation risks are typically initially identified and qualified in the business case, justifying the need for the transformation. Those initial risks come in one or more forms in the business case that can include:

• Business Case Assumptions: Every assumption made in a business case should have a corresponding risk in the initial risk “Risk, Action, Issue, and Decision” (RAID) log if the assumption is not realized.
• Business Case Transformation Risks (if undertaken): If the transformation is undertaken, the initial transformation business and systems risks should be part of the business case. However, these risks are not always captured in the business case, which can lead to oversight and potential issues during the transformation process.
• Business Case Risks (if not undertaken): The organization typically faces risks if the transformation is not undertaken or taken at a slower pace. These risks include internal organizational operations, planned acquisitions, and market risks.

In addition to fully capturing the transformation business case risks, the next set of initial risks typically originates from the system integration (SI) partners’ proposals and subsequent statements of work (SoW). As with the business case, these proposals and SoWs typically have engagement assumptions and risks documented.

Often, these identified risks may be captured in a log, yet the risk dimensions may not have been fully qualified and quantified so that leadership can score, prioritize, and manage them.

Risk Dimensions, Scoring, and Metadata

Risk dimensions are the elements that can be used to describe, qualify, quantify, and analyze a risk. Examples of common risk dimensions can include the following:

• Probability of occurrence.
• Severity of the impact on transformation goal or objective if the risk is realized.
• Severity of impact on post-transformation operations and support if the risk is realized.
• Severity of impact on business partners if the risk is realized, etc.

These dimensions should also have a scoring criterion to assess and score the risk in each dimension. For example, the probability of occurrence can range from a score of “1,” which indicates a very low to zero probability of occurrence, to a score of “5,” which indicates a better than 80%+ probability of occurrence.

The severity of the impact dimensional scoring criterion should also be qualified and quantified based on the subject of impact. For example, if the severity of the impact on the approved transformation schedule delivery objective is at risk, a score of “1” could mean no effect on the schedule delivery. A score of “3” could mean a delay, but a workaround has been identified, while a score of “5” could mean a significant delay in delivery.

For each risk dimension defined and scored, a total score should be calculated by multiplying the probability of impact by each severity of impact dimension defined. The total score assists the transformation team, and leadership ranks the risks for mitigation actions.

The accompanying risk metadata should typically include the risk creator, who is assigned to mitigate the risk, the value stream raising the risk, the business unit that could be impacted if the risk is realized, etc. The total risk score and associated metadata provide the basis for developing the mitigation or ‘step down’ plan to mitigate the risk.

Risk Mitigation or Step-Down Plan

A risk mitigation or step-down plan outlines the actions and resources needed to reduce the probability of occurrence or the severity of the impact in a subject area of a potential risk. It aims to minimize the adverse effects of a risk on the objectives and performance of a project, program, or organization. By developing and executing a risk mitigation or step-down plan, the transformation team and leadership can proactively manage the uncertainty and complexity of the change process.

The step-down plan should include the following elements:

• A clear description of the risk and its sources.
• A total risk score.
• A list of the mitigation actions required and the expected outcomes.
• A timeline for implementing the mitigation actions with an estimated completion date for each action and expected risk score post-completion.
• A corrective plan in case the risk is realized as an issue.

Monitoring, reviewing, and evaluating the progress and effectiveness of the step-down actions should be part of the regular risk review meeting. A key question regarding these mitigations or step-down plans is whether they should be incorporated into the transformation schedule.

That question depends on the need for visibility to the rest of the team and the transformation leadership. My preference depends on how robust a transformation plan and schedule are being managed. If the transformation plan and schedule are part of a more extensive portfolio with shared resources, the mitigation plan should be part of them.

Wrap Up

As with the risk mitigation plan, any risk realized as an issue should also have a corrective action plan that addresses reducing the realized impact on the transformation goal and objectives. Yet if the risk log review is robust and disciplined, and there are escalation paths in place, the number of risks realized as issues should be minimal.

Identifying and scoring risks, documenting, monitoring, and measuring the mitigation or step-down plans are critical to minimizing the number of risks being realized as issues. Risk or RAID logs exist in many “Project Portfolio Management” (PPM) platforms or can quickly be built into SharePoint lists, JIRA, etc.

The log should not be managed in individual Excel or Word documents, regardless of the platform. It should be centralized and available for any team member to review. Versioning should be turned on so that auditors can also find when the updates occurred and who updated the log.

One good metric to assess the robustness of a risk management process would be to trend the ratio of issues to risks mitigated over the lifecycle of the transformation and portfolio. What does that trend speak to concerning the identification and management of risks? One last question for the reader: Where is your risk log maintained?