About Me

header banner

Attack the Risks before the Risks attack you!

You will improve your probability of Project success greatly if you look to identify the Risks for your project and go out and attack the important ones. There are many manuals written on Risk Management so what I intend to do in this post is give a "whistle stop tour" and inspire you to take this seriously in your Projects using a few Proverbs along the way!
Projects - Attack the Risks before the Risks Attack You

What is a Risk?

Firstly a reminder of what a Risk is. A Risk is an event which may happen which can have a negative (or positive) impact on the project in all it's dimensions - Time, Cost, Quality, Benefits etc.

Yes you can have Risks with a positive impact - an upside! For example, if your Project is to introduce a new public search engine. If you stated a Risk of Google going out of business, this would have an upside on your Benefit Case for sure. I just don't think the probability would be that high and we will return to that point later. But it raises an interesting point on Risk Identification. We all focus on internal risks but we should try and force our thinking to consider external risks too.

Another point you might want to get a sense of early on in the project lifecycle (ideally from the Project Board) is how much risk is acceptable - sometimes a project needs to be very risk adverse, sometimes a more risky, adventurous project is acceptable.

Step 1 - Risk Identification & Recording

The first point to recognise about Projects is What you don't know ..... hurts you!

Project Risks - What you don't know hurts you!

So use your own judgement and that of the team (brainstorm workshops) on what could trip up successful execution of the plan (mainly) and also consider both internal and external factors. You can always put in some standard risks, here are a couple for your Risk Log - Parkinson and Murphy!
Project Risks - Parkinson and Murphy are alive and well - and may be working on the Project

Some other top tips with regard to identification are:
  • every open assumption should be considered as a corresponding Risk, see a specific post on this
  • record in a Risk Log which is easily maintainable and sortable
  • use similar style wording "Risk that <something happens> due to <cause> resulting in <effect>"
  • double check, have you captured both the cause and effect of the risk?

Step 2 - Evaluate Risk

Three dimensions to consider in the Evaluation of Risk are:
  • Probability - for simplicity I use a Low / Medium / High rating
  • Impact - for simplicity I use a Low / Medium / High rating but also have text box to articulate in real terms using the typical project dimensions of Time, Cost, Quality, Benefits etc 
  • Proximity - when is a risk likely to materialise as an issue? Clearly if a risk can't materialise for many months you can focus your immediate attention to those that could hit you next week!
What I do in my Excel Risk Log is to apply a simple scoring system 1 for Low, 2 for Medium and 3 for High. I then multiply Probability x Impact to give a Risk Score and sort the resulting log by Score to give a crude list in order of importance to look at.

Step 3 - Devise your risk management response

What are you going to about each risk. Responses can include:
  • Accept - do nothing specific but continue to monitor
  • Mitigate - take actions to reduce the probability of the risk occurring or the impact or both
  • Prevent - change your plan so the risk no longer exists
  • Transfer - give the risk to some other organisation to manage
  • Contingency - establish a planned approach which can be brought into play if and when the risk materialises
Make sure you assign ownership for the Risk. The owner keeps an eye on the risk (has anything changed re probability, impact and proximity) as well as, in many cases, the response actions (although I recommend that the Project Manager keeps an eye on anything significant)

Step 4 - Ongoing monitoring

Ongoing monitoring and review whether new risks have been identified is important across the project lifecycle. My personal approach is to have a weekly meeting with the sole purpose of reviewing RAIDs (Risks, Assumptions, Issues, Dependencies). However:
  • include the topic in other meetings you have with the team so thinking about risks is embedded in the whole team psyche
  • ensure the Risk owners take their role seriously and keep you posted outside any regular meeting. The person should understand that they will be under the spotlight should a risk materialise and questions will be asked!

Conclusion / Other points

As I said in the introduction, Risk Management is a big topic and this is just a taster to inspire you to take it seriously within your project and not just pay lip service to the topic. So go identify, evaluate and attack the big risks which threaten your project success. Otherwise, there is a fair chance that one of them will come and give you a bloody nose!

Some other points not yet mentioned which need consideration in Risk Management:
  • budgetary impact
  • communications to/from the Project Board

Post a Comment

0 Comments