On Issues Versus Risks

Whenever you find yourself in an introductory presentation on risk management, you can expect to hear a question like: “What’s the difference between an issue and a risk?” The expected answer seems to be always: “A risk is something that may or may happen, while an issue is something that has already happened.” 

Correct enough, but this description falls short of conveying any relationship between the two.

Here’s one I coined, I like, and plan to use and re-use: “Issues are the risks you failed to manage, now come to haunt you.”

The sentence makes clear that many of the issues that you face could have been mitigated if only you had done proper risk management.  The assertion is not always true of course.  Some issues just come from unpredictable circumstances, and no risk management is that perfect.  So surely,  there are exceptions, but the strong assertion of the sentence emphasises just that – that exceptions are the exception.

I believe I originally picked up this relationship from Bill Duncan.  A few years ago he quoted someone he knew who said that in a good risk management process, all the issues that arise will have been previously identified in the risk register.  So it’s not my original idea, but I like the “now come to haunt you” bit, which is mine.

Pinpointing the Risk

"It is important to correctly identify the cause from the risk", said the presenter of a risk management process overview.

 

I hadn't given much thought about the distinction between the two, and simply implicitly assumed that I know which is which.  But when I tried to articulate how to distinguish between the a cause and a risk, I felt stuck.  After all, they all seemed to be a chain of event/consequence.

 

Ignoring for the meantime that each event E can be a consequence of any number of events, and that E itself can cause any number of consequence, it is clear that from one point of view, an event E2 can be a consequence of an event E1.  Similarly event E3 can be a consequence of event E2.  So a specific event is both a cause and a consequence.

 

For example, let us suppose we are concerned about the risks our property is facing.

 

Risk: Fire

Cause: Faulty electrical wiring

Consequence: House burns down

 

In this case, we put "Fire" as a risk in our risk register.

 

But what about "Faulty electrical wiring"?  Isn't it a risk as well?

 

Risk: Faulty electrical wiring

Cause: substandard workmanship

Consequence: Fire, leading to house burning down.

 

So should Faulty electrical wiring then be in the risk register?

 

Kik Piney reminded me that it is essential to be clear first about the objectives when going about identifying risks.  Having just studied ISO 31000:2009, I am aware of the relationship between objectives and risk, but for some reason I left it out.  (I am not too sure about being clear first about objectives before going about identifying risks, because sometimes noticing potential areas where things can go wrong will actually help you know what your objectives are).

 

Now suppose we have decided that our objective is "to protect our property".  In this case, it is clear that the risk is fire:

 

Objective: Protect property

Risk: Fire

Risk: Repossession

Risk: loss of property due to plane falling on property

Risk: loss of property due to earthquake

 

"Faulty electrical wiring" is not a risk. Either the property has faulty wiring or it does not.

 

If the objective instead is 'Acquire a problem-free property', then 'faulty electrical wiring' is a risk.  The property we are considering to acquire 'may or may not' have this characteristic. 

 

Final point: always relate risks to objectives.  Nothing new here. Just a reminder.

Project Success

Bill Duncan comments on the definition of project success (link) and touches on the different dimensions beyond merely completing the project 'on time'.  His thoughts sparked a few thoughts as well.

Success can be defined in several dimensions.  The more success criteria defined, the greater the chance that they will conflict with each other.  Invariably, there will be 'success criteria creep.'  Some ranking of success criteria may be required. Perhaps a ranking system may be of use to rank the success criteria according to importance in order to provide guidance whenever conflicts arise.  For example, while it may be deemed important to achieve each major milestone according to schedule, is that more important than completing the whole project on time?  And is completing the project on time more important than meeting a specified project cost?

Other questions to help rank the success criteria might include:

• What are the consequences of not meeting this success criteria?
• Are we prepared to spend more in order to meet this success criteria (otherwise is just a nice-to-have?)  If so, how much? 
• Is it acceptable to fail to meet a success criteria in order to achieve another criteria?

 

Giving this a little more thought, I find a relationship between project requirements and success criteria: why did we define success this way and not that way? The answer lies in the requirements.  We defined this as a success criteria because it is important.  It is important because <project requirement>.  A simple example: success critera A: the stadium is ready for use by March 11, 2011.  Why?  Because a large event is going to use it on March 25, 2011.  Failing to make the stadium available by March 11 means a failure to hold the event.