In June, you saw Context Matters When Discussing Risks in which I outlined four risk category descriptions to use with your stakeholders and teams. Here we will drill down a bit on the first category, Decision Risk.DECISION RISKS
Decision Risks come up throughout the project life cycle and are particularly frequent at the beginning, when of course many decisions need to be made.  They are specifically the risks associated with the options under consideration for a decision. So none of them is a project risk until the decision is actually made and a specific option selected. For example, consider vendor selection for a role on the project. One will be selected on the balance of what they bring to the table against concerns, and the others will be rejected. Keep in mind that rejection may not be permanent – you may want to position the next best vendor as a mitigation for the concerns you have with the selected vendor.

SWOT ANALYSIS
There are many techniques for decision analysis and an important process step for a project manager is that they drive out the risks the project will face for any selected option. Using SWOT as an example, the Strengths and Opportunities are the reasons for selecting the option and will lead to project activities to capture them, while the Weaknesses and Threats translate to proto-risks for the project. A test for a PM to apply on these proto-risks is simply this:  as described, can I document these fully in the risk register in compliance with the organization’s PM methods? If not, the analysis team needs to flesh them out some more.

STRENGTHS AND OPPORTUNITIES AS POSITIVE RISKS
This of course begs the question of what relationship do Strengths and Opportunities have with risks. For example, does it make sense to describe them as the flip side of the metaphorical risk management coin:  positive risks. This is a popular term particularly in the context of start-ups and the decision analysis they perform on how to go to market. However, it is not a useful concept or term in a project context, since it implies a symmetry between risks and opportunities, i.e. they are simply the positive and negative manifestations of a decision. This is incorrect, since how they are managed in a project is quite different.

The fundamental difference is that risks happen to you, while you have to make opportunities happen. In project terms, this means that opportunities enter the planning cycle in order to define the activities that will maximize their potential. Risks, however, reside in the prison of your risk register, always scheming of ways to escape and show up as your new team member, Murphy.

CHANGE MANAGEMENT
The context so far has described Decision Risks as part of project initiation. Where do they show up during subsequent phases? They appear most frequently within the Change Management process, since all changes have a certain degree of option analysis, if nothing more than reject (do nothing differently) or accept (do this single obvious thing). The flow is similar. The scope of the change basically maps to the Strengths and Opportunities and results in new or changed activities.

The Weaknesses and Threats are new proto-risks that get put behind bars once the option they link to is selected by approval of the change request. There is one additional step, though, relative to initiation phase decisions:  you need to interrogate the current inmates of your risk register about how this change and its new risks affect them. Just as the change’s scope modifies the project baseline, its risks modify the risk baseline.

SHORT LIFE SPAN
One of the few good aspects of Decision Risks compared to others is that they have a fairly short life span. They exist only as long as their decision is in play, and as soon as the decision is made, the unselected options’ risks are discarded and the others transfer elsewhere. There are three destinations: Event Risks, Plan Risks and Assumptions. The vast majority of these will become Event Risks and should be easy to transfer, since you were so demanding of the decision analysts about their description, probability and impact. A few could become Plan Risks or Assumptions but these should be avoided if possible, for reasons that we will explore in parts four and five.

Bio:

Mark Jones is an experienced technologist with over 30 years of improving business operations with computing solutions.  In addition, he is a published author (Project Management Competence – a Pragmatic Guide to Assessment for Project Managers, and Why You Need to Employ More People With Disabilities) and is working on other titles.  His most recent PM accomplishment was leading a team building EHR management tools for Ehealth Ontario.

Prior to that he led large teams for IBM’s clients in public sector, retail, utility and telecommunications segments.