When a problem or opportunity is identified, a business case is created which lays out how it can be solved or exploited, how much it will cost, how it will be done and what the likely outcomes of it will be. One piece of information which is often relegated to the back of everyone’s collective minds is the risk assessment. This approach is actually a risk in itself, since acknowledging, assessing and planning contingencies for the risks facing the project are key for its success or failure.
Creating a risk assessment is an unloved part of the business case because that stage of the project is precisely when people want to be pushing all the positives, like how great change will be and thinking about what success will mean for the organization and personally. But we’re here to help you see that risk assessment can strengthen your business case, not hurt it.
The Risk Log
To make sure your risk assessment is at a standard that both accounts and plans for potential risk and gains the trust and support of the project stakeholders, it’s essential to have a high quality and comprehensive risk log (also known as a risk register). If you’re unsure of what exactly an effective risk log should look like, we’ll walk you through its core elements here.
Features of a Risk Log
- Reference number: This column will be used for tracking and referring to the risk.
- Risk Description: This will give a brief description of what the risk is. It is recommended to use a standard format such as: X may occur due to Y, causing Z. E.g. Testing of API may be delayed due to lack of availability, causing the delivery deadline to be missed.
- Date Raised: When the risk was identified, a necessary detail for later project post-mortems and even legal action.
- Status: This describes what state the risk is in, e.g. Open, Closed, In Progress or Under Review.
- Probability: How likely it is for the risk to happen. A standard scale should be used, e.g. Low – High or 1 – 10.
- Severity: How big the risk is, usually calculated by multiplying the probability by the impact (which means a 1 – 10 scale in both will give a neat ‘severity %’).
- Impact: How damaging the result will be if it occurs.
- Mitigating Action: What can be done to prevent the risk from happening. This can include risk transference, e.g. inserting financial penalty clauses in a vendor’s contract or taking out insurance. In the example of the API testing, a mitigating action would be to hire temporary staff or reallocate resources.
- Contingency: How the risk will be dealt with if it does happen. For example, if the API testing mentioned earlier will be delayed, then the client will have to be informed and the project schedule will have to be changed.
- Owner: The person with overall responsibility for the risk area.
It is essential for important project documents such as the risk log to be widely circulated, accessible and updateable by the relevant team members and stakeholders. Multi-user, cloud-based project management software such as Planview AdaptiveWork makes this simple to achieve. To find out how we can help your organization plan for and deal with risk, get in contact today to organize a free demonstration.
