RAID-Log: Risiken, Annahmen, Issues und Abhängigkeiten verfolgen

Ein RAID-Log ist das einzige Dokument, das vier projektzerstörende Kategorien an einem Ort hält: Risiken, Annahmen, Issues und Abhängigkeiten. Bei den meisten Projekten, die ihr Budget oder ihre Termine überschreiten, lässt sich der Schaden auf eine dieser vier Kategorien zurückführen, die niemand aktiv im Blick hatte.

Was ist ein RAID-Log?

Ein RAID-Log ist ein strukturiertes Tracking-Dokument im Projektmanagement, das die vier Kategorien erfasst und überwacht, die bei einem Projekt am häufigsten Probleme verursachen: Risiken (Risks), Annahmen (Assumptions), Issues und Abhängigkeiten (Dependencies). Jede Kategorie erhält einen eigenen Abschnitt (oder farblich kodierte Zeilen), und das gesamte Log liegt an einem gemeinsamen Ort, auf den alle Stakeholder zugreifen können.

Das Log ist kein ausgefeiltes Tool. Es ist meistens eine Tabelle oder eine Seite in der Projektmanagementplattform. Was es wertvoll macht, ist Disziplin: Teams, die das RAID-Log regelmäßig überprüfen, entdecken Probleme Wochen, bevor sie zu Krisen werden.

Key Facts

• Das RAID-Log-Konzept entstammt den Praktiken von PRINCE2 und APM Body of Knowledge aus den frühen 2000er-Jahren und ist heute Standard in 78 % der britischen Regierungsprojekte (APM, 2023).
• Projekte, die ein aktives RAID-Log führen, verzeichnen eine 31 % geringere Rate an erheblichen Terminverzögerungen gegenüber Projekten ohne eines (PMI Pulse of the Profession, 2024).
• Das "I" im RAID (Issues) erfasst typischerweise 2-3-mal mehr Einträge über die Projektlaufzeit als das "R" (Risiken), da Risiken, die eintreten, automatisch zu Issues werden (PMI Community-Daten, 2023).

RAID: Was jeder Buchstabe bedeutet

RAID ist ein Akronym. Jeder Buchstabe steht für eine eigene Kategorie von Projektunsicherheit, und die Unterscheidung ist wichtig, weil jeder Typ eine andere Reaktion erfordert.

Risiken (Risks)

Ein Risiko ist ein mögliches Ereignis, das noch nicht eingetreten ist, aber eintreten könnte. Risiken haben zwei wesentliche Merkmale: Eintrittswahrscheinlichkeit (wie wahrscheinlich ist das Eintreten?) und Auswirkung (wie schlimm wäre es, wenn es eintritt?).

Beispiel: Ein wichtiger Lieferant ist dafür bekannt, in Q4 Lieferverzögerungen zu haben. Das ist auf dem eigenen Projekt noch nicht passiert, aber die Wahrscheinlichkeit ist real. Wenn der Lieferant den Liefertermin verfehlt, verschiebt sich der Go-Live um drei Wochen.

Risiken werden proaktiv gesteuert: eine Eintrittswahrscheinlichkeit bewerten, einen Maßnahmenplan vereinbaren und regelmäßig überprüfen. Manche Teams weisen einen Risikoeigentümer zusätzlich zum Projektmanager aus, da die Person, die ein Risiko am besten überwachen kann, oft diejenige ist, die ihm am nächsten ist.

Annahmen (Assumptions)

Eine Annahme ist etwas, das als wahr behandelt wird, obwohl es nicht formal bestätigt wurde. Jedes Projekt basiert auf Annahmen, und das ist in Ordnung, solange sie aufgeschrieben werden. Probleme entstehen, wenn sich eine Annahme als falsch herausstellt und niemand das merkt, bis die Arbeit zur Hälfte abgeschlossen ist.

Beispiel: Der Projektplan geht davon aus, dass das Rechtsteam Verträge innerhalb von fünf Werktagen prüft. Diese Annahme ist in den Zeitplan eingebaut. Wenn die Rechtsabteilung tatsächlich drei Wochen braucht, bricht der Zeitplan zusammen.

Das Dokumentieren von Annahmen zwingt das Team, sie früh zu validieren. Nach Bestätigung wird eine Annahme als "validiert" markiert und aus der aktiven Überwachung entfernt.

Issues

Ein Issue ist ein Problem, das bereits eingetreten ist. Es ist ein Risiko, das sich materialisiert hat, oder ein Blocker, der ohne Vorwarnung aufgetaucht ist. Issues brauchen sofortige Aufmerksamkeit, nicht Überwachung.

Beispiel: Die Staging-Umgebung ist seit zwei Tagen ausgefallen und blockiert QA-Tests. Das ist kein Risiko mehr. Es ist ein aktives Issue, das das Projekt gerade jetzt verlangsamt.

Issues werden anders verfolgt als Risiken: Sie brauchen heute einen Reaktionsplan, nicht einen Maßnahmenplan für irgendwann. Sie benötigen auch einen Eskalationspfad, wenn der Eigentümer sie nicht innerhalb eines definierten Zeitfensters lösen kann.

Abhängigkeiten (Dependencies)

Eine Abhängigkeit ist eine Beziehung zwischen dem eigenen Projekt und etwas Externem: dem Output eines anderen Teams, einem Lieferanten-Liefergegenstand, einer regulatorischen Genehmigung oder dem Meilenstein eines anderen Projekts.

Beispiel: Das Frontend kann nicht beginnen, bevor das Designteam genehmigte Wireframes liefert. Der Go-Live-Termin hängt davon ab, dass das Cloud-Infrastrukturteam vorher ein Sicherheitsaudit abschließt.

Abhängigkeiten sind gefährlich, weil sie außerhalb der direkten Kontrolle liegen. Ihre Verfolgung im RAID-Log ermöglicht es, Blockaden frühzeitig zu erkennen und entweder zu eskalieren oder den Projektplan anzupassen, bevor die Verzögerung zur Krise wird.

Warum ein RAID-Log verwenden

Die kurze Antwort: Projekte haben zu viele bewegliche Teile, um sie informell zu verfolgen. Ein RAID-Log schafft einen Zwang, Unsicherheiten sichtbar zu machen, statt sie zu verbergen.

Einheitliche Informationsquelle. Statt Risiken im Kopf irgendwelcher Personen und Annahmen in verstreuten E-Mails hält das RAID-Log dem gesamten Team ein gemeinsames Dokument bereit. Wer mittendrin zum Projekt stößt, kann es lesen und die Lage sofort verstehen.

Revisionsspur für Entscheidungen. Wenn ein Risiko eintritt und der Sponsor fragt "Warum wussten wir das nicht?", zeigt das RAID-Log genau, wann das Risiko eingetragen wurde, wer dafür zuständig war und welcher Maßnahmenplan vereinbart wurde. Das ist nicht nur politisch nützlich. Es ist die Art, wie Teams beim nächsten Projekt besser mit Risiken umgehen lernen.

Strukturierte Statusmeetings. Das RAID-Log verwandelt wöchentliche Statusmeetings von vagen Updates in einen strukturierten Durchlauf. Offene Risiken überprüfen, bestätigen, dass Annahmen noch gelten, gelöste Issues schließen und Abhängigkeiten prüfen. Ein 30-minütiges Meeting mit RAID-Log bringt mehr als eine Stunde ohne eines.

Abstimmung mit Governance-Frameworks. Wenn die Organisation PRINCE2, den APM Body of Knowledge oder PMI-Projektlebenszyklus-Standards verwendet, ist das RAID-Log bereits in die Governance-Anforderungen eingebaut. Eines zu führen ist keine Option. Es ist die Grundlage.

RAID-Log-Spalten (was zu verfolgen ist)

Jedes RAID-Log sollte mindestens diese Spalten enthalten. Weitere können ergänzt werden, aber keine der folgenden ohne guten Grund weglassen.

Die Spalte Schweregrad ist der am meisten diskutierte Teil jedes RAID-Logs. Einfach halten. Eine 3-Punkte-Skala (Niedrig, Mittel, Hoch) reicht für die meisten Projekte. Eine 5-Punkte-Skala eignet sich für große Programme. Den Impuls widerstehen, in jede Zeile eine vollständige Wahrscheinlichkeits-Auswirkungs-Matrix einzubauen. Das gehört in ein dediziertes Risikoregister für risikointensive Projekte.

RAID-Log vs. Risikoregister vs. Issue-Log

Diese drei Tools überschneiden sich, und Teams verwenden sie häufig austauschbar. Sie dienen jedoch unterschiedlichen Zwecken.

Für die meisten Projektteams reicht das RAID-Log. Es deckt alles an einem Ort ab. Risikoregister und Issue-Log sind sinnvoll, wenn eine Kategorie (z. B. Risiken in einem pharmazeutischen Regulierungsprojekt) mehr Tiefe benötigt, als ein einzelnes Log leisten kann.

Schritt für Schritt: Ein RAID-Log erstellen

Schritt 1: Tool wählen

Einfach anfangen. Ein gemeinsames Google Sheet oder eine Excel-Arbeitsmappe mit einem Tab pro RAID-Kategorie (oder farblich kodierten Zeilen in einem einzigen Blatt) reicht für die meisten Teams. Wenn ein Projektmanagement-Tool verwendet wird, prüfen, ob es eine native RAID-Log-Vorlage hat. Tools wie Rework, Jira oder Monday haben oft eine strukturierte Log-Ansicht, die mit den Aufgabendaten integriert ist.

Welches Tool auch gewählt wird: Es muss geteilt und für alle Projektstakeholder zugänglich sein. Ein RAID-Log, das im Desktop-Ordner einer Person lebt, verfehlt den gesamten Zweck.

Schritt 2: Spalten einrichten

Den Spaltensatz aus dem vorherigen Abschnitt als Ausgangspunkt nutzen. Eine Spalte "Priorität" oder "Eskalations-Flag" hinzufügen, wenn die Organisation es erfordert. Die Spaltenanzahl überschaubar halten. Logs mit 20 Spalten werden selten konsistent ausgefüllt.

Schritt 3: Log beim Projektkickoff befüllen

Der beste Zeitpunkt, ein RAID-Log zu starten, ist der Kickoff-Workshop. Ein strukturiertes Brainstorming mit dem Kernteam durchführen: Was könnte schiefgehen? Was nehmen wir an? Worauf warten wir von anderen Teams? Diese erste Befüllung dauert 30-60 Minuten und deckt sofort blinde Flecken auf.

Beim Kickoff besonders auf Annahmen konzentrieren. Die meisten Projekte haben 10-20 unausgesprochene Annahmen, die niemand aufgeschrieben hat. Sie zu Papier zu bringen ist selbst eine risikomindernde Maßnahme.

Schritt 4: Log in jedem Statusmeeting überprüfen

Das Log ist nur nützlich, wenn es lebt. In jedem wöchentlichen Statusmeeting 10-15 Minuten reservieren, um offene Einträge durchzugehen: Status aktualisieren, nächste Überprüfungstermine bestätigen, dringlich Gewordenes eskalieren und Gelöstes schließen. In Projektlebenszyklus-Phasen mit vielen externen Abhängigkeiten muss das Log möglicherweise öfter als einmal pro Woche überprüft werden.

Schritt 5: Gelöste Einträge archivieren

Geschlossene Einträge nicht löschen. Sie in einen "Archiv"-Tab verschieben oder ihren Status auf "Geschlossen" setzen. Gelöste Issues und validierte Annahmen sind Teil des institutionellen Wissens des Projekts. Der nächste Projektmanager, der ein ähnliches Projekt übernimmt, wird dankbar sein für eine klare Aufzeichnung, was passiert ist und wie es gehandhabt wurde.

RAID-Log-Vorlage

Diese Tabellenstruktur in das bevorzugte Tool kopieren. Pro Eintrag eine Zeile hinzufügen.

RAID-Log-Beispiele

So sieht ein realistisches RAID-Log für einen mittelgroßen Software-Launch aus. Zu beachten ist, wie jeder Eintragstyp eine andere Reaktion erfordert, obwohl alle im selben Dokument stehen.

Das Risiko (R-002) und die Annahme (A-002) sind hier eng miteinander verknüpft: Das Risiko ist, was passiert, wenn die Annahme sich als falsch erweist. Das ist ein häufiges Muster. Beim Erfassen einer Annahme lohnt es sich, zu fragen: "Was ist das Risiko, wenn diese Annahme falsch ist?" und dieses Risiko in derselben Sitzung einzutragen.

Für die Abhängigkeit (D-002) ist zu beachten, wie der Eintrag sowohl den erwarteten Liefertermin als auch einen "Blocker-Schwellenwert" angibt, nämlich den Termin, ab dem der gesamte Zeitplan gefährdet ist. Diese Präzision macht ein RAID-Log in Meetings tatsächlich nützlich, statt nur eine Pflichtübung zu sein.

Wenn das Team eine RACI-Matrix verwendet, können RAID-Log-Eigentümer direkt mit den RACI-Verantwortlichen verknüpft werden. Das beseitigt Unklarheiten darüber, wer für die Lösung jedes Eintrags zuständig ist.

Häufige Fehler

Best Practices

• Beim Kickoff beginnen, nicht mittendrin. Ein RAID-Log, das zwei Monate nach Projektbeginn angelegt wird, holt nur auf. Die ergiebigste Quelle für Risiken, Annahmen und Abhängigkeiten ist der Kickoff-Workshop, wenn das Team aktiv über die bevorstehende Arbeit nachdenkt.
• Eigentümer konkret benennen. "Das Team" ist kein Eigentümer. Jeden Eintrag einer Person namentlich zuweisen. Diese Person ist verantwortlich für die Aktualisierung des Eintrags und die Eskalation bei Bedarf.
• RAID-Einträge mit dem Zeitplan verknüpfen. Wenn eine Abhängigkeit nicht bis zu einem bestimmten Datum gelöst ist: welche Aufgaben verschieben sich dann? Das RAID-Log mit dem Gantt-Diagramm oder dem kritischen Pfad verbinden, damit die Terminauswirkung sichtbar ist.
• Wöchentlich überprüfen, ohne Ausnahme. Zwei Wochen aussetzen, und das Log wird zur Fiktion. Einträge bleiben dauerhaft auf "Offen", Eigentümer vergessen ihre Verantwortlichkeiten, und das Log verliert seine Glaubwürdigkeit.
• Blocker frühzeitig eskalieren. Wenn ein Issue nach zwei Überprüfungszyklen ohne Fortschritt ungelöst bleibt, zum Projektsponsor eskalieren. Das RAID-Log macht diese Eskalation leicht zu rechtfertigen, weil der Verlauf direkt darin steht.
• Beschreibungen sachlich und konkret halten. "Lieferant ist zu spät" ist wertlos. "Lieferant hat bestätigt, dass Teile 10-14 Tage zu spät eintreffen werden, was Integrationstests von 2026-06-10 auf 2026-06-24 verschiebt" ist umsetzbar.
• Das Log zur Vorbereitung von Steering-Committee-Meetings nutzen. Die schwerwiegendsten offenen Punkte herausziehen und als kurzes Briefing präsentieren. Stakeholder, die ein gepflegtes RAID-Log sehen, vertrauen dem Überblick des Projektmanagers über die Arbeit.
• Mit dem Projektstrukturplan integrieren. Große Programme profitieren davon, wenn RAID-Einträge bestimmten WBS-Elementen zugeordnet werden, was es leichter macht zu sehen, welche Arbeitspakete das größte Risiko tragen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem RAID-Log und einem Risikoregister?

Ein Risikoregister deckt nur Risiken ab, typischerweise in größerer Tiefe. Es enthält üblicherweise Wahrscheinlichkeitsbewertungen, Auswirkungsratings und einen vollständigen Risikoreaktionsplan mit Notfallvorkehrungen. Ein RAID-Log deckt alle vier Kategorien (Risiken, Annahmen, Issues, Abhängigkeiten) in einem einzigen Dokument bei moderater Tiefe ab. Die meisten Projektteams beginnen mit einem RAID-Log. Stark regulierte Programme in Finanzen, Pharma oder der öffentlichen Verwaltung führen häufig ein separates Risikoregister neben dem RAID-Log für die Risikokategorie allein.

Wer ist für das RAID-Log verantwortlich?

Der Projektmanager ist als Dokumentverantwortlicher für die Aktualität des Logs zuständig. Aber jeder einzelne Eintrag hat seinen eigenen Eigentümer, die Person, die für die Überwachung oder Lösung dieses spezifischen Punkts verantwortlich ist. Ein gut geführtes RAID-Log ist ein Teamdokument, keine persönliche To-do-Liste des PM.

Wie oft sollte das RAID-Log aktualisiert werden?

Mindestens einmal wöchentlich im regulären Statusmeeting. Issues mit hohem Schweregrad erfordern oft tägliche Aktualisierungen. Annahmen sollten immer dann überprüft werden, wenn eine wichtige Projektentscheidung getroffen wird, da Entscheidungen häufig Annahmen, die beim Kickoff eingetragen wurden, ungültig machen.

Was ist der Unterschied zwischen einem Risiko und einem Issue?

Der Zeitpunkt. Ein Risiko ist ein mögliches zukünftiges Ereignis, das noch nicht eingetreten ist. Ein Issue ist ein Problem, das bereits besteht. Wenn ein Risiko eintritt, wird es vom Risikoabschnitt in den Issue-Abschnitt verschoben und der Maßnahmenplan durch einen Lösungsplan ersetzt. Dieser Übergang ist wichtig zu verfolgen, da sich der Reaktionstyp vollständig ändert.

Verwenden agile Teams RAID-Logs?

Ja, wenn auch das Format sich anpasst. Teams, die agile Methodik und Scrum einsetzen, bringen RAID-Punkte häufig während Sprint-Retrospektiven oder Backlog-Refinements auf, statt in einer dedizierten wöchentlichen Überprüfung. Manche agilen Teams führen ein schlankes RAID-Board neben ihrem Sprint-Board, besonders um Abhängigkeiten zu verfolgen, da teamübergreifende Abhängigkeiten zu den größten Blockern bei skalierter agiler Entwicklung gehören. Die vier Kategorien sind in Agile ebenso relevant wie im Wasserfall-Ansatz. Nur der Überprüfungsturnus ändert sich.

---

Ein RAID-Log funktioniert, weil es eine Disziplin erzwingt, der sich die meisten Teams widersetzen: aufzuschreiben, was noch nicht bekannt ist, und was als wahr vorausgesetzt wird. Genau dieses Unbehagen ist der Punkt. Projekte scheitern nicht, weil Teams schlecht in ihrer Arbeit sind. Sie scheitern, weil die richtigen Unsicherheiten nicht früh genug sichtbar gemacht wurden, um handeln zu können. Das RAID-Log beim Kickoff starten, durch jedes Statusmeeting am Leben erhalten, und die vier Buchstaben werden vor den vier häufigsten Wegen bewahren, auf denen Projekte auseinanderfallen.