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.

All the risks up front

Last month I was having a discussion and the point was made that perhaps risk managers should use a governance paradigm something like the original requirements paradigm: define all the risks at the beginning, and then only review plans and progress thereafter, resisting--with governance--changes during the course of the project.

I said no.

You can't freeze risks any more so than you can freeze requirements. The world simply does not stand still, and perhaps that is more true for risks than requirements, though I'm really not sure. In any event, as the requirements governance paradigm has evolved, and means and methods developed to deal with change--and perhaps Agile is the most extreme but not exclusive means and method for doing so--so also a regimen for risk management should have a governance mindset to deal with volatility.

To my risk management students I have posited the "cone of uncertainty", something written about by many, to include Dr Barry Boehm.  The cone gives a temporal dimension to risk: the farther out in time, the more optimistic we are in evaluating risk.  There's simply more time to deal with it; we feel we can fix it.  Closer in time, some options are off the table, and we're more pessimistic.  The cone begins to close down.

Thus, if for no other reason, the risk register can not be static.  Even we don't discover any new risks, the risks so far identified will change character, or our assessment of them will change--we call this utility--and the risk response will change with accordingly.

So, bottom line: there can be no static up front identification and assessment.  Even the PMBOK agrees that the process is repeated throughout the project.

Got to keep it relevant and current.

Bookmark this on Delicious

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

Hey, it's halloween!

Happy Halloween!

Too much already!

Mike Clayton at Shift Happens! has a nice post on portfolio prioritization. He asks this question:

Why do so many Organisations Resist Rationalising their Project Portfolios?

And, then he answers his own question with five reasons:

• Patronage
• It's all too difficult
• Is it really essential?
• Loss aversion
• Lessons unlearned

Well, Clayton thinks #5 is the one, and I agree. He goes on to expand:

1.Lack of clear links between the project and the organisation’s key strategic priorities, including agreed measures of success.
2.Lack of clear senior management and Ministerial ownership and leadership.
3.Lack of effective engagement with stakeholders..
4.Lack of skills and proven approach to project management and risk management.
5.Too little attention to breaking development and implementation into manageable steps.
6.Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7.Lack of understanding of, and contact with the supply industry at senior levels in the organisation.
8.Lack of effective project team integration between clients, the supplier team and the supply chain.

Bookmark this on Delicious

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

A great place to work

Over at HBR Blog, Tony Schwartz waxes on the 12 Attributes of a Truly Great Place to Work. We've all seen lists like this one, but take a look at some of the comments to the blog. They are both amusing (as in: fire yourself before they can) and insightful (like, it's all about trust)

Admittedly, the first six are a little expensive for many and assume a brick-and-mortar environment, (provide a gym, and provide good food in the cafeteria) but the universally applicable advice gets started in number 7. 

However, I skip all the way to 11 (provide learning and skill development opportunity) and 12 (stand for something besides profit--which I take to be a surrogate concept since there are non-profits and government units that can benefit from this list)

In my mind, to not be constantly learning is to be going backward, and backward is not forward to a better future.  And, surely, even if the business of business is business (I think a CEO of Coke said that), there's got to be more to it than that, although I admit that the business of business is not God and Country.  When I moved from the DoD to private industry, I learned that pretty quick!

Bookmark this on Delicious

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

Quote of the day

“You know, it’s O.K. to head out for wonderful, but on your way to wonderful, you’re going to have to pass through all right, and when you get to all right, take a good look around and get used to it because that may be as far as you’re going to get

Bill Withers, R&B singer and philosopher

Perhaps a more complicated rendering of "best is the enemy of better", but a more elegant statement, to be sure.

Bookmark this on Delicious

.

Is everything a hammer?

Well, our friends at Dark Matter have raised another issue that we found provoking, to wit: have we gone too far in some cases with the visual display thing? In other words, having invented the hammer, do we use it for everything?  All the world is not a nail, afterall, so perhaps some pause is warranted.

Now, to be fair, the Dark Matter crowd is all about safety, complexity, and and technology risk, especially as it affects human reactions in human-system situations. So naturally, Dark Matter is all over this stuff.

On the other had, as project managers (rather than system engineers) we have some obligation to test and challenge the various solutions, even we don't have the competence to rule things in or out. It's sort of the project equivalent of "reign but does not rule".

Setting up independent design review boards--sort of the red team equivalent for proposals--with 'grey beards' to give independent opinion is one way to do it.  (Does everyone recognize the term 'grey beard' or am I dating myself?)

In the post that got our attention, the issue was the elimination of certain tactile responses replaced by visual indicators. The case in point is the stall indication on the Airbus that crashed near Brazil a couple of years ago. The traditional "stick shaker" had been eliminated, as well as some other traditional tactile oriented systems.

There are all kinds of stories like this. In Gene Kranz's book "Failure is not an option" he describes similar debates between the rulers and the reigners. There was a lot at stake.

This stuff is not to be taken lightly, and certainly not to be delegated to self-appointed teams without a disciplined tie to established saftey regimes.

 Bookmark this on Delicious  



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