Topic 7.2: Risk identification
As you might imagine, the purpose of formal risk identification is to hypothesise as many known risks as possible.
This is because there are significant consequences for how we treat them.
Known risks can be either treated directly or have contingent responses created for them.
All we can do for unknown risks is allocate a general reserve of time and money and hope for the best!
Back in the initiation phase we started considering project risks, although these were largely at the organisational level.
For example, we looked at the risks of market acceptance, technical capacity, legal and economic risks, as well as the risks of proceeding with different alternatives.
At the project level, the risks we are likely to encounter include:
Funding – do we have enough money to deliver the required scope?
Time – will we have enough time? Or, as we considered earlier, how confident are we in our estimates?
Staffing – are the necessary skills available when we need them?
Complexity – are we making things too tricky by half? Remember that inverse relationship between scope and quality!
Political support – how secure is executive management support for our project?
Stakeholder expectations – can they be met? Are they likely to change?
The real world – what is entirely out of our control? What is the risk of flood, fire or other force majeure?
And that doesn’t even begin to consider the innumerable technical risks of our unique project endeavour!
Risks can be identified by performing a historical review of past projects; engaging stakeholders with relevant expertise in the project under consideration; and, applying a wide range of creativity techniques to encourage team members to hypothesise likely risk scenarios.
The knowledge and skills for doing this was covered in the last Module, so I would encourage you to review the relevant presentations.
Regardless of the process followed, though, it is important that project risks are unambiguously described.
This ensures that team members and stakeholders can easily see the relevance of the risk to the project.
For that reason, we often detail each risk using a three part statement: cause – risk – effect.
In other words, ‘If X occurs, then Y will happen, which will have Z impact on the project.’
Therefore the risk identification process can be reduced to three simple questions:
what could possibly go wrong (or right)?
For example, it could rain – the cause
what does this mean for the project?
Equipment will be damaged – the risk
how will this impact project performance?
The project will be delayed by an extra day as we source new equipment, and we will need to source another $500 to replace the damaged equipment (effect)
From this starting point we can further brainstorm a number of variations, using the mind mapping method.
For example: what else could damage the equipment? It could get dropped.
What else could delay the project by one day? A key team member could fall ill.
And so on…