ISO 31000:2009’s Definition of Risk

As anyone involved in risk management knows, a couple of years ago the ISO published their new Risk Management Standard known as ISO/IEC 31000:2009 (ISO 31000 for short).  This standard is new for ISO, and is not replacing an older ISO standard.  For countries like Australia though, which had its own standard (AS/NZS 4360:2004), this new ISO standard supplants that older standard.

One of the innovations coming from ISO 31000 is a new definition of risk.  It is a  concise definition, albeit but strangely phrased. It defines risk as:

"the effect of uncertainty on objectives."

At first glance, it looks straightforward.  But a closer interpretation of the words makes on pause: the what of what on what?  

But before we delve into what it means, let’s compare this definition with the one used in AS/NZS 4360:2004, which was not only the Australian (and New Zealand) standard, but also adopted in several other countries.  As testament to its wide acceptance, the core of ISO 31000, its Risk Management Processes, is taken almost verbatim from AS/NZS 4360:2004.

This is how AS/NZS 4360:2004 defined risk:

"the chance of something happening that will have an impact on objectives." 

Here it’s clear that risk is clearly tied to "something happening".  Risk is an event or a circumstance (together with its chance of happening).

By contrast, in the new ISO definition, risk is the "effect of uncertainty".  What is this ‘effect’? 

ISO 31000 provides an explanation:

Effect - "a deviation from the expected -- positive or negative".

Now, since we are talking about risk, and risk is about future events, we can safely assume that when they say ‘deviation’, they are talking about potential deviation, or a possible deviation, not a deviation that has already happened.

If we take that meaning, then it seems to me that the definition of risk can be translated to:

"the possible deviation … on objectives."

This makes some sense.  Risk is indeed about its possible deviation on our objectives.  We hope to finish a project within 6 months, but it might end up finishing after 17 months. 

But notice that I put in ellipses.  The reason I did that is because if I restore the missing words, the definition of risk becomes:

"the possible deviation of uncertainty on objectives."

Which is clearly gibberish, so let’s parse it further.

In risk management, the word ‘uncertainty’ refers to ‘ignorance’ or ‘lack of knowledge’.   ISO 31000’s definition is aligned with this view:

Uncertainty - "the state, even partial, of deficiency of information related to understanding or knowledge of an event, its consequence or likelihood."

Note the definition: ‘Deficiency of information’, lack of information, or lack of knowledge.  This lack of knowledge, does not, I believe, refer to lack of skill, or lack of expertise, but specifically to lack of knowledge about what will happen. 

Given the above, a possible rephrasing of the definition can go like this: 

Risk - the possible deviation, arising from lack of information, on objectives.

The key difference is that in AS/NZS 4360:2004, risk is an event, whereas in ISO 31000, risk is the deviation.  This is not the consequence, but the deviation. 

So for example, we launch a product which we estimate will bring in $20 million dollars.  For AS / NZS 4360:2004, a possible risk is that a competitor might launch a similar product which changes the market dynamics, resulting in lower revenues for us.  For ISO 31000 a risk might be that sales are not as big as we expected.  What are the consequences of that?

This change in the definition of risk has been met with praise, criticism, and confusion.  One of the primary impetus in redefining risk is the desire to better incorporate the handling of ‘positive risks’ in the risk management process.

It certainly makes one rethink.

Risk Management Bibliography / Library

Some key works on various risk management topics either in my library or I have read.  I plan to update this list every now and then.

Risk, Risk Management, and Uncertainty in General

Aven, T. Misconceptions of Risk. Chichester, West Sussex, U.K.: Wiley, 2010.

Bernstein, Peter L. Against the Gods: The Remarkable Story of Risk. New York: John Wiley & Sons, 1996.

Kammen, Daniel M., and David M. Hassenzahl. Should We Risk It?: Exploring Environmental, Health, and Technological Problem Solving. Princeton, NJ: Princeton UP, 1999

Moore, P. G. The Business of Risk. Cambridge [Cambridgeshire: Cambridge UP, 1983.

Morgan, M. Granger. Risk Communication: A Mental Models Approach. 2002

Rowe, William D. An Anatomy of Risk. New York: Wiley, 1977.

Wilson, Richard, and Edmund A. C. Crouch. Risk-benefit Analysis. Cambridge, MA: Harvard Center for Risk Analysis, 2001.

Yoe, Charles E. Primer on Risk Analysis: Decision Making under Uncertainty. Boca Raton, FL: CRC/Taylor & Francis, 2012. Print.

Business / Enterprise Risk Management

Culp, Christopher L. The Risk Management Process: Business Strategy and Tactics. New York: J. Wiley, 2001.

Fraser, John, and Betty J. Simkins. Enterprise Risk Management: Today's Leading Research and Best Practices for Tomorrow's Executives. Hoboken, NJ: J. Wiley & Sons, 2010.

Hampton, John J. Fundamentals of Enterprise Risk Management: How Top Companies Assess Risk, Manage Exposures, and Seize Opportunities. New York: American Management Association, 2009.

Monahan, Gregory. Enterprise Risk Management: A Methodology for Achieving Strategic Objectives. Hoboken, NJ: John Wiley & Sons, 2008.

Young, Peter C., and Steven C. Tippins. Managing Business Risk: An Organization-wide Approach to Risk Management.  2001.

Project / Program Risk Management

Chicken, John C. Managing Risks and Decisions in Major Projects. 1994.

Conrow, E. H. Effective Risk Management: Some Keys to Success. Reston, 2nd Ed. 2003.

Dorofee, Audrey J. Continuous Risk Management Guidebook.  1996

Operations / Operational Risk Management

van Grinsven, Improving Operational Risk Management. Amsterdam: IOS, 2009.

Banking and Financial Risk Management

Bessis, Joël. Risk Management in Banking. New York: Wiley, 2002.

Greuning, Hennie Van., and Sonja Brajovic. Bratanovic. Analyzing and Managing Banking Risk. Washington D.C.: World Bank, 2009.

van Grinsven, Risk Management in Financial Institutions: Formulating Value Propositions. Amsterdam: Delft UP/IOS, 2010.

Safety and Risk Management

Duffey, R. B., and John Walton Saull. Know the Risk: Learning from Errors and Accidents : Safety and Risk in Today's Technology. Amsterdam: Butterworth-Heinemann, 2003.

Status Your Project with the WBS

The WBS serves as a perfect framework for project status reporting

Your WBS is the list of everything that needs to get done to complete the project.  It’s a ready-made framework for monitoring and statusing the project.

Let’s begin with the basic structure of the WBS:

WBS Code	WBS Description
100	Project Management
200	Product
200.1	Product Requirements
200.1.1	Stakeholder Requirements
200.1.2	System Requirements
200.2	Product Design
200.3	Product Build
200.4	Product Testing
200.5	Product Deployment

If we are going to use this for reporting, we need to include who’s in charge of delivering each WBS Item.  Generally, this can be the Project Manager for that piece of work.

WBS Code	WBS Description	Responsible
100	Project Management	PM
200	Product	n/a
200.1	Product Requirements	n/a
200.1.1	Stakeholder Requirements	Bill F
200.1.2	System Requirements	Jane T
200.2	Product Design	John X
200.3	Product Build	Mary G
200.4	Product Testing	Keith D
200.5	Product Deployment	Sara S

The updated table above shows which manager or lead has responsibility for delivering the work described in each WBS entry.  The items 200 – Product, and 200.1 Product Requirements have no designated responsible person because all the work under them are parcelled out to the work subitems under them.

Now we need to update the table to show the status.

WBS Code	WBS Description	Responsible	Status
100	Project Management	PM	n/a
200	Product	n/a	Started
200.1	Product Requirements	n/a	Started
200.1.1	Stakeholder Requirements	Bill F	Completed
200.1.2	System Requirements	Jane T	70%
200.2	Product Design	John X	NYS
200.3	Product Build	Mary G	NYS
200.4	Product Testing	Keith D	10%
200.5	Product Deployment	Sara S	NYS

In the above update, we see that item 200.1.1 has been completed, 200.1.2 is 70% completed, some of the work are Not Yet Started.  Work 100 – Project Management will have no status because it is ongoing work, while 200 and 200.1 will have only Started at their level. They will become Completed when all the sub-items under them have been completed.

The problem with the above is that it says nothing about whether the project is going according to schedule, going ahead, or being delayed.

For that we can use Earned Values to show the status of the work.

And because the status date of each individual work item may differ, it might be useful to add another column to indicate the as-of status date for that piece of work.