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. 

Requirements

Craig has posted a taxonomy of requirements on his blog (the taxonomy is Don Firesmith’s not Craig’s). 

I haven’t seen the discussion mentioned in the post, so I don’t know  whether it had any influence on the illustration or is independent of it.  But the nomenclature shown in the illustration, having the format of ‘X requirements’ where X can be anything from ‘Functiona'l’ requirements, ‘Documentation’ requirements, etc. got me thinking. 

A ‘requirement’ is something that someone needs from someone else.  A bit more formally, some entity needs (‘requires’) something from another entity.  When you say ‘maintenance requirements’, ou have to be clear, who is needing these requirements?

Without a clear understanding of who or what that requiree is, you can be assured that the ‘requirement’ will be muddled. 

The diagram shows ‘Documentation Requirement’ in a box.  There is an arrow from that box pointing to a box labeled ‘Product Requirements’.  What does that arrow mean?  Does it mean that documentation requirements are a subset of product requirements? And that as part of delivering the product, documentation should be delivered as well? 

If that is how to interpret the arrow, what does the arrow from ‘Business Requirements’ to ‘Product Requirements’ mean? 

Concatenation of Risk

Currently reading J. Davidson Frame’s “Managing Risk in Organizations”.  Great example of a seemingly insignificant event cascading into a major headache.  A printing press experiences a fire and will not be able to deliver brochures expected to be that were supposed to come today.  These brochures are needed for a client’s conference in two weeks time. All the arranged plans to sort, label, and send them out have to be replanned.

The Problem Statement

Man-made systems are created to exploit opportunities or to reduce threats.  They are designed to fulfill a mission, or objective, aimed a exploiting the opportunity, or reducing a threat.

A problem space is a relativistic concept. Two people in the same organisation may view problems differently.

Problems and solutions could be two sides of the same coin. One man’s problem is another man’s opportunity -- a client has a problem, the solution provider has an opportunity.

Sometimes what we think as problem solving is actually only symptom solving.

Problem spaces are not static. They evolve.

Problems can be symptoms.  Finding the root cause helps in finding an effective solution.

In systems, often the root cause of problem spaces can be many.

Sometimes the best way to understand the solution space is to strart with a conceptual solution.

The problem space is partitioned into solution spaces. This is to reduce the complexity.  It can be impossible to provide a single homogeneous solution that addresses the whole solution space. Each partitioned solution space is analysed deeper and even partitioned.

You cannot really expect to solve a problem if you don’t know what the problem is.  One of the first steps in solving a problem is to understand the problem. 

Often, a problem cannot be solved away, it can only be managed.

Implementation of a solution changes the surrounding system and may introduce new problems and opportunities. Systems are systems.

 

References:

• System Analysis, Design, and Development: Concepts, Principles, and Practices (Wiley Series in Systems Engineering and Management)