Jan 14, 2013

A Better Definition of Risk?

I HAVE conflicting feelings about ISO 31000’s definition of risk.  This standard defines risk as ‘the effect of uncertainty on objectives’, a definition that succeeds at simultaneously being both clear and enigmatic. 

Witness the various discussions in LinkedIn about what the definition means.  Look around the web for many online blog entries, articles, and explanations of what the definition mean, and carefully note the certitude shown by those who wrote those online materials about what the definition means.  Notice how they differ in their understanding.

In light of the absence of any clarifying remarks by the writers of the standard (who seem to be non-existent on the internet) about what they meant by their definition, I have settled on my own understanding of what they meant. 

Their definition seeks to succinctly explain the nature of risk.  When they say ‘effect’, they mean ‘phenomenon’.  They don’t mean ‘consequence’ as many online writers seem to  think.  (Or at least, the standard writers should not have meant ‘consequence’ in sense of a risk eventuating bringing forth its consequences!).   The reason why I feel certain ‘effect’ is not ‘consequence’ is because risk is about something that has not yet happened.  If something has not happened, it has no consequence.  Had they said, ‘risk is the potential effect of uncertainty…’, then it would clear they would have meant ‘consequence’.

My current position is that the standard writers are attempting to explain in the definition what the essence of risk is. 

The best way I can think of of what they are saying is by making an analogy, comparing ‘risk’ with ‘shadow’.  I will propose a definition of the word ‘shadow’:

the effect of an opaque, solid object on a light source. 

I like this analogy because it almost perfectly parallels the ISO 31000 definition of risk.  If you have objectives, and you have uncertainty, the intersection of the two brings forth a phenomenon which we call ‘risk’

If you have a light source, and you have an opaque, solid object, the intersection of the two brings forth a phenomenon which we call ‘shadow’.

Remove either objectives or uncertainty, and risk disappears. No intersection, no risk.  Remove either the light source or the solid object, and the shadow disappears.  No intersection, no shadow.  

I have two criticisms for the risk definition though.  First, the definition, while strictly correct, is near to being useless.  It is an academic, technical definition, not an operational definition that can be acted upon by practitioners ‘in the trenches’.   How would risk practitioners explain risk to lay members or board members of the organisation using such a definition? 

My second criticism revolves around the use of the word ‘objectives’.  The Merriam-Webster definition of objective is “something toward which effort is directed : an aim, goal, or end of action”, accurately reflecting the normal day to day usage of the word to mean something that is being strived for, something to be achieved, something not yet.

But risk is not always (nor even most of the time) about something you wish to achieve.  It is often to protect what you already achieved

What you already have are also at risk. 

Strictly speaking, if you have good health and you have a desire to maintain that good health, then you sometime speak of such an objective: to maintain my good health.

But what about other things? People do not consciously state that their objective is to ensure that they keep on having a house. Or that their objective is to remain alive. They have an interest in ensuring they remain alive. They have an interest in ensuring their house remains liveable by them. But they are not objectives in the same degree as things they are striving to achieve, such as a job promotion, completion of a project, and so on.

Your health, your job, your finances, your properties, your relationship. your client list, your market position, your current operating efficiencies, your reputation, etc. are all at risk.  These are things you have already achieved; objectives you already attained.  You are interested in protecting them;  they are your interests.

Risk management is (far more) often used to protect existing interests, while also being used as an aid in ensuring we achieve our objectives.  It is in the former where risk management plays a more central role.  Risk management is key to maintaining what we have; it is the means there.  It is only useful in achieving what we do not yet have; here it is not the means.

My proposition is therefore to change the wording of the risk definition from ‘objectives’ to ‘interests’.   Thus risk becomes: ‘the effect of uncertainty on interests’  where interest refers to things we value, such as health, reputation, property.   But it also clearly encompasses as well as things you seek to achieve but have not yet -- your objectives.

I think this change would be an improvement to the definition.

Jan 8, 2013

The Value of Ideas

Ideas are ‘a dime a dozen’ says the old quote.  And it’s true.  Unless and until an idea gets implemented, it has no effect.  It’s like gold that you didn’t know you had. 

Only when an idea is executed can you expect to receive its benefits.  There is a caveat though.  Ideas can also bring unwelcome effects.  Perhaps that is one explanation why many good ideas remain ideas.  We are afraid of the bad effects if we implement an idea.

Some ideas have little negative effect.  Put your money in the bank so it will earn interest.  There is very little danger in there.

Other ideas have potential negative effects. Put your money in the stock market so it will gain value, or at least negate the effects of inflation.  But wait: you might also lose some or all of your money. 

Ideas have an aim.  The idea to look left and right before you cross the street has the aim of keeping you safe when you cross the street.

Ideas are propositions about how things can be better.  The proposition of looking left and right before crossing is that by doing so, you will notice if there are vehicles approaching. 

Ideas have a cost to implement.  Some ideas are easier to implement than others.  Look left and right before you cross is one of those that is easy to implement and cost nothing.  That is why all of us do it.

The idea of backing up your work frequently has the aim of ensuring you have a copy in case something goes wrong with your computer.  The cost of doing so is more than the cost of looking before you cross.  That is why we have to be prodded to do it.

Ideas have an effectiveness.  Some ideas work better than others.  Looking left and right before you cross has a very good effectiveness.  It always works.  The idea of creating a project schedule has the aim (among others) of controlling the project’s delivery timeframes.  It doesn’t always work.

To sum up, ideas have characteristics set them apart from other ideas:

  • The aim
  • The proposition
  • The cost to execute
  • The effectiveness

Is there a better idea than looking left and right before crossing the street?  How about listening before crossing?  It has the same aim: to keep you safe.  It has the proposition that you can hear if a vehicle is coming.  The cost to execute is comparable to looking.  The effectiveness is not so good.  We are not as good at judging the velocity of vehicles by their sound.

Dec 17, 2012

What are the Different Kinds of Requirements?

ARGUABLY the most well-known categorisation of requirements is the Functional and Non-Functional dichotomy.  So ubiquitous is this classification that one can refer to them with the acronyms F and N/F and people know what you mean. 

F is about what the system must be able to do, and N/F is about characteristics that the system must exhibit to some specified level, such as being “available for use 99% of the time” or ‘of yellow colour’.

Another major classification of requirements is that between business and system requirements.  The vast majority of projects in the IT and Telecoms field will produce two requirements documents: the BRD (Business Requirements Definition / Document), and the SRD (System Requirements Definition / Document).  The key distinction between a business requirement and a system requirement is that the former is about what the ‘business’ (or organisation) needs from the system, whereas the system requirement is about what the solution system needs to be able to do (functionality), and exhibit (non-functional requirements), in order to meet the business requirement.

If a system project is aware of only these two classifications of requirements, then serious gaps exist and it is very likely that the resulting system will not meet the business objectives to the degree promised in the business case.

One way to look at the requirements is that they form a hierarchy which is more than merely the business and system requirements.

Mission Requirements

At the top of the requirements hierarchy lie the mission requirements.  An organisation has objectives that need to be met, such as ‘improve processing speed’, ‘reduce cost per part’, ‘meet regulatory requirements’.  A concept of a solution is developed and mission level requirements are developed.  These requirements specify what is needed from the solution in order that it will meet the business objectives.  The concept solution, if it is to deliver the objectives of the organisation, must meet the mission level requirements.

These requirements may include such things as interoperability with existing organisational systems, availability by a certain future date, or cost only a certain amount.  

Stakeholder Requirements

Next come the stakeholder requirements. What do each of the stakeholders need to be able to do, in order to meet the mission requirements?  If the mission is to 'improve processing speed by 100%’, what does stakeholder A, B, C, etc. need?  These requirements are written in the language of the stakeholders (for it originated from them, and since they need to confirm the cleaned-up version). 

Although these requirements originated from the stakeholders, they almost always need to be elicited from them through capable facilitation.  They also need to be reviewed for completeness.  Stakeholders tend to provide only the most salient requirements prominent in their mind.

Derived Requirements

The Stakeholder Requirements are analysed and reviewed to produce the Derived Requirements.  Derived Requirements are the input to the Design process and the Verification process and therefore are written both in more precise language (e.g., “the system shall…”) and in more technical language.   Since these requirements are derived, there must be some form of written justification as to how a derived requirement meets a stakeholder requirement.  From an administrative point of view, we also need to maintain traceability links back to the stakeholder or mission requirements.

System Requirements

System Requirements are Derived Requirements which specify system-level functionality or characteristics of the desired system.

Component Requirements

Component Requirements are Derived Requirements which specify what specific components must meet.  For example, for a web-based system, components might include requirements for web servers and database management systems. 

There are other ways to classify requirements, but they are orthogonal to the above.  For example, there are things such as Input Requirements, or Operational Requirements, and Schedule Requirements, but each of these also fall within one of the above hierarchy.