Are you on top of your project risks? Do you struggle writing risk statements and communicating them effectively? Do you run a Project Risk Log but find it tedious to update? Does everyone understand what the really important risks are on your project? Do you have endless debates about what a risk is and what it isn’t?
You are not alone…..
Let’s face it: Project Risk Management is not exactly the sexiest subject is it? I think every Project Manager struggles with Risk Management at some stage and even very experienced Project Managers find communicating risk effectively a challenge.
Common mistakes when communicating project risks
From my experience working with Project Managers everyday, the main issue seems to be around communicating risks, rather than the actual mitigation and management of the risks themselves.
These are the most common issues that I see with communicating project risks:
- The risk statement is too vague or unclear
- The impact of the risk is unclear
- The likelihood of the risk happening, and the impact on the project if the risk happens are not really clear or missing completely
- The risk statement will not be understood by the audience the risk is being communicated to, for example it may be explained in very technical terms for a non-technical audience
- The risk stated is out of date, has changed or morphed into something else
- The risk stated is irrelevant or pitched at the wrong level to the audience
- The risk statement contains several risks bundled together
- Important risks that need to be communicated are missed but less important risks are highlighted instead
So lets get back to basics…… and ask ourselves a question
What are we trying to achieve with Project Risk Management?
I believe a key part of Project Manager’s role is to manage risk on a day-to-day basis – it is not a “once a week” or “once a month” thing. What I mean by managing risk is this:
- Identify risks
- Understand the potential impact of the risks
- Communicate risks at the correct level to the right people
- Mitigate risks
So lets break this down in a bit more detail.
How to identify project risks
The answer is quite simple – by talking to people!
In most cases the people that will be able to identify the risks on the project are the people that are involved in it day to day.
I would advocate discussing risk as part of your everyday project activities rather than operating it as a separate risk analysis process. If it is baked into the project then it becomes easy to update the Risk Log as we go along. The key to success here is: little and often.
There are however a couple of times in the project where I would break this rule. At the very start of the project I would gather all of the people involved in the project, such as the delivery team and as many stakeholders as possible and I would run a session to identify all the risks that anyone can think of for the project. I have often done this as part of a project kick off workshop and have found it to be extremely useful to understand people’s view of the risks from many different angles.
The other time I would spend specific time allocated to Risk on the project is when you are just about to enter a critical phase of the project for example if you are doing a big launch of a system. I would carve out some time to focus on the specifics around risks around the launch and also spend some time looking at how they can be mitigated.
Other than these two specific scenarios I would be working with the project delivery team and stakeholders on a daily basis to assess where we are, what risks we are working on and what we can see coming up. I would also expect everyone involved to flag any risks to me at the earliest opportunity.
How to write a good risk statement
The key to stating project risks properly is to make sure they are written in a way that is clearly understood by the audience reading the risk.
I like to phrase risks using this format:
“If <event X> happens then there is a risk that the project will be impacted in <Y way>”
For example:
- If the new servers are not delivered by 10th February, then there is a risk that the commissioning engineers will not be able to start on the 11th and so there could be a delay to the project timeline.
Broken down: If [EVENT] the new servers are not delivered by 10th February, then there is a risk that the [IMPACT] commissioning engineers will not be able to start on the 11th and so there could be a [REAL IMPACT] delay to the project timeline
2. If the new HR software is not delivered by 1st May, then we may have to extend the contracts for the HR software testing team meaning there would be an increase in budget required.
Broken down: If [EVENT] the new HR software is not delivered by 1st May, then we may have to [IMPACT] extend the contracts for the HR software testing team meaning there would be an [REAL IMPACT] increase in budget required.
Rate your risks with an overall risk score
Now we have a good statement of the risk it is useful to rate your risks as follows:
- Rate the likelihood of the risk happening on a scale of 1 to 5 (1=low, 5= very high)
- Rate the impact of the risk if it happens on a scale of 1 to 5
- Multiply the two together to get an overall risk score in range 1-25
The overall risk score is really important as it allows us to then rank our risks highest first. Our main project management effort should be in mitigating our highest scoring risks; that is, the ones that are most likely to occur and will have the highest impact if they do occur.
Additional tips for writing risks:
- State the risk in unambiguous terms
- Keep risks “atomic” ie about one thing
- Explain the risk in terms so that anyone reading the risk will understand it
- If it is a technical subject attempt to summarize in layman’s terms
The Project Risk Log
Project risks should be documented in a Project Risk Log, which is normally maintained by the Project Manager. The easiest and most flexible tool to use for this is a spreadsheet.
The Risk log should have the following information for each risk identified:
- Title of the Risk
- Summary of the risk – using the format outlined in previous section
- Summary of the risk impact – using the format outlined in previous section
- Likelihood of risk – scale 1-5
- Impact of risk – scale 1-5
- Overall risk rating – Likelihood x Impact
- Mitigation plan – summary of actions being taken to mitigate the risk
It can also be useful to log the following information:
- Risk identifier – eg. R001, R002 etc. so easier to use reference number rather than explaining the risk each time
- Person who raised the risk – so you can refer back to them for clarity etc.
- Risk owner – ie the person owning the mitigation actions
- Proximity of risk – the date when the risk is likely to impact the project
- Date raised
- Forecast date for closing risk
Communicating risk at the right level for the audience
As I stated earlier the main focus for the Project Manager is on mitigating the highest-ranking risks. These are also the risks that should be communicated to the Project Sponsor and Key Stakeholders on the project through regular project reporting and/or project governance such as Project Steering Boards.
Keep your risks updated regularly and communicate often. Some risks may require assistance from the Sponsor and/or Stakeholders so get this help as early as possible.
Generally speaking I would try and keep the number of risks highlighted at these governance forums as low as possible – normally 4-7 risks is optimal. If you find that you have some risks that are very similar in nature – you may want to roll these up into summary level risks for communication purposes, but keep the detail in the Risk Log and cross reference the high level risks to the detailed ones so that nothing is lost and any confusions or repetition is avoided.
There is a fine balance to be had between communicating too much technical detail and not making the risks so high level that they are meaningless.
So now everyone is clear on what the risks are on your project. Now all you have to do is run your project and work hard to manage the risk away as soon as you can and keep everyone informed of your progress and get them involved to help you if needed.
The key in project risk management is to share good information, let people know what the challenges are and seek help. Good Luck!
Chris Wilson