Der RAID-Log ist ein Projektmanagement-Werkzeug, das der Erfassung und Verwaltung diverser kritischer Aspekte eines Projekts dient. Er hilft dabei, den Überblick über potenzielle und aktuelle Herausforderungen zu behalten und sicherzustellen, dass notwendige Maßnahmen geplant und umgesetzt werden. Der RAID-Log bietet eine strukturierte Methode, um die relevanten Informationen eines Projekts an einer Stelle zu bündeln und übersichtlich darzustellen. Er dient der Unterstützung des Projektteams bei der Minimierung von Risiken, der Lösung von Problemen und der Nachvollziehbarkeit von Entscheidungen. Durch die konsequente und transparente Nutzung eines RAID-Logs kann die Kommunikation im Team und mit dem Kunden verbessert und die Wahrscheinlichkeit eines erfolgreichen Projektabschlusses erhöht werden.

RAID, CRAID, RAAIIDD – was heißt das alles?!

Der Name “RAID-Log” setzt sich zusammen aus den Anfangsbuchstaben jener Logs, welche darin gebündelt werden. Hierbei gibt es nicht die eine Wahrheit, sondern mehrere Optionen, wie man den RAID-Log gestalten kann. Dabei kann es aber je nach Projektgröße und -umfeld aber sinnvoll sein, den RAID-Log zu erweitern bzw. weitere Informationen zu inkludieren; in diesem Fall kann daraus ein CRAID- oder gar ein RAAIIDD-Log werden. So komisch sich das lesen mag, so simpel ist die Erklärung – hinter den Buchstaben verstecken sich folgende Begriffe bzw. damit zusammenhängende Logs:

  • Risks (Risiken)
  • Actions (Tätigkeiten)
  • Assumptions (Annahmen)
  • Constraints (Einschränkungen)
  • Changes (Projektänderungen)
  • Dependencies (Abhängigkeiten)
  • Decisions (Entscheidungen)

Wann und wie wir den RAID-Log in der Praxis einsetzen

In einem anderen Blog-Eintrag haben wir bereits erklärt, dass nicht jedes Projekt jeden erdenklichen Log benötigt: Die Geheimwaffe der Profis: Logs im Projektmanagement

Aufgrund der Projektziele und des Projektumfelds sollte man in der Setup-Phase abwägen, welche Informationen man für die Steuerung des Projekts benötigen wird bzw. explizit dokumentieren möchte – es kann durchaus vorkommen, dass wir keine expliziten Logs führen, wenn wir zur Einschätzung kommen, dass der Mehrwert nicht gegeben ist. Ein Beispiel gefällig? Wenn es klar ist, dass wir ein agiles Projekt mit langer Laufzeit vor uns haben (z.B. ein Jahr oder länger), werden wir in jedem Fall einen Decision-Log führen – in diesem Fall werden zwangsläufig unzählige Entscheidungen getroffen werden müssen. Ein Jahr später wird sich vermutlich niemand mehr daran erinnern, wieso Feature XY, das zu Beginn ganz oben im Backlog gestanden ist, niemals umgesetzt wurde – im Decision-Log findet man jedoch die Erklärung dafür, von wem diese Entscheidung wann getroffen wurde.

Wenn wir Logs nutzen, ist im Normalfall der RAID-Log in der Variante “Risks, Actions, Issues, Decisions” das Mittel unserer Wahl, wobei folgende Dinge aus unserer Sicht essenziell sind:

  • Miteinbeziehung des Kunden: Wir stimmen die geführten Logs mit dem Kundenansprechpartner ab bzw. gehen mitunter so weit, dass wir die Logs gemeinsam führen und nicht zwei “Parallelwelten” aufziehen.
  • Transparenz: Wir legen Wert darauf, dass die Logs für alle Stakeholder einsehbar sind – vom eigenen Team bis zum Top-Level-Management des Kunden. Dabei ist es unwichtig, welches Tool zum Einsatz kommt – der RAID-Log kann sowohl in einem gemeinsam genutzten Confluence als auch in einem Excel geführt werden, welches auf einem allgemein zugänglichen Dokumenten-Management-System abgelegt wird. Selbst im “worst case”, also kla