Inhaltsverzeichnis
Eine Risikoanalyse zeigt, welche Risiken dein Projekt gefährden könnten und wie du ihnen begegnest. In diesem Artikel erfährst du, wie du Risiken erkennst, bewertest und dokumentierst. Du bekommst ein konkretes Risikoregister zum Übernehmen und ein vollständiges Beispiel für IT-Projekte.
Risikoanalyse Projektarbeit in drei Schritten: 1. Risiken identifizieren (Was kann schiefgehen?), 2. Risiken bewerten (Wahrscheinlichkeit × Auswirkung in der Matrix), 3. Maßnahmen planen (präventiv und reaktiv). Das Ergebnis dokumentierst du im Risikoregister (Tabelle) und in der Risikomatrix (Visualisierung).
Was ist eine Risikoanalyse?
Eine Risikoanalyse ist ein systematisches Verfahren, um potenzielle Probleme in einem Projekt frühzeitig zu erkennen und zu bewerten. Sie beantwortet drei zentrale Fragen: Was kann schiefgehen? Wie wahrscheinlich ist das? Und wie schlimm wäre es, wenn es passiert?
Die Risikoanalyse ist ein Teil des Risikomanagements. Während die Analyse Risiken identifiziert, bewertet und Maßnahmen plant, umfasst Risikomanagement zusätzlich das fortlaufende Monitoring und die Aktualisierung während des Projekts. Für deine Projektarbeit dokumentierst du beides: die initiale Analyse in der Planungsphase und den Umgang mit Risiken während der Durchführung.
Risiko vs Problem: Der wichtige Unterschied
Ein Risiko ist ein mögliches Ereignis, das noch nicht eingetreten ist. Du identifizierst es präventiv und planst Maßnahmen für den Fall, dass es eintritt. Ein Problem (auch Issue genannt) ist ein Risiko, das bereits eingetreten ist und jetzt aktiv gelöst werden muss.
In der Dokumentation ist diese Unterscheidung wichtig. Risiken gehören in die Planungsphase: „Folgende Risiken wurden identifiziert..." Probleme gehören in die Durchführungsphase: „Während der Implementierung trat folgendes Problem auf..." Im Fazit und der Reflexion vergleichst du dann: Welche Risiken sind eingetreten? Welche nicht? Wie wirksam waren die Maßnahmen?
Das Risikoregister: So sieht die Tabelle aus
Das Risikoregister ist eine Tabelle, in der du alle identifizierten Risiken mit Bewertung und Maßnahmen dokumentierst. Es ist das zentrale Artefakt deiner Risikoanalyse. Die folgenden Spalten haben sich in der Praxis bewährt.
ID: Eindeutige Nummer (R01, R02, ...) für Verweise im Text.
Risikobeschreibung: Was kann passieren? Konkret und verständlich.
Kategorie: Technisch, organisatorisch, zeitlich oder Ressourcen.
Ursache: Warum könnte das Risiko eintreten?
Eintrittswahrscheinlichkeit (EW): 1 = niedrig, 2 = mittel, 3 = hoch.
Auswirkung (AW): 1 = gering, 2 = mittel, 3 = hoch.
Risikozahl: EW × AW (1–9). Priorisierung: grün (1–2), gelb (3–4), rot (6–9).
Trigger/Frühwarnsignal: Woran erkennst du, dass das Risiko eintritt?
Präventive Maßnahme: Was tust du, damit das Risiko nicht eintritt?
Notfallplan (reaktiv): Was tust du, wenn das Risiko eintritt?
Verantwortliche Person: Wer überwacht das Risiko und setzt Maßnahmen um?
Status: Offen, in Bearbeitung, eingetreten, geschlossen.
Letztes Review: Datum der letzten Überprüfung (z. B. KW 3, 15.01.2026).
Die folgende Tabellenvorlage kannst du direkt in Word oder Excel übernehmen. Die erste Zeile enthält die Spaltenüberschriften, die zweite Zeile ein Beispiel zum Ausfüllen.
Semikolongetrennt für deutsches Excel. Kopiere beide Zeilen und füge sie in Zelle A1 ein. Falls dein Text selbst Semikolons enthält, setze das Feld in Anführungszeichen oder ersetze sie durch Kommas.
ID;Risikobeschreibung;Kategorie ;Ursache ;EW;AW;Risikozahl ;Trigger;Präventive Maßnahme;Notfall Plan;Verantwortliche Person;Status;Letztes Review
R01;API-Dokumentation unvollständig;Technisch;Legacy-System;2;3;6;API-Test schlägt fehl;Doku anfordern und Test in Woche 2;CSV-Import als Fallback;Projektleiter;Offen;KW 2
Je nach Vorgaben deiner IHK, deines Prüfers oder Unternehmens kannst du Spalten weglassen oder ergänzen. Die Kernelemente (Beschreibung, Bewertung, Maßnahme) sollten immer enthalten sein. Frag im Zweifel nach, welche Detailtiefe erwartet wird.
Risiken systematisch identifizieren
Am Anfang steht die Frage: Was kann in meinem Projekt schiefgehen? Gehe systematisch die vier Risikokategorien durch und überlege für jede, welche konkreten Szenarien dein Projekt betreffen. Ein Brainstorming zu Beginn des Projekts ist ein guter Ausgangspunkt. Gehe die Phasen aus deinem Zeitplan durch und frag erfahrene Kollegen nach typischen Stolperfallen.
Technische Risiken: Software funktioniert nicht wie erwartet, Schnittstellen sind inkompatibel, Testumgebung steht nicht rechtzeitig bereit, Performance-Probleme unter Last.
Organisatorische Risiken: Ansprechpartner ist nicht erreichbar, Freigaben verzögern sich, Anforderungen ändern sich während des Projekts, unklare Zuständigkeiten.
Zeitliche Risiken: Aufwand wird unterschätzt, parallele Aufgaben im Betrieb binden Kapazitäten, Krankheit oder Urlaub von Beteiligten, Abhängigkeit von externen Lieferterminen.
Ressourcen: Budget wird gekürzt, benötigte Hardware ist nicht verfügbar, fehlendes Know-how, Lizenzprobleme bei Software.
Risiken bewerten: Die Risikomatrix
Die Risikomatrix visualisiert, welche Risiken kritisch sind. Auf der X-Achse steht die Eintrittswahrscheinlichkeit, auf der Y-Achse die Auswirkung. Die Position in der Matrix zeigt die Priorität: Risiken im roten Bereich (oben rechts) erfordern sofortige Maßnahmen, Risiken im grünen Bereich (unten links) kannst du beobachten.
Für Projektarbeiten empfiehlt sich eine 3×3-Matrix (Skala 1–3). Sie ist übersichtlich und zwingt zu klaren Entscheidungen. Eine 5×5-Matrix bietet mehr Differenzierung, ist aber oft zu feingranular für den Projektumfang. Wichtig ist, dass du die gewählte Skala konsistent verwendest und die Stufen konkret definierst.
Bewertungsskala konkret definieren
Damit die Bewertung nicht willkürlich wirkt, definierst du vorab, was die Stufen bedeuten. Die folgenden Definitionen sind Beispielwerte, die du an dein Projekt, deine IHK oder Unternehmensvorgaben anpassen kannst. Entscheidend ist, dass du die gewählte Skala in der Dokumentation transparent machst und konsistent anwendest.
1 = Niedrig (selten): Das Risiko tritt erfahrungsgemäß selten ein. Keine konkreten Hinweise aus dem Projektumfeld oder vergleichbaren Vorhaben.
2 = Mittel (gelegentlich): Das Risiko tritt gelegentlich ein. Vergleichbare Probleme sind aus anderen Projekten bekannt, aber nicht die Regel.
3 = Hoch (häufig): Das Risiko tritt erfahrungsgemäß häufig ein. Erfahrungswerte, aktuelle Rahmenbedingungen oder konkrete Warnsignale deuten darauf hin.
1 = Gering: Termin verzögert sich um maximal 1–2 Tage. Qualität oder Funktionsumfang nicht wesentlich betroffen. Mehraufwand unter 10 % des geplanten Aufwands.
2 = Mittel: Termin verzögert sich um mehrere Tage bis eine Woche. Teilziele müssen angepasst werden. Mehraufwand 10–30 % des geplanten Aufwands.
3 = Hoch: Projektziel ist gefährdet, Abgabetermin nicht haltbar oder wesentliche Funktionen fallen weg. Mehraufwand über 30 % oder Projekt muss neu geplant werden.
Die konkreten Tage und Prozentwerte sind Richtwerte. Passe sie an deinen Projektumfang an.
Risikozahl = EW × AW. Bei einer 3×3-Matrix: 1–2 = geringes Risiko (grün, beobachten), 3–4 = mittleres Risiko (gelb, Maßnahmen planen), 6–9 = hohes Risiko (rot, sofort handeln). Die Risikozahl ist ein Hilfsmittel zur Priorisierung, ersetzt aber nicht die inhaltliche Einschätzung.
Maßnahmen planen und dokumentieren
Für jedes Risiko mit mittlerer oder hoher Risikozahl definierst du Maßnahmen. Unterscheide zwischen präventiven Maßnahmen (verhindern, dass das Risiko eintritt) und reaktiven Maßnahmen (Notfallplan, wenn es eintritt). Nicht jedes Risiko braucht beides, aber du solltest bewusst entscheiden.
Du änderst den Projektplan so, dass das Risiko gar nicht erst entstehen kann.
Beispiel: Statt eine unbekannte Technologie einzusetzen, wählst du eine bewährte Alternative, mit der du bereits Erfahrung hast.
Du akzeptierst das Risiko, reduzierst aber Wahrscheinlichkeit oder Auswirkung.
Beispiel: Du planst einen Zeitpuffer von 3 Tagen ein für den Fall, dass die Integration länger dauert als geplant. Falls das Risiko eintritt, ist der Termin trotzdem haltbar.
Du nimmst das Risiko bewusst in Kauf, weil Gegenmaßnahmen unverhältnismäßig wären.
Beispiel: Ein Stromausfall im Rechenzentrum ist theoretisch möglich, aber so unwahrscheinlich und außerhalb deiner Kontrolle, dass du keine Maßnahmen planst. Dokumentiere die bewusste Entscheidung.
Ein gut formuliertes Risiko enthält: Ereignis (Was kann passieren?) + Ursache (Warum?) + Bewertung (EW × AW = Risikozahl) + Trigger (Woran erkenne ich es?) + Präventive Maßnahme + Notfallplan + Verantwortliche Person + Letztes Review. Wenn eines fehlt, ergänze es, bevor du das Risiko als „dokumentiert" betrachtest.
Risiken überwachen: Monitoring im Projekt
Die Risikoanalyse ist kein einmaliges Dokument, das du in der Planungsphase erstellst und dann vergisst. Während des Projekts überwachst du die identifizierten Risiken und aktualisierst das Risikoregister. Das gehört zum Risikomanagement und zeigt dem Prüfungsausschuss, dass du professionell arbeitest.
Wann: Bei jedem Meilenstein oder wöchentlich bei kurzen Projekten. Plane feste Termine im Zeitplan ein.
Neue Risiken: Sind während der Arbeit neue Risiken aufgetaucht, die du ergänzen musst?
Bewertung aktuell: Hat sich die Einschätzung geändert? Ist ein Risiko wahrscheinlicher oder unwahrscheinlicher geworden?
Risiko eingetreten: Ist ein Risiko zum Problem geworden? Dann ändere den Status auf „eingetreten" und dokumentiere die Reaktion.
Maßnahmen wirksam: Haben präventive Maßnahmen gegriffen? Konntest du ein Risiko entschärfen?
Risikoanalyse in der Dokumentation
Die Risikoanalyse taucht an mehreren Stellen deiner Projektarbeit auf: in der Planungsphase, während der Durchführung und im Fazit. Das vollständige Risikoregister und die Risikomatrix gehören in den Anhang. Im Hauptteil beschreibst du dein Vorgehen und die wichtigsten Risiken. Die folgenden Textbausteine kannst du direkt übernehmen und anpassen.
„Vor Projektbeginn wurde eine Risikoanalyse durchgeführt. Dabei wurden [Anzahl] potenzielle Risiken in den Kategorien Technik, Organisation, Zeit und Ressourcen identifiziert. Die Bewertung erfolgte anhand einer 3×3-Matrix nach Eintrittswahrscheinlichkeit und Auswirkung. Als kritische Risiken mit Risikozahl 6 oder höher wurden [Risiko 1] und [Risiko 2] eingestuft. Für diese wurden präventive Maßnahmen und Notfallpläne definiert. Das vollständige Risikoregister findet sich in Anhang [X]."
„Vor Projektbeginn wurde eine Risikoanalyse durchgeführt. Dabei wurden acht potenzielle Risiken in den Kategorien Technik, Organisation, Zeit und Ressourcen identifiziert. Die Bewertung erfolgte anhand einer 3×3-Matrix nach Eintrittswahrscheinlichkeit und Auswirkung. Als kritische Risiken mit Risikozahl 6 oder höher wurden die unvollständige API-Dokumentation (R01) und mögliche Anforderungsänderungen (R02) eingestuft. Für diese wurden präventive Maßnahmen und Notfallpläne definiert. Das vollständige Risikoregister findet sich in Anhang B."
„Während der Implementierungsphase wurde das Risikoregister regelmäßig überprüft. Das Risiko [R0X: Beschreibung] trat in Projektwoche [Y] ein: [konkretes Problem]. Durch den vorbereiteten Notfallplan konnte das Problem innerhalb von [Zeitraum] gelöst werden, indem [Maßnahme]. Der Zeitplan wurde um [X Tage] angepasst."
„Während der Implementierungsphase wurde das Risikoregister wöchentlich überprüft. Das Risiko R02 (Anforderungsänderungen durch Fachabteilung) trat in Projektwoche 4 ein: Die Fachabteilung forderte kurzfristig eine zusätzliche Exportfunktion. Durch den vorbereiteten Notfallplan konnte das Problem innerhalb von zwei Tagen gelöst werden, indem die Funktion für Phase 2 eingeplant und stattdessen ein manueller Workaround dokumentiert wurde. Der Zeitplan wurde um einen Tag angepasst."
„Von den [Anzahl] identifizierten Risiken ist [Anzahl] eingetreten. Die präventiven Maßnahmen für [Risiko] haben sich als wirksam erwiesen, da [Begründung]. Das Risiko [R0X] wurde unterschätzt; hier wäre eine frühere [Maßnahme] sinnvoll gewesen. Für zukünftige Projekte nehme ich mit, dass [Learning]."
„Von den acht identifizierten Risiken ist eines eingetreten. Die präventiven Maßnahmen für das Schnittstellenrisiko (R01) haben sich als wirksam erwiesen, da der frühzeitige API-Test in Woche 2 Kompatibilitätsprobleme rechtzeitig aufdeckte. Das Risiko R02 (Anforderungsänderungen) wurde unterschätzt; hier wäre eine engere Abstimmung mit der Fachabteilung in der Konzeptphase sinnvoll gewesen. Für zukünftige Projekte nehme ich mit, dass schriftlich fixierte Anforderungen allein nicht ausreichen und regelmäßige Feedback-Runden eingeplant werden sollten."
Beispiel: Vollständiges Risikoregister
Hier siehst du ein konkretes Beispiel für ein IT-Projekt (Webanwendung zur Arbeitszeiterfassung). Das erste Risiko ist vollständig ausgearbeitet mit allen Spalten, damit du das Format direkt übernehmen kannst.
Kategorie: Technisch
Beschreibung: Die REST-API des bestehenden Zeiterfassungssystems ist unzureichend dokumentiert. Die Integration könnte länger dauern oder fehlschlagen.
Ursache: Legacy-System ohne aktuelle Dokumentation, Ansprechpartner beim Hersteller schwer erreichbar.
Bewertung: EW = 2 (mittel) | AW = 3 (hoch) | Risikozahl = 6
Trigger: Erste API-Tests schlagen fehl. Dokumentation enthält veraltete Endpunkte.
Präventive Maßnahme: Schnittstellentest in Projektwoche 2 einplanen (vor Hauptentwicklung). Dokumentation und Testdaten frühzeitig beim Hersteller anfordern.
Notfallplan: Falls Integration nicht möglich: CSV-Import als Fallback implementieren (Mehraufwand ca. 2 Tage).
Verantwortliche Person: Projektleiter (eigene Person)
Status: Offen
Letztes Review: KW 2 (nächstes: KW 4)
R02: Anforderungsänderungen durch Fachabteilung
Kategorie: Organisatorisch | EW = 3 | AW = 2 | Risikozahl = 6
Trigger: Fachabteilung meldet „noch eine kleine Änderung" nach Freigabe.
Präventiv: Anforderungen schriftlich fixieren, Änderungen nur über Change-Request.
Notfall: Priorisierung mit Auftraggeber, ggf. Funktionen in Phase 2 verschieben.
R03: Krankheit während kritischer Phase
Kategorie: Zeitlich | EW = 1 | AW = 3 | Risikozahl = 3
Trigger: Erste Krankheitssymptome in kritischer Projektphase.
Präventiv: Puffer von 3 Tagen im Zeitplan. Kritische Arbeiten nicht auf letzte Woche legen.
Notfall: Auftraggeber informieren, Termin ggf. verschieben.
R04: Testumgebung nicht rechtzeitig verfügbar
Kategorie: Ressourcen | EW = 2 | AW = 2 | Risikozahl = 4
Trigger: Keine Bestätigung für Testserver bis Ende Woche 1.
Präventiv: Testserver in Woche 1 anfordern, Bestätigung einholen.
Notfall: Lokale Entwicklungsumgebung als Ersatz nutzen.
Typische Fehler vermeiden
- Zu viele oder zu wenige Risiken: Eine Liste mit 20 Risiken zeigt nicht, dass du priorisieren kannst. Zwei Risiken wirken oberflächlich. Orientiere dich an der Faustregel: So viele Risiken, bis alle kritischen Bereiche abgedeckt sind, aber ohne Redundanz.
- Nur präventive Maßnahmen: Was machst du, wenn das Risiko trotz Maßnahmen eintritt? Ein Notfallplan (Plan B) zeigt, dass du wirklich durchdacht hast. Das gilt vor allem für Risiken mit hoher Auswirkung.
- Bewertung ohne Begründung: Warum ist ein Risiko „hoch"? Ohne kurze Erklärung wirkt die Einschätzung willkürlich. „Die Wahrscheinlichkeit wird als mittel eingestuft, da vergleichbare Schnittstellenprobleme in früheren Projekten aufgetreten sind" ist nachvollziehbar.
- Risikoanalyse nie aktualisiert: Wenn du im Fazit schreibst „Die Risikoanalyse wurde erstellt", aber keinen Bezug zum Projektverlauf herstellst, fehlt der Nachweis, dass du sie genutzt hast. Dokumentiere Statusänderungen und vergleiche Plan mit Realität.
Nächster Schritt: Von der Analyse zur Umsetzung
Deine Risikoanalyse ist fertig, wenn du ein Risikoregister mit Bewertung und Maßnahmen hast und die Risikomatrix visualisiert ist. Prüfe: Sind alle vier Kategorien durchdacht? Ist die Bewertungsskala definiert? Gibt es für kritische Risiken präventive Maßnahmen und Notfallpläne?
Die Risikoanalyse ergänzt den Zeitplan und den Projektstrukturplan. Zusammen bilden sie das Fundament für eine strukturierte Projektdurchführung. Nutze die Textbausteine aus dem Abschnitt „Risikoanalyse in der Dokumentation", um deine Ergebnisse sauber in der Projektarbeit zu verankern.
Wenn deine Projektarbeit fertig ist, findest du bei BachelorHero passende Bindungsoptionen. Das Softcover eignet sich für Projektarbeiten mit mittlerem Umfang.
Häufig gestellte Fragen
Wie viele Risiken sollte ich dokumentieren?
Die Anzahl hängt von Projektgröße und Vorgaben ab. Für eine typische IHK-Projektarbeit sind 5 bis 10 Risiken im Risikoregister realistisch, davon 3 bis 5 im Hauptteil ausführlich beschrieben. Entscheidend ist, dass alle kritischen Bereiche abgedeckt sind. Prüfe die Vorgaben deiner IHK oder frag deinen Prüfer.
Was schreibe ich, wenn kein Risiko eingetreten ist?
Das ist ein gutes Zeichen. Schreibe im Fazit: „Keines der identifizierten Risiken ist eingetreten. Die präventiven Maßnahmen haben sich als wirksam erwiesen." Das zeigt, dass deine Planung funktioniert hat.
Wie begründe ich Wahrscheinlichkeiten ohne Daten?
Nutze Erfahrungswerte und Annahmen. Frag Kollegen nach ähnlichen Projekten. Formuliere transparent: „Die Wahrscheinlichkeit wird als mittel eingestuft, da in vergleichbaren Projekten Schnittstellenprobleme häufig auftraten." Die Begründung ist wichtiger als die exakte Zahl.
Was ist der Unterschied zwischen Risikovermeidung und Risikominimierung?
Bei der Risikovermeidung änderst du den Projektplan so, dass das Risiko gar nicht erst entstehen kann (z. B. bekannte statt neue Technologie). Bei der Risikominimierung akzeptierst du das Risiko, reduzierst aber Wahrscheinlichkeit oder Auswirkung durch Maßnahmen (z. B. Zeitpuffer).
Gehört die Risikoanalyse in den Anhang oder Hauptteil?
Beides. Im Hauptteil beschreibst du Vorgehen und die wichtigsten Risiken. Das vollständige Risikoregister und die Risikomatrix gehören in den Anhang. Nutze die Textbausteine aus dem Abschnitt „Risikoanalyse in der Dokumentation".
Wann und wie oft reviewe ich die Risiken?
Bei jedem Meilenstein oder wöchentlich bei kurzen Projekten. Dokumentiere das Datum in der Spalte „Letztes Review" und aktualisiere den Status, wenn sich etwas ändert. Details findest du im Abschnitt „Risiken überwachen".
Weitere interessante Artikel 
Das Fazit der Projektarbeit 
Literaturrecherche durchführen 
Problemstellung der Projektarbeit