Friday, November 4, 2011

Opportunity or risk?

Opportunity or risk?

Not to be too dry, let's nevertheless acknowledge that the 'official' definition of risk, as given by PMI PMBOK, is that a risk is an event or condition that could have either a negative or positive impact on project objectives. And, if you follow the thread in the PMBOK gloassary, 'opportunity' is the name given to the positive impact thread. Now, the ISO 31000 standard for risk management does not go quite as far, defining risk as an uncertainty that affects project objectives

So, what is opportunity? Risk, or just a postive effect? And, does it matter, really?

Well, yes, actually it does, for these reasons:

a. Risk has it's own register of possible and probable events and conditions, largely not in the performance management baseline (PMB).  Thus, most risks are 'off-baseline'.  And the reason is simple: risks are generally thought of as threats to project success, PMI's glossary not withstanding.  The point of risk management is to mitigate threats to the PMB.

b. Opportunities, equally off-baseline, usually mean a change in scope.  Thus, whereas an opportunity may thought of as scope creep, the general disposition is to accept worthwhile opportunities, not mitigate against them.

c. Incentives generally follow success, but risks are not about success.  Thus, risks are not about incentives.  Money tends to focus the mind, so focus is often not on the risk register.  On the other hand, an opportunity may bring with it not only success but reward for foresight

d. Opportunities naturally find their way into the change management system, and are usually dealt with in an entirely different workflow from the risk management system. 

The PMBOK, in Chapter 11, offers four response ideas for risks: avoid, accept, transfer, and mitigate. 

The PMBOK offers a different list for opportunities: exploit, share, enhance, and accept.

However, when discussing this recently with my risk management students, one came up with three others that I think are quite clever:
IGNORE because it was out of scope; INFORM the outside party that it impacted so they can run with it; or INCLUDE in the project because it was a better way to achieve the project objectives.

 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.