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)

System Operations Model

Every (man-made) system is intended to be deployed, operated, and eventually disposed of.  Having a common understanding of how the system is to be deployed, operated, and disposed helps avoid much miscommunication between the project team.

A System Operations Model is a high-level model of how a system is envisioned to be deployed, operated, and eventually, disposed.

It shows, in graphical terms (a SOM is typically diagrammed) the interrelationships among the different stages, gates, and operations:

• System development
• Entrance criteria (entrance into deployment)
• System deployment
• Performance of purpose (mission)
• System maintenance
• System reconfiguration
• Phasing out
• System disposal

Once we have built the SOM, it becomes the basis for further systematic elaboration into operations and tasks.

Seeing Tomorrow, III

Continuing book review of Dembo & Freeman’s “Seeing Tomorrow: Rewriting the Rules of Risk”

In chapter 2, the authors introduce four elements they consider to be core to any forward-looking approach to risk management:

• Time horizon
• Scenarios
• Risk measure
• Benchmarks

Time horizon refers to the future period that we are interested in.  It is a distinct period (with a distinct begin and end, as opposed to simply ‘the future’).  An investor who wants to assess the risks involved in an investment needs to think about the timeframe of his investment.  This timeframe (or time horizon)  is very different for someone who wants to cash in in two years than for someone who plans to cash in 15 years into the future.

Of the four elements, the authors give the longest treatment to scenarios.  A scenario is a projection of what could possibly happen in the future.  The purpose of creating scenarios is to help us plan for that event if it occurs. 

The key here, the authors say, is not merely generating a scenario but several scenarios.  These set of scenarios will help us gain a clearer understanding of the range of dangers (and opportunities) we might face. 

If a scenario eventuates, and we had anticipated that scenario, and made plans for it, then we are in a better position to react and perhaps exploit the new situation.  We will be better placed, relative to our competitors and relative to where would be had we not planned for it.

The third element of risk management is deciding on a risk measure. This is about deciding we measure riskiness.  Apparently this is very tricky, since choosing a measure like Value at Risk (VaR) could protentially produce similar values to very different risk situations, effectively obscuring the reality that they are very different propositions.

The final element is Benchmark, or having something to compare with.  Choosing the appropriate benchmark is key to understanding how well we are managing our risks.  Do we choose to benchmark our investment performance relative to Warren Buffet’s or the DOW index or something else?

After the discussion on the four elements, the authors also touch on Risk-Adjusted Valuation.  This is the ‘real’ price tag of something and is almost always ignored.  For example, suppose you buy an expensive ring for $20,000.  Now, you would want to insure something that valuable since you cannot afford to self-insure it (absorb the loss if it gets lost).  So let’s say you pay $100 per year to insure that ring.  That total amount (comprised of the original amount of the ring, plus its ongoing insurance) is the Risk-Adjusted Value of that ring.  The authors want the reader to begin thinking always about the Risk-Adjust Value of everything.

The chapter ends by tying up all the four elements in a short example using a model called Marking-to-Future, a model developed by one of the authors.

Seeing Tomorrow, II

Book review of Dembo & Freeman’s “Seeing Tomorrow: Rewriting the Rules of Risk”

In chapter 1, the authors give more details about the Soros / Reichmann deal gone wrong which they hinted at in the introduction.   It seems the reason for the deal was that Reichmann camp considered only one possible risk event (one that would be a windfall for them), got fixated on that and wouldn’t budge in the negotiations.  They (inadvertently?) preferred to risk losing the whole deal rather than giving up a small portion of the profit.

Demob & Freeman writes that the way to think about risk not to consider one possible event, but to look at several different possible outcomes, explore how each event will make use react .

The chapter then very lightly mentions considerations about risk. That we all have different views of risk, that what is attractive to one is repellent to another, that risks have positive and negative aspects, that doing nothing can be risky as well. 

The one interesting notion I hadn’t come across before stood out briefly:

“an acceptable risk one day might appear a foolish gamble on the next day.” 

But after further reflection, this is very common in hindsight, when events that we weren’t able to consider during decision time unfold.

The second half of the chapter consist of continuing remarks about flawed and outdated approaches to risk management, examples of failures in managing risk: Orange County, the very biggest banks, etc.   They also picked up on Peter Bernstein’s notion on whether modern man has replaced his earlier superstitions of the fates and the gods with new superstitions about the magic of statistics and quantifications of risk.

The topic then shifts to the idea of sharing the risk, with a story about a group of women involved in charity, who without realising it, bought futures contracts on grains. 

They reveal a little more about their soon-to-be-explained  framework, by noting that risk sharing (distributing the risk) is an important concept of the framework.

The last few paragraphs of the chapter – oddly - begin sounding like a marketing brochure on reinsurance. Words like catastrophe reinsurance, catastrophe insurance bonds, pure risk, packaging of business risk and so on are spoken about (with a bit of a hint of glee?)  Some of the final paragraphs in this chapter may be more opaque  for readers not yet familiar with insurance terms as they are used without definition.

A review of chapter 2 will come next.