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. What exactly risks and issues are, what the difference between the two terms is, and how the process of risk and issue management is structured are presented in this article.

1 Introduction

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

  • Project Schedule.

  • Scope.

  • Budget.

  • the quality

In addition, factors such as loss of motivation or image must also be taken into account.

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

Risk and issue management is part of both classic and agile project management. In the SAFe Framework, the process module “Agile Risk Management” is dedicated to this 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)®.

2 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 loss if the risk materializes.

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 turns out not to be feasible)

  • 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. B. When supplier selection decisions are not made as recommended by the project team because of interests outside the project, such as a higher-level supplier’s strategy or personal contacts.

Risk identification

Workshops can serve as a basis for identifying risks, where 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

vThe 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 [%] * scope [€].

The scope is the estimated financial consequences 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 prevention or reduction: measures are taken to reduce or eliminate the likelihood of a risk occurring

  • Risk limitation: 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.

  • Acceptance of a risk without measures: Used for risks with low consequences, where the preventive or emergency measures are more expensive than the damage itself.

3 Definition of 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, these 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 issues management is about 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 it is possible to plan how to reduce the potential consequences that may occur.

The differences between risks and problems are presented here:

VIP.LEAN_issuevsrisk
Unterschied Risiken und Issues

Management of risks and issues should be done according to risk management cycle described below. When there is a problem, it is not about mitigation, but about solving the negative impact that has occurred right away.

4 Cycle of risk and issue


Management

VIP.LEAN_cycle of risk and issues management
Zyklus des Risk- und Issuemanagement

4.1 Identification of risks/problems

In der Startphase des Projekts liegt der Schwerpunkt auf der Identifizierung von Risiken. Es gibt allgemeine und projektspezifische Risiken , die so früh wie möglich bekannt und kommuniziert werden sollten. Probleme werden direkt im operativen Projektgeschehen identifiziert und erfasst, da Ihr Impact gleich aktiv ist. In manchen Fällen entsteht das Problem nach dem Eintreten eines vorher identifizierten Risiko.

Quellen für Projektrisiken sind:

 

  • das Projektteam
  • Allgemeines Risikoprotokoll
  • Datenbanken mit Erfahrungen aus früheren Projekten/Releases
  • Andere Projekt-/Quartalsmanager
  • Risikomanager oder Projektberatung

Vor jeder neuen Projektphase sollten Besprechungen zur Risikoidentifizierung mit den Anwendungsmanagern und den Produktmanagern abgehalten werden. Je nach Projektphase empfiehlt es sich, weitere Projektbeteiligte zu konsultieren.

4.2 Documentation of risks/problems

Das Projektmanagement ist auf die Kommunikation von Risiken/Problemen durch das Projektteam angewiesen. Aufgrund der unterschiedlichen Rollen und Zuständigkeiten haben die verschiedenen Projektbeteiligten, unterschiedliche Ansichten über Risiken. Daher ist es wichtig, dass der Projektmanager mit Vertretern aller Interessengruppen im Kontakt steht.

Das Projektteam oder derjenige, der ein Problem oder Risiko identifiziert, sollte folgende Aufgaben übernehmen

 

  • Wichtige Probleme und Risiken proaktiv an die Projektleitung melden.
  • Sicherstellen, dass das Problem gut verstanden wird (idealerweise einschließlich Schweregrad und Lösungsmöglichkeiten).
  • Alle Verantwortlichkeiten eines Risikoverantwortlichen übernehmen, sofern kein anderer Verantwortlicher gefunden wird.
  • Risiko- und Problemprotokoll für die Dokumentation.
  • Risiken und Probleme sollten dokumentiert werden, idealerweise in einem kolleberativen Projektmanagement Tool wie Jira. Wir zeigen dazu eine Implementierung inkl. BI Dashboards. Das Tool enthält die Risiken und Probleme, die besondere Aufmerksamkeit des Projektmanagements erfordern, und bildet die Grundlage für die Berichterstattung.

 

Im Rahmen des Identifizierungsprozesses muss der Projektmanager sicherstellen, dass:

 

  • Das Problem oder Risiko gut verstanden wird.
  • Eine klare und leicht verständliche Beschreibung des Risikos oder Problems wird erstellt.
  • Das Risiko/Problem wird in das Risiko- und Problemprotokoll eingetragen.

4.3 Determining the risk owners

Die Meldung eines Risikos/Problems an das Projektmanagement bedeutet nicht, dass die Verantwortung auf das Projektmanagement übertragen wird. Wenn der “Identifizierer” klar zum Ausdruck bringt, dass jemand anderes verantwortlich sein soll, hat das Projektmanagement mehrere Möglichkeiten:

 

  • Neuzuweisung des Risikos/des Problems an den “Identifizierer”.
  • Übergabe des Risikos oder Problems an jemanden, der besser in der Lage ist, dieses zu managen.

4.4 Assessment of probability and impact

Das Verfahren für das Risiko- und Problemmanagement erfordert auch eine Bewertung der Risiken und Probleme im Hinblick auf ihre Auswirkungen und ihre Eintrittswahrscheinlichkeit. Während eine Wahrscheinlichkeitsabschätzung nur für Risiken sinnvoll ist, ist eine Abschätzung der Folgen sowohl für Risiken, als auch für Probleme erforderlich.

Die Wahrscheinlichkeit, beschreibt wie wahrscheinlich ein Risiko eintreten kann (in Prozent). Die Bewertung erfolgt nach folgendem Schema:

 

  • Unwahrscheinlich (0-10%)
  • Möglich (11-30%)
  • Sehr wahrscheinlich (31-50%)
  • Wahrscheinlich (51-80%)
  • Sehr wahrscheinlich (81-99%)
  • Eingetreten (100%)

Bei der Bewertung der Auswirkungen, die ein Risiko oder ein Problem mit sich bringen könnten, sollte eine kurze Beschreibung der Folgen festgehalten werden, z. B. in Bezug auf den Zeitplan, das Budget und/oder die Qualität des Projekts.

Zusätzlich wird die Auswirkung klassifiziert:

 

  • Sehr gering
  • Gering
  • Mittel
  • Hoch
  • Sehr hoch 
  • Exakter Wert in €

4.5 Development of solution measures

Ist ein Risiko eingetroffen und/oder zum Problem geworden, muss für dieses eine Lösungsmaßnahme gefunden werden. Dies erfolgt nach folgendem Schema:

 

  • Identifizierung von Lösungsoptionen
  • Festlegung von Maßnahmen zur Minderung der Folgen
  • Sicherstellung der Durchführung der definierten Lösungsmaßnahmen
  • Die definierten Maßnahmen in den Risiko- und Problemberichten müssen an die Projektleitung weitergeleitet werden
  • Festlegung eines geplanten Abschlussdatums
  • Falls die Maßnahmen zur Risikominderung oder Problemlösung eine potenzielle Budgetüberschreitung mit sich ziehen, muss die geplante Maßnahme zu erst vom Projektleiter genehmigt werden.

In Bezug auf das Berichtswesen lassen sich Risiken und Probleme in drei Kategorien unterteilen. Je nach Kategorie wird ein andere Vorgehen bei der Lösungsentwicklung empfohlen. Diese drei Kategorien stellen wir im Folgenden vor:

 

  • Vom Projektteam lösbare Risken und Probleme:

Risiken/Probleme, die innerhalb des Projektteams angegangen und gelöst werden können, ohne Einfluß auf den Status des Projektes. Hier reicht die Dokumentation der Risiken und Probleme, eine Aufnahme im Projektbericht ist jedoch nicht nötig.

 

  • Vom Projektmanager lösbare Risiken und Probleme:

Risiken und Probleme, die erhebliche Auswirkungen auf Zeitplan, Umfang, Budget oder Qualität des Projekts haben, oder, Risiken und Probleme, die vom Projektteam nicht allein bewältigt werden können. Das Team muss diese Risiken/Probleme an das Projektmanagement melden. Eine Überwachung und/ oder Betreuung erfolgt durch die Projektleitung. Der Projektmanager meldet diese Risiken und Probleme im Statusreport, teigt jedoch dass die Lösung in seinem Handlungsbereich liegt.

 

  • Vom Projektmanager lösbare Risiken und Probleme:

In diesem Fall muss die die Lösung vom Senior Management gefunden werden. In der Regel liegt ein entsprechendes Statusrreport vor, um das Management Attention zu erreichen.

Für die Kommunikation von Risiken und Problemen sollten vom Projektmanagement sowohl formelle als auch informelle Prozesse eingerichtet werden, um einen optimalen Überblick zu erhalten:

 

Formelle Prozesse

  • Meetings, z.B. Application Management Meeting, SR Management Meeting, Project Management Meeting, Delivery Board, Meetings während der Testphase
  • Berichte: SR-Management-Bericht, Anwendungsberichte für das Linienmanagement

Informelle Prozesse

  • Ad-hoc-Sitzungen mit Teammitgliedern zur Identifizierung und Klärung von Problemen
  • E-Mail/Telefon
  • Treffen zwischen Projektleiter, Co-Projektleiter, Risikomanager oder Projektberater
  • Überwachung des Fortschritts

4.6 Progress control

Wurde ein Risiko identifiziert ist es wichtig, die Fortschritte bei der Risikominderung und Problemlösung auf allen Ebenen zu überwachen.

Das bedeutet, dass der Fortschritt vom Risikoverantwortlichen, dem Anwendungs-/Business-Analysten und bei schwerwiegenden Risiken/Problemen von der Projektleitung in wöchentlichen Wöchentliche SR- und Anwendungsstatusberichten überwacht werden muss.

4.7 Recording of additional risks/themes

Wurde ein Risiko identifiziert ist es wichtig, die Fortschritte bei der Risikominderung und Problemlösung auf allen Ebenen zu überwachen.

Das bedeutet, dass der Fortschritt vom Risikoverantwortlichen, dem Anwendungs-/Business-Analysten und bei schwerwiegenden Risiken/Problemen von der Projektleitung in wöchentlichen Wöchentliche SR- und Anwendungsstatusberichten überwacht werden muss. Das Projektteam sollte bei Abschluss eines Risikos, folgende Informationen festhalten:

 

  • Projektübergreifende Auswirkungen von Risiken und Problemen 
  • gewonnene Erkenntnisse in Form von Feedback und Empfehlungen

LINKS

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

    Categories

    Search

    More Posts