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 klar voneinander getrennten System zwischen Auftraggeber und Auftragnehmer, kann man zu Beginn definieren, wer den Lead hat und somit den RAID-Log verwaltet und in der Folge regelmäßig an alle relevanten Stakeholder ausschickt.
- Relevanz: Dokumentation um der reinen Prozesserfüllung willen liefert keinen realen Mehrwert. Wenn wir den RAID-Log zum Einsatz bringen, dann achten wir auf die entsprechende Relevanz im Projekt. Das bedeutet, dass wir ganz klar definieren, dass der RAID-Log tourlich auf Projektleiter-Ebene (z.B. in einem wöchentlichen Projekt-JF) durchgesehen und eventuelle Implikationen für die Umsetzung abgeleitet werden.
Unser gängiges Template für RAID-Logs
Jeder der vier angeführten Logs – und somit auch der RAID-Log selbst – kann in unterschiedlichen Ausprägungen geführt werden. Man kann pro Log gefühlt 100 Spalten und damit Informationen pro Item führen und jeden noch so kleinen Aspekt eines Items, z.B. eines Risikos, minutiös abdecken. Andererseits kann man auch mit einer absoluten Minimalvariante durchkommen, in der eigentlich nur die Überschrift pro Item angegeben (z.B. “Feature XY wird nicht umgesetzt” als Entscheidung) und weiterführende Informationen komplett weggelassen werden.
Um einen gesunden Mittelweg aufzuzeigen, der die wichtigsten Aspekte abdeckt, aber zugleich den Aufwand nicht in ungeahnte Höhen schießen lässt, stellen wir zum Abschluss ein Mustertemplate zur Verfügung: PDC Template RAID-Log
Wir hoffen, dass es Ihnen dabei hilft, Ihre aktuellen und künftigen Projekte noch besser zu steuern!
