RAID

RAID Management

RAID steht für 

  • Risks
  • Assumptions
  • Issues
  • Dependency

Diese vier Punkte sind wichtige Punkte innerhalb der Dokumentation eines Projektes und sind Bestandteil des Projektmanagementplans.

Es obliegt der Aufgabe des Projektleiters diese vier Punkte in entsprechender Qualität und Aktualität zu pflegen. Die initiale Basis stellt der Vertrag dar. Die Vertragsanalyse kann dazu genutzt werden, um unmittelbar nach dem Projektstart ein initiales Assesment durchzuführen. Das RAID-Log sollte regelmäßig aktualisiert werden. Dabei werden die historischen Daten mitgeführt. Auf diese Weise lässt sich herleiten wie es zu einer aktuellen Situation gekommen ist, wer beteiligt war, welche Umstände zu der aktuellen Situation führten. Nicht selten ist ein Vertrag für ein Projekt ungenau geschrieben und auch die Annahmen, welche sich zum Vertragsabschluß darstellten, sind zum Projektstart bereits verändert. Die Vertragsanalyse stellt also ein Assesment für den Projektstart dar.

Assumptions ( Annahmen ) werden in jedem Projekt getroffen und müssen auch dokumentiert werden. In einem Projekt arbeiten Menschen miteinander. Unterschiedliche Erfahrungen, Wahrnehmungen führen zu unterschiedlichen Ansichten von Annahmen. Um Annahmen zu dokumentieren und objektiv darzustellen sollten diese und auch die Hintergründe der Annahme beschrieben sein. Diese Annahmen sind eine wichtige Unterstützung bei der realistischen Bewertung von Risiken, Störungen und Abhänigkeiten.

Issues ( Probleme, Fragen, Klärungsbedarf ) sind aktuelle Punkte die bereits eingetreten sind. In der Praxis sind Issues und Risks eng verwand und werden auch oft durcheinander geworfen. Die eindeutige Abgrenzung ist, ein Issue ist etwas was eingetreten ist. Ein Risk ( Risko ) ist etwas was eintreten kann. Es ist wichtig genau diese Unterscheidung näher zu betrachten, denn die Art des Managements ist grundsätzlich unterschiedlich. Dazu hilft wenn man sich folgende Def. für ein Risiko bedient.

Ein Risiko ist ein Ereignis, welches mit einer Eintrittswahrscheinlichkeit und mit einer Auswirkung (positiver oder negativer Amplitude) in der Zukunft auf das Projekt wirkt.

Ein Risiko zu managen ist generell gar nicht schwer. Nimmt man die Felder Eintrittswahrscheinlichkeit und Auswirkung und gibt diesen Feldern Werte von 1 bis 5, multipliziert die Werte, so bekommt man einen Risk-Value und kann auf dieser Basis eine Entscheidung für den Umgang damit treffen. Es ist dabei notwendig ein wenig Fingerspitzengefühl anzuwenden. Das Personen in Urlaub gehen, krank werden können, Personen kündigen können, sind Risiken aber wichtig ist es doch spezifische Risiken für dieses Projekt zu identifizieren und nicht auf einer generellen Ebene den Fokus auf das Wesentliche zu verpuffen. (Im übrigen werden solche generellen Risiken meist sowieso getragen oder recht einfach mitigiert). Mit dem Risk Value haben wir nun Werte von 1 bis 25 in unterschiedlichen Schritte vorliegen. In diesem Wertebereich hat man nun zwei Breakpoints, welche das unterschiedliche Riskmanagement repräsentieren.

  • Bis zum ersten Breakpoint werden Risks akzeptiert
    Das bedeutet diese Risiken sind vorhanden, der Projektmanager ist sich diesen sehr wohl bewusst. Aktivitäten diese Risken zu mitigieren würden aber den Rahmen sprengen und vermutlich keinen Mehrwert darstellen.

  • Die Risiken zwischen dem ersten und zweiten Breakpoint werden durch das Projektteam bearbeitet
    Das Projektteam wird für diese Risiken Maßnahmen durchführen, um die Eintrittswahrscheinlichkeit und/ oder die Auswirkung zu minimieren

  • Die Riskien oberhalb des zweiten Breakpoints werden eskaliert
    Eskalation ist notwendig, weil der Projektleiter/ das Projektteam nicht selbstständig in der Lage ist dieses Risko vom Projekt abzuwenden. Hierzu bedarf es einer genauen Analyse und Dokumentation. Das höhere Gremium, in der Regel ein Projektsteuerungskreis, wird genau diese Dokumentation und Einschätzung benötigen.

Dependencies ( Abhängigkeiten ) dokumentieren die Bedingungen/ Kriterien die Notwendig sind, um mit bestimmten Themen oder mit Teilen eines Projektes starten zu können. Insbesondere bei komplexeren Projekten ist diese Beschreibung der Abhängigkeiten sehr wichtig, damit alle Parteien dieser Abhängigkeitsbeziehung ein präzises Verständnis haben und sich darüber bewusst sind.
Im Rahmen des Managements von Abhängigkeiten kann es sogar sinnvoll sein diese Beschreibung formell bestätigen zu lassen. Dieses ist notwendig, wenn es sich um externe Parteien ( Subunternehmer, Zulieferer, etc. ) eines Projektes handelt.