Risks and Issues Are Not The Same

Josh has a nice post on his PMStudent blog from Susan de Sousa speaking the "Contingency Plans." A bit of reading reveals this is actually about risk management. Risk Management is of course part of project management. Tim Lister's quote...

Risk Management is How Adults Manage Projects

is the good starting point for all discussions around riks.

But when you follow Susan's link down into her Blog where the topic of risk management is discussed you'll find lots of useful information. But there is a critical disconnect there and many other places in the risk management world.

Risk ≠ Issue

This is a common mistake and one made by Susan. She lists some risk developed in a work shop

Now these risks should fall into one of the following categories which are:

1. Management - The risk that there won't be enough Sponsor or Stakeholder input to ensure business requirements are delivered.
2. Resources - The risk that there will not be enough resources available to deliver the project
3. Requirements - The risk that the requirements will not be either fully specified or not correctly understood
4. Technical - The risk that the proposed deliverables cannot actually be delivered, or else won't work utilising the technology used within the Organisation
5. Environment - The risk that something will change in the environment the project will utilise.
6. Acceptance - The risk that either the Project Sponsor / Client will want to change the scope of the deliverables, or else will not accept the defined deliverables once developed.

These are not risks, they are issues. They are issues that are impediments to the progress of the project. But they are not risks as defined in all risk management books, government guidance, and even the PMI PMBOK Risk Management Chapter.

If this confusion is made the project balloons with risks and the project management becocmes a clerk trying to manage all the issues masquerading as risks.

Let's start with the US Department of Defense definition of risk:

Risk management is concerned with the outcome of future events, whose exact outcome is unknown, and with how to deal with these uncertainties, i.e., a range of possible outcomes. In general, outcomes are categorized as favorable or unfavorable, and risk management is the art and science of planning, assessing, and handling future events to ensure favorable outcomes.

From the DoD Risk Management Guide, 2006:

Risk is a measure of future uncertainties in achieving program performance goals and objectives within defined cost, schedule and performance constraints.

Risks have three components:

• A future root cause (yet to happen), which, if eliminated or corrected, would prevent a potential consequence from occurring,
• A probability (or likelihood) assessed at the present time of that future root cause
• occurring, and
• The consequence (or effect) of that future occurrence.

Now let's look at the "risks" listed from the post

1. The risk that there won't be enough Sponsor or Stakeholder input to ensure business requirements are delivered. This ISSUE must be dealt with in the chartering session. A Responsibility Assignment Matrix defines the accountabilities of all the project members. Failing to provide te needed information from the right person is n "Issue" that must be addressed in the weekly status meeting.
2. The risk that there will not be enough resources available to deliver the project. This ISSUE is a resource planning and management failure. We know the number of needed resources, we know the capacity for recruiting and retention. A plan to sustain the project is needed.
3. The risk that the requirements will not be either fully specified or not correctly understood. This Issue is directly addressed through the requirements management process.
4. The risk that the proposed deliverables cannot actually be delivered, or else won't work utilizing the technology used within the Organisation. This Issue has some parts risk and some parts issue.

So let's look at 4. to see how to sort this out.

There is a probability that the deliverables don't do what we want them to do. But getting to do what we want them to do is an "issue." Planning, execution, testing, verificcation and validation are part of the issue.

Where the risk comes in is that the deliverables can NEVER be made to do what we want them to do. You'd have to invent new physics to get them to do what we want them to do. That is where the risk part comes in...

There is a probability that what we have planned (and assumed we could execute if we did our job right) will not actually work.

That's a risk. Everything else on the post regarding risk is pretty much an Issue. A final piece of advice from the DoD Risk Management Guide

Risk management is the overarching process that encompasses identification, analysis, mitigation planning, mitigation plan implementation, and tracking. Risk management should begin at the earliest stages of program planning and continue throughout the total life-cycle of the program. Additionally, risk management is most effective if it is fully integrated with the program’s systems engineering and program management processes—as a driver and a dependency on those processes for root cause and consequence management. A common misconception, and program office practice, concerning risk management is to identify and track issues (vice risks), and then manage the consequences (vice the root causes). This practice tends to mask true risks, and it serves to track rather than resolve or mitigate risks. This guide focuses on risk mitigation planning and implementation rather on risk avoidance, transfer or assumption.