7. Risikomanagement in der Projektdurchführung
Lernziele
Nach diesem Kapitel können Sie: - Die Bedeutung des Risikomanagements in der Projektdurchführung erklären - Risiken systematisch identifizieren und kategorisieren - Risiken qualitativ und quantitativ bewerten - Geeignete Risikobehandlungsmaßnahmen auswählen - Risikokommunikation professionell gestalten - Das Risikomanagement kontinuierlich überwachen und steuern
Modul Übersicht
Modul 11 - Kapitel 7
Lesezeit: ~15-20 Min
Quelle: 11 - Projektsteuerung in IT-Projekten.pdf, FS-ITB-11_Steuerung-01_v0c.pdf
1. Einführung: Risikomanagement in der Projektdurchführung
1.1 Definition: Risiko
Ein Risiko ist ein unsicheres Ereignis oder eine Bedingung, das, wenn es eintritt, eine positive oder negative Auswirkung auf mindestens ein Projektziel hat.
Risiko vs. Chance
Risiken sind nicht nur negativ (Bedrohungen), sondern können auch positiv sein (Chancen). Risikomanagement befasst sich daher sowohl mit Risikominimierung als auch mit Chancenmaximierung.
1.2 Warum Risikomanagement in der Durchführung kritisch ist
Während der Projektdurchführung setzt die Risikoüberwachung und -steuerung den Risikomanagementplan um. Zusätzlich identifiziert sie eventuelle neue Risiken und bewertet diese. Sie beobachtet identifizierte Risiken und stellt bei Bedarf Änderungsanträge oder empfiehlt Korrekturmaßnahmen und vorbeugende Maßnahmen zur Verhinderung von Schäden und zur Realisierung von Chancen.
| Aspekt | Bedeutung in der Projektdurchführung |
|---|---|
| Kontinuierliche Erfassung | Neue Risiken werden kontinuierlich erkannt |
| Laufende Bewertung | Identifizierte Risiken werden laufend überwacht und neu bewertet |
| Maßnahmen-Steuerung | Risikobehandlungsmaßnahmen werden aktiv gesteuert |
| Veränderte Bedingungen | Risikomanagement wird an veränderte Bedingungen angepasst |
| Risikokommunikation | Regelmäßige Berichterstattung an Entscheidungsträger |
1.3 Risikomanagement-Prozess
flowchart TD
A[Risikoidentifikation] --> B[Risikoanalyse & -bewertung]
B --> C[Risikobehandlungsstrategie auswählen]
C --> D[Maßnahmen implementieren]
D --> E[Risikokontrolle & Überwachung]
E --> F{Risiko noch aktiv?}
F -->|Ja| E
F -->|Nein| G[Risiko schließen]
E --> H{Neue Risiken?}
H -->|Ja| A
H -->|Nein| I[Regelmäßige Review-Schleife]
style A fill:#e3f2fd
style B fill:#fff9c4
style C fill:#ffecb3
style D fill:#c8e6c9
style I fill:#e1bee72. Risikoidentifikation
2.1 Kontinuierliche Erfassung
Die Risikoüberwachung und -steuerung verbindet alle anderen Prozesse des Risikomanagements mit den anderen Prozessen zur Überwachung und Steuerung des Projekts.
Kontinuierliche Erfassung (Dokumentation) und Überwachung aller relevanten Risiken:
| Identifikationsquelle | Beispiele |
|---|---|
| Projektstatusberichte | Abweichungen im Zeitplan, Budget, Qualität |
| Meilenstein-Reviews | Verpasste oder kritische Meilensteine |
| Team-Meetings | Bedenken, Probleme, Beobachtungen aus dem Team |
| Stakeholder-Kommunikation | Feedback von Kunden, Fachbereichen, Management |
| Technische Reviews | Architektur-, Design-, Code-Reviews |
| Qualitätsberichte | Testergebnisse, Fehlerstatistiken |
| Änderungsanträge | Neue Anforderungen führen zu neuen Risiken |
| Externe Faktoren | Marktveränderungen, regulatorische Änderungen, Lieferantenprobleme |
| Erfahrungen aus anderen Projekten | Lessons Learned aus ähnlichen Projekten |
Identifikation ist kontinuierlich
Die Risikoidentifikation ist keine einmalige Aktivität zu Projektstart, sondern ein kontinuierlicher Prozess über den gesamten Projektzyklus hinweg. Neue Risiken können jederzeit auftreten.
2.2 Kategorisierung von Risiken
Risiken können nach verschiedenen Kriterien kategorisiert werden:
| Kategorie | Unterkategorien | Beispiele |
|---|---|---|
| Technische Risiken | Architektur, Entwicklung, Integration, Performance, Security | Systemarchitektur nicht skalierbar, Schnittstellenprobleme, Performance-Engpässe |
| Management-Risiken | Führung, Entscheidungen, Ressourcen, Priorisierung | Mangelnde Führung, unklare Entscheidungen, Ressourcenengpässe |
| Organisatorische Risiken | Stakeholder, Kommunikation, Prozesse, Kultur | Widerstand gegen Änderungen, schlechte Kommunikation, kulturelle Unterschiede |
| Umfangs-Risiken (Scope) | Anforderungen, Änderungen, Scope Creep | Unklare Anforderungen, häufige Änderungen, Scope Creep |
| Termin-Risiken (Zeit) | Planung, Abhängigkeiten, Verzögerungen | Zu optimistische Planung, kritische Pfade, Verzögerungen von Lieferanten |
| Kosten-Risiken | Budget, Ressourcen, Finanzierung | Budgetüberschreitung, Ressourcenmangel, Finanzierungsprobleme |
| Qualitäts-Risiken | Anforderungen, Tests, Akzeptanz | Mangelnde Qualität, Testmängel, Ablehnung durch Kunden |
| Externe Risiken | Markt, Lieferanten, Regulatorik, Politik | Marktveränderungen, Lieferantenprobleme, neue Gesetze |
| Personal-Risiken | Personal, Kompetenzen, Motivation | Fachkräftemangel, Kompetenzdefizite, mangelnde Motivation |
2.3 Risikoregister
Das Risikoregister (Risiko-Log) ist das zentrale Dokument für das Risikomanagement:
| Risk-ID | Risiko | Kategorie | Eintrittswahrscheinlichkeit | Auswirkung | Risikopriorität | Verantwortlicher | Status | Maßnahmen | Letztes Update |
|---|---|---|---|---|---|---|---|---|---|
| R-001 | Datenbank-Performance bei >100.000 Datensätzen nicht ausreichend | Technisch | Mittel (3) | Hoch (4) | 12 | Entwickler-A | Aktiv | Performance-Tests durchführen, Indizes optimieren | 15.01.2026 |
| R-002 | Lieferant der Komponente X kann nicht termingerecht liefern | Extern | Hoch (4) | Mittel (3) | 12 | Beschaffungs-A | Aktiv | Alternativlieferant identifizieren, Puffer einplanen | 15.01.2026 |
| R-003 | Fachbereich X lehnt neue Software ab | Organisatorisch | Mittel (3) | Hoch (4) | 12 | Projektleiter | Überwacht | Stakeholder-Management, Early-Bird-Programm | 15.01.2026 |
Risikoregister ist ein lebendes Dokument
Das Risikoregister ist kein statisches Dokument, sondern wird kontinuierlich aktualisiert: - Neue Risiken hinzugefügt - Wahrscheinlichkeit und Auswirkung aktualisiert - Maßnahmen dokumentiert und Status aktualisiert - Risiken geschlossen oder inaktiviert
3. Risikoanalyse und -bewertung
3.1 Qualitative Risikoanalyse
Die qualitative Risikoanalyse bewertet Risiken basierend auf Eintrittswahrscheinlichkeit und Auswirkung.
3.1.1 Wahrscheinlichkeit (Probability)
| Skala | Wahrscheinlichkeit | Beschreibung |
|---|---|---|
| 1 | Sehr gering (< 10%) | Sehr unwahrscheinlich |
| 2 | Gering (10-30%) | Unwahrscheinlich |
| 3 | Mittel (30-60%) | Möglich |
| 4 | Hoch (60-90%) | Wahrscheinlich |
| 5 | Sehr hoch (> 90%) | Sehr wahrscheinlich |
3.1.2 Auswirkung (Impact)
| Skala | Auswirkung | Beschreibung |
|---|---|---|
| 1 | Gering | Geringfügige Auswirkungen, leicht zu kompensieren |
| 2 | Mittel | Moderate Auswirkungen, kompensierbar mit Aufwand |
| 3 | Hoch | Signifikante Auswirkungen, kompensierbar mit hohem Aufwand |
| 4 | Kritisch | Schwere Auswirkungen, Projektziel gefährdet |
| 5 | Katastrophal | Extreme Auswirkungen, Projektabbruch möglich |
3.1.3 Risikopriorität (Risk Priority Number - RPN)
Die Risikopriorität wird als Produkt aus Wahrscheinlichkeit und Auswirkung berechnet:
| RPN | Priorität | Maßnahmen |
|---|---|---|
| 1-4 | Gering | Überwachen, keine spezifischen Maßnahmen erforderlich |
| 5-9 | Mittel | Maßnahmen bei Zeitplanung berücksichtigen |
| 10-15 | Hoch | Aktive Maßnahmen erforderlich |
| 16-25 | Sehr hoch | Sofortige Maßnahmen, Eskalation an Management |
3.1.4 Risiko-Matrix
Die Risiko-Matrix visualisiert Risiken:
graph TD
subgraph "Auswirkung →"
direction LR
A1[1 Gering]
A2[2 Mittel]
A3[3 Hoch]
A4[4 Kritisch]
A5[5 Katastrophal]
end
subgraph "↓ Wahrscheinlichkeit"
B1[5 Sehr hoch]
B2[4 Hoch]
B3[3 Mittel]
B4[2 Gering]
B5[1 Sehr gering]
end
B1 -->|RPN: 5-25| A1
B1 --> A2
B1 --> A3
B1 --> A4
B1 --> A5
B2 --> A1
B2 --> A2
B2 --> A3
B2 --> A4
B2 --> A5
B3 --> A1
B3 --> A2
B3 --> A3
B3 --> A4
B3 --> A5
B4 --> A1
B4 --> A2
B4 --> A3
B4 --> A4
B4 --> A5
B5 --> A1
B5 --> A2
B5 --> A3
B5 --> A4
B5 --> A5
style A4 fill:#ffcdd2
style A5 fill:#f44336
style B1 fill:#ffcdd23.2 Quantitative Risikoanalyse (optional)
Die quantitative Risikoanalyse führt numerische Analysen durch:
| Methode | Beschreibung | Anwendbarkeit |
|---|---|---|
| Erwartungswert-Analyse | Erwarteter Schaden = Wahrscheinlichkeit × Auswirkung (in €) | Für monetäre Auswirkungen |
| Monte-Carlo-Simulation | Simulation von Szenarien mit Zufallsvariablen | Für komplexe Projekte mit vielen Risiken |
| Szenario-Analyse | Analyse von optimistischen, realistischen und pessimistischen Szenarien | Für Strategie-Entscheidungen |
| Empfindlichkeitsanalyse | Analyse der Empfindlichkeit von Projektparamettern | Für kritische Paramter |
Erwartungswert-Analyse
Risiko: Datenbank-Ausfall, der Umsatzverlust verursacht
- Wahrscheinlichkeit: 10% (0,1)
- Auswirkung: 100.000 € Umsatzverlust
Erwarteter Schaden: 0,1 × 100.000 € = 10.000 €
Interpretation: Auf den langjährigen Durchschnitt gesehen kostet dieses Risiko 10.000 € pro Projekt.
4. Risikobehandlungsstrategien
4.1 Verantwortliche für die Verfolgung
Für jedes Risiko wird ein Verantwortlicher benannt:
| Verantwortliche | Aufgaben |
|---|---|
| Risikobesitzer | Überwacht das Risiko, steuert die Maßnahmen, meldet Änderungen |
| Risikomanager | Koordiniert das Risikomanagement, berichtet an Management |
| Projektleiter | Verantwortlich für Gesamtrisikomanagement im Projekt |
| Stakeholder | Betroffene Parteien, unterstützen bei Maßnahmen |
4.2 Strategien zur Risikobehandlung
| Strategie | Beschreibung | Beispiel | Anwendbarkeit |
|---|---|---|---|
| Vermeiden (Avoid) | Risikowahrscheinlichkeit auf Null setzen | Technologie wechseln, um Performance-Risiko zu vermeiden | Für Risiken mit hoher Auswirkung und kontrollierbarer Wahrscheinlichkeit |
| Minderung (Mitigate) | Wahrscheinlichkeit oder Auswirkung reduzieren | Tests durchführen, um Fehlerwahrscheinlichkeit zu senken | Für alle Risiken, besonders bei hoher Wahrscheinlichkeit |
| Übertragen (Transfer) | Risiko auf andere Parteien übertragen | Versicherungen abschließen, Outsourcing mit Service-Level-Agreements | Für Risiken, die von anderen besser kontrolliert werden können |
| Akzeptieren (Accept) | Risiko akzeptieren und falls eintritt, reagieren | Risiko akzeptieren und Kontingenz-Reserve einplanen | Für Risiken mit geringer Auswirkung oder unvermeidbaren Risiken |
4.3 Maßnahmen-Einleitung
Einleiten von Maßnahmen zur Erreichung der angestrebten risikopolitischen Ziele:
| Strategie | Maßnahmen | Verantwortlicher | Zeitrahmen |
|---|---|---|---|
| Vermeiden | Technologie-Stack anpassen, Anforderung ändern, Partner wechseln | Projektleiter, Architekt | Sofort |
| Minderung | Prototyping, Tests, Schulungen, Backup-Strategie, Puffer einplanen | Verantwortliche | Laufend |
| Übertragen | Versicherungen, SLA, Outsourcing-Verträge | Beschaffung, Legal | Vor Projektstart |
| Akzeptieren | Kontingenz-Reserve einplanen, Notfallplan erstellen | Finanz, Projektleiter | Vor Projektstart |
Kombination von Strategien
Oft ist eine Kombination von Strategien sinnvoll. Beispiel: Ein Risiko wird teilweise gemindert (Tests) und der Rest wird akzeptiert (Kontingenz-Reserve).
4.4 Kontinuierliche Überprüfung
Laufende Überprüfung der risikoorientierten Steuerungsmaßnahmen und ggf. Anpassung an veränderte Bedingungen:
| Überprüfungsaspekt | Fragen | Maßnahmen |
|---|---|---|
| Risiko-Aktivität | Ist das Risiko noch aktiv? Ist es eingetreten? | Status im Risikoregister aktualisieren |
| Wahrscheinlichkeit | Hat sich die Wahrscheinlichkeit geändert? | Wahrscheinlichkeit neu bewerten |
| Auswirkung | Hat sich die Auswirkung geändert? | Auswirkung neu bewerten |
| Wirksamkeit der Maßnahmen | Sind die Maßnahmen wirksam? | Maßnahmen evaluieren, ggf. anpassen |
| Neue Informationen | Gibt es neue Informationen über das Risiko? | Risiko-Informationen aktualisieren |
| Veränderte Bedingungen | Haben sich Bedingungen geändert? | Risikobewertung anpassen |
4.5 Regelmäßige Kontrolle
Regelmäßige Kontrolle der risikoorientierten Steuerungsmaßnahmen:
| Überprüfungsfrequenz | Anlässe |
|---|---|
| Täglich | Kritische Risiken, besonders in kritischen Projektphasen |
| Wöchentlich | Wöchentliche Projektbesprechungen, Standard für IT-Projekte |
| 14-tägig/Monatlich | Regelmäßige Reviews, weniger kritische Risiken |
| Bei Meilensteinen | Erneutes Risiko-Assessment bei jedem Meilenstein |
| Bei Projektplanänderungen | Neu-Bewertung bei Planänderungen |
Kontrollhäufigkeit anpassen
Die Kontrollhäufigkeit sollte an die Risikosituation angepasst werden: - Hohe Risikosituation: Tägliche oder wöchentliche Kontrolle - Mittlere Risikosituation: Wöchentliche oder 14-tägige Kontrolle - Niedrige Risikosituation: Monatliche Kontrolle
4.6 Risiko-Review bei Meilensteinen
Bei jedem Meilenstein wird ein erneutes Risiko-Assessment durchgeführt:
| Frage | Erklärung |
|---|---|
| Gibt es neue Risiken? | Neue Risiken identifizieren und bewerten |
| Hat sich die Wichtigkeit bei Risiken verändert? | Wahrscheinlichkeit und Auswirkung neu bewerten |
| Sind Maßnahmen wirksam? | Maßnahmen evaluieren und ggf. anpassen |
| Sind Risiken eingetreten? | Eingetretene Risiken auswerten, lernen, dokumentieren |
| Gibt es Chancen? | Chancen identifizieren und nutzen |
5. Risikokommunikation
5.1 Bedeutung der Risikokommunikation
Risikokommunikation ist wichtig und man sollte sie keinesfalls dem Zufall überlassen, sondern als Bestandteil des Kommunikationsplans sehen.
Kommunikation ist Schlüssel
"Risikokommunikation ist das Bindeglied zwischen Risikomanagement und Projektsteuerung. Ohne Kommunikation ist das beste Risikomanagement wertlos."
5.2 Regelmäßige Berichterstattung
Regelmäßige Berichterstattung über die wesentlichen Risiken an die jeweiligen Entscheidungsträger:
| Berichtstyp | Empfänger | Frequenz | Inhalte |
|---|---|---|---|
| Risiko-Statusbericht | Projektleiter, Lenkungsausschuss | Wöchentlich/Monatlich | Top 10 Risiken, Status-Update, neue Risiken, geschlossene Risiken |
| Risiko-Executive-Summary | Management, C-Level | Monatlich/Quartalsweise | Zusammenfassung der wichtigsten Risiken, Trends, Eskalationen |
| Risiko-Dashboard | Alle Stakeholder | Laufend (Online) | Visuelle Darstellung der Risikosituation |
| Risiko-Eskalation | Management, C-Level | Ad hoc | Kritische Risiken, Eskalation bei Bedarf |
5.3 Aufzeigen von Abweichungen
Aufzeigen von Abweichungen gegenüber den vorgegebenen risikopolitischen Zielen:
| Abweichungstyp | Beispiel | Eskalation |
|---|---|---|
| Risiko-Anzahl | Anzahl der Hoch-Risiken hat signifikant zugenommen | Eskalation an Management |
| Risiko-Priorität | Höchste Risikopriorität hat sich erhöht | Eskalation an Management |
| Maßnahmen-Wirksamkeit | Maßnahmen sind nicht wirksam, Risikosituation verschlechtert | Eskalation an Management |
| Ressourcen-Engpässe | Keine Ressourcen zur Durchführung von Maßnahmen | Eskalation an Management |
| Zeitplan-Beeinflussung | Risiken beeinflussen den Zeitplan signifikant | Eskalation an Lenkungsausschuss |
!!! warning "Eskalationskriterien definieren** Definieren Sie klare Eskalationskriterien für Risiken: - "Bei >5 Hoch-Risiken eskalieren an Lenkungsausschuss" - "Bei Risiken mit Auswirkung 5 (katastrophal) sofort eskalieren" - "Bei Budgetüberschreitung durch Risiken >20% eskalieren an Management"
6. Zusammenfassung
6.1 Kernpunkte des Kapitels
- Risikomanagement ist kontinuierlich - Keine einmalige Aktivität, sondern ein dauerhafter Prozess
- Risikoidentifikation - Neue Risiken werden kontinuierlich erkannt und dokumentiert
- Risikoanalyse und -bewertung - Qualitative und quantitative Bewertung von Risiken
- Risikobehandlungsstrategien - Vermeiden, Minderung, Übertragen, Akzeptieren
- Kontinuierliche Überwachung - Regelmäßige Überprüfung und Anpassung
- Risikokommunikation - Regelmäßige Berichterstattung an Entscheidungsträger
6.2 Erfolgsfaktoren
| Erfolgsfaktor | Maßnahmen |
|---|---|
| Kontinuierliche Identifikation | Neue Risiken laufend erkennen und dokumentieren |
| Klare Verantwortlichkeiten | Verantwortliche für jedes Risiko benennen |
| Realistische Bewertung | Wahrscheinlichkeit und Auswirkung realistisch bewerten |
| Proaktive Maßnahmen | Maßnahmen proaktiv, nicht nur reaktiv |
| Regelmäßige Überprüfung | Kontinuierliche Überwachung und Anpassung |
| Gute Kommunikation | Transparente Risikokommunikation an alle Stakeholder |
| Kultur der Offenheit | Offene Risikokultur, Risiken werden nicht versteckt |
| Wissensmanagement | Lessons Learned aus Risiken dokumentieren und nutzen |
| Tool-Unterstützung | Nutzung von Risikomanagement-Tools |
7. Schlüsselbegriffe
| Begriff | Definition |
|---|---|
| Risiko | Unsicheres Ereignis oder Bedingung mit positiver oder negativer Auswirkung auf Projektziele |
| Chance | Positives Risiko, das ggf. genutzt werden kann |
| Risikoidentifikation | Prozess zur Erkennung von Risiken |
| Risikoanalyse | Bewertung von Risiken (Wahrscheinlichkeit und Auswirkung) |
| Qualitative Risikoanalyse | Bewertung basierend auf Wahrscheinlichkeit und Auswirkung (Skalen) |
| Quantitative Risikoanalyse | Numerische Analyse von Risiken (Erwartungswert, Simulation) |
| Risikopriorität (RPN) | Priorisierung von Risiken basierend auf Wahrscheinlichkeit und Auswirkung |
| Risikoregister | Zentrales Dokument für das Risikomanagement |
| Risikobehandlungsstrategie | Strategie zur Behandlung von Risiken (Vermeiden, Minderung, Übertragen, Akzeptieren) |
| Risikobesitzer | Verantwortliche Person für ein Risiko |
| Kontingenz-Reserve | Budget- oder Zeitpuffer für akzeptierte Risiken |
| Eskalation | Weiterleitung von kritischen Risiken an höhere Entscheidungsebene |
| Risikokommunikation | Kommunikation von Risiken an Stakeholder |
| Risikomonitoring | Kontinuierliche Überwachung von Risiken |
| Risikoreview | Regelmäßige Überprüfung der Risikosituation |
| Lessons Learned | Erfahrungen und Lern-Erfahrungen aus Risiken |
| Monte-Carlo-Simulation | Simulation von Szenarien mit Zufallsvariablen für Risikoanalyse |
| Erwartungswert | Erwarteter Schaden oder Nutzen eines Risikos (Wahrscheinlichkeit × Auswirkung) |
8. Verständnisfragen
Frage 1: Risikoanalyse und -bewertung
Ein IT-Projekt hat folgende Risiken identifiziert:
- Risiko A: Lieferant liefert Komponente nicht termingerecht (Wahrscheinlichkeit: Hoch (4), Auswirkung: Kritisch (4))
- Risiko B: Datenbank-Performance bei >100.000 Datensätzen nicht ausreichend (Wahrscheinlichkeit: Mittel (3), Auswirkung: Hoch (3))
- Risiko C: Fachbereich X lehnt neue Software ab (Wahrscheinlichkeit: Mittel (3), Auswirkung: Kritisch (4))
a) Berechnen Sie die Risikopriorität (RPN) für jedes Risiko. b) Welches Risiko hat die höchste Priorität? c) Welche Risikobehandlungsstrategien würden Sie für jedes Risiko empfehlen?
Lösung: a) Risikopriorität (RPN = Wahrscheinlichkeit × Auswirkung):
| Risiko | Wahrscheinlichkeit | Auswirkung | RPN |
|---|---|---|---|
| Risiko A | 4 (Hoch) | 4 (Kritisch) | 16 |
| Risiko B | 3 (Mittel) | 3 (Hoch) | 9 |
| Risiko C | 3 (Mittel) | 4 (Kritisch) | 12 |
b) Höchste Priorität: Risiko A (RPN = 16)
Begründung: Risiko A hat die höchste Risikopriorität mit RPN = 16. Nach der RPN-Skala (16-25: Sehr hoch, Sofortige Maßnahmen, Eskalation) ist dies ein sehr hohes Risiko, das sofortige Maßnahmen erfordert.
c) Risikobehandlungsstrategien:
| Risiko | Empfohlene Strategie | Begründung |
|---|---|---|
| Risiko A (Lieferant liefert nicht termingerecht) | Minderung oder Übertragen | Wahrscheinlichkeit und Auswirkung sind hoch. Minderung: Alternativlieferant identifizieren, Puffer einplanen, frühzeitige Kommunikation mit Lieferant. Übertragen: SLA mit Lieferant, Strafzahlungen bei Verzögerung. |
| Risiko B (Datenbank-Performance nicht ausreichend) | Minderung oder Vermeiden | Wahrscheinlichkeit und Auswirkung sind mittel bis hoch. Minderung: Performance-Tests, Indizes optimieren, Skalierungsstrategie. Vermeiden: Alternative Datenbank-Technologie mit besserer Performance. |
| Risiko C (Fachbereich lehnt Software ab) | Minderung | Auswirkung ist kritisch. Minderung: Stakeholder-Management, Early-Bird-Programm, frühzeitige Einbindung des Fachbereichs, Schulung, Benefits kommunizieren. |
Frage 2: Risikokommunikation und Eskalation
Ein Projektleiter hat ein kritisches Risiko identifiziert: Die Datenmigration könnte fehlschlagen, was zu Datenverlust führen würde (Wahrscheinlichkeit: Mittel (3), Auswirkung: Katastrophal (5)). Er hat die Maßnahme "Daten-Backup vor Migration" geplant, aber das Management wird bisher nicht informiert.
a) Sollte der Projektleiter das Risiko eskalieren? Warum? b) Was sollte der Projektleiter in einem Risiko-Eskalationsbericht kommunizieren? c) Wann und wie oft sollte der Projektleiter über den Status dieses Risikos berichten?
Lösung: a) Ja, der Projektleiter sollte das Risiko eskalieren.
Begründung: - Die Risikopriorität ist sehr hoch (RPN = 3 × 5 = 15, in der Skala 10-15: Hoch, Aktive Maßnahmen erforderlich) - Die Auswirkung ist katastrophal (Datenverlust), was zu massiven finanziellen Schäden und Vertrauensverlust führen kann - Die Maßnahme "Daten-Backup vor Migration" ist wichtig, aber das Management muss über das Risiko informiert werden - Eskalationskriterien sind erfüllt: Risiko mit Auswirkung 5 (katastrophal) sollte sofort eskaliert werden
b) Inhalt des Risiko-Eskalationsberichts:
| Berichtsabschnitt | Inhalte |
|---|---|
| Zusammenfassung | Kritisches Risiko identifiziert: Datenmigration könnte fehlschlagen, Datenverlust möglich |
| Risiko-Beschreibung | Beschreibung des Risikos, betroffene Systeme, Datenmenge, Zeitrahmen |
| Auswirkungen | Mögliche Auswirkungen: Datenverlust, Umsatzverlust, Compliance-Verletzungen, Vertrauensverlust, Projektabbruch |
| Wahrscheinlichkeit | Wahrscheinlichkeit: Mittel (30-60%), Begründung der Bewertung |
| Geplante Maßnahmen | Maßnahme: Daten-Backup vor Migration, Testmigration, Rollback-Plan, Datensicherungs-Verfahren |
| Ressourcen-Bedarf | Benötigte Ressourcen: Additionaler Speicher für Backup, Zeit für Tests, Team-Ressourcen |
| Zeitplan | Zeitplan für Maßnahmen: Backup vor dem 15.03., Testmigration vom 16.-20.03., Produktivmigration am 31.03. | Eskalationsanforderung | Management-Entscheidung erforderlich: Genehmigung der Maßnahmen, Budgetfreigabe, Priorisierung | Empfehlung | Empfehlung: Sofortige Genehmigung der Maßnahmen, Priorisierung dieses Risikos, Überwachung der Maßnahmen |
c) Berichtsfrequenz für dieses kritisches Risiko:
| Phase | Frequenz | Begründung |
|-------|----------|------------|
**Vor Migration** | **Täglich** oder **bei Maßnahmen-Status-Änderungen** | Kritisches Risiko erfordert tägliche Überwachung |
| Während Migration** | **Laufend** (Stündlich) oder **bei Problemen** | Migration ist kritischer Zeitpunkt, laufendes Monitoring erforderlich |
**Nach Migration** | **Wöchentlich** für 4-6 Wochen | Nachbereitung, Überwachung der Datenqualität |
**General** | **Im Projektstatusbericht (wöchentlich)** | Regelmäßiges Reporting an Lenkungsausschuss und Management |
Zusätzlich: **Sofortige Eskalation** bei:
- Problemen bei der Backup-Erstellung
- Fehlern bei der Testmigration
- Abweichungen vom Zeitplan
- Unvorhergesehene Probleme
Frage 3: Risikobehandlungsstrategien
Ein IT-Projekt hat ein Risiko identifiziert: Das neu entwickelte System könnte bei >1.000 gleichzeitigen Benutzern Performance-Probleme haben. Die Projektleitung diskutiert verschiedene Strategien.
a) Erklären Sie die vier Risikobehandlungsstrategien (Vermeiden, Minderung, Übertragen, Akzeptieren) für dieses Risiko. b) Welche Strategie(n) würden Sie empfehlen und warum? c) Welche konkreten Maßnahmen würden Sie für die empfohlene(n) Strategie(n) vorschlagen?
Lösung: a) Risikobehandlungsstrategien für das Performance-Risiko:
| Strategie | Erklärung | Anwendung auf Performance-Risiko |
|---|---|---|
| Vermeiden (Avoid) | Risikowahrscheinlichkeit auf Null setzen | Performance-Risiko vermeiden durch Auswahl einer anderen Architektur, die für >1.000 Benutzer skaliert (z.B. Microservices statt Monolith, Cloud-basierte Skalierung, Caching-Strategie) |
| Minderung (Mitigate) | Wahrscheinlichkeit oder Auswirkung reduzieren | Performance-Risiko mindern durch Performance-Tests, Lasttests, Optimierung von Datenbankabfragen, Caching, Load Balancing, horizontale Skalierung |
| Übertragen (Transfer) | Risiko auf andere Parteien übertragen | Performance-Risiko übertragen durch Cloud-Hosting mit garantierten SLAs (z.B. AWS Auto Scaling), Externalisierung der Performance-Optimierung an Experten |
| Akzeptieren (Accept) | Risiko akzeptieren und falls eintritt, reagieren | Performance-Risiko akzeptieren und Kontingenz-Maßnahmen planen (z.B. Notfall-Plan für Performance-Engpässe, Kommunikationsplan an Benutzer, Puffer für Performance-Optimierung nach Go-Live) |
b) Empfohlene Strategie(n):
Kombination von Minderung und Übertragen wird empfohlen:
- Minderung (Primärstrategie):
- Performance- und Lasttests vor Go-Live
- Caching-Strategie implementieren
- Datenbankoptimierung durchführen
-
Horizontale Skalierung vorbereiten
-
Übertragen (Sekundärstrategie):
- Cloud-basierte Hosting-Lösung mit Auto-Scaling
- SLA mit Cloud-Provider für Performance und Verfügbarkeit
- Externalisierung von Performance-Optimierung an Experten, falls notwendig
Begründung: - Vermeiden ist in diesem Fall oft nicht realistisch, da Performance-Optimierung Teil der Entwicklung ist - Minderung ist die primäre Strategie, da Performance-Tests und Optimierungen Standardmaßnahmen sind - Übertragen ergänzt Minderung durch Cloud-Skalierung und SLAs, was zusätzliche Sicherheit bietet - Akzeptieren sollte nur als Backup-Plan verwendet werden (Kontingenz-Maßnahmen), da Performance-Probleme kritische Auswirkungen haben können
c) Konkrete Maßnahmen für die empfohlenen Strategien:
Minderungs-Maßnahmen:
| Maßnahme | Verantwortlicher | Zeitrahmen |
|---|---|---|
| Performance-Tests | Test-Team, Entwickler | Vor Go-Live, 2 Wochen |
| Lasttests | Test-Team | Vor Go-Live, 1 Woche |
| Caching-Strategie | Architekt, Entwickler | In Entwicklung, 3 Wochen |
| Datenbankoptimierung | Datenbank-Admin, Entwickler | In Entwicklung, 2 Wochen |
| Load Balancing | Systemarchitekt, DevOps | Vor Go-Live, 1 Woche |
| Horizontale Skalierung | DevOps | Vor Go-Live, 1 Woche |
Übertragungs-Maßnahmen:
| Maßnahme | Verantwortlicher | Zeitrahmen |
|---|---|---|
| Cloud-Hosting mit Auto-Scaling | DevOps, Cloud-Provider | Vor Go-Live, 2 Wochen |
| SLA mit Cloud-Provider | Legal, Cloud-Provider | Vor Go-Live, 1 Woche |
| Performance-Monitoring | DevOps | Laufend ab Go-Live |
| Alerting bei Performance-Problemen | DevOps | Vor Go-Live, 1 Woche |
Kontingenz-Maßnahmen (für Akzeptieren):
| Maßnahme | Verantwortlicher | Zeitrahmen |
|---|---|---|
| Notfallplan für Performance-Engpässe | Projektleiter | Vor Go-Live |
| Kommunikationsplan an Benutzer | Kommunikation | Vor Go-Live |
| Puffer für Performance-Optimierung nach Go-Live | Entwickler | Im Projektplan einplanen |
Nächstes Kapitel: 8. Quiz