So let’s start with developing an understanding of what risk management means to the general populus. What is Risk Management?

Wikipedia, with some modifications of my own, describes it as:

Risk management is the human activity which integrates recognition of risk, risk assessment, developing strategies to manage it, and mitigation of risk using managerial resources.

The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.

Objective of risk management is to reduce different risks related to a project to the level accepted by the project board/managing organisation. It may refer to numerous types of threats caused by environment, technology, human resource and politics.

This is a pretty good description. Remember it.

There is one point I’d like to make before we go too far into the article. Whilst there are obvious negative connotations with the word risk this process can be equally applied to ‘opportunities’. Instead of trying to mitigate the impact or probability of opportunities you might want to ‘enhance’ them to magnify the potential benefits. When you read this article try to keep this in mind and apply those same RM principles to OM (opportunity management).

So, the first question I’m sure you’re asking is: “Where do I start?”…at the beginning of course….the beginning of the project…

The following process can be used as a reference guide as you navigate through this article. All process map steps are fleshed out in the body of the content.

The first and, arguably, most important phase of the RM process should happen alongside the requirements gathering stage of the project.

Get management sign-off of your RM process.

Let me reiterate this point…do not try to launch this process without the requisite level of stakeholder buy-in. Lack of stakeholder support is the primary reason RM fails….don’t let this happen to you.

So the first thing you need to do is create a simple template for your risk log. An obvious choice is MS Excel. I fully accept that there are many powerful tools out there within which to manage your risks (and multiple programme management toolsets such as Niku Clarity, Mercury ITG, Planview, Primavera P3e etc which possess this functionality as standard in their offering) but the focus of this article is simplicity of implementation and execution. This simplicity needs to be reflected not only in the content we are capturing but in the tools we are using to capture the content and the supporting process we are using to drive the capture. If you get any of those elements wrong you will face an uphill struggle to successfully implement RM.

 

Type ‘Risk Log Sample’ or ‘Risk Register Sample’ into Google and you’ll get a plethora of results. Choose one and customise it to your needs.

 

As you increase the size of your project you may need to start categorising the risks by area (e.g. development team, programme management, research and development, operations, finance, sales etc). For the purposes of this article we will assume the project / programme is not of sufficient size to build in multiple ‘feeder’ risk logs.

Whilst this article has been written from the perspective of project initiation it equally applies to implementing RM during a project. At this point I’d recommend that you define a RM cycle that aligns with your management reporting cycle. This is essentially a breakdown of when you will update your risk log, run risk reporting and summarise the risks to be escalated to the management team. For most projects an appropriate cycle is every 2 weeks or every month (simply because risks are less likely to change significantly from cycle to cycle whereas other information - like issues or earned value - should be collected more frequently as it changes more rapidly).  It is important to ensure risks are an agenda item on your team status meetings.

OK, back to the practicalities of implementing the process. A risk brainstorm should be undertaken (but can be supplemented by a more structured template list of the most common risks according to your experience/the experience of your team).

There are a number of resources you can use to help you focus attention on possible risks. A few good links to use are:

• Risk Taxonomy - http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.006.html

• Risk Resources - http://fox.wikis.com/wc.dll?Wiki~CategoryRisk

These risks should initially be assessed at a high level, and you should define a numbering system for both Impact and Probability. It is important to categorise the risk at a high level and this can be readily achieved by defining a clear range for each of these variables. A sample categorisation follows (but should be customised to your projects needs):

Impact
- (5) Catastrophic (Very High) – (30% < x of project budget, mandatory milestone threatened, critical path activity impacted)
- (4) Significant (High) – (15% < x < 30% of project budget, critical milestone threatened, near-critical path activity threatened – minimal float eliminated)
- (3) Moderate (Medium) – (5% < x < 15% of project budget, milestone threatened, near-critical path activity threatened, float reduced but still not critical path)
- (2) Minor (Low) – (1% < x < 5% of project budget, non-critical path activity float eliminated)
- (1) Insignificant (Very Low) – (x < 1% of project budget, non-critical path activity float reduced)

Probability
- (5) Probable (Very High) - (30% < x )
- (4) Possible (High) - (15% < x < 30%)
- (3) Unlikely (Medium) – (5% < x < 15%)
- (2) Rare (Low) – (1% < x < 5%)
- (1) Negligible (Very Low) - (x < 1% )

This initial scoring will help bring the most significant risks to the forefront and ensure valuable project time isn’t lost concentrating on the risks with lower, overall, severity.

A rough chart (Figure 1) is attached which shows one widely-adopted scoring mechanism that uses simple multiplication to assess the severity of the risks and hence determine the initial risk focus areas (represented by the red and amber sections). It is worth noting that the green section shouldn’t be completely ignored but instead compiled into the overall Risk Register for future re-evaluation as the project progresses (as the originally assessed impact and probability can obviously change over the project lifecycle). 
 
The sections above can be generically described as follows:

• Red risk – These are classed as primary or critical risks requiring immediate attention. They may have a high or low impact or probability of occurrence but their overall severity warrants their treatment as a high priority. This may mean that strategies should be developed to reduce or eliminate the risks or mitigation in the form of contingency planning should be put in place and the risk monitored on a regular frequency.
• Amber risk – These risks are classed as significant. They may have a high or low impact or probability of occurrence but their overall severity is regarded as sufficiently serious to warrant appropriate consideration. As above strategies should be developed to reduce or eliminate the risks or mitigation in the form of contingency planning should be put in place and the risk monitored on a regular frequency.
• Green risk – These risks are less severe but may cause upset and inconvenience in the short term. These risks require minimal monitoring unless subsequent risk assessments show a substantial change in their probability of occurrence or impact.

These risks whose ‘severity’ (probability multiplied by impact) that have been scored of 5 or over (amber or red sections) should now be compiled and taken through to the next stage of RM where, in priority order, we evaluate them in more detail (it is worth noting that the threshold over which you take risks forward and leave them behind is really up to you/your project and how much time you have available to undertake this exercise).

Now that you have ordered your risks and determined which ones will be evaluated in more detail we can move onto the second, more detailed, analysis phase.

 

Whilst it isn’t unusual to find risk logs with 20 or more fields I find that to make it: a) manageable, b) digestible and c) usable you need to strip these down to core principles (especially since we’re talking about a RM system that will actually work). In my opinion these 12 core fields are as follows:

 

1. ID – A unique identifier. Label them as you see fit…as long as they are unique
2. Description – Simply a clear concise description of the risk and its potential impact. This field is where you can outline some basic reasoning for your cost and probability estimates. Start with the simple title of the risk e.g. Resource Scarcity – There is a risk…etc
3. Risk author – Who identified/raised the risk in the first place.
4. Risk opened – The date the risk was identified/raised.
5. Risk closed – The date the risk was deemed as no longer being active.
6. Cost Impact – You should now convert the initial numerical impact (between 1 – 5) into a tangible cost impact. Some people try to argue that some risks can not be quantified in this manner….I say to them to give me an example of a risk that can’t be quantified and I’ll give you an example of something that isn’t a risk. But I admit sometimes you have to be creative when these risks might not actually cause a cost impact (e.g. having a wedding ceremony in the rain verses under a marquee) however you need to think in terms of ‘worth’. What is it worth to have all your wedding guests dry verses soaked to the skin (don’t get this confused with the cost of mitigating the risk…we’ll come to that shortly, just think of the value to you of this event not occurring)
7. Probability – Simply put, what is the % chance that this risk will occur. Using the above example, what are the chances of rain on a given day. If you are planning the wedding 6 months in advance you will need to base this probability on past estimates of rainfall in the location and time of year. This might give you an average chance of rain of, say, 10% (as you get closer to the risk window [between start and end date of exposure] you will re-evaluate your risks to get a better view of their probability/impact). In this example you would be able to get a 7-day forecast as you approach the wedding day, giving you a much more accurate probability of a ‘rainfall’ event occurring.
8. Treatment – Once the risk has been identified you have to decide how you are going to treat it. Each of these options should be documented in enough detail for anyone reading the log to understand. In some instances the reduction or contingency plans may refer to an additional, more detailed, breakdown. The options for risk treatment are as follows:
1. Mitigation/Reduction – Refers to an active reduction in the impact or probability of the risk occurring. Using our example this may mean moving the wedding in Texas (to reduce the likelihood of rainfall) or paying for a marquee to be erected on the day which can house the guests if rain occurs (and hence reduces the impact). Essentially this means actively planning additional activities that are undertaken before the risk exposure window to lessen its impact/probability.
2. Avoidance – Take action in advance of the risk exposure window to reduce the likelihood of the impact to zero E.g. Plan to have the wedding indoors so the impact of rain is eliminated.
3. Acceptance – Understand the risk and accept that it may happen. This will usually happen when the impact (in the event of the risk occurring) is minimal or the probability approaches zero. In our example this would mean taking no action and just accepting that if it rains the guests will get wet.
4. Transference – Moving the impact of the risk to another party. This type of treatment isn’t possible in all circumstances but is often associated with the utilisation of Insurance Brokers who will charge you a premium to take ownership of the risk themselves.
5. Contingency -  This final type of treatment is one of the most common, in that it involves planning a response to the risk that can be actioned immediately should the risk come to fruition. In our wedding example this could mean having a number of alternate indoor venues on hand should the risk occur.
9. Treatment description – So, you’ve decided how you’ll treat the risk but now you need to concisely and clearly define your approach. Don’t go overboard in your description but ensure you have enough detail for it to be useful to another party who may be read the content.
10. Treatment cost – Estimate how much is it going to cost your project to put this form of treatment in place? In the case of acceptance this will be zero. In the cases of avoidance, mitigation, transference and contingency this will have a cost impact.
11. Treatment responsibility – Who is going to action the treatment outlined above? This should the individual accountable.
12. Exposure Start Date – From what date is your project exposed to this risk? Whilst this can obviously get more complex if the exposure level changes over time the most important factor here is to keep it simple. Whilst it may not be 100% accurate it will certainly be significantly better than not having RM at all!
13. Exposure End Date – To which date is your project exposed to this risk?

OK. So I mentioned at the beginning of this article that the best place to start was the beginning of the project. So let’s just revisit where we should be by this stage:

 

• You can describe the purpose of RM
• You have created a risk register template and defined the  associated risk management cycle
• You have brainstormed the project risks
• You have evaluated your risks against probability and impact and prioritised those to be evaluated further
• You have undertaken a detailed evaluation of the prioritised risks and logged all appropriate details (as outlined above)
• You have defined, agreed and documented the best treatment for each risk
• You have calculated your project contingency and management reserve

 

Now I want to talk you through a poorly applied area of RM…reporting…

Lets outline a few generic reporting principles, that I strongly believe in, before we move on:

 

• Don’t confuse quantity of reporting with quality;
• Don’t create a report unless you have a specific sponsor (i.e. someone really, really wants to see it regularly);
• Ensure the content is accurate. There is nothing that undermines your (or your teams) credibility faster than an inaccurate or contextually flawed report;
• Be prepared to defend the data content of your reports. Ensure you can talk knowledgeably about the data set;
• Revisit reports periodically (every 3 months is reasonable) to ensure you maintain sponsorship and confirm that people understand them and are still finding them useful;
• Train your people to interpret and use the information in the reports. The old saying of “If I build it they will come” applies, in reverse, here; and
• Look for value in every graph, list and report you produce. A good rule of thumb is: can an important management decision be made off the back of the report? If the answer is no you have probably fallen into the trap of producing something pretty but useless…or worse still ugly and useless.

 

OK. With those rules in mind I’d like to reproduce and describe a couple of simple reports that I have used in the real world….reports that work.

A simple report which captures the assessed effectiveness of the defined risk treatments. It shows the assessed severity of your original risk profile and that same profile after your various treatments (contingency, acceptance, avoidance etc) have been applied. 

Let me do a quick example: Risk 9 – Originally a high impact but low probability risk. We aren’t comfortable with the severity of the impact if it occurs (however unlikely). So we decide to talk to an broker and get insurance to cover the cost impact of the risk. You’ll note that the probability hasn’t reduced (as you haven’t taken any action to minimise the likelihood of occurrence) although the impact has reduced significantly to reflect the fact that the insurance you have taken out has minimised the amount you will have to pay should the risk come to fruition. The residual impact may be down to the insurance ‘excess’ you have to pay in the event of the risk being realised.

 

The definition of an ‘acceptable’ risk profile is down to the project sponsor. But it’s essential that you are aware of that profile so you can manage the risk information effectively and ensure your risk analysis is informed.

The premise for this report is simple….To get the financial impact of risk in front of your senior management team. Sounds sensible doesn’t it? There is nowhere to hide and no excuses when you present impacts in real cost terms. You may stir up a hornet’s nest and people may challenge the impact estimates or probability but don’t get defensive of the numbers, just politely but firmly point out the process to re-estimate risks and ask for their contribution…once they realise they have a direct link into the process they will stop challenging the content and start focusing on effective risk treatment and exposure management.

 

The graph below is a straightforward manifestation of this principle. The example below shows ten risks plotted using exposure start and end dates, exposure severity (impact multiplied by probability) and plotted cumulatively over the length of the project.

 

So what analysis can we derive from this graph?

 

• Total estimated exposure at any point in time (useful for determining the potential level of contingency draw-down over the life of the project);
• Risk expiration over time. This will allow down-sizing of the contingency budget as the project progresses (this is especially useful over long projects or programmes when the contingency can run into the millions); and
• Risk peaks and troughs. This will help you prepare for times of higher probability peaks of activity (this can be driven by contingency plan implementation or execution of planned mitigation actions).

Perhaps the most common of risk reports and, in most instances, the most useful is the tabular risk report (aka the Risk League Table). Essentially it’s a table of your risks with their associated content. The risk with the highest severity (probability multiplied by impact) will appear at the top and risk with the lowest severity at the bottom.

 

This report can be regarded as your ‘working’ report that is the basis for detailed discussion on top severity risks, proposed treatments and treatment sign-off.


There are hundreds of sample tabular risk reports on the web so find one that broadly suits your needs and customise as appropriate.

You should now be up-to-speed on all the basics to make RM work for you and your project or programme. But before we finish up remember that, in practical terms, so many RM systems will fail because they don’t get stakeholder support. If you can garner their support (as mentioned earlier in this article) then you must ensure you keep them engaged. OK, so here are a few key principles:

 

• Keep the process as simple as possible (don’t over-engineer it);
• Approach risk contributors with a gentle but firm approach. Playing ‘bad cop’ will undermine business relationships and being too nice will eventually erode the respect they have for you and the process compliance and deadlines will suffer; and
• Make all reporting relevant. Concentrate on providing stakeholders with useful, actionable metrics and analysis rather than falling into the quantity over quality trap…

 

Now you’re armed with a high level pragmatic view on creating a workable and sustainable RM solution. Good luck!