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.

In Praise of Bibliographies

One of the best things about books are their bibliographies.  Sometimes a book's bibliography is worth more than the book itself.  If it is any good, the bibliography arms you with a map, or a mini-library, to other treasures about the subject you are reading about.   

When you are reading the very first book you have read about a subject, the bibliography is often a map to a new world. If it's a good bibliography, it leads you to treasure. But sometimes it can lead you to a rubbish pile. 

I always skim through the bibliographies of each book I read, marking down titles that may interest me next. 

It’s still vivid in my mind the occasion when I first came across Patrick Henry Winston’s “Lisp”. I remember exactly where I was.  I found a copy at our school library. I was in university, somewhat new to programming, but already infected by an intense interest in computer science, a subject I only had recently discovered. 

I had already read perhaps a dozen Pascal and Fortran books before picking up “Lisp”, but Winston’s was the most wonderfully strange computer programming book I had come across then (and still since). 

First was the very strange programming language (Lisp was not like normal procedural languages).  Then the domain was very new to me (it was the first book I read about Artificial Intelligence).  But it was also because Winston had a quirky writing style.  Looking back later, and understanding his academic interest in how humans learn, I’m sure this style was deliberately designed.

His book imprinted in my mind the names of dozens of computer scientists in the AI field. Names like Marvin Minsky, Douglas Lenat, Elaine Rich, and others whose very unusual sounding names (to me back then) felt like they were not normal humans, but members of a different breed, a strange breed, an alien breed. I swore to read all of them.   

Not all bibliographies are good (and by bibliography I include ‘References’). But, off the top of my head, authors who are great at compiling bibliographies include Andrew S. Tanenbaum, C. J. Date, Jeffrey D. Ullman, Douglas Comer.

Sometimes I forget how I learned about a book. I estimate that of all the books I’ve read or intend to read, the vast majority were inspired from a bibliography of some book I read.

So I thought it might be a fun exercise to list down some key books that have influenced me, write down their bibliographies (I’ll limit it to books only), and see how they are connected.

This is a tedious exercise so it will happen slowly, and when time permits.

Example of a Decision Tree

A simple example of using a decision tree to help us with decision-making.

A couple renting an apartment and is wondering whether they should sign a 1-year contract on the rent.  If they sign a contract, their rent is guaranteed not to increase during the 1-year period. If they don’t sign a contract, their rent will increase by about $20 after 6 months.

This seems like a simple decision.  But there is a drawback to signing the contract. If the couple decides to terminate the contract before the end of 1 year, they are liable to pay up to 25 weeks worth of rent to the landlord, unless the landlord is able to get someone else to rent the place earlier. 

The couple intends to buy their own home if the right opportunity comes, so there is a chance that they would need to terminate any contract they sign.

Supposing the initial rent is $900 per month, what is the couple’s best option?

Let us choose the simplest situation first.  Let’s assume there is zero chance that the couple will terminate the contract.  So the decision tree looks like this:

The tree says that the option to sign a lease contract will result in a total 1-year rent of $10,800 ($900 * 12 months), while not signing a lease contract will result in a total 1-year rent of $11,800 ($900 * 6 months + $900 * 1.2 * 6 months).

But what happens if the couple finds their dream house and moves out of the house after 8 months?

The Essence of Risk Management

All of man’s activities is fraught with uncertainty and risk.  When he undertakes something, he faces uncertainty and risk and loss.  Even when he does not undertake anything new, but simply goes on with life as normal, he still faces uncertainty and risk and loss.

Therein lies the essence of risk management, to which man runs to, to seek an answer to his question: in the face of this uncertainty, what should we do?

Operations Risk

Every company faces risks as it goes about its day-to-day operations. 

A bank branch could find itself in the midst of a robbery.  A fastfood restaurant could suddenly have a cook badly burned by an overturned pot filled with boiling water.  A shipping company may have one of its ships boarded by pirates.  A veterinary clinic may have one of its staff or customers bitten by a dog. A data centre may find the building it is located in collapsing due to an earthquake. These risks are called ‘Operations Risk’, or alternatively ‘Operational Risk’. 

The types of operations risk a company faces depends heavily on its line of business, although the nature of risk is that it is often unexpected: the bank could suddenly discover that the pirates who boarded the ship in the above example are actually the bank’s customers.  The shipping company may find its cook burned badly while preparing food.

Operations risk is different from the other types of risks that companies face.  It is not credit risk, which is the risk related to debtors not paying the company.  It is not strategic risk.  It is not market risk.  It is not reputation risk.  Nevertheless, risks arising from operations can cascade into these types of risks.  The revelation that a pirate has been hoarding its loot in your bank can rapidly discredit the bank (reputation risk). 

Conrow and Opportunity Management

There are two kinds of risk managers.  There is the kind who think that risk management is about managing ‘negative’ risks.  Then there are those who think that risk management should include managing ‘positive’ risks.

Briefly, a negative risk is a situation that has undesired impacts on our objectives, while a positive risk is a situation that could potentially have desirable impacts on our objectives.  For the most part, risk management has been about managing negative risks.  People buy fire insurance just in case their house burns down.  Nobody buys insurance just in case their house doesn’t burn down.

Edmund Conrow and Robert Charette has an article in Defense AT&L critical of ‘Opportunity Management’ (PDF link) .  The authors argue that Opportunity Management, or OM, is unnecessary, and will only bring in more trouble than benefits.  The main argument Conrow & Charette make is that the standard processes of project management, risk management, and systems engineering, are enough to ensure that the project takes care of opportunities that present themselves in the course of the execution of the project. Therefore there is no need for a distinct OM.

Before I came across this article, I’ve already come across literature endorsing the inclusion into risk management the management of ‘upside risks’ (opportunities),  but I’ve not come across any literature that purports to advance OM as aggresively as that suggested by Conrow and Charette’s article.   The authors worry about OM IPT’s (Integrated Project Teams) running about looking for opportunities in a projects, and enveloping the whole project team with scope creep.

The Australia Risk Management Standard ANZ 4360:2004 indeed recommends management of positive risks.  Chapman and Ward have also been proponents of this view for many years.  But from what I understand of at least these two sources, the main idea is, as part of risk management, to be prepared in case it is the positive event, rather than the negative event that occurs.  That is, to be prepared to take advantage of the situation.