RAID-Log: Was es ist, eine Vorlage und wie Sie es im Meeting prüfen

Nadias Team hat beim Projekt-Kickoff ein schönes RAID-Log angelegt. Zweiundzwanzig Zeilen, farbig markiert, jedes Risiko bewertet. In Woche sechs hatte es niemand mehr geöffnet. Dann verpasste der Möbellieferant seinen Liefertermin, und der Büroumzug verschob sich um zwei Wochen. Das Risiko stand die ganze Zeit in Zeile 9, mit einer verantwortlichen Person, die vergessen hatte, dass es ihres war. (Nadia ist ein Beispiel, keine echte Projektleiterin.)

Sie kennen das Muster wahrscheinlich. Ein RAID-Log ist schnell angelegt und schwer am Leben zu halten. Das Problem ist nicht die Tabelle. Das Problem ist, dass niemand sie gemeinsam ansieht, zu einem festen Termin, mit den Verantwortlichen im Raum.

Dieser Leitfaden ändert das. Sie bekommen eine klare Definition, eine RAID-Log-Vorlage zum Kopieren, ein ausgefülltes Beispiel aus einem Projekt und eine 15-minütige Agenda für das wöchentliche Review, die das Log aktuell hält. Dazu eine Liste der Sätze, an denen Sie im Meeting ein neues Risiko oder Problem erkennen, damit Sie es festhalten können, während es gesagt wird.

Wenn Sie in diesem Meeting protokollieren, kann ParrotNotes es auf Ihrem Smartphone aufnehmen und Ihnen danach ein Transkript und eine Zusammenfassung liefern, damit nichts verloren geht, was im Raum gesagt wurde.

Was ist ein RAID-Log?

Ein RAID-Log ist ein einzelnes Projektdokument, das vier Arten von Einträgen verfolgt: Risks, Assumptions, Issues und Dependencies, also Risiken, Annahmen, Probleme und Abhängigkeiten. Jeder Eintrag hat eine verantwortliche Person, einen Status und einen nächsten Schritt, und das Team prüft das Log in einem festen Rhythmus, meist im wöchentlichen Projektmeeting. Darauf läuft RAID im Projektmanagement hinaus: eine Liste mit allem, was das Projekt aufhalten könnte, und einem Namen neben jeder Zeile.

Das bedeuten die einzelnen Buchstaben:

So unterscheiden Sie am einfachsten ein Risiko von einem Problem: Ein Risiko ist noch nicht eingetreten, ein Problem schon. Tritt ein Risiko ein, wandert es in die Problemliste. Stellt sich eine Annahme als falsch heraus, wird sie meist zu einem Risiko oder einem Problem.

Andere Bedeutungen von A und D

Manche Teams verwenden für dieselben Buchstaben andere Begriffe. Im RAID-Log-Leitfaden von Asana heißt es, das A in RAID könne für Actions (Maßnahmen) oder Assumptions (Annahmen) stehen, und das D für Decisions (Entscheidungen) oder Dependencies (Abhängigkeiten).

Legen Sie sich auf eine Bedeutung fest und schreiben Sie sie oben ins Log. Wenn Sie Maßnahmen und Entscheidungen getrennt verfolgen, führen Sie sie in einer Maßnahmenliste und einem Entscheidungsprotokoll, und nutzen Sie das RAID-Log für die vier Einträge oben.

RAID-Log oder Risikoregister

Ein Risikoregister verfolgt nur Risiken, meist mit einer detaillierten Bewertung von Wahrscheinlichkeit und Auswirkung. Ein RAID-Log ist breiter: Es stellt Risiken neben die Annahmen, Probleme und Abhängigkeiten, aus denen sie entstehen oder die ihnen folgen. Kleine Projekte brauchen oft nur das RAID-Log. Große führen ein vollständiges Risikoregister und ein RAID-Log, das darauf verweist.

Wenn Sie nur den Risikoteil brauchen, erstellt die kostenlose Risikoregister-Vorlage ein Register mit Wahrscheinlichkeit, Auswirkung, Risikowert, verantwortlicher Person und Maßnahme für jedes Risiko, fertig zum Drucken.

Die RAID-Log-Vorlage (zum Kopieren)

Führen Sie alle vier Arten in einer Tabelle, mit einer Spalte für den Typ. Eine Tabelle lässt sich im Meeting leichter durchgehen als vier Reiter, weil Sie nach verantwortlicher Person oder Datum sortieren und einmal durchgehen können.

Kopieren Sie sie als Text, wenn Sie in einem Dokument oder einer Tabelle arbeiten:

ID | Typ | Beschreibung | Gemeldet von / am | Auswirkung | Wahrscheinlichkeit | Verantwortlich | Maßnahme / nächster Schritt | Fällig- oder Prüfdatum | Status | Notizen

Jeder Typ braucht außerdem etwas, das die anderen nicht brauchen:

• Risiken brauchen eine Reaktion: vermeiden, mindern, übertragen oder akzeptieren. „Beobachten“ ist nur dann eine Reaktion, wenn es ein Prüfdatum gibt.
• Annahmen brauchen einen Weg, sie zu prüfen, und ein Datum, bis zu dem sie bestätigt sind. Eine Annahme ohne Prüfdatum ist nur eine Hoffnung.
• Probleme brauchen einen Eskalationsweg: wer entscheidet, wenn die verantwortliche Person es nicht lösen kann.
• Abhängigkeiten brauchen den Namen der anderen Partei und das Datum, bis zu dem Sie die Leistung brauchen.

Ein RAID-Log-Beispiel: ein Büroumzug

Hier ist ein ausgefülltes RAID-Log für ein Beispielprojekt: Ein Team von 40 Personen zieht am 14. März auf eine neue Büroetage. Projektleiterin ist Nadia aus der Geschichte am Anfang.

Sehen Sie sich A-01 und I-01 an. Das Team ging von einem Umzug am Samstag aus. Omar fragte nach, die Annahme war falsch, und noch in derselben Woche wurde daraus ein Problem. So funktioniert ein RAID-Log: Das Problem zeigte sich fünf Wochen vor dem Umzugstag, nicht an ihm.

Achten Sie auch darauf, dass jede Zeile genau eine verantwortliche Person und ein Prüfdatum hat. Das Prüfdatum bringt die Zeile zurück ins wöchentliche Meeting.

So legen Sie ein RAID-Log in 30 Minuten an

Beginnen Sie das Log beim Projekt-Kickoff oder in einer kurzen Sitzung kurz danach. Unsere Kickoff-Meeting-Agenda hat bereits einen Block für Risiken und offene Fragen. Diese kurze RAID-Analyse macht aus diesem Block ein Log.

1. Laden Sie die Leute ein, die wissen, wo es hakt. Die Projektleitung, eine Person aus jedem beteiligten Team und alle, die einen Lieferanten betreuen.
2. Nehmen Sie sich fünf Minuten pro Buchstabe. Stellen Sie die Frage aus der Tabelle oben: „Was könnte schiefgehen?“, „Was setzen wir als selbstverständlich voraus?“, „Was ist schon ein Problem?“, „Auf wen warten wir?“
3. Schreiben Sie jeden Eintrag als einen Satz. Noch keine Bewertung. Erst alles auf die Tafel.
4. Geben Sie jedem Eintrag eine verantwortliche Person, bevor die Sitzung endet. Wenn niemand ihn übernehmen will, fragen Sie, ob er überhaupt ins Log gehört.
5. Bewerten Sie die Risiken und setzen Sie Prüfdaten danach. Die Projektleitung schafft das in 10 Minuten und schickt das Log zur Kommentierung herum.

Rechnen Sie mit 10 bis 25 Einträgen für ein Projekt von einigen Monaten. Deutlich mehr, und das Review-Meeting geht unter; fassen Sie Einträge mit derselben verantwortlichen Person und derselben Ursache zusammen.

Sie leiten den Kickoff und schreiben gleichzeitig mit? Testen Sie ParrotNotes kostenlos, nehmen Sie die Sitzung auf und bauen Sie das erste RAID-Log aus dem Transkript statt aus dem Gedächtnis.

So prüfen Sie das RAID-Log im wöchentlichen Meeting

Die meisten Leitfäden sagen, man solle das Log regelmäßig prüfen. Der RAID-Leitfaden von Smartsheet sagt, Projektmanager sollten das Log „mindestens in den wöchentlichen Statusmeetings“ prüfen und anpassen. Der Leitfaden zu RAID-Logs von Parallel Project Training stimmt zu: Das Log sollte „zumindest nach Teammeetings“ aktualisiert werden. Wie dieses Review abläuft, sagt keiner der beiden. Hier ist eine 15-minütige Agenda, die in ein wöchentliches Projekt- oder Statusmeeting passt.

Die 15-minütige Agenda für das wöchentliche RAID-Review

Regeln, die das Review bei 15 Minuten halten

1. Nach Prüfdatum prüfen, nicht Zeile für Zeile. Nur Einträge, die diese Woche fällig sind, kommen dran. Alles andere bleibt unberührt im Log, bis sein Datum kommt. So passt ein Log mit 25 Zeilen in 15 Minuten.

2. Die Verantwortlichen sprechen, nicht die Projektleitung. Jede verantwortliche Person sagt einen Satz: was sich geändert hat und was als Nächstes kommt. Fehlt jemand, rutscht der Eintrag in die nächste Woche, und die Leitung fragt danach nach.

3. Probleme vor Risiken. Probleme schaden dem Projekt jetzt. Wird die Zeit knapp, schrumpft der Risikoblock, nie der Problemblock.

4. Außerhalb des Meetings lösen. Braucht ein Eintrag mehr als zwei Minuten, nennen Sie die Leute, die miteinander reden müssen, und planen Sie das für danach ein. Ins Log kommt eine Notiz, ins Meeting keine Debatte.

5. Einträge schließen. Ein Log wird nur länger, wenn niemand Zeilen schließt. Fragen Sie jede Woche: „Können wir einen dieser Einträge schließen?“ Geschlossene Zeilen bleiben grau markiert im Log, damit der Verlauf für die Projektnachbetrachtung erhalten bleibt.

6. Ab einer Schwelle eskalieren. Vereinbaren Sie zu Beginn, welche Einträge an den Sponsor oder den Lenkungsausschuss gehen, zum Beispiel jedes Problem mit hoher Auswirkung, das die verantwortliche Person nicht innerhalb von zwei Wochen lösen kann. Schicken Sie diese Einträge, nicht das ganze Log.

Als Markus anfing, das RAID-Review seines Teams so zu führen (ebenfalls ein Beispiel), überzog sein wöchentliches Projektmeeting nicht mehr. Das Log hatte 31 Zeilen, aber jede Woche waren nur sechs oder sieben fällig. Im ersten Monat schloss das Team 11 Zeilen, die seit Wochen erledigt, aber nie als geschlossen markiert waren.

Wenn Sie zusätzlich ein schriftliches Update an Personen schicken, die nicht teilnehmen, hat die kostenlose Projektstatusbericht-Vorlage Abschnitte für Ampelstatus, Risiken, benötigte Entscheidungen und nächste Schritte, sodass das RAID-Review direkt hineinfließt.

Neue RAID-Einträge im Meeting erkennen

Neue Risiken und Probleme kommen selten mit Etikett. Sie tauchen nebenbei auf, mitten in einem Update, und sind vergessen, wenn das Meeting endet. Die Aufgabe der Protokollführung ist, sie zu hören und festzuhalten.

Auf diese Sätze sollten Sie achten:

„Das sollte passen“ ist der Satz, den man am leichtesten überhört. Er klingt nach einer guten Nachricht, ist aber eine ungeprüfte Annahme. Im Umzugsbeispiel begann A-01 als „Samstag sollte für das Gebäude passen“.

Lesen Sie am Ende des Meetings jeden neuen Eintrag vor: ID, eine Zeile Beschreibung, verantwortliche Person und Prüfdatum. Das dauert eine Minute, und genau dann sagt jemand „das ist nicht meins“ oder „das ist eigentlich schon passiert“, solange Sie die Zeile noch korrigieren können.

Leila, Teamleiterin bei einem Website-Relaunch (ein Beispiel), führte dieses Vorlesen in ihrem wöchentlichen Meeting ein. In der zweiten Woche hörte eine Designerin „D-04: Das Content-Team liefert die Texte bis zum 15.“ und sagte, das Content-Team wisse nichts von diesem Termin. Eine Nachricht am selben Nachmittag ersparte eine Woche Warten.

Das Meeting aufnehmen und die Zusammenfassung ins Log übernehmen

Wer die RAID-Notizen schreibt, hat einen schweren Job. Diese Person muss der Diskussion folgen, eine Annahme hinter „das sollte passen“ erkennen und sie notieren, bevor das nächste Update beginnt.

ParrotNotes nimmt ihr das Tippen ab. Legen Sie Ihr Smartphone auf den Tisch und nehmen Sie das wöchentliche Meeting auf (mit dem Einverständnis aller). Wenn Sie stoppen, transkribiert ParrotNotes das Gespräch und schreibt eine Zusammenfassung, und KI-gestützte Aufnahmen ziehen zusätzlich die Aufgaben heraus. Danach gehen Sie die Zusammenfassung mit der Satztabelle oben durch und ergänzen die neuen RAID-Zeilen, ausgehend von dem, was wirklich gesagt wurde, statt aus dem Gedächtnis.

Ein paar Details, Stand Oktober 2026:

• Free-Tarif: 100 Minuten Aufnahme pro Monat, bis zu 30 Minuten pro Aufnahme, eine KI-Zusammenfassung zu jeder Aufnahme und 5 KI-gestützte Aufnahmen pro Monat mit Aufgaben. Ein 15-minütiges RAID-Review passt problemlos.
• Pro (19,99 USD pro Monat oder 14,99 USD pro Monat bei jährlicher Zahlung): Aufnahmen bis 3 Stunden, Sprechererkennung, damit Sie sehen, wer welchen Eintrag eingebracht hat, und eigene Insight-Vorlagen. Sie können eine Vorlage mit Risiken, Annahmen, Problemen und Abhängigkeiten als Überschriften speichern, sodass jede wöchentliche Aufnahme in die vier Listen sortiert zurückkommt.
• KI-Chat (Pro) lässt Sie der Aufnahme eine Frage stellen, etwa „Was hat Leo zum Netzwerk-Switch gesagt?“ Die semantische KI-Suche findet, wann ein Problem zum ersten Mal erwähnt wurde, über Wochen von Meetings hinweg.

Es gibt keinen Bot, den Sie einladen müssen, und nichts zu verbinden, denn die App nimmt den Raum mit dem Smartphone auf, das Sie ohnehin dabeihaben. Das Log gehört weiter Ihnen; ParrotNotes liefert den ersten Entwurf dessen, was sich geändert hat. Laden Sie ParrotNotes herunter, bevor Ihr nächstes Projektmeeting beginnt.

Halten Sie Ihr RAID-Log am Leben

Ein RAID-Log nützt nur, wenn es aktuell ist, und aktuell bleibt es, weil das Team es jede Woche gemeinsam ansieht. Zusammengefasst:

• Eine Tabelle, vier Typen, jede Zeile mit einer verantwortlichen Person und einem Prüfdatum.
• Eine 30-minütige Kickoff-Sitzung liefert die ersten 10 bis 25 Einträge.
• Ein 15-minütiges Wochenreview, nach Prüfdatum, Probleme zuerst, mit Vorlesen am Ende.
• Die Satztabelle hilft Ihnen, neue Risiken, Annahmen, Probleme und Abhängigkeiten zu erfassen, während sie noch ausgesprochen werden.

Kopieren Sie die RAID-Log-Vorlage noch heute in Ihren Projektordner, geben Sie jeder Zeile ein Prüfdatum und setzen Sie das 15-minütige Review auf die Agenda der nächsten Woche.

Und wenn Sie in diesem Meeting lieber zuhören als tippen, testen Sie ParrotNotes kostenlos. Nehmen Sie das Review auf, lesen Sie die Zusammenfassung und aktualisieren Sie das Log, bevor das nächste Meeting beginnt.