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:

  • what could possibly happen to affect the project?
  • what is the likelihood of this happening?
  • how will it affect the project?
  • what can we do about it?
  • when identifying the risks it is essential to consider the cause, likelihood and impact

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:

  • treat – take action to reduce the impact or likelihood of the risk happening
  • tolerate – accept the risk and monitor the situation
  • terminate – do something different to prevent the risk from occurring
  • transfer – take out insurance or get a third party to take on an area of work

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.

  • The mitigation action chosen should be implemented to control 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)


  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)
  • Financial impact can be dealt with within project budget.
  • Minor time overruns that can be managed within overall project timescales.
  • Project objectives/deliverables could be impaired by up to 5%.
  • Financial impact can be managed within project budget.
  • Moderate time overruns which may impact other projects and or project Go Live / end date.
  • Project objectives/deliverables could be impaired by up to 10%.
  • Significant overspend forecast.
  • Significant time overruns which will impact the project end date.
  • Project objectives/deliverables could be impaired by up to 20%.
  • Project failure expected.
  • Severe overspend forecasted.
  • Project objectives/deliverables could be impaired by more than 40%.

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.

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.

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?
Arrow symbol
Contact us
Strategic Projects Office