Most project managers are used to making a qualitative risk analysis in two dimensions: the likelihood that an event will occur, and the impact of the event. And most risk management plans include some sort of “T-shirt” sizing scale to facilitate classification of probability and impact as small, medium, large, and so on. While not particularly rigorous, this approach does have the benefit of getting SME participation without making great demands on their time or making them uncomfortable with complex quantifying processes. This approach is useful primarily for determining which risks are significant enough to require a risk response strategy or additional quantitative analysis.
But to paraphrase Rod Serling, there is a third dimension: time. Some risks are always present, while others are episodic or cyclical, or even overtaken by events. For that reason, it can be valuable to consider the life cycle of a risk, in order to determine whether it needs special handling.
Characterizing the Evolution of a Risk
Let’s consider three cases:
- A risk that impacts a task or deliverable. For example, an external event or delivery that, if delayed, would delay a project task on the critical path. We’ll call this a dependency risk.
- A risk associated with an assumption. In many cases, a critical assumption can’t be confirmed to be accurate until somewhat later; thus, the possibility that it is incorrect will linger until that time.
- An external / environmental or internal business risk that might have significant impact but only in some specific window of time. We’ll call this a “fly-by” risk.
There are other scenarios, but in the typical IT project, most will fall into one of these categories.
Most project schedules include dependencies—one task can’t begin until another is complete. While good project plans have some slack built in, a task on the critical path that is delayed can have significant impact. For example, if your project has a requirement to go live at the beginning of a quarter, all it takes is a delay in the right place to significantly impact the schedule and all associated project costs. Thus, the probability of the event occurring is spread over a rather narrow span of time, but the impact follows it and can be spread over a much longer period.
In developing responses for dependency risks, it can be helpful to prepare both a mitigation strategy to reduce the probability of the event, and a contingency plan to manage the event as an issue if it happens anyway. Dependency risks naturally have an end date; the event probability of a properly managed dependency risk should be expected to be reduced as that date comes closer. Part of your risk management strategy should include diagnostic metrics, a specific expectation of the probability reduction over time, and triggers to proactively initiate conversion of the risk to an issue before the end date.
Most projects are planned with at least a few assumptions—consider them to be accepted risks. Good project plans identify the assumptions as such, and include tasks to validate the critical assumptions. Where the validity of the assumption is questionable enough to represent a significant risk, the validation tasks should get a correspondingly higher priority. Risk responses for assumption risks may have to include revisiting the budget and business case. You don’t want to preside over a “zombie project” when the cost / benefit ratio has shifted in the wrong direction.
Assumptions are necessary for decision-making in the absence of certainty—we simply need to have a plan for how we’ll deal with newly found certainty, before we get to it.
While an asteroid strike isn’t a significant risk for most IT projects, year-end processing and other business-as-usual activities can be. I’ve seen more than one project delayed when resources were pulled for an emergency response to an event we already had on the calendar. If you know you might have to compete for resources during some finite window of time, identify it as a risk.
You may not be able to reduce the probability of the event, but it may be possible to transfer the risk by assigning tasks during that critical period to other resources. It may also be possible to avoid the risk by proactively juggling some tasks during the planning stage to reduce your exposure during that window. This usually doesn’t need to be more complicated than incorporating public holidays and staff vacation plans into your schedule.
The Evolving Project Risk Exposure Profile
While it isn’t necessary for all projects, it can be helpful to express your project’s risk exposure profile over time. There are a number of ways to graph the combination of probability and impact of multiple risks over a timeline. Showing your key stakeholders how the risks to the project are being shepherded to retirement can go a long way toward retaining their support when those events you are trying to prevent happen anyway. If you can demonstrate how your risk management plan will ultimately eliminate risk exposure at some point near the end of the project, you’ll probably get a lot more engagement in reaching your goals.
For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager