Risk Management, along with Corporate Governance has become one of the biggest focuses for companies globally. This is largely a result of the broader operating environment (market conditions, regulation, consumer demand, competition and unfortunately natural disasters and pandemics) becoming increasingly volatile which can impact ROI. This in turn has increased the focus on Risk Management in projects and it is one of the key processes every Project Manager should know.
Managing Risk on your Projects
In order to have a clear view of Project risk, the Project itself needs to be well defined via a Project Charter or in the Project Brief, Scope documents or Release Plans. Without that clear baseline, the level of risk cannot be established. A common pitfall for many projects where risks can’t be quantified and they all get treated the same. Given risks are ever-present and the Project accepted a certain amount of risk as part of the investment approval in the first place, the Project team could drown in immaterial risks and ‘what-ifs’ without knowing which ones really matter.
The best way to do this is to have a risk matrix that can use the two dimensions of likelihood and consequence for you. A typical matrix uses a five by five grid to assess risk – here is an example 👇
Risks on projects also need to have two ‘states’ where the first state is the rating should no action be taken. This is called the inherent risk rating and can be used to determine what treatment strategy should be employed including ‘do nothing’. The second state is the residual risk rating which is based on an action being taken and it having an effect of reducing the risk (either in full or to a degree) to a level that can be accepted.
Finally, Risk Management must be linked to authority levels and delegations. This should be via a Delegation of Authority (DOA) policy in an enterprise risk framework that ensures that risk acceptance can only be done by someone recognised as having the authority to do so.
Example of Risk Management in a Project
Scenario
In a software development project a vendor informs the Project Manager that they are facing some delays in delivering the required component within the agreed timeline. Worst case the vendor states that if they are not able to deliver the component, due to other commitments for the vendor resources, they cannot deliver for another 4 weeks. The vendor tells the Project Manager they will monitor it and hopefully everything should be fine but wanted to flag it.
In this scenario there are a few options for the Project Manager:
- The do nothing approach - Be optimistic that everything will be fine and wait for updates from the vendor.
- The basic Risk Management approach – log the risk that there could be a delay but do not undertake any analysis or develop additional treatment plans.
- The recommended Risk Management approach – log the risk and determine the risk rating to establish next steps.
Risk Assessment
The Project Manager and stakeholders discuss the risk and review the likelihood and consequence:
- Likelihood – ‘Likely’ given the vendor has a history of failed deliverables and the team has assessed status of the component as behind schedule.
- Consequence – ‘Major’ given a 4-week delay will mean the project misses the planned release and will impact future work.
- Inherent Risk Rating = Extreme
In most organisations, Extreme risks are unacceptable so there is now a clear need to develop a mitigation plan and reduce the risk.
Risk Mitigation Plan
The Project Team, working with the vendor determines that they can reorganise some work and prioritise additional capacity to bring the deliverable back in line with schedule. The Project Team also works on the Release Plan and gets approval for a contingency plan where the release can still go ahead with the component to be delivered in a subsequent drop. The updated risk assessment is as follows:
- Likelihood – ‘unlikely’ given the team has brought the plan back into line with dependent dates.
- Consequence – ‘Moderate’ given that even if there is a delay the project can avoid missing the release and although some work will carry over, it will not materially impact the investment or outcomes.
- Inherent Risk Rating = Moderate (acceptable)
This is an example of a ‘mitigate’ strategy where the Project Team actively sought to intervene and reduce the risk. Other strategies include ‘accept’, ‘avoid’, ‘transfer’ (trade-off) and as mentioned of course there is the ‘do nothing’ approach.