Integriertes Risikomanagement im Projekt: Portfolio, Eskalation und Kommunikation

Kategorie: Methodik & Frameworks

Infografik: Integriertes Risikomanagement im Projektumfeld

Was ist integriertes Risikomanagement im Projekt?

Integriertes Risikomanagement ist ein durchgehender Prozess, der Risiken auf Projektebene identifiziert, bewertet und behandelt und sie zugleich über definierte Eskalationsstufen und Aggregationsregeln in die Programm- und Portfoliosteuerung überführt. Die ISO 31000 beschreibt dafür drei Ebenen: Grundsätze, Rahmenwerk und Prozess (Quelle). Der PMBOK Guide zerlegt den Prozess in sechs Schritte: Risikomanagement planen, Risiken identifizieren, qualitativ analysieren, quantitativ analysieren, Maßnahmen planen und Risiken überwachen (Quelle).

Der Unterschied zum klassischen Projektrisikomanagement liegt im Wort „integriert". Ein Risikoregister, das nur im Projekt liegt, warnt nur das Projekt. Ein Risiko, das drei Projekte gleichzeitig trifft, wird erst auf Portfolioebene sichtbar.

Wann brauchen Sie die integrierte Sicht, und wann nicht?

Sie brauchen sie, wenn mindestens eine der folgenden Bedingungen zutrifft:

• Mehrere Projekte greifen auf dieselbe Ressource, denselben Lieferanten oder dieselbe Technologie zu.
• Einzelne Risiken übersteigen die Risikotragfähigkeit des Projektbudgets.
• Die Organisation hält Reserven zentral und nicht je Projekt.
• Genehmigungs- oder Normrisiken betreffen eine ganze Produktlinie.

Sie brauchen sie nicht bei einem isolierten Projekt unter sechs Monaten Laufzeit mit eigener Ressourcenbasis und ohne geteilte Lieferkette. Dort erzeugt eine Portfolioaggregation Aufwand ohne Steuerungsnutzen. Die ISO 31000 ist ausdrücklich eine Leitlinie, kein zertifizierbarer Standard, und lässt diese Skalierung zu (Quelle).

Ein zweiter Grenzfall: Wenn Ihre Organisation keine Entscheidungsstelle oberhalb des Projekts hat, ist Eskalation wirkungslos. Dann bauen Sie zuerst das Gremium, dann den Prozess. Ein Risikobericht an einen Verteiler ohne Budgethoheit erzeugt Aufwand und keine Entscheidung.

Der Zeitpunkt zählt ebenfalls. Die integrierte Bewertung gehört in die Definitionsphase, nicht in die Realisierung. Ein Risiko, das erst nach der Bestellung der Langläuferteile bewertet wird, hat seine wirksamste Gegenmaßnahme bereits verloren.

Wie läuft integriertes Risikomanagement in sieben Schritten ab?

1. Anwendungsbereich, Kontext und Kriterien festlegen

Ziel: Ein gemeinsamer Maßstab für alle Projekte im Portfolio.

Vorgehen: Definieren Sie Wahrscheinlichkeits- und Wirkungsklassen einmal für die Organisation, nicht je Projekt. Legen Sie Schwellenwerte fest, ab denen ein Risiko die Projektebene verlässt. Die ISO 31000 stellt diesen Schritt an den Anfang des Prozesses, getragen von Kommunikation, Überwachung und Aufzeichnung (Quelle).

Typischer Fehler: Jedes Projekt definiert „hoch" selbst. Die Aggregation summiert dann Äpfel und Birnen.

2. Risiken identifizieren

Ziel: Vollständigkeit vor Genauigkeit.

Vorgehen: Der PMBOK-Prozess „Identify Risks" erfasst Einzelrisiken und übergreifende Risikoquellen samt ihrer Merkmale (Quelle). Nutzen Sie Arbeitspakete des Projektstrukturplans, Lieferantenliste, Schnittstellenliste und Lessons Learned als Suchraster. Jedes Risiko bekommt Ursache, Ereignis und Wirkung getrennt notiert.

Typischer Fehler: Wirkungen als Risiken erfassen. „Termin reißt" ist keine Ursache, sondern eine Folge.

3. Qualitativ bewerten und priorisieren

Ziel: Reihenfolge der Bearbeitung.

Vorgehen: Bewerten Sie Eintrittswahrscheinlichkeit und Wirkung in der Risikomatrix. Die DIN EN IEC 31010 führt die Risikomatrix als semi-quantitatives Verfahren zwischen qualitativen Methoden wie HAZOP und quantitativen wie der Monte-Carlo-Simulation (Quelle). Die Fassung von Dezember 2024 erweitert den Methodenkatalog von 30 auf 41 Verfahren (Quelle).

Eine Fünf-mal-fünf-Matrix reicht in der Praxis. Entscheidend ist, dass die Klassengrenzen in Euro und Wochen hinterlegt sind und nicht in Adjektiven. „Wirkung hoch" muss heißen: 100.000 bis 250.000 Euro oder vier bis acht Wochen Verzug auf dem kritischen Pfad.

Die neue Fassung der Norm bewertet zusätzlich die Wirksamkeit bereits vorhandener Steuerungsmaßnahmen und die Qualität der verfügbaren Informationen (Quelle). Ein Risiko, das auf einer dünnen Datenlage beruht, gehört markiert, nicht gemittelt.

Typischer Fehler: Die Matrix als Ergebnis behandeln. Sie priorisiert, sie bewertet nicht in Euro.

4. Quantitativ bewerten und Reserven ableiten

Ziel: Risiken in Geld und Zeit ausdrücken.

Vorgehen: Rechnen Sie je Risiko den Erwartungswert: EMV = Wahrscheinlichkeit × Wirkung. Der PMBOK Guide führt die Expected-Monetary-Value-Analyse als statistisches Verfahren, das den Mittelwert über eintretende und nicht eintretende Szenarien bildet; negative Werte stehen für Bedrohungen, positive für Chancen (Quelle). Die Summe der Erwartungswerte ist die Grundlage der Contingency-Reserve, also der Reserve für identifizierte Risiken ohne Maßnahme (Quelle).

Typischer Fehler: Contingency- und Management-Reserve vermischen. Die erste deckt bekannte Risiken, die zweite unbekannte, und sie liegt oberhalb des Projektbudgets.

5. Maßnahmen planen und umsetzen

Ziel: Jedes priorisierte Risiko hat einen Eigentümer und ein Datum.

Vorgehen: „Plan Risk Responses" entwickelt Optionen und wählt Strategien für Einzelrisiken und für die Gesamtrisikolage (Quelle). Vermeiden, vermindern, übertragen, akzeptieren. Jede Maßnahme erhält Kosten, Termin und Verantwortlichen und wandert in den Terminplan, nicht in eine separate Liste.

Typischer Fehler: Maßnahmen ohne Restrisikobewertung. Nach der Maßnahme ist die Bewertung eine andere.

6. Eskalieren und auf Portfolioebene aggregieren

Ziel: Risiken dort entscheiden, wo die Entscheidungsbefugnis liegt.

Vorgehen: Definieren Sie drei Stufen. Projekt entscheidet innerhalb der eigenen Reserve. Programm entscheidet, wenn mehrere Projekte desselben Programms betroffen sind oder die Projektreserve nicht reicht. Portfolio entscheidet, wenn strategische Ziele, Kapitalbindung oder programmübergreifende Ressourcen betroffen sind. Die ISO 21502 beschreibt Projekt, Programm und Portfolio als die drei Grundelemente dieser Struktur (Quelle). Für die Portfoliosicht gilt ISO 21504 (Quelle).

Aggregieren heißt nicht addieren. Risiken mit gemeinsamer Ursache dürfen nicht als unabhängige Einzelrisiken verrechnet werden. Fällt die gemeinsame Ursache ein, treffen alle betroffenen Projekte gleichzeitig.

Die Entscheidungsvorlage bei Eskalation enthält vier Angaben: Risiko mit Erwartungswert, betroffene Projekte, vorgeschlagene Maßnahme mit Kosten, und das Restrisiko nach Maßnahme. Fehlt eine davon, fällt die Entscheidung nicht, sondern wird vertagt.

Typischer Fehler: Eskalation als Statusmeldung. Eine Eskalation ohne Entscheidungsvorlage ist eine Abgabe von Verantwortung.

7. Kommunizieren und überwachen

Ziel: Jeder Empfänger bekommt die Risikoinformation in der Form, in der er entscheiden kann.

Vorgehen: Der Kommunikationsplan legt fest, wer welche Information zu welchem Zeitpunkt in welcher Form erhält (Quelle). Der PMBOK-Prozess „Monitor Risks" verfolgt die Umsetzung der Maßnahmen, identifiziert neue Risiken und prüft die Wirksamkeit des Prozesses selbst (Quelle).

Typischer Fehler: Ein Bericht für alle. Das Portfolioboard braucht keine 40 Einzelrisiken, sondern die vier gemeinsamen Ursachen dahinter.

Wie sieht das durchgerechnet aus?

Ausgangslage: Anlagenbauprojekt, Abfülllinie für einen Getränkehersteller, Auftragswert 6,4 Mio. Euro, Laufzeit 18 Monate. Das Risikoregister enthält fünf bewertete Risiken. Die Zahlen sind konstruiert.

Rechenweg: EMV = Wahrscheinlichkeit × Wirkung. Für R1: 0,35 × 180.000 = 63.000 Euro. Die Summe der Erwartungswerte beträgt 222.000 Euro, das sind 3,5 Prozent des Auftragswerts. Diese 222.000 Euro bilden die Contingency-Reserve des Projekts. Die maximale Wirkung von 705.000 Euro ist dagegen kein Reservewert, sondern das Worst-Case-Szenario, in dem alle fünf Risiken eintreten.

Eskalationsentscheidung nach den Kriterien aus Schritt 1:

• R2 überschreitet die Projektschwelle von 200.000 Euro Einzelwirkung. Die Nacharbeit an einem druckführenden Bauteil berührt zudem die Abnahmeprüfung. Entscheidung: Eskalation auf Programmebene, weil dort die Prüfkapazität der Schweißfachaufsicht für alle Anlagenprojekte geplant wird.
• R4 betrifft eine Person, die in drei Projekten des Portfolios als Inbetriebnehmer eingeplant ist. Die drei Projekte bewerten die Wirkung mit 120.000, 95.000 und 145.000 Euro, jeweils bei 30 Prozent Wahrscheinlichkeit. Aggregiert: 0,30 × 360.000 = 108.000 Euro. Kein einzelnes Projekt sieht mehr als 36.000 Euro. Das Portfolio sieht die vollen 108.000 Euro und entscheidet über die Gegenmaßnahme, hier den Aufbau eines zweiten qualifizierten Inbetriebnehmers für 55.000 Euro Schulungs- und Freistellungskosten.
• R5 ist ein Finanzrisiko mit gemeinsamer Ursache über alle Projekte mit USD-Beschaffung. Absicherung gehört in die Treasury-Funktion, nicht in das Projekt. Entscheidung: Eskalation auf Portfolioebene, Projekt führt das Risiko nur nachrichtlich.

Die Gegenmaßnahme zu R4 lohnt sich aus Portfoliosicht: 55.000 Euro Aufwand gegen 108.000 Euro Erwartungswert. Aus Sicht des Einzelprojekts wäre dieselbe Maßnahme abgelehnt worden, weil sie 55.000 Euro gegen einen Erwartungswert von 36.000 Euro stellt. Dieselbe Maßnahme, zwei Entscheidungen, abhängig allein von der Bewertungsebene.

Nach Eskalation verbleiben R1 und R3 mit zusammen 108.000 Euro Erwartungswert in der Projektreserve. Der Rest liegt dort, wo die Entscheidung getroffen wird. Genau das ist die Wirkung der Integration: Die Reserve folgt der Entscheidungsbefugnis.

Fazit

Risikomanagement scheitert selten an der Identifikation. Es scheitert an der Ebene. Ein Risiko, das nur im Projektregister steht, wird mit Projektmitteln bekämpft, auch wenn seine Ursache portfolioweit wirkt und seine Behandlung eine Portfolioentscheidung wäre. Drei Festlegungen lösen das: einheitliche Bewertungskriterien, dokumentierte Eskalationsschwellen und Reserven auf derselben Ebene wie die Entscheidungsbefugnis. Ohne die dritte Festlegung bleiben die ersten beiden Papier.

Weiterführend: 5 Methoden der Aufwandsschätzung im Vergleich · Machbarkeitsbewertung im Projekt: Input, Methoden, Output

Quellen

1. DGWZ: DIN ISO 31000 Risikomanagement — https://www.dgwz.de/din-iso-31000-risikomanagement (abgerufen 2026-09)
2. ProjectEngineer: Project Risk Management According to the PMBOK — https://www.projectengineer.net/project-risk-management-according-to-the-pmbok/ (abgerufen 2026-09)
3. Projex: PMBOK Identify Risks process — https://www.projex.com/pmbok-identify-risks-process/ (abgerufen 2026-09)
4. PMTI: Project Risk Management Processes — https://www.4pmti.com/learn/project-risk-management-processes/ (abgerufen 2026-09)
5. BrainBOK: Expected Monetary Value (EMV) — https://www.brainbok.com/guide/pm-study-notes/risk/expected-monetary-value-emv (abgerufen 2026-09)
6. DGWZ: Neue DIN EN IEC 31010 Verfahren zur Risikobeurteilung — https://www.dgwz.de/neue-din-en-iec-31010-risikomanagement-risikobeurteilung (abgerufen 2026-09)
7. Globalnorm: Die neue DIN EN IEC 31010:2024-12 zur Risikobeurteilung — https://compliance.globalnorm.de/product-compliance-news/detail/die-neue-din-en-iec-310102024-12-zur-risikobeurteilung/ (abgerufen 2026-09)
8. Roland Wanner: Risikomanagement-Glossar (Contingency Reserve) — https://rolandwanner.ch/projekt-risikomanagement/risikomanagement-glossar/ (abgerufen 2026-09)
9. ISO 21502:2020 Guidance on project management — https://www.iso.org/standard/74947.html (abgerufen 2026-09)
10. ISO 21504:2022 Guidance on portfolio management — https://webstore.ansi.org/standards/iso/ISO215042022 (abgerufen 2026-09)
11. Projektmagazin: Risikoregister — https://www.projektmagazin.de/glossarterm/risikoregister (abgerufen 2026-09)
12. Projektmagazin: DIN 69901 Projektmanagement — https://www.projektmagazin.de/glossarterm/din-69901-projektmanagement-projektmanagementsysteme (abgerufen 2026-09)

Mehr zu Projektmanagement für technisch komplexe Projekte: Aligia