Risk and Issue Management

Risk and issue management are central components of project management. Risks and issues must be successfully identified and minimized to ensure the success of a project. This article explains exactly what risks and issues are, what the difference between the two is, and how the process of risk and issue management works.

Intro

Risk and issues management help reduce or, at best, prevent negative impacts to a project. A project is considered at risk if any of the following elements are impacted:

  • Project schedule.

  • Scope.

  • Budget.

  • Quality.

In addition, factors such as loss of motivation or image must also be considered.

Risk analysis and management represent a systematic and formal process approach. The process of risk management takes place in all phases of the project life cycle.

Risk and issue management is part of both classical and agile project management. In the SAFe Framework, the process module “Agile Risk Management” is dedicated to the topic. In the PMI Framework, the topic is mapped in the “Risk Management Framework”. There is a dedicated certification for this: PMI – Risk Management Professional (PMI-RMP)®. 

What are project risks?

Project risks are uncertain events with a negative impact on the success of the project. They are determined by the probability of occurrence of the risk and the potential damage if the risk occurs.

 

Types of risks

  • Commercial risks (e.g. payment difficulties, insolvency of a contractual partner)
  • Technical risks (e.g. a concept for a novel technical solution proves impossible to implement)
  • Deadline risks (e.g. a supplier fails to provide the requested service on time via its own product development process)
  • Resource risks (e.g., if the resources earmarked for a project are still needed for a previous project and are not available for a current project)
  • Political risks (e.g., when decisions about supplier selection are not made as recommended by the project team because of interests outside the project, such as the strategy of a higher-level supplier or personal contacts)

Risk identification

Workshops can serve as a basis for identifying risks, in which the project team identifies risks using, for example, brainstorm techniques, risk checklists, or by analyzing projects that have already been completed. Risks can also be identified spontaneously in weekly team meetings or discussions.

Risk analysis

The expected value of a risk (= risk value) is a product of the probability of occurrence and the potential consequences if the risk occurs:

 

Risk value = probability of occurrence [%] * consequence [€].

 

The consequence is the estimated financial impact of a risk event: How high is the damage in euros for the company if the risk occurs?

 

The probability of occurrence is usually estimated by the project team before the project starts.

 

  • Risk avoidance or reduction: Measures are taken to reduce or eliminate the probability of a risk occurring
  • Risk mitigation: The possible occurrence of the risk is accepted, as avoidance would be too expensive. If the risk does occur, the team is prepared with predefined measures.
  • Risk transfer: A risk is transferred to another organization.
  • Accepting a risk without action: Used for risks with low consequences, where the preventive or emergency measures are more expensive than the damage itself.

 

Definition Issues

Problems are events that are happening “now”, that are already impacting the project and need to be actively addressed to limit the negative consequences (Impacts). In many cases, they are problems that could not have been foreseen. Risks that occur can become problems (Issues).

 

In risk management, the initial focus is on predicting future events (risk identification), while in issues management, the focus is on finding a quick solution to an existing problem (developing responses/mitigation actions).

 

However, the urgency to take action or an estimated probability of 100% does not automatically make a risk a problem. For example, if the event is in the future, it is a risk and not a problem, because here a quick solution is not needed, but planning can be done on how to reduce the potential consequences that may occur.

 

The difference between risks and problems is explained here:

 

VIP.LEAN_issuevsrisk
Issues vs. Risks

Risk and Issue Management Cycle

The management of risks and issues should follow this risk management cycle. In the case of a problem, the focus is not on mitigation but on solving the negative impact that has occurred.

 

VIP.LEAN_Zyklus des Risiko- und Issues Managements
Risk and Issue Management Cycle

Identification of risks/issues

In the start-up phase of the project, the focus is on identifying risks. There are general and project specific risks , which should be known and communicated as early as possible. Problems are identified and captured directly in the operational project events, as your impact is active right away. In some cases, the problem arises after the occurrence of a previously identified risk.

 

Sources of project risks are:

 

  • The project team.
  • General risk log.
  • Databases of experience from previous projects/releases.
  • Other project/quarter managers.
  • Risk manager or project consultant.

 

Risk identification meetings should be held with application managers and product managers prior to each new project phase. Depending on the project phase, it may be advisable to consult other project stakeholders.

 

Documentation of risks/problems

Project management relies on the communication of risks/issues by the project team. Due to the different roles and responsibilities, the different project stakeholders, have different views on risks. Therefore, it is important for the project manager to be in contact with representatives of all stakeholders.

 

The project team, or the person who identifies an issue or risk, should do the following:

 

  • Proactively report important issues and risks to project management.
  • Ensure the problem is well understood (ideally including severity and possible solutions).
  • Assume all responsibilities of a risk owner unless another owner is identified.
  • Risk and problem log for documentation.

 

Risks and issues should be documented, ideally in a collaborative project management tool such as Jira. We show an implementation including BI dashboards for this purpose. The tool contains the risks and issues that require special attention from project management and forms the basis for reporting.

 

As part of the identification process, the project manager must ensure that:

 

  • The problem or risk is well understood.
  • A clear and easily understood description of the risk or problem is prepared.
  • The risk/problem is entered into the risk and problem log.

 

Determining who is responsible for the risk

Project management relies on the communication of risks/issues by the project team. Due to the different roles and responsibilities, the different project stakeholders, have different views on risks. Therefore, it is important for the project manager to be in contact with representatives of all stakeholders.

 

 

The project team, or the person who identifies an issue or risk, should do the following:

 

  • Proactively report important issues and risks to project management.
  • Ensure the problem is well understood (ideally including severity and possible solutions).
  • Assume all responsibilities of a risk owner unless another owner is identified.
  • Risk and problem log for documentation.

 

Risks and issues should be documented, ideally in a collaborative project management tool such as Jira. We show an implementation including BI dashboards for this purpose. The tool contains the risks and issues that require special attention from project management and forms the basis for reporting.

 

 

As part of the identification process, the project manager must ensure that:

 

 

  • The problem or risk is well understood.
  • A clear and easily understood description of the risk or problem is prepared.
  • The risk/problem is entered into the risk and problem log
  • This phase of the risk and problem management cycle requires establishing a due date and securing a risk/problem owner.
  • Reporting a risk/problem to project management does not mean that responsibility is transferred to project management. If the “identifier” clearly expresses that someone else should be responsible, project management has several options:
  • Reassign the risk/problem to the “identifier”.
  • Transferring the risk or problem to someone better able to manage it.

 

Assessment of likelihood and impact

The risk and problem management process also requires an assessment of risks and problems in terms of their impact and likelihood of occurrence. While probability assessment is only useful for risks, impact assessment is required for both risks and problems.

 

The probability describes how likely a risk is to occur (in percent). The assessment is made according to the following scheme:

 

  • Unlikely (0-10%)
  • Possible (11-30%)
  • Very likely (31-50%)
  • Probable (51-80%)
  • Very likely (81-99%)
  • Occurred (100%)

When evaluating the impact that a risk or issue could bring, a brief description of the impact should be recorded, e.g., related to the schedule, budget, and/or quality of the project.

 

In addition, the impact is classified:

 

  • Very Low
  • Low
  • Medium
  • High
  • Very high
  • Exact value in €

 

Development of solution measures

If a risk has occurred and/or become a problem, a solution measure must be found for it. This is done according to the following scheme:

 

  • Identification of solution options
  • Defining measures to mitigate the consequences
  • Ensuring that the defined solution measures are implemented
  • The defined measures in the risk and problem reports must be forwarded to project management
  • Establish a planned completion date

If the risk mitigation or problem resolution actions involve a potential budget overrun, the planned action must first be approved by the project manager.

 

In terms of reporting, risks and problems can be divided into three categories. Depending on the category, a different approach to solution development is recommended. We present these three categories below:

 

1. Risks and issues that can be solved by the project team: 

risks/issues that can be addressed and solved within the project team without impacting the status of the project. Here, documentation of the risks and problems is sufficient, but inclusion in the project report is not necessary.

 

2. Risks and issues that can be solved by the project manager: 

risks and issues that have a significant impact on the schedule, scope, budget, or quality of the project, or, risks and issues that cannot be addressed by the project team alone. The team must report these risks/issues to project management. Monitoring and/ or support is provided by the project management. The project manager reports these risks and problems in the status report, but shows that the solution is within his scope of action.

 

3. Risks and problems that can not be solved by the project manager:

In this case, the solution must be found by senior management. As a rule, an appropriate status report is available to achieve management attention.

 

For the communication of risks and problems, both formal and informal processes should be set up by the project management to get an optimal overview:

 

Formal processes

 

Meetings, e.g. Application Management Meeting, SR Management Meeting, Project Management Meeting, Delivery Board, meetings during the test phase

 

Reports: SR Management Report, Application Reports for Line Management

 

Informal processes

 

  • Ad hoc meetings with team members to identify and resolve issues
  • Email/phone
  • Meetings between project manager, co-project manager, risk manager or project consultant
  • Progress monitoring

 

Progress monitoring

Once a risk has been identified, it is important to monitor progress in risk mitigation and problem resolution at all levels.

 

This means that progress must be monitored by the risk owner, the application/business analyst, and for serious risks/issues, by project management in weekly SR and application status reports.

 

Capture additional risks/issues

The project team should, at the conclusion of a risk, record the following information:

 

  • Project-wide impact of risks and issues
  • Lessons learned in the form of feedback and recommendations

 

LINKS

Table of contents
    Add a header to begin generating the table of contents

    Categories

    Share on facebook
    Share on twitter
    Share on linkedin
    Share on xing
    Share on whatsapp

    More Posts