If you take a moment to review most risk logs, on closer analysis you will find that the quality is variable at best.
The reason is that many project teams do not put the appropriate time and effort into capturing and managing project risks.
Unfortunately many see the process as a “tick box exercise” that they only do because they think they should and / or they are asked by the PMO. However, the reality is that capturing and managing risks can help prevent the issues that delay a project.
This blog contains a number of posts on risk management. However, there is not one on how to write a project risk. Therefore, this post will cover the 5 steps to writing an effective project risk. Note, the assumption is that you have taken the steps to capture the risks.
1. Title
Every risk should have a title that makes it clear to what the risk relates.
Poor Title: Resources
While the risk may relate to resources to support the project, this title is too generic. It does not specify what type of resources, is there not enough / too many and why they are needed.
Good Title: Lack of Java resources to develop website interface
This title makes it clear that the risk is lack of java resources and that they are needed to develop a website interface. You could even be specific on the actual website if there are a number of other website developments.
While you want the title to be clear, try to keep it short.
2. Risk Detail
Each risk should have a clear description that explains the risk so that the reviewers can understand the risk. As some may not be close to the project detail, it needs to be written using language that all can understand, including avoiding the use of technical / project jargon and acronyms.
Bad Risk Detail: There may not be sufficient resources to complete the project.
While this makes it clear that there may insufficient resources for the project, it does not detail type of resources, when they are required and the work that needs to be completed.
Good Risk Detail: There may not be sufficient java developers to complete the development of the website interface between September and October 2014.
This makes it clear of the type of resources, that there may not be enough, what they are needed for and when.
3. Risk Consequence
The reason for identifying a project risk is that they usually will have some form of impact on the project if the risk becomes an issue. Therefore, it is important to document the consequence so that the reviewers can understand the consequence to the project if the risk is not managed.
Bad Risk Consequence: Lack of resources may cause delays.
Again, very generic and does not really explain the consequence. Surprisingly, this type of statement is far too common in risks.
Good Risk Consequence: Delays to completing the website interface development by 31st October 2014. This will directly delay the testing phase. Each day delay during development will extend the completion date of the project by 1 day.
This statement makes it clear that the consequence of not having the required resources will delay the development of the website interface and will ultimately delay the end of the project.
4. Target Resolution Date
This is the date by when the risk needs to be addressed (mitigating action taken) or accepted (the project is happy to accept the impact if the risk becomes an issue).
Bad Resolution Date: No date specified, TBC (to be confirmed), TBA (to be advised), general dates (i.e. end of year, end of project).
If there is no clear understanding when the risk needs to be addressed, it is usually because it has not been clearly defined. It is common to see generic risks relating to resources and the end date being set as end of year / project. Not very helpful.
Good Resolution Date: This should be the date by when action needs to be taken to address the risk. In the example in this post, java website development needs to complete between September and October. Therefore, the date to address resource concerns must be 1st September 2014 at the latest (the date the resources need to be available). In reality you would want to set a date in August to give contingency i.e. 15th August.
Important: try to set real dates as opposed to ones where it does not matter. If a date is set and missed and there is no consequence, it will mean that other deadlines will not be taken seriously.
5. Mitigating Action
Defining the risk is only part of what needs to be captured. The project team should also provide proposed mitigation (the action to be taken to address the risk).
Bad Mitigation Action: Monitor resources to identify delays.
Another generic statement that states that resources will be monitored. This will probably result in lack of resources only being known when it is too late.
Good Mitigation Action: Identify named resources to complete java website interface and gain agreement that they will be available to support development between September and October. As contingency, engage 3rd party provider of java developers to see if they can provide resources at short notice should they be required.
This mitigating action gains commitment of the required resources and also tries to put in place a back-up plan.
Summary
It is important to clearly capture the key components to a risk.
Title – a good description of the risk
Risk Detail – specific explanation of the risk
Risk Consequence – what will happen if the risk is not addressed
Target Resolution Date – the date by when the risk must be addressed or accepted
Mitigating Action – what steps will be taken to address the risk
Following these 5 steps will help ensure that you capture and define good risks for your project.
If you are a PMO you can use them as the principles for the processes you define and mentor the project teams.
You can find associated project risk resources in the links below this post.
