Risikomanagement Beispiel: Schritt für Schritt am Praxisprojekt

Das Beispielprojekt: CRM-Einführung

Ein mittelständischer Maschinenbauer mit 150 Mitarbeitern will seinen Vertrieb professionalisieren. Bisher arbeiten die 40 Vertriebsmitarbeiter mit Excel-Listen und Outlook-Ordnern – Kundendaten sind über persönliche Dateien verstreut, Angebote lassen sich kaum nachvollziehen und Forecasts basieren auf Bauchgefühl. Die Geschäftsführung erwartet durch ein zentrales System kürzere Verkaufszyklen und verlässlichere Pipeline-Daten.

Das Unternehmen entscheidet sich für die Einführung eines cloud-basierten CRM-Systems. Die wichtigsten Rahmendaten:

• Budget: 180.000 EUR
• Laufzeit: 6 Monate
• Go-Live-Termin: Fix, vor Beginn des neuen Geschäftsjahres
• Team: Interne Projektleiterin, zwei Key-User aus dem Vertrieb, externer Implementierungspartner mit drei Beratern
• Schnittstelle: Das CRM soll an das bestehende ERP-System angebunden werden

Ein Projektplan steht, die Projektphasen sind definiert. Was fehlt: ein systematisches Risikomanagement. Die Projektleiterin führt das Team in fünf Schritten durch den Prozess.

Schritt 1 – Risiken identifizieren

Im ersten Schritt sammelt das Projektteam in einem Workshop alle Risiken, die das Projekt gefährden könnten. Die Projektleiterin nutzt zwei Methoden: ein strukturiertes Brainstorming mit dem gesamten Projektteam und eine Checkliste typischer Risiken aus früheren IT-Projekten des Unternehmens. Ergänzend befragt sie den IT-Leiter und den Vertriebsleiter einzeln – beide bringen Perspektiven ein, die im Workshop nicht zur Sprache kamen. Eine ausführliche Anleitung zu Methoden der Risikoidentifikation finden Sie in unserem separaten Artikel.

Nach zwei Stunden stehen sieben zentrale Risiken auf der Liste:

1. R1 – Datenqualität im Altsystem unzureichend. Die Kundendaten in Excel und Outlook sind lückenhaft, enthalten Dubletten und veraltete Kontakte. Die Datenmigration wird aufwendiger als geplant.

2. R2 – ERP-Schnittstelle komplexer als erwartet. Das ERP-System nutzt eine proprietäre API mit lückenhafter Dokumentation. Die Anbindung könnte mehr Zeit erfordern als kalkuliert.

3. R3 – Geringe Nutzerakzeptanz im Vertrieb. Das Vertriebsteam ist an seine Excel-Workflows gewöhnt. Widerstand gegen das neue System kann den Projekterfolg gefährden, selbst wenn die Technik funktioniert.

4. R4 – Externer Partner liefert verspätet. Der Implementierungspartner betreut parallel weitere Kunden. Ressourcenengpässe könnten zu Verzögerungen führen.

5. R5 – Anforderungen ändern sich während der Implementierung. Erfahrungsgemäß erkennen Fachbereiche neue Wünsche erst, wenn sie den Prototyp sehen. Scope Creep bedroht Zeitplan und Budget.

6. R6 – Performance-Probleme bei gleichzeitigem Zugriff. Wenn alle 40 Vertriebsmitarbeiter gleichzeitig arbeiten, könnte die Systemleistung einbrechen.

7. R7 – DSGVO-Anforderungen werden spät erkannt. Ein CRM enthält personenbezogene Daten. Löschkonzepte, Einwilligungsmanagement und Auftragsverarbeitungsverträge müssen frühzeitig berücksichtigt werden.

Schritt 2 – Risiken bewerten

Jedes Risiko wird auf zwei Skalen bewertet: Eintrittswahrscheinlichkeit und Auswirkung. Das Team verwendet eine fünfstufige Skala, die vor der Bewertung gemeinsam definiert wird. So stellt die Projektleiterin sicher, dass alle dasselbe unter „mittel” oder „hoch” verstehen. Detaillierte Methoden beschreibt unser Artikel Risiken bewerten.

Bewertungsskala

Stufe	Eintrittswahrscheinlichkeit	Auswirkung
1 – Sehr gering	< 10 %	Kaum spürbar, keine Planänderung nötig
2 – Gering	10–30 %	Geringfügige Verzögerung oder Mehrkosten (< 5 %)
3 – Mittel	30–60 %	Spürbare Abweichung, Mehrkosten 5–15 %
4 – Hoch	60–85 %	Erhebliche Abweichung (15–30 %), Scope gefährdet
5 – Sehr hoch	> 85 %	Projektziel gefährdet, massive Überschreitung

Ergebnis der Bewertung

Die Teammitglieder bewerten jedes Risiko einzeln, anschließend werden die Einschätzungen diskutiert und konsolidiert. Aus Eintrittswahrscheinlichkeit (W) und Auswirkung (A) ergibt sich die Risikoprioritätszahl (RPZ = W × A):

Risiko	W	A	RPZ	Kategorie
R1: Datenqualität unzureichend	Mittel (3)	Schwer (4)	12	Hoch
R2: ERP-Schnittstelle komplex	Mittel (3)	Mittel (3)	9	Mittel
R3: Geringe Nutzerakzeptanz	Hoch (4)	Schwer (4)	16	Kritisch
R4: Partner liefert verspätet	Gering (2)	Mittel (3)	6	Niedrig
R5: Scope Creep	Hoch (4)	Mittel (3)	12	Hoch
R6: Performance-Probleme	Gering (2)	Gering (2)	4	Niedrig
R7: DSGVO spät erkannt	Mittel (3)	Katastrophal (5)	15	Kritisch

Schritt 3 – Risikomatrix erstellen

Die bewerteten Risiken werden in eine Risikomatrix eingetragen. Die Position jedes Risikos ergibt sich aus der Kombination von Eintrittswahrscheinlichkeit (Zeile) und Auswirkung (Spalte). Die Farbcodierung zeigt auf einen Blick, wo der größte Handlungsbedarf liegt.

	Unbedeutend (1)	Gering (2)	Mittel (3)	Schwer (4)	Katastrophal (5)
Sehr hoch (5)
Hoch (4)			R5	R3
Mittel (3)			R2	R1	R7
Gering (2)		R6	R4
Sehr gering (1)

Zeilen = Eintrittswahrscheinlichkeit, Spalten = Auswirkung

Das Bild ist eindeutig: Zwei Risiken liegen im roten Bereich (R3 und R7), zwei im orangen (R1 und R5). Hier muss das Projektteam handeln. R2 ist im gelben Bereich – planen und beobachten. R4 und R6 sind grün – im Auge behalten, aber kein sofortiger Handlungsbedarf.

Schritt 4 – Maßnahmen planen

Für jedes Risiko definiert das Team eine Strategie und konkrete Maßnahmen. Die vier Grundstrategien im Risikomanagement sind: Vermeiden, Vermindern, Übertragen und Akzeptieren. Unser Artikel zu Risikomaßnahmen beschreibt diese Strategien im Detail.

Kritische Risiken

R3 – Geringe Nutzerakzeptanz (Strategie: Vermindern)

Das größte Risiko ist nicht technisch, sondern menschlich. Die Projektleiterin plant vier Maßnahmen: Erstens werden zwei Key-User aus dem Vertrieb ab Projektstart als Botschafter eingebunden – sie gestalten das System mit und tragen die Entscheidungen ins Team. Zweitens startet in Monat 3 eine Pilotphase mit fünf ausgewählten Vertriebsmitarbeitern, deren Feedback direkt in die Konfiguration einfließt. Drittens ersetzen praxisnahe Schulungen an realen Kundendaten die üblichen abstrakten Systemeinführungen. Viertens werden Quick Wins sichtbar gemacht – etwa automatisierte Angebotsvorlagen, die dem Vertrieb sofort Zeit sparen.

R7 – DSGVO-Anforderungen spät erkannt (Strategie: Vermeiden)

Der Datenschutzbeauftragte wird ab Projektstart eingebunden, nicht erst vor dem Go-Live. In Sprint 1 entsteht das Löschkonzept. Einwilligungsmanagement und Auftragsverarbeitungsverträge werden als eigene Arbeitspakete definiert. Ein Privacy-by-Design-Review findet vor dem Go-Live statt.

Hohe Risiken

R1 – Datenqualität unzureichend (Strategie: Vermindern)

Die Datenbereinigung wird als eigenes Arbeitspaket vor die Migration gezogen. In Sprint 2 findet eine Testmigration auf einem Staging-System statt. Das Team definiert Akzeptanzkriterien: Weniger als 2 % Dubletten, alle Pflichtfelder befüllt, Ansprechpartner aktuell.

R5 – Scope Creep (Strategie: Vermindern)

Ein Change-Request-Prozess wird vereinbart: Neue Anforderungen werden dokumentiert, bewertet und priorisiert. Wünsche, die den Go-Live-Termin gefährden, werden in Phase 2 verschoben. Das MVP (Minimum Viable Product) ist klar definiert – Vertriebspipeline, Angebotsmanagement und Reporting.

Mittlere und niedrige Risiken

R2 – ERP-Schnittstelle (Strategie: Vermindern): Ein Proof-of-Concept in Sprint 1 prüft die Machbarkeit. Der Zeitplan enthält zwei Wochen Puffer für die Integration.

R4 – Partnerverzug (Strategie: Übertragen): Der Vertrag enthält Meilensteine mit Pönalen. Ein Eskalationspfad ist definiert.

R6 – Performance (Strategie: Akzeptieren): Ein Lasttest mit 40 simultanen Nutzern ist vor dem Go-Live eingeplant. Das Risiko wird bewusst akzeptiert, weil der Cloud-Anbieter Skalierbarkeit garantiert.

Schritt 5 – Risiken überwachen

Risikomanagement ist kein einmaliger Workshop – es ist ein fortlaufender Prozess über die gesamte Projektlaufzeit. Im CRM-Projekt führt die Projektleiterin alle zwei Wochen ein Risiko-Review in der Projektstatusbesprechung durch. Drei Fragen stehen dabei im Mittelpunkt: Haben sich Eintrittswahrscheinlichkeiten oder Auswirkungen verändert? Sind neue Risiken aufgetaucht? Können Risiken geschlossen werden, weil die Maßnahmen gegriffen haben? Das Risikoregister wird bei jedem Review aktualisiert.

Zwei Beispiele aus dem Projektverlauf zeigen, warum diese Überwachung entscheidend ist:

R3 (Nutzerakzeptanz) wurde nach der erfolgreichen Pilotphase von „Kritisch” auf „Mittel” herabgestuft. Das Vertriebsteam reagierte positiv auf die automatisierten Angebotsvorlagen – der anfängliche Widerstand wich Neugier.

R2 (ERP-Schnittstelle) hingegen wurde von „Mittel” auf „Hoch” hochgestuft. Der Proof-of-Concept offenbarte, dass die API-Dokumentation fehlerhaft war. Zusätzliche Maßnahme: Ein externer Schnittstellenexperte wurde für drei Wochen hinzugezogen.

Ohne die regelmäßigen Reviews hätte das Team R2 unterschätzt und den Go-Live-Termin gefährdet. Die Lektion: Eine Risikobewertung zu Projektbeginn ist wertvoll – aber nur, wenn sie im Projektverlauf fortgeschrieben wird.

Das vollständige Risikoregister

Das Risikoregister fasst alle Informationen an einem Ort zusammen. Es ist das zentrale Steuerungsinstrument im Risikomanagement-Prozess – ein lebendes Dokument, das bei jeder Statusbesprechung aktualisiert wird.

ID	Risiko	W	A	RPZ	Strategie	Maßnahme	Verantwortlich	Status
R1	Datenqualität unzureichend	3	4	12	Vermindern	Datenbereinigung vor Migration, Testmigration in Sprint 2	Key-User 1	In Arbeit
R2	ERP-Schnittstelle komplex	3→4	3	9→12	Vermindern	PoC in Sprint 1, ext. Experte hinzugezogen	Ext. Partner	Eskaliert
R3	Geringe Nutzerakzeptanz	4→3	4	16→12	Vermindern	Key-User als Botschafter, Pilotphase, Schulungen	Projektleiterin	Verringert
R4	Partner liefert verspätet	2	3	6	Übertragen	Vertragliche Meilensteine mit Pönalen	Projektleiterin	Offen
R5	Scope Creep	4	3	12	Vermindern	Change-Request-Prozess, MVP definiert	Projektleiterin	In Arbeit
R6	Performance-Probleme	2	2	4	Akzeptieren	Lasttest vor Go-Live	Ext. Partner	Offen
R7	DSGVO spät erkannt	3	5	15	Vermeiden	DSB ab Projektstart, Löschkonzept in Sprint 1	DSB / Projektleiterin	In Arbeit

In der Praxis pflegen viele Teams ihr Risikoregister in einer Tabellenkalkulation. Bei wachsender Projektanzahl empfiehlt sich eine Projektmanagement-Software, die Risiken, Maßnahmen und Verantwortlichkeiten zentral verwaltet. Unser Artikel zum Risikoregister im Projektmanagement beschreibt den Aufbau und die Pflege im Detail.

Was dieses Beispiel zeigt

Die größten Risiken sind nicht immer technisch. R3 (Nutzerakzeptanz) war das kritischste Risiko – kein Bug, kein Systemausfall, sondern menschlicher Widerstand gegen Veränderung.

Frühe Identifikation verhindert teure Nachbesserungen. Hätte das Team R7 (DSGVO) erst kurz vor Go-Live entdeckt, wäre eine Verschiebung um Monate unvermeidlich gewesen.

Risiken verändern sich. R3 sank nach der Pilotphase, R2 stieg nach dem Proof-of-Concept. Nur durch regelmäßige Reviews bleibt das Bild aktuell.

Der Prozess ist übertragbar. Dieselben fünf Schritte – identifizieren, bewerten, priorisieren, Maßnahmen planen, überwachen – funktionieren unabhängig von Projektgröße und Branche. Auch ein Chancenmanagement folgt derselben Logik, nur mit positivem Vorzeichen.

Einfach starten schlägt perfekt planen. Sieben Risiken mit konkreten Maßnahmen und Verantwortlichen schaffen mehr Transparenz als eine theoretisch vollständige Analyse, die nie umgesetzt wird.

Häufig gestellte Fragen

Was ist ein Beispiel für Risikomanagement im Projekt?

Ein typisches Beispiel: Bei einer CRM-Einführung identifiziert das Projektteam Risiken wie unzureichende Datenqualität, geringe Nutzerakzeptanz oder ungeklärte Datenschutzanforderungen. Diese Risiken werden nach Eintrittswahrscheinlichkeit und Auswirkung bewertet, in einer Risikomatrix priorisiert und mit konkreten Maßnahmen versehen. Der gesamte Prozess wird laufend überwacht und aktualisiert.

Welche Risiken gibt es in IT-Projekten?

IT-Projekte bergen typischerweise vier Kategorien von Risiken: Technische Risiken (Schnittstellenprobleme, Performance, Datenqualität), organisatorische Risiken (Nutzerakzeptanz, Scope Creep, Ressourcenengpässe), externe Risiken (Lieferantenverzug, Marktveränderungen) und rechtliche Risiken (Datenschutz, Compliance). Eine vollständige Übersicht bietet unser Artikel zu Projektrisiken identifizieren.

Wie erstelle ich ein Risikoregister?

Ein Risikoregister enthält für jedes Risiko mindestens: eine eindeutige ID, eine Beschreibung, die Bewertung (Eintrittswahrscheinlichkeit und Auswirkung), die gewählte Strategie (Vermeiden, Vermindern, Übertragen oder Akzeptieren), konkrete Maßnahmen, einen Verantwortlichen und den aktuellen Status. Das Register wird bei jeder Statusbesprechung aktualisiert.

Was sind die fünf Schritte im Risikomanagement?

Die fünf Schritte sind: (1) Risiken identifizieren, (2) Risiken bewerten, (3) Risiken priorisieren – typischerweise mit einer Risikomatrix, (4) Maßnahmen planen und umsetzen, (5) Risiken laufend überwachen und steuern. Der Prozess ist zyklisch: Neue Risiken können jederzeit auftreten und durchlaufen dieselben Schritte.

Wie oft sollte man Risiken im Projekt überprüfen?

Mindestens bei jedem Meilenstein und in jeder Projektstatusbesprechung. In agilen Projekten bietet sich das Sprint Review an. Risiken verändern sich im Projektverlauf: Neue kommen hinzu, bestehende werden wahrscheinlicher oder verlieren an Relevanz. Ein fester Rhythmus – etwa alle zwei Wochen – stellt sicher, dass das Risikoregister aktuell bleibt.