Risk Management

Risk-Matrix__FillWzYwMCwzNDBd

Risk Management for any project manager is a very much maligned topic. It is the one area that seems to cause so many clever PMs the greatest doubt and confusion. Why is this so? I think it is because we have so many things to consider when we are running our project and since risk is all about uncertainty thus it has not occurred and may never occur –it is all too hard and as a busy PM we have other areas that we can concentrate on without too much effort – therefore, lets do the easy aspects of managing our project and move on.

Sound familiar – well read on for whilst I can’t solve all your risk management problems I can provide you with some practical advice on how to assist your risk management activity.

The concept of risk has been around for thousands of years, evidence exists that it was used in by Egyptians over 3000 years ago when they were building the pyramids.

Most recently the concept of risk has developed a negative connotation – the chance of loss or cause of loss, however, it wasn’t always portrayed this way. The Arabic word ‘Risq’ means ‘favourable outcomes’ and the Greek word ‘Rhiza’ referred to either positive or negative results of sailing around a cliff into unchartered waters.

Both of these definitions provide a more balanced concept for risk – that of ‘Danger and Opportunity’.

As a result, most methods define risks as ‘the chance of something happening that will have an impact on objectives’ (or as per ISO 3100 – ‘the effect of uncertainty on objectives’.)

That being so – we project managers typically have a negative view in relation to risk management that is mostly associated with the impact on the six fundamental variables of any project – namely cost, time, quality, scope, benefit and risk.  That is, anything that has a chance to negatively impact on one of these variables causes us problems – and because we too want to end up in Programme management we don’t want problems because they may stop us getting promoted.

So now that we can understand how important this is to us – how can do we most effectively use our precious commodity (time) in our risk management activities.

Risk management is a process driven discipline whereby a Project sets up management policies, procedures and practices to manage risks and opportunities.

Fundamentally all risk management methods (eg. such as: Risk Committees, Critical Chain, RAMP – Risk Analysis and Management for Projects, CRAMM – CCTA Risk Analysis and Management Method, Continuous Risk Management, Management of Risk, or even ISO 3100 – Principles and Guidelines on Implementation) have a generic common thread to approaching risk –

–          Risk Assessment – composed of Identify Uncertainties, Analyse the Risks, and Prioritise Risks

–          Risk Control – Mitigate Risk, Plan for Emergencies and Measure and Control.

However, what we fail to discover most of the time is that prior to charging off into our risk identification workshop we need to establish a very simple fundamental that will save us countless discussions (arguments).

That is, as part of setting up our Risk Management plan, let’s define some criteria against which we can map our risks. Typically in any project we want to identify ratings for three fundamental aspects of any risk:

a)      What is the definition of likely hood (or chance of it occurring)

b)      What level of impact if it does occur and how important is it that

c)       What is the importance of this risk (risk rating)

Even in the most basic risk management workshop, you probably use the concepts of High, Medium and Low.  The question is what does this mean to us (especially when we have to get up in front of management tell them what each risk means and why we think it is important). The trick is to do some definition work so that whenever we run the risk activities every one works based on the same definitions.

In order to define what they all mean we need to: speak to the stakeholders of the project – what are their critical success criteria; review our project character (visibility, value, experience, size & complexity, etc); and confirm our projects elements of success (scope, cost, time, quality, benefits, etc).

Based on these discussions we should be able to develop some criteria scales against which we can use to judge our respective risks. For example we could use a rating table for determining chance via the following qualitative statements:

RatingDescription
Almost certainExpected to occur in most circumstances
LikelyWill probably occur in most circumstances
PossibleCould occur at some time
UnlikelyNot expected to occur
RareExceptional circumstances only

Or for determining risk impacts based on probability, for example using something like the table below: (NB. You can use numerical scores if needed)

Project Success CriteriaVery Low .05Low .1Moderate .2High .4Very High .8
CostInsignificant cost increase< 5% cost increase5-10% cost increase10-20% cost increase>20% cost increase
ScheduleInsignificant schedule slippage< 5% schedule slippage5-10% Overall project slippage10-20% Overall project slippage>20% Overall project schedule slips
ScopeScope decrease, barely noticeableMinor Areas of Scope are affectedMajorScope reduction unacceptable to the ClientProject End item is effectively useless
QualityQuality degradation, barely noticeableOnly very demanding applications are affectedQuality reduction requires client approvalQuality reduction Unacceptable to the ClientProject End item is effectively useless

Finally, we need to establish some guidance for both how important the risk is and what do we have to do if it is Low, Medium, High or Extreme.

LikelihoodConsequence
 InsignificantMinorModerateMajorSevere
Almost CertainMediumMediumHighHighExtreme
LikelyMediumMediumMediumHighExtreme
PossibleLowMediumMediumHighHigh
UnlikelyLowLowMediumMediumHigh
RareLowLowLowMediumMedium

Having established this basic information we are now ready to start identifying and classifying our risks. This critical information ensures that everybody in the project can very simply determine – against a know criteria – how important this risk is to the project and eliminates the guess work or inconsistency that occurs between stakeholders in the project.

Regardless of whatever criteria your going to use it must be established and detailed right up the front of the risk management activity so that it can be consistently applied throughout the process.

Leave a comment

Your email address will not be published. Required fields are marked *