Risikoanalyse im Projekt: Was kann schiefgehen – und was tun wir dagegen?

Risikoanalyse im Projekt: Was kann schiefgehen – und was tun wir dagegen?

https://bildung.social/@oerinformatik/

https://oer-informatik.de/risikoanalyse

Risikoanalyse, Risikomanagement, Projektmanagement, Risikomatrix, Risikowert, Risikoliste, Risikostrategien, Gegenmaßnahmen, FMEA, Risikoprioritätszahl, Betriebsrisiken, Geschäftsmodell

tl/dr; (ca. 27 min Lesezeit): Jedes Projekt ist ein Vorhaben mit Unsicherheit. Eine Risikoanalyse sorgt dafür, dass Du mögliche Störungen früh erkennst, statt sie erst als Problem zu erleben. Dieser Artikel zeigt, wie Du Risiken identifizierst, Ursache, Risiko und Auswirkung sauber trennst, Risiken mit Eintrittswahrscheinlichkeit und Auswirkung bewertest, passende Gegenmaßnahmen und Risikostrategien auswählst und alles in einer Risikoliste zusammenführst, die während des ganzen Projekts fortgeschrieben wird. Für digitale Geschäftsmodelle kommen die Risiken des laufenden Betriebs hinzu [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel ist Teil einer Artikelreihe über Projektmanagement in IT-Projekten: Projektorganisation / Stakeholder, Projektumfeld und Akzeptanz / Vorgehensmodelle / Netzplan / Risikoanalyse im Projekt / Übungsaufgaben zur Risikoanalyse

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Als Projektmanagement-Grundlagen kann ich nach Durchlesen des Artikels…

• … erklären, was ein Projektrisiko ist, und es von einem Problem und von einer Chance unterscheiden.

• … für ein konkretes IT-Projekt Risiken aus verschiedenen Bereichen (technisch, organisatorisch, personell, wirtschaftlich, rechtlich) identifizieren und Methoden der Risikoidentifikation nennen.

• … zu einem Risiko eine passende Ursache und eine Auswirkung auf die Projektziele (Termin, Kosten, Leistung) eintragen, ohne die beiden zu verwechseln.

• … aus einem beschriebenen Problem das daraus entstehende Risiko beschreiben.

• … Risiken mit Eintrittswahrscheinlichkeit und Auswirkung bewerten, den Risikowert berechnen und Risiken in einer Risikomatrix einordnen und priorisieren.

• … zu einem Risiko eine geeignete Gegenmaßnahme beschreiben oder zuordnen und dabei vorbeugende Maßnahmen von Notfallmaßnahmen unterscheiden.

• … eine Risikoliste aufbauen, eine vorgegebene Risikoliste ergänzen oder korrigieren und erklären, warum sie im ganzen Projekt fortgeschrieben wird.

Darüber hinaus kann ich als Projektmanagement-Expertenwissen…

• … Maßnahmen den Risikostrategien Vermeiden, Vermindern, Übertragen und Akzeptieren zuordnen und das Restrisiko nach einer Maßnahme beurteilen.

• … Frühwarnindikatoren mit Schwellenwerten für die Überwachung eines Risikos festlegen.

• … für ein digitales Geschäftsmodell Projektrisiken und Risiken des laufenden Betriebs (Ausfall, Datenübertragung, Sensorik, Cyberangriff, Abhängigkeit von Dienstleistern, Nachfrage, Datenschutz) unterscheiden, mit Ursache, Auswirkung und Gegenmaßnahme erläutern und mit Machbarkeitsanalyse und Notfallkonzept verbinden.

• … eine FMEA (Fehlermöglichkeits- und Einflussanalyse) mit der Risikoprioritätszahl durchführen und die Gewichtung begründen.

Dieser Artikel baut auf der Kann-Liste des Artikels Projektorganisation auf.

Ein Projekt ist per Definition neuartig: Es gibt kein Handbuch, in dem jeder Schritt schon erprobt ist. Deshalb weiß zu Beginn niemand genau, ob die Schätzung des Aufwands stimmt, ob die Schnittstelle des Partners so funktioniert wie dokumentiert oder ob die künftigen Nutzer*innen das neue System annehmen. Die Risikoanalyse ist der Teil der Projektplanung, in dem das Team diese Unsicherheiten offen auf den Tisch legt – nicht, um schwarzzumalen, sondern um rechtzeitig handeln zu können. Im Prozessmodell der Projektmanagement-Norm DIN 69901-2 ist „Risiko“ ein eigener Themenbereich (Prozessuntergruppe), der in allen Projektphasen vorkommt; die Leitlinie ISO 31000 beschreibt Risikomanagement allgemein für Organisationen.

Was ist ein Projektrisiko?

Ein Risiko (risk) ist ein mögliches Ereignis oder ein möglicher Zustand, der – wenn er eintritt – die Projektziele gefährdet: Das Projekt wird später fertig, teurer oder liefert nicht die vereinbarte Leistung bzw. Qualität (die drei Ecken des magischen Dreiecks). Im schlimmsten Fall wird das Projekt abgebrochen.

Zwei Merkmale machen ein Risiko aus:

• Es ist unsicher, ob es eintritt (Eintrittswahrscheinlichkeit zwischen 0 und 100 %).

• Es hat eine negative Auswirkung auf mindestens ein Projektziel (Schadensausmaß).

Davon abzugrenzen sind zwei verwandte Begriffe:

Risiko, Problem und Chance

Begriff	Bedeutung	Beispiel
Risiko	kann eintreten, schadet dann dem Projekt	Die Schnittstelle des Zahlungsdienstleisters könnte sich während der Entwicklung ändern.
Problem	ist bereits eingetreten, muss jetzt gelöst werden	Die neue Version der Schnittstelle liefert seit Montag andere Feldnamen; der Bestellprozess bricht ab.
Chance	kann eintreten, nützt dann dem Projekt	Ein Fördermittelprogramm könnte einen Teil der Hardware bezahlen.

Ein eingetretenes Risiko wird zum Problem. Umgekehrt steckt in einem bekannten Problem oft ein Risiko für die Zukunft: Weißt Du zum Beispiel, dass der einzige Netzwerkadministrator im Frühjahr drei Monate in Elternzeit geht, dann ist das Risiko, dass der geplante Austausch der WLAN-Access-Points in dieser Zeit liegen bleibt und sich der Starttermin verschiebt. Chancen werden in der Risikoanalyse häufig mitbetrachtet, etwa in einer SWOT-Analyse (Strengths, Weaknesses, Opportunities, Threats), in der Chancen (opportunities) und Risiken (threats) die äußeren Einflüsse beschreiben.

Ursache, Risiko und Auswirkung: eine Kette

Die wichtigste Denkfigur der Risikoanalyse ist eine Kette aus drei Gliedern:

Ursache (weil …) → Risiko (kann es passieren, dass …) → Auswirkung (mit der Folge, dass …)

• Die Ursache ist der Auslöser oder die Schwachstelle, die das Risiko erst möglich macht. An ihr setzen vorbeugende Maßnahmen an.

• Das Risiko ist das unerwünschte Ereignis selbst.

• Die Auswirkung beschreibt, was dann mit den Projektzielen passiert: Verzögerung, Mehrkosten, Qualitätsmängel, Projektabbruch. An ihr setzen Notfallmaßnahmen an.

Ein Beispiel aus einem App-Projekt:

Ursache, Risiko und Auswirkung an einem Beispiel

Ursache	Risiko	Auswirkung
Die Altdaten der Kundschaft liegen in drei Tabellenkalkulationen mit unterschiedlich benannten Spalten.	Bei der Übernahme in die neue App werden Datensätze falsch zugeordnet oder gehen verloren.	Vor dem Start ist aufwendige Nacharbeit nötig; die App geht später online oder mit lückenhaften Daten.

Typischer Fehler: Ursache und Auswirkung werden vertauscht („Ursache: Das Projekt verzögert sich“) oder das Risiko wird nur mit anderen Worten wiederholt („Risiko: Aufwand unterschätzt – Ursache: falsche Aufwandsschätzung“). Prüfe deshalb jede Zeile mit der Frage: Liegt die Ursache zeitlich vor dem Risiko und die Auswirkung danach?

Risikomanagement als Kreislauf

Die Risikoanalyse ist keine einmalige Übung beim Projektstart. Sie ist Teil eines Kreislaufs, der das ganze Projekt begleitet:

1. Risiken identifizieren: Was kann schiefgehen?

2. Risiken analysieren: Welche Ursache steckt dahinter, welche Auswirkung hätte es?

3. Risiken bewerten: Wie wahrscheinlich ist das Risiko, wie schwer wiegt die Auswirkung? Welche Risiken sind die wichtigsten?

4. Maßnahmen planen: Wie beugen wir vor, was tun wir im Ernstfall, wer ist verantwortlich?

5. Überwachen und fortschreiben: Sind die Maßnahmen umgesetzt und wirksam? Sind neue Risiken hinzugekommen, alte entfallen?

Die Ergebnisse aller Schritte landen in einer Risikoliste (auch Risikoregister, risk register). Die Identifikation von Projektrisiken gehört zu den typischen Aufgaben der Projektleitung; erarbeitet wird die Liste aber am besten gemeinsam mit dem Team und den Stakeholdern. Beim Projektabschluss werden im Abschlussbericht auch die Risiken festgehalten, die unvorhergesehen eingetreten sind – das ist wertvolles Wissen für das nächste Projekt (Lessons Learned).

Risiken identifizieren: Wo lauert die Gefahr?

Niemand findet alle Risiken allein am Schreibtisch. Bewährte Methoden und Quellen sind:

• Brainstorming oder Risiko-Workshop mit dem Projektteam und Fachleuten aus den betroffenen Abteilungen.

• Checklisten mit typischen Risiken (wie die Tabelle weiter unten), die eine Organisation über viele Projekte gesammelt hat.

• Lessons Learned und Abschlussberichte früherer, ähnlicher Projekte.

• Befragung von Expert*innen, etwa der Personen, die das Altsystem betreuen.

• Stakeholder- und Umfeldanalyse: Befürchtungen und Widerstände von Stakeholdern sind häufig Projektrisiken (siehe Artikel Stakeholder, Projektumfeld und Akzeptanz).

• Prüfung der Projektpläne: Vorgänge auf dem kritischen Pfad im Netzplan, knappe Puffer, Abhängigkeiten von Lieferanten.

• SWOT-Analyse: Die Felder „Weaknesses“ und „Threats“ liefern Risiken, „Opportunities“ Chancen.

Damit nichts übersehen wird, hilft es, die Risiken nach Bereichen zu sortieren:

Bereiche, in denen Projektrisiken entstehen

Bereich	typische Risiken
technisch	inkompatible Schnittstellen, Datenverlust bei der Migration, Performance reicht nicht, neue Technik ist unerprobt, Abhängigkeit von externen Diensten
organisatorisch	Aufwand unterschätzt, Personal nicht verfügbar (Krankheit, Parallelprojekte), Wissen bei nur einer Person, unklare Zuständigkeiten, mangelnde Kommunikation
fachlich (Anforderungen)	unklare oder lückenhafte Anforderungen, Anforderungen ändern sich, Fehler in der Anforderungsanalyse
personell und sozial	Widerstand der Beschäftigten (Angst vor Arbeitsplatzverlust, Kontrolle), fehlende Akzeptanz der Nutzer*innen, Einspruch des Betriebs- oder Personalrats
wirtschaftlich	Budget wird überschritten, Lieferant fällt aus oder erhöht Preise, erwarteter Nutzen bleibt aus, Kund*innen können nicht zahlen
rechtlich	Verstoß gegen Datenschutz (DSGVO), Lizenzbedingungen, Vertragsstrafen, fehlende Barrierefreiheit

Ein Risiko ist umso brauchbarer, je konkreter es auf das Projekt bezogen ist. „Technische Probleme“ ist kein Risiko, mit dem jemand arbeiten kann. „Die Schnittstelle des Kassensystems liefert Umsätze nur einmal täglich, die App braucht sie aber minütlich“ schon.

Risiken bewerten: Was ist wirklich wichtig?

Nicht jedes Risiko verdient denselben Aufwand. Zur Bewertung werden für jedes Risiko mindestens zwei Größen geschätzt:

• Eintrittswahrscheinlichkeit W: Wie wahrscheinlich ist es, dass das Risiko eintritt?

• Auswirkung bzw. Schadensausmaß S: Wie stark wären Termin, Kosten oder Leistung betroffen?

Weitere Faktoren, die in die Bewertung einfließen, sind die Ursache (Ist sie bekannt und beeinflussbar?) und die Einflussmöglichkeiten des Projekts (Können wir überhaupt etwas tun, oder liegt das Risiko ganz außerhalb unserer Kontrolle?). Häufig wird auch festgehalten, wann ein Risiko eintreten kann und ob es sich früh erkennen lässt.

Weil sich Wahrscheinlichkeiten und Schäden selten genau beziffern lassen, arbeitet man meist mit Stufen, zum Beispiel von 1 (sehr gering) bis 5 (sehr hoch). Das Produkt ergibt den Risikowert (auch Risikokennzahl):

R = W \cdot S

Mit Stufen von 1 bis 5 liegt der Risikowert zwischen 1 und 25. Die Risikomatrix zeigt alle Kombinationen auf einen Blick; die Farben legen fest, wie mit einem Risiko umgegangen wird:

• rot (15–25): sofort Maßnahmen ergreifen, Projektleitung und Auftraggeber informieren.

• gelb (8–14): Maßnahmen planen und umsetzen, regelmäßig beobachten.

• grün (1–7): beobachten, ggf. bewusst in Kauf nehmen.

Die Grenzen der Bereiche legt jedes Projekt bzw. jede Organisation selbst fest. Zwei Dinge sollten immer gelten:

• Ein Risiko mit katastrophaler Auswirkung (Stufe 5) bekommt immer zumindest einen Notfallplan – auch wenn es sehr unwahrscheinlich ist und rechnerisch im grünen Bereich liegt. Ein Rechenzentrumsbrand ist selten, aber wenn er eintritt, rettet Dich nur ein vorher getestetes Backup.

• Die Stufen sind Schätzungen. Wichtiger als die genaue Zahl ist, dass das Team die Begründung festhält („W = 4, weil die Schnittstelle schon zweimal ohne Ankündigung geändert wurde“) und die Werte bei neuen Informationen anpasst.

Statt Stufen kann man auch eine Wahrscheinlichkeit in Prozent und einen Schaden in Euro schätzen. Das Produkt heißt dann Risikokosten oder erwarteter Schaden – bei 20 % Eintrittswahrscheinlichkeit und 15.000 € Mehrkosten sind das 3.000 €. Dieser Betrag hilft zu entscheiden, wie viel eine Gegenmaßnahme kosten darf und wie hoch eine Reserve im Budget (Risikoreserve) sein sollte.

Gegenmaßnahmen: vorbeugen und vorsorgen

Für jedes wichtige Risiko plant das Team mindestens eine Gegenmaßnahme. Eine Maßnahme passt dann zum Risiko, wenn sie entweder an der Ursache ansetzt (das Risiko wird unwahrscheinlicher) oder an der Auswirkung (der Schaden wird kleiner). Eine Maßnahme wie „besser planen“ ist zu allgemein; sie muss konkret, umsetzbar und einer verantwortlichen Person zugeordnet sein.

Vorbeugende Maßnahmen und Notfallmaßnahmen

Art	setzt an bei …	wirkt auf …	Beispiel (Risiko: Datenverlust bei der Datenmigration)
vorbeugende Maßnahme (präventiv)	der Ursache, bevor das Risiko eintritt	Eintrittswahrscheinlichkeit	Testmigration mit einer Kopie der Altdaten, Abgleich der Datensätze
Notfallmaßnahme (korrektiv, Notfallplan)	der Auswirkung, wenn das Risiko eintritt	Schadensausmaß	vollständiges Backup vor der Migration, festgelegter Weg zurück zum Altsystem (Rollback)

Zu einer guten Notfallmaßnahme gehört ein Auslöser: Ab wann gilt das Risiko als eingetreten, und wer entscheidet dann? („Wenn nach der Migration mehr als 1 % der Datensätze fehlen, entscheidet die Projektleitung bis 12 Uhr über den Rollback.“)

Risikostrategien: Wie gehe ich grundsätzlich mit einem Risiko um?

Die einzelnen Maßnahmen lassen sich vier grundsätzlichen Strategien zuordnen:

Auch nach einer Maßnahme bleibt meistens ein Restrisiko. Das Team bewertet das Risiko deshalb nach der Maßnahme neu („W sinkt von 4 auf 2, der Risikowert von 12 auf 6“) und entscheidet, ob das Restrisiko tragbar ist.

Typische Risiken in IT-Projekten

Viele Risiken tauchen in fast jedem IT-Projekt auf. Die folgende Übersicht eignet sich als Checkliste – sie ersetzt aber nicht den Blick auf das konkrete Projekt.

Typische Risiken in IT-Projekten mit Ursachen, Auswirkungen und Gegenmaßnahmen

Risiko	mögliche Ursache	mögliche Auswirkung	Gegenmaßnahme
unklare Anforderungen	Auftraggeber kennt die eigenen Abläufe nur grob, Fachabteilung wurde nicht befragt	Fehlentwicklung, Nacharbeit, Verzögerung	Ziele und Anforderungen gemeinsam mit den Fachabteilungen erarbeiten und abnehmen lassen, Prototypen bzw. Mockups früh zeigen
Anforderungen ändern sich im Projekt	Abläufe im Betrieb werden während des Projekts umgestellt, Nutzer*innen erkennen erst an der laufenden Software, was ihnen fehlt	fertige Teile müssen umgebaut werden, Zeitplan und Kostenrahmen geraten ins Wanken	kurze Iterationen mit regelmäßiger Vorführung beim Auftraggeber (agiles Vorgehen); bei klassischem Vorgehen ein geregeltes Änderungsmanagement (Change Requests)
Aufwand unterschätzt	keine Erfahrung mit der Fachlichkeit, Schätzung ohne Vergleichswerte	späteres Projektende, Mehrkosten	Schätzung im Team mit Erfahrungswerten, Zeitpuffer, Meilensteine mit Kontrolle
inkompatible Schnittstellen	Datenformate wurden nicht genau abgestimmt, Dokumentation des Partners veraltet	Daten werden falsch übertragen, Nacharbeit verschiebt den Termin und kostet Geld	Schnittstelle früh spezifizieren, Machbarkeitsprüfung bzw. Prototyp (Proof of Concept), Integrationstests
Datenverlust bei der Migration	uneinheitliche Altdaten, fehlender Test der Übernahme	Datensätze fehlen oder sind falsch, Betrieb steht still	Backups, Testmigrationen, Datenbereinigung vor der Übernahme, Parallelbetrieb
mangelnde Kommunikation	verteiltes Team, keine festen Termine, Informationen in privaten Postfächern	Missverständnisse, Entwicklung in die falsche Richtung	regelmäßige Team- und Stakeholder-Meetings, zentrales Projektwerkzeug (Ticketsystem, Wiki)
Personal fällt aus oder ist überlastet	Parallelprojekte, Krankheit, Wissen nur bei einer Person	Stillstand einzelner Arbeitspakete	Termin- und Personaleinsatzplanung mit Vertretung, Wissen dokumentieren, Pair Programming
Widerstand der Beschäftigten	Sorge, dass Aufgaben wegfallen oder die eigene Arbeit überwacht wird	Einführung stockt, das neue System wird umgangen oder nicht genutzt	frühzeitige Einbindung und Information, Schulungen, Betriebs- bzw. Personalrat beteiligen
fehlende Akzeptanz der Nutzer*innen	Bedienung umständlich, Nutzen nicht erkennbar	erwarteter Nutzen bleibt aus	Nutzer*innen in Anforderungen und Tests einbeziehen, Usability-Tests, Projektmarketing
Datenschutzverstoß	personenbezogene Daten ohne Rechtsgrundlage, fehlendes Löschkonzept	Bußgeld, Imageschaden, Nachbesserung	Datenschutzbeauftragte früh beteiligen, Datenschutz durch Technikgestaltung (privacy by design)

Risiken digitaler Geschäftsmodelle: Einführung und Betrieb

Bisher ging es um Risiken, die das Projekt bedrohen: Es wird zu spät fertig, zu teuer oder liefert nicht die vereinbarte Leistung. Baut ein Unternehmen ein digitales Geschäftsmodell auf – etwa eine App mit Abo, eine Plattform, die Sensordaten auswertet, oder einen Online-Dienst für Geschäftskund*innen –, endet die Unsicherheit nicht mit der Abnahme. Dann beginnt der laufende Betrieb, und mit ihm kommen Risiken, die das Geschäft bedrohen: Der Dienst ist nicht erreichbar, Daten gehen verloren, Kund*innen kündigen. Eine Risikoanalyse für ein neues Geschäftsmodell betrachtet deshalb beide Zeiträume.

Projektrisiken und Betriebsrisiken eines digitalen Geschäftsmodells

	Projektrisiko	Betriebsrisiko (Risiko des laufenden Geschäftsmodells)
bedroht …	Termin, Kosten und Leistung des Projekts	Verfügbarkeit, Integrität und Vertraulichkeit des Dienstes, Umsatz, Ruf, Einhaltung gesetzlicher und vertraglicher Pflichten
Zeitraum	bis zum Projektabschluss	solange der Dienst angeboten wird
Beispiel	Die Schnittstelle zum Zahlungsdienstleister ist zum geplanten Start nicht fertig.	Der Zahlungsdienstleister fällt einen Tag aus; Abo-Beiträge werden nicht eingezogen.
verwaltet in …	Risikoliste des Projekts	Risiko- und Notfallmanagement des Unternehmens

Die Grenze ist fließend: Viele Betriebsrisiken lassen sich nur im Projekt wirksam vermindern, weil Redundanz, Datensicherung und Notfallabläufe von Anfang an eingeplant werden müssen. Deshalb gehören sie schon in die Risikoliste des Projekts – mit dem Vermerk, wer sie nach Projektende übernimmt.

Typische Betriebsrisiken digitaler Geschäftsmodelle sind:

Typische Betriebsrisiken digitaler Geschäftsmodelle

Risiko	mögliche Ursache	mögliche Auswirkung	Gegenmaßnahme
Plattform oder Server fällt aus	Hardwaredefekt, fehlgeschlagenes Update, Störung beim Cloud-Anbieter	Dienst nicht erreichbar, Kund*innen können nicht bestellen bzw. nutzen, Vertragsstrafen	redundante Systeme (Cluster, zweites Rechenzentrum), Updates erst in einer Testumgebung, zugesicherte Verfügbarkeit im Vertrag (Service Level Agreement, SLA)
Datenübertragung von Geräten bricht ab	Funkloch, Störung beim Netzbetreiber, Gerät außerhalb der Netzabdeckung	Messwerte fehlen, Nachweise sind lückenhaft	Zwischenspeicherung im Gerät und Nachsenden, sobald wieder Verbindung besteht (store and forward), zweiter Übertragungsweg
Sensoren oder Geräte liefern falsche oder keine Werte	Verschleiß, Materialfehler, leerer Akku, falsche Montage	falsche Entscheidungen, Reklamationen, Austauschkosten	Plausibilitätsprüfung der Werte, Überwachung von Akku und Status mit Warnung, redundante Sensoren bei kritischen Messungen, Montageanleitung und Endkontrolle
Daten werden verschlüsselt oder gestohlen	Cyberangriff (Ransomware, Phishing), ungepatchte Systeme	Dienst steht still, Lösegeldforderung, Datenschutzverletzung mit Meldepflicht	Datensicherungskonzept mit Offline-Kopie, Patch-Management, Zwei-Faktor-Anmeldung, Notfallplan für Sicherheitsvorfälle
Abhängigkeit von einem Dienstleister	Anbieter erhöht Preise, ändert die Schnittstelle oder stellt den Dienst ein	Mehrkosten, Nacharbeit, im Extremfall Ende des Angebots	Verträge mit Ankündigungsfristen für Änderungen, Daten exportierbar halten, Alternativanbieter prüfen
erwartete Nachfrage bleibt aus	Zahlungsbereitschaft überschätzt, Wettbewerber mit günstigerem Angebot	Kosten werden nicht gedeckt, das Geschäftsmodell scheitert	Markt- und Preisanalyse, Pilotphase mit echter Kundschaft, Kennzahlen wie Neuabschlüsse und Kündigungsquote früh beobachten
Verstoß gegen Datenschutz oder Nachweispflichten	Standortdaten ohne Rechtsgrundlage, fehlendes Löschkonzept, Protokolle nicht revisionssicher	Bußgeld, Vertrauensverlust, Nachbesserung	Datenschutz-Folgenabschätzung, Datenschutz durch Technikgestaltung (privacy by design), revisionssichere Archivierung

Für Betriebsrisiken mit hoher Auswirkung reicht eine einzelne Maßnahme selten. Unternehmen fassen die Notfallmaßnahmen dann in einem Notfallkonzept zusammen: Welche Geschäftsprozesse sind kritisch, wie lange dürfen sie höchstens ausfallen, wer entscheidet im Ernstfall, und wie wird ein Notbetrieb hergestellt? Der BSI-Standard 200-4 beschreibt dieses Business Continuity Management (BCM) ausführlich; technische Maßnahmen findest Du in den Artikeln Hochverfügbarkeit und Datensicherung.

Vorsicht beim Übertragen von Betriebsrisiken: Eine Versicherung (etwa eine Cyberversicherung) oder ein Vertrag mit einem Dienstleister übernimmt meist nur die finanziellen Folgen. Der Imageschaden, verärgerte Kund*innen und gesetzliche Pflichten bleiben beim Unternehmen – eine Verletzung des Schutzes personenbezogener Daten muss es zum Beispiel in der Regel binnen 72 Stunden der Aufsichtsbehörde melden (Art. 33 DSGVO). Übertragen ersetzt deshalb weder vorbeugende Maßnahmen noch einen Notfallplan.

Zwei Werkzeuge der Projektplanung helfen besonders, Risiken eines neuen Geschäftsmodells früh zu erkennen und zu vermindern:

• Die Machbarkeitsanalyse (siehe Projektorganisation) prüft die technische, wirtschaftliche, organisatorische und rechtliche Machbarkeit. Jede Unsicherheit, die sie nicht ausräumen kann, ist ein Risiko für die Risikoliste. Ein Proof of Concept (Machbarkeitsnachweis) oder ein Prototyp klärt technische Fragen unter echten Bedingungen, bevor viel Geld fließt.

• Ein agiles Vorgehen mit kurzen Iterationen und Reviews gemeinsam mit der Kundschaft (siehe Vorgehensmodelle) vermindert das Risiko, an sich ändernden Anforderungen vorbeizuentwickeln. Es ersetzt aber keine Risikoanalyse: Auch in Scrum werden Risiken in Reviews und Retrospektiven besprochen und im Backlog berücksichtigt.

Die Risikoliste: alles an einem Ort

Die Risikoliste fasst die Ergebnisse zusammen. Für jedes Risiko enthält sie typischerweise:

• eine Nummer und eine kurze, konkrete Beschreibung,

• Ursache und Auswirkung,

• die Bewertung (W, S, Risikowert) und damit die Priorität,

• Maßnahmen (vorbeugend und für den Notfall) mit Verantwortlichen und Termin,

• einen Frühwarnindikator, an dem man erkennt, dass sich das Risiko anbahnt,

• den Status (offen, Maßnahme läuft, eingetreten, erledigt) und das Datum der letzten Prüfung.

Ein Beispiel: digitale Essensbestellung in einer Betriebskantine

Eine Spedition mit 300 Beschäftigten will in ihrer Kantine Bestellzettel und Bargeld abschaffen. Künftig sollen die Beschäftigten ihr Mittagessen per App vorbestellen und mit dem Dienstausweis bezahlen; die Kantine erhält die Bestellmengen am Vortag. Ein Auszug aus der Risikoliste beim Projektstart:

Auszug aus einer Risikoliste für eine digitale Kantinenbestellung (W, S: Stufen 1–5)

Nr.	Risiko	Ursache	Auswirkung	W	S	R	Maßnahme (Verantwortung)	Frühwarnindikator
1	Fahrer*innen im Schichtdienst nutzen die App nicht.	kein Diensthandy, Bestellschluss passt nicht zu den Schichten	Kantine plant mit falschen Mengen, Lebensmittel werden weggeworfen, Nutzen bleibt aus	4	4	16	Bestellterminal im Aufenthaltsraum, Bestellschluss mit dem Schichtplan abstimmen (Projektleitung)	Anteil der Vorbestellungen in der Pilotwoche unter 50 %
2	Die Bezahlfunktion lässt sich nicht an das Ausweissystem anbinden.	Hersteller des Ausweissystems stellt keine offene Schnittstelle bereit	Verzögerung, Zusatzkosten für eine eigene Bezahllösung	2	5	10	Machbarkeitsprüfung mit dem Hersteller vor Vertragsschluss (Entwicklung); Notfall: Bezahlung vorerst weiter bar bzw. über monatliche Sammelabrechnung, bis eine eigene Bezahllösung steht (Kantinenleitung)	Hersteller hat zwei Wochen nach Anfrage keine Schnittstellenbeschreibung geliefert
3	Der Betriebsrat stimmt nicht zu.	Bestelldaten könnten zur Kontrolle von Pausenzeiten genutzt werden	Einführung verzögert sich oder scheitert	3	4	12	Betriebsrat vor Projektstart informieren, Auswertungen nur anonym, Betriebsvereinbarung (Personalabteilung)	Rückfragen oder Einwände in der Sitzung des Betriebsrats
4	Die Kantinenkasse fällt aus.	Netzwerkstörung, Serverausfall	Beschäftigte können nicht bezahlen, Warteschlangen	1	3	3	akzeptieren; Notfall: Ausgabe mit Strichliste, nachträgliche Abbuchung (Kantinenleitung)	–

Die Liste zeigt die Reihenfolge der Bearbeitung: Risiko 1 (rot) zuerst, dann 3 und 2 (gelb). Risiko 4 wird bewusst akzeptiert, bekommt aber eine einfache Notfallregel. In jeder Statussitzung schaut das Team auf die Frühwarnindikatoren und passt die Liste an.

Für Fortgeschrittene: die FMEA

Vor allem in der Prozess- und Produktentwicklung wird die Fehlermöglichkeits- und Einflussanalyse (FMEA, Failure Mode and Effects Analysis, Norm DIN EN IEC 60812) eingesetzt. Sie betrachtet nicht Projektrisiken allgemein, sondern mögliche Fehler eines Prozesses oder Produkts – mit Fehlerfolge und Fehlerursache – und bewertet jeden Fehler mit drei Kennzahlen, jeweils von 1 bis 10:

• Bedeutung B: Wie schwer wiegt die Fehlerfolge? (1 = kaum wahrnehmbar, 10 = z. B. Gesetzesverstoß oder Gefährdung)

• Auftreten A: Wie wahrscheinlich tritt der Fehler auf? (1 = unwahrscheinlich, 10 = ständig)

• Entdeckung E: Wie wahrscheinlich wird der Fehler entdeckt, bevor er Schaden anrichtet? (1 = fast sicher entdeckt, 10 = kaum zu entdecken) – Achtung, die Skala läuft hier umgekehrt.

Das Produkt ist die Risikoprioritätszahl:

RPZ = B \cdot A \cdot E \qquad (1 \le RPZ \le 1000)

Fehler mit hoher RPZ (oder sehr hoher Bedeutung) werden zuerst durch Maßnahmen entschärft. Danach wird neu bewertet; die RPZ muss sinken. Die FMEA lohnt sich, weil Fehler früh und systematisch erkannt werden, bevor sie teuer werden, und weil das Wissen der Beteiligten dokumentiert wird. Bei der Begründung der Zahlen kommt es darauf an, jede Kennzahl mit der Situation zu belegen („Entdeckung 2, weil das Formular Pflichtfelder vor dem Absenden prüft“).

Risiken sauber formulieren

Ob in der Projektarbeit oder beim Üben: Eine Risikoanalyse überzeugt, wenn jede Zeile eine stimmige Kette bildet. Drei Prüffragen helfen dabei:

• Liegt die Ursache vor dem Risiko? Die Ursache ist ein Umstand, der heute schon besteht; das Risiko ist das unsichere Ereignis, das daraus folgen kann.

• Trifft die Auswirkung ein Projektziel? Benenne, ob Termin, Kosten, Qualität oder Umfang betroffen sind – „es gibt Probleme“ reicht nicht.

• Wirkt die Gegenmaßnahme auf genau dieses Risiko? Sie senkt die Eintrittswahrscheinlichkeit, mildert die Auswirkung oder legt fest, was bei Eintritt passiert. Eine allgemeine Maßnahme wie „gut planen“ wirkt auf kein bestimmtes Risiko.

Sind schon Risiken genannt, ergänze neue, statt bekannte mit anderen Worten zu wiederholen. Bei digitalen Geschäftsmodellen gehören auch die Risiken des laufenden Betriebs dazu.

Beim Operator „beschreiben“ reicht ein Stichwort nicht: Formuliere ganze Sätze mit Bezug zur Situation, zum Beispiel „Weil die Nutzer*innen …, kann es passieren, dass …; dadurch …“. Beim Operator „identifizieren“ genügt eine knappe, aber konkrete Benennung. Beim Operator „erläutern“ wiegen Risiko und Gegenmaßnahme meist deutlich schwerer als die Ursache: Beschreibe beim Risiko, was konkret passieren kann und welches Ziel es trifft, und begründe bei der Gegenmaßnahme, warum sie wirkt.

Leitfragen

1. Woran unterscheidest Du ein Risiko von einem Problem und von einer Chance? Antwort

Ein Risiko ist ein mögliches Ereignis, das unsicher ist und bei Eintritt mindestens ein Projektziel gefährdet. Ein Problem ist dagegen bereits eingetreten und muss jetzt gelöst werden, und eine Chance ist ebenfalls unsicher, nützt dem Projekt aber, wenn sie eintritt – siehe Abschnitt „Was ist ein Projektrisiko?“.

2. Mit welchen Methoden und in welchen Bereichen suchst Du nach Risiken eines IT-Projekts? Antwort

Bewährt sind Brainstorming oder Risiko-Workshops, Checklisten, Lessons Learned früherer Projekte, Befragung von Expert*innen, Stakeholder- und Umfeldanalyse, die Prüfung der Projektpläne (z. B. kritischer Pfad) und die SWOT-Analyse. Damit nichts übersehen wird, sortierst Du nach Bereichen: technisch, organisatorisch, fachlich (Anforderungen), personell und sozial, wirtschaftlich und rechtlich – siehe Abschnitt „Risiken identifizieren: Wo lauert die Gefahr?“.

3. Wie prüfst Du, ob Ursache und Auswirkung eines Risikos richtig zugeordnet sind, und welche Projektziele kann eine Auswirkung betreffen? Antwort

Du prüfst die Kette „Ursache (weil …) → Risiko (kann es passieren, dass …) → Auswirkung (mit der Folge, dass …)“ mit der Frage, ob die Ursache zeitlich vor dem Risiko und die Auswirkung danach liegt; die Ursache darf das Risiko auch nicht nur mit anderen Worten wiederholen. Die Auswirkung betrifft die Projektziele Termin, Kosten oder Leistung bzw. Qualität, im Extremfall droht der Projektabbruch – siehe Abschnitt „Ursache, Risiko und Auswirkung: eine Kette“.

4. Mit welchen Faktoren wird ein Risiko bewertet, wie berechnest Du den Risikowert, und was zeigt eine Risikomatrix? Antwort

Bewertet wird mindestens mit Eintrittswahrscheinlichkeit W und Auswirkung (Schadensausmaß) S, ergänzt um Ursache und Einflussmöglichkeiten des Projekts. Der Risikowert ist R = W \cdot S, bei Stufen von 1 bis 5 also zwischen 1 und 25. Die Risikomatrix zeigt alle Kombinationen auf einen Blick und legt mit farbigen Bereichen (rot, gelb, grün) fest, wie dringend mit einem Risiko umzugehen ist – siehe Abschnitt „Risiken bewerten: Was ist wirklich wichtig?“.

5. Wann ist eine Gegenmaßnahme vorbeugend, wann eine Notfallmaßnahme, und woran erkennst Du, dass sie zum Risiko passt? Antwort

Eine vorbeugende Maßnahme setzt an der Ursache an, bevor das Risiko eintritt, und senkt die Eintrittswahrscheinlichkeit (z. B. Testmigration). Eine Notfallmaßnahme setzt an der Auswirkung an, wenn das Risiko eingetreten ist, und verringert den Schaden (z. B. Backup und Rollback). Eine Maßnahme passt, wenn sie an Ursache oder Auswirkung genau dieses Risikos ansetzt und konkret, umsetzbar und einer verantwortlichen Person zugeordnet ist – siehe Abschnitt „Gegenmaßnahmen: vorbeugen und vorsorgen“.

6. Welche vier Risikostrategien gibt es, und was versteht man unter dem Restrisiko? Antwort

Die vier Strategien sind Vermeiden (Ursache beseitigen), Vermindern (Wahrscheinlichkeit oder Auswirkung verringern), Übertragen (Folgen trägt jemand anderes, z. B. Versicherung) und Akzeptieren (bewusst in Kauf nehmen). Das Restrisiko ist das Risiko, das nach einer Maßnahme meist noch bleibt; es wird neu bewertet, und das Team entscheidet, ob es tragbar ist – siehe Abschnitt „Risikostrategien: Wie gehe ich grundsätzlich mit einem Risiko um?“.

7. Welche Angaben gehören in eine Risikoliste, und warum wird sie während des ganzen Projekts fortgeschrieben? Antwort

In die Risikoliste gehören Nummer und konkrete Beschreibung, Ursache und Auswirkung, Bewertung (W, S, Risikowert), vorbeugende und Notfallmaßnahmen mit Verantwortlichen und Termin, ein Frühwarnindikator sowie Status und Datum der letzten Prüfung. Sie wird fortgeschrieben, weil Risikomanagement ein Kreislauf ist: Maßnahmen müssen überwacht, neue Risiken ergänzt und erledigte geschlossen werden – siehe Abschnitt „Die Risikoliste: alles an einem Ort“ und Abschnitt „Risikomanagement als Kreislauf“.

8. Wie berechnest Du die Risikoprioritätszahl einer FMEA, und was bedeutet ein niedriger Wert bei der Entdeckung? Antwort

Die Risikoprioritätszahl ist RPZ = B \cdot A \cdot E aus Bedeutung, Auftreten und Entdeckung, jeweils von 1 bis 10, also zwischen 1 und 1000. Bei der Entdeckung läuft die Skala umgekehrt: Ein niedriger Wert bedeutet, dass der Fehler fast sicher entdeckt wird, bevor er Schaden anrichtet – siehe Abschnitt „Für Fortgeschrittene: die FMEA“.

9. Wodurch unterscheiden sich Projektrisiken von Risiken des laufenden Betriebs eines digitalen Geschäftsmodells, und wie gehst Du mit Betriebsrisiken um? Antwort

Projektrisiken gefährden Termin, Kosten und Leistung des Projekts und enden mit dem Projektabschluss. Betriebsrisiken gefährden den laufenden Dienst (Verfügbarkeit, Daten, Umsatz, Ruf, Pflichten), solange er angeboten wird – zum Beispiel Serverausfall, abgebrochene Datenübertragung, defekte Sensoren, Cyberangriffe, Abhängigkeit von Dienstleistern, ausbleibende Nachfrage oder Datenschutzverstöße. Sie werden schon im Projekt mit Redundanz, Datensicherung und Notfallabläufen vermindert und danach im Risiko- und Notfallmanagement des Unternehmens weitergeführt; Versicherungen übertragen nur die finanziellen Folgen – siehe Abschnitt „Risiken digitaler Geschäftsmodelle: Einführung und Betrieb“.

Links und weitere Informationen

• zum Üben: Übungsaufgaben zur Risikoanalyse im Projekt

• verwandte Artikel: Projektorganisation, Stakeholder, Projektumfeld und Akzeptanz, Vorgehensmodelle, Netzplan, Hochverfügbarkeit und Datensicherung

• zur Vertiefung: Projektmanagement-Normen DIN 69901-1 bis -5 (Risiko als Prozessuntergruppe im Prozessmodell), ISO 31000 (Risikomanagement – Leitlinien), DIN EN IEC 60812 (FMEA) und BSI-Standard 200-4 (Business Continuity Management)

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Risikoanalyse im Projekt: Was kann schiefgehen – und was tun wir dagegen?” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/risikoanalyse veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/projekt/projektmanagement. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]