Project risk and issue management
What is a risk?
“An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives” APM Introduction to Risk Management.
To effectively manage risk, we must first find out as much as we can about what could go wrong with the project and then determine what can be done to prevent it from happening. This is not an isolated activity for one person as risks need to be identified and managed throughout the duration of the project.
The majority of risks are related to the fact that your project plan is based on estimates; however there are also unexpected events that can occur, such as key staff availability, legislation or government changes which have a cause and effect impact, for example “There is a risk that new legislation might lead to a change in system requirements”. Your project could also be dependent on the output of another project of which you have no control over.
It is worth noting that not all risks are bad, risk can present new opportunities and benefits and a balanced approach to risk management will ensure that rewards or opportunities are also considered when reviewing the possible negative effects of a risk.
Remember, all projects bring with them an element of risk, even the best planned ones!
What is an issue?
Risks and issues are closely linked. In simple terms, an issue is either a risk with near 100% probability, or one that has already happened. It could be a known risk that has escalated; in which case there could already be options for mitigation in place, or it could arise unexpectedly and be a complete unknown. If left unresolved an issue would negatively impact on the successful delivery of the project, and therefore immediate action needs to be taken.
Difference between a risk and an issue
A risk is a potential occurrence whereas an issue is something that has actually occurred. Good risk management will of course prevent many risks from turning into real issues.
Risk management process
Project risk management is a structured process of identifying and assessing risks, and then planning and implementing actions to respond to the risk.
Identify - Assess - Plan
This process allows individual risk events and overall project risks to be understood and managed proactively, increasing the chance of successful delivery of a project. A good time to review project risks would be during project team meetings. This will help inform discussions and determine whether any project risk requires escalation through formal governance structures i.e. project boards, Systems and Academic Projects Board (SAPB) / Capital Projects Board (CPB) and / or escalated to Project Coordination Group (PCG).
The Project Manager is responsible for putting in place a risk management process for the duration of the project. The risk owner must be clearly defined, documented and agreed as they have ultimate responsibility for ensuring the management of risk process is applied, even if someone else might actually deal with the risk.
Risk management is an essential part of project management, and should not be overlooked or trivialised.
The table below outlines the risk management process in more detail:
| Key steps | Actions |
| Identify the risk |
When identifying and assessing the likelihood and impact of the risk it is best to draw on the experiences of your team members, stakeholders, and lessons learned from other projects. It should be a team effort as people with different skills, experiences and specialisms will see individual risks differently and you want a balanced rather than a biased, analysis. You need to think about the following:
It is important that all risks are captured in a risk register (see below). |
| Evaluate the risk |
Evaluating the risk will consider the scale of impact and likelihood of the risk occurring, using a risk matrix (see below) to appropriately score and rank the risk. You should also consider assumptions and dependencies when evaluating risks and issues. If another project is dependent on the output from your project, then communicating and/or escalating risks is crucial to determine the issues/risks on the other project and at programme level. Similarly, if your project is dependent on another project, you need to ensure that risks to your project have been included in their risk register. |
| Review the options for mitigation |
This will explore various options to mitigate or control the risk, depending on the severity of the issue. This could include:
Any actions to mitigate against a risk or issue need to take in to account the costs, compared with the anticipated benefits from treating the risk. |
| Plan and resource the risk | Planning and resourcing should identify who is best placed to be the risk owner, and therefore be responsible for monitoring the risk, and who would be the appropriate person/team to work on the risk should it become necessary. This is not always the same person/team for both actions. |
| Manage and monitor the actions |
It is important that risks and the associated actions are reviewed on a regular basis. Something might be a high risk at the beginning of the project, however as the project develops it might become less of a worry, and can therefore be reduced to a medium, moderate or low risk. Similarly the mitigating action may reduce or resolve the risk.
|
| Communication | The resolution, and/or escalation of the risk, should be communicated with the project team, and where necessary the wider stakeholder group. |
Risk matrix
The project management framework has adopted a 4x4 risk matrix for the assessment of project risk (.pdf)
Proximity
| Time of risk occurring | |
| Immediate threat of risk materialising in the next month. | |
| Threat of risk materialising in the next 3 months. |
|
| Threat of risk materialising in the next 6 months. |
|
| Threat of risk materialising in the next 12 months. |
Risk criteria for impact
| Risk criteria for impact | Descriptor (cost, time, quality, scope, benefits) |
| Low |
|
| Moderate |
|
| Medium |
|
| High |
|
Risk criteria for likelihood
| Risk criteria for likelihood | Descriptor | Explanation (cost, time, quality, scope, benefits) |
| Low | 1– 20% likelihood of risk materialising. | Low level risk, mitigation in place risk being managed. |
| Moderate | 21 – 50% chance of occurring. | Medium Level Risk, mitigation in progress. |
| Medium | 51 – 80% likelihood of risk materialising. | Mitigation in progress requires SRO/PRO attention. |
| High | More than 80% chance of occurring. | Mitigation to be put into place immediately requires SRO/PRO attention. |
Risk register
A risk register is a useful tool for recording and managing identified risks. Risks are analysed and given a score based on their impact and likelihood of occurring and then regularly reviewed and re-scored in light of the progress of the mitigating action.
This approach provides a documented framework from which risks can be reported to boards as well as acting as a useful tool for communicating project risk to stakeholders.
The Strategic Projects Office has risk register templates that you can use, along with examples of completed registers to help get you started.
- Excel risk register (.xls)
Issue log
Issues should be logged immediately in an issue log, and should be communicated to the project team and sponsor. Progress of the issue should be reviewed regularly through the project board or steering group. Depending on the severity of the issue, a working group may also be set up to monitor and control it.
The issue log should record the detail of the issue, along with any escalation and resolution information. The University has issue log templates that you can use.
- Excel issue log (.xls)
RAG status monitoring
RAG (red, amber, green) statuses are monitored through PCG and recorded on a portfolio risk register by the Governance Team.
Project Managers will be expected to submit a project progress report (.xls) to each meeting of its sub group to provide a snapshot into how the project is progressing. If the progress report shows a red RAG status PCG will then agree a course of action to help support the Project Manager in order to get the project back on track.
When to escalate risks and issues
Escalation could be classed as one of the main risk response strategy types, alongside treat, tolerate, transfer, and terminate, and can be defined as:
"A risk response strategy whereby the project manager recognises that a risk is outside the scope of the project and communicates the details of the risk to that person or part of the organization where it is best owned and managed." APM Risk Escalation
This risk response strategy is appropriate when the project team or the project sponsor agrees that a risk (either threat or opportunity) is outside the scope of the project and should be managed at the program level, portfolio level, or other relevant part of the organisation, and not at a project level.
The Project Manager determines who should be notified about the risk and communicates the details to that person or part of the organization. It is important that ownership of escalated risks is accepted by the relevant part of the organisation. Escalated risks are not monitored further by the project team after escalation, although they may be recorded in the risk register for information.
Risk challenges
Internal and external challenges leading to project risks.
Infrastructure and system interoperability
- Disparate systems?
- Poor scalability?
- System and information
Cultural change and communication
- Silo working?
- Lack of stakeholder buy-in?
- Competing priorities?
Data integrity and privacy
- Data breaches and subsequent reputational damage?
Resources with the right skills
- Availability?
- Retention issues (desirable skills)?
Political environment
- Brexit impact?
- Changes in policy and regulatory requirements?
