RAID-Log-Vorlage Permalink
Verwenden Sie diese Vorlage, um ein RAID-Log in Quire zu führen: Halten Sie Risiken, Annahmen, Probleme und Abhängigkeiten an einem Ort fest, ordnen Sie sie in der Tabellenansicht nach Auswirkung und führen Sie ein wöchentliches Review durch, das tatsächlich Dinge abschließt.
Sie können das RAID-Log-Projekt besuchen und es in Ihren Arbeitsbereich duplizieren, sodass Sie nicht alles von Grund auf neu aufbauen müssen.
Sie können auch weitere fertige Vorlagen erkunden, um Ihren Arbeitsablauf zu beschleunigen.
RAID-Logs verstehen
RAID steht für Risks, Assumptions, Issues and Dependencies – Risiken, Annahmen, Probleme und Abhängigkeiten. Ein RAID-Log ist die laufende Aufzeichnung aller vier: was schiefgehen könnte, worauf man ohne Prüfung setzt, was bereits schiefgelaufen ist und was man von Personen außerhalb des Teams benötigt.
Die meisten Teams erfassen davon irgendetwas irgendwo. Nur wenige halten alle vier an einem Ort fest – und genau dort liegt der Wert. Ein fehlender Budgetcode wirkt wie ein kleines administratives Problem, bis man bemerkt, dass er der Grund ist, warum der Lieferant keine Zugangsdaten herausgibt – was wiederum der Grund ist, warum die Vereinbarung für die Einführungswoche noch immer nicht unterzeichnet ist. Eine Ursache, drei separate Listen, niemand, der sie zusammenführt.
Das Log ist als fünf Abschnitte aufgebaut, mit einem Meilenstein oben, sodass alle Daten darunter gegen die maßgebliche Deadline gelesen werden.
Vier Abschnitte enthalten die Kategorien selbst. Der fünfte, die RAID-Governance, enthält die Review-Kadenz – der Teil, der darüber entscheidet, ob das Log den zweiten Monat überlebt. Einundzwanzig ausgearbeitete Beispieleinträge sind bereits ausgefüllt, damit Sie die Form eines guten Eintrags kennenlernen können, bevor Sie sie durch eigene ersetzen.
RAID-Log oder Risikoregister
Quire bietet beide Instrumente an, und sie beantworten unterschiedliche Fragen. Ein Risikoregister ist ein tiefes Instrument für eine Kategorie: eine 5×5-Matrix, numerische Risikobewertungen, fünf formale Reaktionsstrategien und eine Governance-Kadenz, alles auf Risiken allein ausgerichtet. Ein RAID-Log ist ein flacheres Instrument für vier Kategorien, das Risiken nur mit Wahrscheinlichkeit und Auswirkung bewertet, aber auch die Annahmen und Abhängigkeiten erfasst, für die ein Register keinen Platz hat.
Verwenden Sie das Log, wenn Sie einen einzigen Ort für alles möchten, was das Projekt gefährden könnte. Verwenden Sie das Register, wenn Risikomanagement die eigentliche Hauptaufgabe ist und die Bewertung belastbar sein muss. Beide parallel zu führen ist üblich – das Log als laufendes Arbeitsprotokoll, das Register als formales Artefakt.
Die Vorlage wird mit einem Dokument geliefert, das Einrichtung, Kategorieregeln und die häufigsten Fehlermuster beschreibt.
Ein zweites Dokument enthält die Tagesordnung für das wöchentliche Review, damit wer auch immer die Besprechung leitet, die Reihenfolge nicht am Morgen selbst erfinden muss.
Die vier Kategorien unterscheiden
Die Kategorien werden ständig verwechselt, und eine Diskussion darüber, wohin etwas gehört, ist ein guter Weg, die ersten zehn Minuten eines Reviews zu verschwenden. Vier Tests klären fast alles.
| Kategorie | Zeitform | Frage, die sie beantwortet | Test |
|---|---|---|---|
| Risiko | Zukunft, ungewiss | Was könnte schiefgehen? | Lässt es sich als „Wenn X, dann Y” formulieren? |
| Annahme | Gegenwart, ungeprüft | Worauf setzen wir? | Wären Sie überrascht, wenn es sich als falsch herausstellte? |
| Problem | Gegenwart, sicher | Was geht gerade schief? | Ist es bereits eingetreten? |
| Abhängigkeit | Zukunft, Aufgabe anderer | Was brauchen wir von anderen? | Liegt die nächste Aktion außerhalb Ihres Teams? |
Drei Regeln klären den Rest.
- Ein eingetretenes Risiko ist kein Risiko mehr. Verschieben Sie es in die Probleme und schließen Sie das Risiko mit einem Hinweis, wohin es verschoben wurde, anstatt es an beiden Stellen offen zu lassen.
- Eine Annahme, die sich als falsch herausstellt, ist nicht nur falsch – sie hat Folgen. Schließen Sie die Annahme und erfassen Sie diese Folgen als Risiko oder Problem.
- Eine Abhängigkeit, der Sie nicht mehr nachgehen, ist ein Risiko. Bewerten Sie sie beim monatlichen Cleanup neu.
Der Beispieleintrag A-01 in der Vorlage ist das ausgearbeitete Beispiel für Regel zwei, verknüpft mit dem Problem, das daraus entstand.
Das Log in der Tabellenansicht lesen
Die Tabellenansicht ist nur in den Professional-, Premium- und Enterprise-Abos verfügbar. Weitere Informationen finden Sie auf unserer Preisseite.
Die Tabellenansicht ist das eigentliche RAID-Log. Sie zeigt alle benutzerdefinierten Felder neben dem Eintrag, und das Sortieren nach Auswirkung verwandelt den Listenanfang in die Besprechungsagenda.
Sieben Felder tragen das Log.
| Feld | Funktion |
|---|---|
| RAID-ID | Ein stabiler Bezeichner wie R-01 oder D-05, damit man in einer Besprechung auf einen Eintrag verweisen kann, ohne den Titel vorzulesen. Eine Nummer nie wiederverwenden, auch nicht nach dem Schließen eines Eintrags. |
| Typ | Dupliziert den Abschnitt absichtlich. Abschnitte strukturieren die Liste; der Typ ermöglicht das Filtern, Gruppieren oder Herausziehen einer Kategorie über ein Portfolio hinweg. |
| Wahrscheinlichkeit | Nur für Risiken. Probleme sind bereits eingetreten, daher bleibt die Spalte für sie leer. |
| Auswirkung | Gilt für alles. Dies ist die Spalte, nach der sortiert wird, und die entscheidet, was eskaliert wird. |
| Erfasst am | Wann der Eintrag protokolliert wurde. |
| Zuletzt überprüft | Das Feld, das Vernachlässigung offenbart. Beim monatlichen Cleanup danach sortieren und von den ältesten aufwärts arbeiten. |
| Abhängt von | Nennt das Team, den Lieferanten oder die Person, die am Zug ist. Wird hauptsächlich für Abhängigkeiten verwendet, ist aber überall nützlich, wo ein Eintrag außerhalb Ihrer Kontrolle feststeckt. |
„Erfasst am” und „Zuletzt überprüft” wirken wie Buchführung. Ein Eintrag, der im März erfasst, im April überprüft und im September noch immer offen ist, wird nicht gesteuert – und diese beiden Daten sind die einzige Möglichkeit, das zu erkennen, ohne dass jemand es zufällig bemerkt.
Hinweis: Wenn Sie die Wahrscheinlichkeit für ein Problem ausfüllen, ist es wahrscheinlich ein Risiko, das noch nicht umklassifiziert wurde. Probleme sind bereits eingetreten, ihre Wahrscheinlichkeit beträgt daher hundert Prozent.
Acht Tags schneiden quer durch alle vier Kategorien: Budget, Zeitplan, Technisch, Umfang, Kunde, Lieferant, Personal und Compliance. Sie beantworten eine andere Frage als der Typ: nicht, was für eine Art Eintrag es ist, sondern woher er stammt.
Einen Eintrag schreiben, der nützt
Der Unterschied zwischen einem nützlichen RAID-Log und einem Compliance-Artefakt liegt fast ausschließlich darin, wie die Einträge formuliert sind. Jeder Beispieleintrag in der Vorlage folgt derselben vierteiligen Struktur.
Die Beschreibung beginnt mit einer Wenn-X-dann-Y-Formulierung, nennt dann die Auswirkung bei Eintreten in Einheiten, die jemanden interessieren, beschreibt dann die Reaktion und gibt schließlich den Auslöser an. Maßnahmen hängen als Unteraufgaben am Eintrag, damit Plan und Protokoll an einem Ort bleiben.
Fünf Regeln machen den Unterschied.
- Risiken als Ursache und Wirkung formulieren. „Lieferantenverzögerung” ist eine Sorge. „Wenn der Lieferant den 6. August verfehlt, dann beginnt der Authentifizierungstest ohne Produktionszugangsdaten und der Test verschiebt sich um zwei Wochen” ist etwas, auf das ein Team reagieren kann.
- Jedem Risiko einen Auslöser geben. Den beobachtbaren Punkt, an dem es aufhört, hypothetisch zu sein. Ohne Auslöser erfolgt die Eskalation spät und aus dem Bauch heraus.
- Die Reaktion benennen. Vermeiden, mindern, übertragen oder akzeptieren. „Beobachten” ist keine Reaktion, sondern eine Umschreibung von „Wir haben noch nicht entschieden”.
- Auswirkung in Einheiten ausdrücken, die jemanden interessieren. Wochen, Geld, Kunden, Reputation. „Hohe Auswirkung” sagt einem Sponsor nichts.
- Alles mit einem Datum versehen. Ein Eintrag ohne Fälligkeitsdatum wird nie bearbeitet.
Weisen Sie jedem Eintrag eine namentlich genannte Person zu. Ein Team verfolgt nie etwas, weil niemand darin glaubt, dass die Nachverfolgung speziell seine Aufgabe ist.
Fortschritt in der Board-Ansicht verfolgen
Die Board-Ansicht gruppiert nach Status und zeigt Bewegung statt Inventar – ein anderes und ehrlicheres Bild.
Sechs Status steuern das Log.
| Status | Verwenden, wenn |
|---|---|
| Offen | Erfasst und zugewiesen, noch nichts passiert. |
| In Bearbeitung | Jemand arbeitet aktiv daran. |
| Eskaliert | Es hat den Rahmen des Projektteams gesprengt und erfordert eine Entscheidung auf höherer Ebene. |
| Warten auf Antwort | Der Ball liegt wirklich bei jemand anderem. |
| Geschlossen | Gelöst, zurückgezogen oder nicht mehr relevant. |
| Validiert | Eine Annahme, die geprüft und als wahr bestätigt wurde. |
„Warten auf Antwort” ist der Status, der seinen Platz verdient. Ohne ihn müsste „In Bearbeitung” sowohl „Ich arbeite daran” als auch „Ich habe vor neun Tagen eine E-Mail geschickt” abdecken – und diese beiden erfordern völlig unterschiedliche Folgemaßnahmen.
Tipp: Beobachten Sie die Spalte „Eskaliert” über einige Wochen, statt sie einmalig zu lesen. Wenn sie schneller gefüllt als geleert wird, ist das ein zuverlässigeres Gesundheitssignal als jeder Statusbericht.
Querschnittliche Ansichten mit Unterlisten
Im Free-Subscription-Abo können Sie zwei Unterlisten pro Projekt erstellen, und diese Vorlage wird mit 4 geliefert. Behalten Sie nach dem Duplizieren die zwei, die Ihr Team am häufigsten öffnet, oder upgraden Sie Ihr Subscription-Abo, um alle vier zu nutzen. Weitere Informationen finden Sie auf unserer Preisseite.
Die Abschnitte beantworten „Was für eine Art Eintrag ist das?” Vier Unterlisten beantworten Fragen, die quer durch alle vier Kategorien gleichzeitig schneiden – und genau hier zahlt es sich aus, ein Log statt vier zu führen.
- Jetzt eskalieren enthält alle Einträge mit kritischer Auswirkung, die noch offen sind, unabhängig von der Kategorie. Das ist die Unterlage für den Lenkungsausschuss. Wenn sie über etwa sechs Einträge hinausgeht, wird das Projekt beobachtet statt gesteuert.
- Warten auf jemand anderen enthält alles, dessen nächster Schritt nicht bei Ihnen liegt. Öffnen Sie es vor jedem Statusgespräch und verfolgen Sie die drei obersten Einträge.
- Unvalidierte Annahmen ist die Liste, die niemand liest, bis es zu spät ist. Lesen Sie sie einmal pro Quartal laut vor.
- Die Lieferantenkette ist ein ausgearbeitetes Beispiel und kein Filter.
Letztere lohnt es sich zuerst zu öffnen, weil sie das gesamte Argument für ein einziges Log in vier Einträgen zeigt.
Eine nicht eingereichte Bestellung ist ein Problem. Sie blockiert die Freigabe durch die Finanzbuchhaltung – das ist eine Abhängigkeit. Das blockiert den Lieferanten bei der Lieferung von Produktionszugangsdaten – eine weitere Abhängigkeit. Und das ist der Grund, warum die Vereinbarung für die Einführungswoche noch immer nicht unterzeichnet ist, was als Risiko erfasst ist. Drei Kategorien, eine Ursache – nur sichtbar, weil sie im selben Log leben. Die Einträge sind mit echten Aufgabenabhängigkeiten verknüpft, sodass die Kette durchgesetzt und nicht nur beschrieben wird.
Das Log ehrlich halten
Ein Log ohne Review ist ein Dokument, kein Prozess. Der Governance-Abschnitt enthält vier wiederkehrende Aufgaben, damit der Rhythmus im Zeitplan landet, anstatt davon abhängig zu sein, dass jemand daran denkt.
| Kadenz | Was passiert |
|---|---|
| Wöchentlich | Ein 30-minütiges Review, sortiert nach Auswirkung. Der Listenanfang ist die Agenda. |
| Monatlich | Veraltete Einträge schließen und offene Risiken neu bewerten. Ein Risiko, das im März bewertet wurde, ist im Juli selten noch korrekt eingestuft. |
| Vierteljährlich | Annahmen neu validieren. Das ist das Review, das alle überspringen und das gleichzeitig die meisten Probleme aufdeckt. |
| Bei Bedarf | Risikobehaftet Einträge an den Lenkungsausschuss eskalieren. |
Drei Fehlermuster erklären die meisten toten RAID-Logs, und es lohnt sich, sie zu benennen, weil sie leise eintreffen.
- Es wird zum Friedhof. Fünfzig offene Einträge, die meisten davon veraltet, sodass alle aufhören, es zu öffnen. Ein Eintrag, den niemand seit zwei Monaten angerührt hat, ist entweder nicht real oder hat keinen Verantwortlichen.
- Alles ist hohe Auswirkung. Wenn das gesamte Log risikobehaftet ist, priorisiert es nichts mehr. Vier kritische Einträge von zwanzig ist ein plausibles Projekt. Vierzehn ist ein Projekt, über das niemand nachgedacht hat.
- Es wird nur vor dem Lenkungsausschuss aktualisiert. An diesem Punkt hat es sich von einem Steuerungsinstrument in ein Berichtswerkzeug verwandelt.
Alle drei haben dieselbe unspektakuläre Lösung: ein kurzes wöchentliches Review und konsequentes Schließen von Einträgen.
Lesen Sie in unserem Blog mehr darüber, wie man Risiken bewertet und ein Register lebendig hält.
Häufig gestellte Fragen
Was ist ein RAID-Log?
Ein RAID-Log ist eine einzige laufende Aufzeichnung dessen, was schiefgehen könnte, worauf man ohne Prüfung setzt, was bereits schiefgelaufen ist und was man von Personen außerhalb des Teams benötigt. Alle vier an einem Ort zu halten ermöglicht es, zu erkennen, dass getrennt wirkende Probleme eine gemeinsame Ursache haben.
Wofür steht RAID?
Risks, Assumptions, Issues and Dependencies – Risiken, Annahmen, Probleme und Abhängigkeiten. Es gibt auch die Erweiterung Risks, Actions, Issues and Decisions, die häufiger im Programm- und Portfoliomanagement verwendet wird. Die Quire-Vorlage verwendet die erste Version, weil Annahmen und Abhängigkeiten die zwei Kategorien sind, die Teams am seltensten anderswo verfolgen.
Was ist der Unterschied zwischen einem Risiko und einem Problem?
Zeitform und Gewissheit. Ein Risiko liegt in der Zukunft und ist ungewiss – es wird als „Wenn X, dann Y” formuliert. Ein Problem liegt in der Gegenwart und ist sicher, weil es bereits eingetreten ist. Wenn ein Risiko eintritt, hört es auf, ein Risiko zu sein – verschieben Sie es daher in die Probleme und schließen Sie das Risiko mit einem Hinweis, wohin es verschoben wurde.
Was ist der Unterschied zwischen einem RAID-Log und einem Risikoregister?
Ein Risikoregister ist ein tiefes Instrument für eine Kategorie mit einer 5×5-Matrix und formalen Reaktionsstrategien. Ein RAID-Log ist ein flacheres Instrument für vier und deckt die Annahmen und Abhängigkeiten ab, für die ein Register keinen Platz hat. Viele Teams führen beide Instrumente parallel.
Wer ist für das RAID-Log verantwortlich?
Die Projektleitung ist für das Log selbst verantwortlich – die Review-Kadenz, das Schließen veralteter Einträge und die Eskalationen. Jeder einzelne Eintrag benötigt eine namentlich genannte Person, nie ein Team, weil ein Team nie etwas verfolgt.
Wie oft sollte ein RAID-Log reviewed werden?
Wöchentlich für das gesamte Log, etwa 30 Minuten, sortiert nach Auswirkung. Monatlich zum Schließen veralteter Einträge und Neubewerten offener Risiken. Vierteljährlich zur Neuvalidierung von Annahmen. Die Vorlage enthält alle drei als Wiederkehrende Aufgaben, sodass sie automatisch im Zeitplan erscheinen.
Was sollte ein RAID-Log-Eintrag enthalten?
Eine stabile ID wie R-01, die Kategorie, eine Auswirkungsbewertung, eine namentlich genannte verantwortliche Person, ein Fälligkeitsdatum und eine schriftliche Reaktion. Risiken benötigen zusätzlich eine Wahrscheinlichkeit und einen Auslöser – den beobachtbaren Punkt, an dem das Risiko aufhört, hypothetisch zu sein, und jemand handeln muss.
Warum hören RAID-Logs auf, nützlich zu sein?
Drei Fehlermuster: Das Log wird zu einem Friedhof veralteter Einträge, alles wird als hohe Auswirkung markiert, sodass nichts mehr priorisiert wird, oder es wird nur vor dem Lenkungsausschuss aktualisiert. Die Lösung für alle drei ist ein kurzes wöchentliches Review und konsequentes Schließen von Einträgen.
Gibt es eine fertige RAID-Log-Vorlage in Quire?
Ja. Besuchen Sie das RAID-Log-Projekt und duplizieren Sie es in Ihren Arbeitsbereich, um die vier Kategorie-Abschnitte plus Governance, sieben benutzerdefinierte Felder, sechs Status, acht Tags, vier querschnittliche Unterlisten und einundzwanzig ausgearbeitete Beispieleinträge bereits eingerichtet zu erhalten.