Als Programmanager, Projektleiter oder Auftraggeber bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

  • Womit erfassen wir strukturiert negative Faktoren auf unser frisch gestartetes Projekt?
  • Was Hilft uns wesentliche Störgrößen für das laufende Vorhaben im Blick zu behalten?
  • Wie können wir die Top-Fallstricke einer Initiative anschaulich darstellen und kommunizieren?

Unterstützung findest Du im RAID Log und der damit verbundenen RAID Analyse.


Überblick

Ergebnis: Störgrößen für ein Projekt identifiziert und Gegenmaßnahmen aufgesetzt

Teilnehmer: mind. 1

Dauer: ab 30 Minuten (je nach Projektgröße und Zahl der Teilnehmer)

Utensilien: Whiteboard/Flipchart/Metaplan-Wand, Karten & Stifte oder Notebook & Office Software

Zweck

Ein RAID Log hilft Dir bestehende Störungen und potentielle Bedrohungen in einem Projekt systematisch zu erfassen, zu sammeln und nachzuverfolgen. Die vier Buchstaben des englischen Akronyms stehen für die negativen Einflussgrößen auf ein Vorhaben: Risks, Assumptions, Issues und Depedencies, daher Risiken, Annahmen, Probleme und Abhängigkeiten.

Nutze das RAID Log zu Beginn oder während eines Vorhabens und verschaffe Dir mit ihm Klarheit über akute oder mögliche Stolpersteine auf dem Weg zu den Projektzielen. Nutze es zudem als Erinnerungswerkzeug detektierte Störgrößen kontinuierlich nachzugehen und auszuräumen.

Synonyme Bezeichnungen für das RAID Log sind RAID Register, Issue Log oder Risk Log, teilweise auch mit einem trennenden Bindestrich.


Aufbau

RAID Log

Im Zentrum des RAID Log stehen vier negative Einflussgrößen, die Du tabellarisch festhältst und systematisch nachverfolgst. Am besten Du notierst negative Punkte auf Karten. Diese lassen sich stapeln, verschieben und nachträglich vom RAID Log entfernen. Außerdem zwingen Karten aufgrund ihres eingeschränkten Platzes zur Prägnanz.

RAID Log
Struktur und Elemente des RAID Logs

Versehe Dein Register mit Meta-Infos, wie einem aussagekräftigen Titel, den verantwortlichen Autoren sowie das Datum der letzten Aktualisierung.

Risks (Risiken)

Mögliche Ereignisse, die - falls eingetreten - Dein Projekt negativ beeinflussen oder möglicherweise sogar gefährden. Ein Risiko kann eintreten, muss dies aber nicht tun.

  • Was könnte im Worst-Case im Projekt passieren?
  • Welches Risiken sind für diese Art von Projekt typisch?
  • Gegen welche möglichen Geschehnisse sollten wir uns wappnen?

Risiken stellen eine Bedrohung für den Projekterfolg dar. Verfolge sie proaktiv mit Hilfe von Linderungsmaßnahmen.

Assumptions (Annahmen)

Prämissen über Ergebnisse, Vorgehen und Randbedingungen, die - falls sie wider erwarten nicht eintreten - Dein Projekt ausbremsen oder in Schieflage bringen. Eine Annahme sollte sich bewahrheiten, muss dies aber nicht tun.

  • Welche Aspekte nehmen wir als gegeben an?
  • Von welchen zeitlichen Randbedingungen gehen wir aus?
  • Auf welche organisatorischen Rahmenfaktoren basiert unsere Planung?

Projekte scheitern, weil (implizit) Annahmen getroffen wurden, die sich jedoch später als falsch herausstellen. Mache Dir diese potentielle Hindernisse bewusst und überlege, mit welchen Maßnahmen Du sie a priori entkräften oder vollständig auflösen kannst.

Issues (Probleme)

Eingetretene Schwierigkeiten, die Dein Projekt behindern.

  • Was senkt nennenswert die Qualität unserer Projektergebnisse?
  • Welche ungeplante Tatsache kostet wiederkehrend Zeit und Energie?
  • Welcher Umstand behindert den Projekterfolg?

Je nach seinem Hinderungsgrad solltest Du ein Problem lindern oder ganz ausräumen.

Dependencies (Abhängigkeiten)

Bedingtheit des Projektes von externen Faktoren, Ereignissen oder Ergebnissen, die - falls sie sich nicht erfüllen, nicht starten bzw. nicht enden - zu Verzögerungen im Verlauf führen.

  • Auf welche Zuarbeit von Parallelprojekten sind wir angewiesen?
  • Welche externe Entscheidungen sind für den Projektfortschritt essentiell?
  • Was ist die Schlüsselressource im Vorhaben?

Abhängigkeiten sind eine Sonderform des Risikos. Sie liegen außerhalb des Einflussbereiches des Vorhabens. Mache Dir Abhängigkeiten bewusst und versuche sie zu reduzieren oder komplett auszuschalten.


Anwendung

Als Projektleiter setzt Du das RAID Log für ein neues oder bereits in Umsetzung befindliches Projekt ein. Erarbeite den Initialstand im Idealfall in einem gemeinsamen Workshop mit Deinem Projektteam. Bei dieser sogenannten RAID Analyse geht ihr wie folgt vor:

  • 1

    Störgrößen bestimmen

    Bestimmt nacheinander die Risiken, Annahmen, Probleme und Abhängigkeiten für den Verlauf sowie die Ergebnisse des Projektes.

  • 2

    Verantwortlichen benennen

    Ein RAID Log ist nur dann wirksam, falls Ihr für jeden erfassten Punkt einen Kümmerer ernennt. Es gilt: Probleme sollten aktiv in Form einer Aufgabe beseitigt werden. Für Risiken, Abhängigkeiten und Annahmen solltet Ihr hingegen einen Maßnahmenplan skizzieren.

  • 3

    Register nutzen

    Rufe als Projektleiter das RAID Log regelmäßig ins Gedächtnis. Gut geeignet sind Statusmeetings in denen Ihr das Register im Team aktuell haltet. Alternativ stellst Du das Register an einer prominenten Stelle im Büro auf.


Beispiele

RAID Log für die Besteigung des Mont Blancs

Angenommen Du planst mit drei Wanderfreunden den höchsten Berg der Alpen - den Mont Blanc - zu besteigen. Im Vorfeld der Tour fertigst Du ein RAID Log an. Für die identifizierten Störgrößen setzt Du zudem Maßnahmen auf.

Unvollständiges RAID Log für die Besteigung des Berges Mont Blanc
Beispiel für ein RAID Log für die Besteigung des Mont Blancs

Vor- & Nachteile

Pro

  • Das RAID Log ist einfach verständlich, rasch aufgesetzt und vielfältig einsetzbar.
  • Projekteilnehmer zwingt das Werkzeug zur bewussten Auseinandersetzung mit Störgrößen für das Vorhaben.
  • Aufgeschrieben und transparent - das Register vermittelt ein Gefühl der Kontrolle und Transparenz.
  • Eingesetzt im Team, entwickeln die Teilnehmer mit Hilfe des RAID Logs ein gemeinsames Verständnis zu den wichtigsten Projektklippen.

Contra

  • Das RAID Log bedeutet einmaligen Initiierungs- und wiederkehrenden Pflegeaufwand. Inhaltlich ändert sich im Projekt durch das Artefakt nichts.
  • Falls Du bereits über ein aktives Risikomanagement und ein Problem Board verfügst, fällt der zusätzliche Mehrwert des Registers sehr gering aus.
  • Das Instrument macht keine Aussage darüber, wie Bedrohungen und Hindernisse identifiziert und behandelt werden können bzw. sollten.

Praxistipps

  • Tipp 1 - Bei Zuordnung keine Haarspalterei betreiben

    Manchen fällt es schwer, einen störenden Einfluss in die richtige RAID Kategorie einzuordnen.

    Ist “Der Projektleiter Herr Schmidt und die Auftraggeberin Frau Müller verstehen sich nicht gut.” ein Problem oder ein Risiko?

    Im Zweifel gilt: Besser irgendwo einsortieren, als gar nicht.

  • Tipp 2 - RAID Log auf wesentliche Punkte begrenzen

    Bei langen und vielschichtigen Projekten kann Dein RAID Log schnell zu einer gigantischen Liste anschwellen. Die anschließende Pflege versursacht hohen Zusatzaufwand.

    Bevor das Register selbst zum Problem wird, verringerst Du den Detailgrad und lässt unbedeutende Störgrößen weg. Beschränke Dich auf die Top-5 Kandidaten je RAID Kategorie.

    Falls es gar nicht anders geht, pflegst Du für jede Kategorie eine separate Liste. Beispielsweise legst Du eine Übersicht für Parallelprojekte, IT-Systemschnittstellen, Projektpartnern oder Gremien an.

  • Tipp 3 - Karten mit hilfreichen Zusatzinfos versehen

    Erweitere die Ausdrucksstärke Deines RAID Logs, indem Du die Karten der Störgrößen mit Zusatzinfos versiehst. Einige Anregungen:

    • Kartenfarbe – Schadensmaß einer Störgröße (rot – hoch, gelb – mittel, grün – kaum)
    • Namen – Verantwortlicher für Beseitigung oder Überwachung einer Störgröße
    • Datum – Detektion einer Störgröße
  • Tipp 4 - Bestandteile von RAID umwidmen

    Großer Vorteil des Akronyms RAID ist die einfache Merkbarkeit. Scheue nicht davor die Bestandteile des Registers umzuwidmen, falls dies für Dein Projekt sinnvoll ist. Typische Alternativnutzungen sind:

    • Actions (statt Assumptions): Aufgaben im Projekt
    • Decisions (statt Dependencies): Notwendige Entscheidungen für den Projektverlauf
  • Tipp 5 - Abhängigkeiten gezielt managen

    Jeff Bezos, Gründer des Tech-Unternehmen Amazon, empfahl 2003 in einem S-Team Meeting drei Schritte zum Managen von Abhängigkeiten:

    1. Übernimm die Abhängigkeit selbst, wann immer dies möglich ist. Dann musst Du Dich auf keinen anderen verlassen.
    2. Handle eindeutige Zusagen mit den abhängigen Partnern aus.
    3. Schaffe Absicherungen, wo immer möglich. Entwickle einen Notfallplan.

    Wasserdichte Verträge, aktive Kommunikation sowie Risikomanagement sind drei Maßnahmen mit Abhängigkeiten zurechtzukommen. Demonstriere, dass Du überdurchschnittliches geleistet die Abhängigkeit zu reduzieren.


Ursprung

Der Ursprung der Methode ist mir nicht bekannt. Gerne Deine Hinweise per E-Mail an mich.


Bonusmaterial

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Online PM Courses - Mike Clayton: What are RAID, CAD, and DCARI? (4,5 min) - das Konzept im Videoclip erklärt

"Wenn du eine Sache gut erledigt haben möchtest, erledige sie selbst."

- Napoleon Bonaparte, französischer General, Diktator und Kaiser

Zuletzt aktualisiert am 23. September 2021 durch Dr. Christopher Schulz

PDFDrucken

Du möchtest Consulting Methodenkompetenz als Buch?

  • 24 erprobte Consulting Tools auf > 200 Seiten
  • Mein Erfahrungswissen als eBook und Print
  • Kompakt erklärt und einfach umsetzbar
  • An einer Stelle direkt zum Nachschlagen
  • Bereits über 4.000 zufriedene Leser



Gib ein Kommentar

Your email address will not be published.