RAID im Projektmanagement: Wie es PMOs und Stakeholder unterstützt

RAID im Projektmanagement ist ein strukturierter Ansatz zur Erfassung und Steuerung der Risiken, Annahmen, Probleme und Abhängigkeiten, die den Umfang, den Zeitplan, die Kosten oder die Qualität eines Projekts beeinflussen können.

RAID lässt sich am besten als drei Dinge gleichzeitig verstehen:

• Ein Rahmenwerk: eine einheitliche Methode, um Unsicherheit (Risiken und Annahmen) und Realität (Probleme und Abhängigkeiten) zu kategorisieren, damit nichts Wichtiges in E-Mail-Verläufen oder Besprechungsnotizen verloren geht.
• Ein fortlaufender Managementprozess: RAID-Elemente werden identifiziert, bewertet, zugewiesen, bearbeitet und abgeschlossen. Der Prozess endet nicht mit der Erstellung der Liste.
• Ein Kommunikations- und Steuerungsmechanismus: RAID-Protokolle bieten Projektsponsoren, Lenkungsausschüssen und PMOs einen gemeinsamen Bezugspunkt für die Diskussion über den Projektzustand, anstatt sich auf informelle Statusberichte zu verlassen.

Der häufigste Fehler im RAID-Projektmanagement ist die Behandlung des RAID-Protokolls als einmaliges Ergebnis zu Projektbeginn. In gut geführten Projekten ist RAID ein dynamischer Prozess: Neue Risiken entstehen, Annahmen werden bestätigt oder widerlegt, Probleme werden gelöst und Abhängigkeiten verschieben sich mit geänderten Zeitplänen. Ein nicht aktiv gepflegtes RAID-Protokoll wird schnell ungenau, und ein ungenaues RAID-Protokoll ist oft gefährlicher als gar kein Protokoll, da es falsche Sicherheit erzeugt.

RAID steht für Risiken, Annahmen, Probleme und Abhängigkeiten. Jede Komponente beantwortet eine andere Frage zum Projekt.

1. Risiken

Ein Risiko ist ein mögliches zukünftiges Ereignis oder ein möglicher Zustand, der noch nicht eingetreten ist, aber im Falle seines Eintretens negative Auswirkungen auf Umfang, Zeitplan, Kosten, Ressourcen, Qualität oder Geschäftsziele haben könnte. Risiken werden typischerweise wie folgt bewertet:

• Wahrscheinlichkeit: Wie wahrscheinlich ist das Eintreten des Risikos?
• Auswirkungen: Wie schwerwiegend die Folgen wären, wenn es dazu käme
• Risikomanagement : eine kombinierte Betrachtung von Wahrscheinlichkeit und Auswirkung, die häufig zur Priorisierung verwendet wird
• Eigentümer: die Person, die für die Überwachung und Reaktion auf das Risiko verantwortlich ist.
• Schadensbegrenzung: Maßnahmen, die jetzt ergriffen werden, um die Wahrscheinlichkeit oder die Auswirkungen zu verringern
• Notfallplan: die geplante Reaktion, falls das Risiko tatsächlich eintritt
• Auslöser: Frühwarnzeichen dafür, dass sich das Risiko realisiert
• Status: offen, unter Beobachtung, abgemildert, abgeschlossen oder realisiert (d. h. es ist zu einem Problem geworden)

2. Annahmen

Annahmen sind Bedingungen, die das Team für Planungszwecke für wahr hält, aber nicht formell überprüft hat. Jeder Projektplan basiert auf Annahmen, ob diese nun schriftlich festgehalten sind oder nicht. Das Problem sind nicht die Annahmen selbst, sondern deren Nichtüberprüfung.

Eine nicht bestätigte Annahme kann sich stillschweigend in ein Risiko, ein Problem oder eine Abhängigkeit verwandeln:

• Wenn es ungewiss ist, ob es zutreffen wird, verhält es sich wie ein Risiko.
• Sollte sich dies als falsch erweisen und das Projekt bereits beeinträchtigen, wird es zu einem Problem.
• Wenn die Bestätigung die Mitwirkung eines anderen Teams erfordert, handelt es sich faktisch um eine Abhängigkeit.

Beispiel: Das Projektteam geht davon aus, dass die Finanzabteilung des Kunden die Kontenplandaten bis zum Beginn von Phase 2 bereinigt und für die Migration bereit hat. Wenn dies nicht direkt mit dem Finanzteam bestätigt wurde, handelt es sich um eine Annahme, die später zu einem Hindernis werden könnte.

3. Probleme

Der deutlichste Unterschied bei RAID: Ein Risiko kann eintreten, ein Problem ist bereits eingetreten.

Probleme erfordern:

• Schweregradklassifizierung: Wie stark sich das Problem aktuell auswirkt
• Verantwortung: Jemand, der für die Lösungsfindung verantwortlich ist und nicht nur das Problem zur Kenntnis nimmt.
• Korrekturmaßnahmen: Was wird unternommen, um das Problem zu beheben?
• Fälligkeitstermine: Wann wird mit einer Lösung gerechnet?
• Eskalation: Muss das Problem zur Lösung über das Projektteam hinausgehen?
• Lösungsstatus: offen, in Bearbeitung, eskaliert, gelöst

4. Abhängigkeiten

Abhängigkeiten sind Aufgaben, Ressourcen, Teams, Lieferanten, Entscheidungen, Systeme oder Ergebnisse, von denen ein Arbeitsschritt abhängt. Abhängigkeiten können sein:

• Aufgabenmanagement : Eine Aufgabe kann erst beginnen, wenn eine andere abgeschlossen ist.
• Ressourcenabhängigkeiten: Eine Aufgabe erfordert eine bestimmte Person, Fähigkeit oder ein bestimmtes Gerät.
• Abhängigkeiten von externen Anbietern: Die Arbeit ist von den Leistungen eines externen Anbieters abhängig.
• Teamabhängigkeiten: Die Ergebnisse eines Teams fließen in die Arbeit eines anderen Teams ein.
• Projektabhängigkeiten: Ein Meilenstein eines Projekts blockiert ein anderes Projekt
• Projektübergreifende Abhängigkeiten: Mehrere aktive Projekte nutzen dieselbe gemeinsame Ressource, dasselbe System oder dieselbe Entscheidung.
• Externe Abhängigkeiten: behördliche Genehmigungen, Infrastruktur von Drittanbietern oder clientseitige Bereitschaft

Abhängigkeiten sind in RAID von entscheidender Bedeutung, da eine einzelne verzögerte Abhängigkeit selten ein isoliertes Problem verursacht. Es kommt zu einer Kettenreaktion: Eine verspätete Lieferung eines Zulieferers verschiebt einen Meilenstein, die Meilensteinverschiebung ändert sich, wenn ein gemeinsamer Spezialist benötigt wird, dieser Ressourcenkonflikt beeinträchtigt ein zweites Projekt, das auf dieselbe Person angewiesen ist, und die kombinierte Verzögerung wirkt sich auf eine Portfolio-bezogene Verpflichtung gegenüber einem Lenkungsausschuss aus.

Beispiel: Ein Rechenzentrumsmigrationsprojekt ist davon abhängig, dass das Netzwerksicherheitsteam die Firewall-Neukonfiguration abschließt. Das Sicherheitsteam betreut außerdem zwei weitere laufende Projekte. Eine zweiwöchige Verzögerung der Firewall-Arbeiten verzögert nicht nur einen Migrationsschritt, sondern verschiebt auch den Umstellungstermin. Dies wirkt sich wiederum auf die Ressourcenplanung des nachfolgenden Projekts aus, das bereits für die Nutzung desselben Infrastrukturteams vorgesehen ist.

Ein RAID-Protokoll ist ein gängiges Instrument im Projektmanagement, um Risiken, Annahmen, Probleme und Abhängigkeiten zu verfolgen und zu steuern, die die Projektabwicklung beeinflussen können. Es bietet Projektmanagern und Teams einen klaren Überblick über potenzielle Bedrohungen, aktuelle Probleme, wichtige Annahmen und Abhängigkeiten, die berücksichtigt werden müssen.

Ein RAID-Protokoll ist mehr als eine Liste von Projektrisiken. Es ist ein dynamisches Managementdokument und sollte regelmäßig überprüft, priorisiert und bestimmten Verantwortlichen zugewiesen werden. Durch die Pflege der Beziehungen zwischen RAID-Elementen und Projektplänen, Aufgaben, Ressourcen und Meilensteinen können Teams Probleme frühzeitig erkennen und Korrekturmaßnahmen ergreifen, bevor diese wesentliche Auswirkungen auf die Projektergebnisse haben.

Betrachten Sie die Implementierung eines ERP-Systems in einem Unternehmen unter Beteiligung der Abteilungen Finanzen, Betrieb, IT und eines externen Implementierungspartners.

Organisationen führen diese Dokumente mitunter separat oder fassen sie in einem RAID-Protokoll mit der Kategorie „Entscheidungen“ zusammen. Beide Vorgehensweisen sind gültig; wichtiger als die gewählte Struktur selbst ist die einheitliche Vorgehensweise des Teams.

1. Es wird beim Start ein RAID-Protokoll erstellt und anschließend nur selten aktualisiert.
2. RAID-Elemente aufzeichnen, ohne einen eindeutigen Besitzer zuzuweisen.
3. Verwechslung von Risiken und Problemen sowie falsche Kennzeichnung realisierter Risiken.
4. Alle Risiken als gleich wichtig zu behandeln, anstatt sie nach Eintrittswahrscheinlichkeit, Auswirkung und Gefährdung zu priorisieren.
5. Annahmen nicht zu überprüfen, bevor sie Risiken, Probleme oder Abhängigkeiten erzeugen oder dazu beitragen, ist ein Versäumnis. 
6. Die Abhängigkeiten werden in einem separaten Dokument vom eigentlichen Projektzeitplan erfasst.
7. Pflege von voneinander getrennten RAID-Tabellenkalkulationen pro Projekt ohne gemeinsames Format.
8. Das Versäumnis, im Vorfeld klare Eskalationskriterien festzulegen.
9. Risiken aufzeigen, ohne sie in konkrete Geschäftsauswirkungen zu übersetzen, die für Führungskräfte relevant sind.
10. Das Versäumnis, veraltete oder aufgelöste RAID-Elemente zu schließen, führt zu einer Überfrachtung des aktiven Protokolls.
11. Versäumnis, verwandte oder systemische Risiken über mehrere Projekte hinweg zu identifizieren 
12. Den Führungskräften wird kein Überblick über das gesamte Portfolio geboten, sondern nur Momentaufnahmen einzelner Projekte.
13. RAID als bloße Checkliste zur Einhaltung von Vorschriften anstatt als aktives Entscheidungshilfeinstrument zu nutzen.

RAID ist im Projektmanagement aus mehreren konkreten Gründen wichtig:

• Probleme frühzeitig erkennen – Die meisten Projektfehler treten nicht plötzlich auf. Sie lassen sich auf ein nicht erfasstes Risiko, eine nicht überprüfte Annahme, ein nicht eskaliertes Problem oder eine nicht rechtzeitig erkannte Abhängigkeit zurückführen. RAID deckt diese Probleme auf, bevor sie zu verpassten Fristen oder Budgetüberschreitungen führen.
• Verhindert, dass kleine Probleme zu großen werden – im Ressourcenmanagement oder bei Lieferanten lassen sich leichter beheben, wenn sie frühzeitig erkannt werden. Bleiben sie unbehandelt, können sie zu Terminverzögerungen, Kostensteigerungen und verpassten Meilensteinen führen.
• Wird projektübergreifend kritisch – Verzögerungen, Ressourcenkonflikte oder Probleme mit Lieferanten in einem Projekt bleiben selten auf ein einzelnes Projekt beschränkt. Sie wirken sich häufig auf andere Projekte aus, die dieselben Personen, Lieferanten oder Entscheidungsträger betreffen. RAID hilft Teams, diese Zusammenhänge zu erkennen, anstatt sie erst nach einem Problem zu entdecken.
• Schafft klare Zuständigkeiten und Verantwortlichkeiten – Ein RAID-Protokoll ordnet jedem Risiko, Problem oder jeder Abhängigkeit einen bestimmten Verantwortlichen zu. Dadurch wird aus einem vagen Bewusstsein für ein Problem eine Person, die tatsächlich für dessen Behebung verantwortlich ist.
• Gibt den Teams eine gemeinsame Sprache für den Status – Anstatt einer vagen Aktualisierung wie „Die Dinge sind etwas im Verzug“, verweist ein RAID-Protokoll auf die genaue Ursache: ein benanntes Risiko, Problem oder eine Abhängigkeit, mit einem zugehörigen Status und einem Verantwortlichen.
• Unterstützt eine bessere Entscheidungsfindung – Mit den verfügbaren RAID-Daten können Projektmanager, PMOsund Führungskräfte fundierte Entscheidungen über Prioritäten, Ressourcen und Eskalation treffen, anstatt sich auf Vermutungen oder informelle Informationen zu verlassen.

Die Verwaltung von RAID innerhalb eines einzelnen Projekts ist ein Problem des Projektmanagements. Die Verwaltung von RAID über ein gesamtes Portfolio hinweg ist ein Problem des Projektmanagementbüros (PMO) und der Governance und bringt Herausforderungen mit sich, für deren Lösung eine projektbezogene Tabellenkalkulation nie konzipiert wurde.

Häufige Schwierigkeiten im Unternehmensmaßstab sind:

• Einzelne Projekt-RAID-Protokolle , die isoliert existieren und bei denen es keine Möglichkeit gibt, dasselbe Risiko in mehreren Initiativen gleichzeitig zu erkennen.
• Gemeinsame Risiken, wie beispielsweise ein systemisches Leistungsproblem eines Anbieters, das jedes vom Anbieter unterstützte Projekt betrifft.
• Gemeinsame Lieferanten, bei denen eine Verzögerung bei einem Lieferanten Auswirkungen auf mehrere unabhängige Projekte hat.
• Gemeinsam genutzte Ressourcen , bei denen derselbe Spezialist, dasselbe Team oder dieselbe Infrastrukturkomponente gleichzeitig für mehrere Projekte benötigt wird.
• Projektübergreifende Abhängigkeiten, bei denen der Meilenstein von Projekt A den Starttermin von Projekt B bestimmt.
• Portfolioprioritäten: PMO-Leiter müssen wissen, welche RAID-Elemente die strategisch wichtigsten Initiativen des Unternehmens gefährden, und nicht nur, welches Projekt die längste RAID-Protokollliste aufweist.

PMO-Leiter müssen typischerweise eine vollständige Transparenzkette durchlaufen: RAID-Element, Projektauswirkungen, Programmauswirkungen, Portfolioauswirkungen. Jede einzelne Abweichung von einer Abhängigkeit sollte von der Aufgabenebene bis hin zu der Frage, ob sie eine Lieferverpflichtung auf Portfolioebene gefährdet, nachvollziehbar sein. Diese Transparenzkette mit unzusammenhängenden, projektbezogenen Tabellenkalkulationen zu erreichen, erfordert in der Regel einen erheblichen manuellen Konsolidierungsaufwand, der in jedem Berichtszyklus wiederholt werden muss. Hier spielen Projektmanagement-Plattformen auf Portfolioebene ihre Stärken aus.

Das Verständnis des RAID-Konzepts ist der einfachere Teil. Die Umsetzung in Dutzenden aktiver Projekte, gemeinsam genutzten Ressourcen und den Anforderungen an das Management-Reporting stellt die meisten Unternehmen vor große Herausforderungen. Celoxis ist als umfassende Projekt- und Portfoliomanagement-Plattform konzipiert, und viele ihrer Funktionen lassen sich direkt auf die oben beschriebenen Herausforderungen im RAID-Management anwenden.

Das Kernproblem bei der RAID-Verfolgung mittels Tabellenkalkulationen, E-Mails und Besprechungsnotizen ist die Fragmentierung: Informationen zum selben Projekt befinden sich an verschiedenen Orten, werden von verschiedenen Personen zu unterschiedlichen Zeiten aktualisiert und es gibt keine zentrale Datenquelle. Celoxis unterstützt anpassbare Workflow-Automatisierung, einschließlich Vorlagen für Risiken, Probleme und RAID-Protokolle. So können Teams diese Informationen in derselben Umgebung erfassen, die auch für die Projektverwaltung genutzt wird. Anstatt dass ein Risiko in einer separaten Tabelle ohne Bezug zum betroffenen Zeitplan gespeichert wird, lassen sich RAID-Informationen als Teil des zugehörigen Projekt-Workflows erfassen – zusammen mit Aufgaben, Ressourcen und Meilensteinen, die davon betroffen sein könnten.

2. Überwachung von Risiken in mehreren Projekten

PMOs stoßen häufig auf Schwierigkeiten, wenn jedes Projekt seine eigene Risikotabelle ohne einheitliches Format und ohne einfache Möglichkeit zur Zusammenfassung der Daten führt. Celoxis bietet für das Projektportfoliomanagement , darunter Dashboards und Analysen, die den Projektstatus über mehrere Initiativen hinweg gleichzeitig transparent machen. Dies unterstützt einen nahtlosen Übergang von der individuellen Risikoverfolgung über den Gesamtprojektstatus bis hin zur Portfolio-Transparenz, ohne dass vor jeder Überprüfung manuell Tabellen von jedem Projektteam zusammengestellt werden müssen.

3. Abhängigkeiten zwischen Aufgaben und Projekten verfolgen

Abhängigkeitsmanagement ist ein zentraler Bestandteil von RAID und lässt sich in Tabellenkalkulationen nur schwer präzise darstellen. Celoxis bietet eine Gantt-basierte Projektplanung mit Aufgabenabhängigkeiten und dynamischer Terminplanung. Verschiebt sich eine Vorgängeraufgabe, werden abhängige Aufgaben und nachgelagerte Termine entsprechend aktualisiert. Da Projekte innerhalb desselben Portfolios verknüpft werden können, erkennen Teams frühzeitig, wie sich Verzögerungen in Projekten auf die Zeitpläne anderer Projekte auswirken, anstatt die Folgen erst im Nachhinein zu bemerken.

4. RAID-Verantwortlichkeit und -Verantwortlichkeit verbessern

Ein RAID-Element ohne Verantwortlichen ist lediglich eine Notiz. Durch die Strukturierung von RAID-Informationen innerhalb der Projekt- und Workflow-Umgebung von Celoxis können Elemente bestimmten Verantwortlichen mit zugehörigen Aufgaben und Fälligkeitsterminen zugewiesen werden. So bleibt die Verantwortlichkeit im gesamten Projektplan sichtbar und muss nicht in einem separaten, leicht zu vergessenden Dokument gespeichert werden.

5. RAID-Dashboards und -Berichte erstellen

Verschiedene Stakeholder benötigen unterschiedliche Ansichten derselben RAID-Daten. Projektmanager benötigen detaillierte Einzelposteninformationen. PMO-Leiter benötigen projektübergreifende Muster. Führungskräfte benötigen Informationen zu den Geschäftsauswirkungen und zum Portfolio-Umfeld, nicht nur eine einfache Liste von Einträgen. Celoxis bietet konfigurierbare Dashboards und Berichte, darunter Portfolio-Dashboards und die Möglichkeit, von einer Übersichtsansicht bis in die zugrunde liegenden Projektdetails zu navigieren. So lässt sich die RAID-Transparenz an die jeweilige Zielgruppe anpassen, ohne dass separate manuelle Berichte für jede Zielgruppe erstellt werden müssen.

6. RAID mit Live-Projektdaten verbinden

Dies ist der zentrale Gedanke hinter der Nutzung von RAID als mehr als nur Dokumentation. RAID wird besonders nützlich, wenn Projektteams Risiken, Probleme und Abhängigkeiten mit den Zeitplänen, Ressourcen, Meilensteinen und Portfolioentscheidungen verknüpfen können, die sie beeinflussen, anstatt diese Informationen in einer separaten Datei zu verwalten. Da Celoxis als integrierte Projekt- und Portfoliomanagement-Umgebung und nicht als eigenständiges RAID-Protokollierungstool fungiert, lassen sich RAID-bezogene Informationen zusammen mit Zeitplänen, Aufgaben, Ressourcenzuweisungen, Budgets, Meilensteinen und dem Gesamtprojektstatus anzeigen. Diese Verknüpfung ermöglicht es, eine Verzögerung aufgrund einer Abhängigkeit bis zu ihren tatsächlichen Auswirkungen auf Zeitplan und Ressourcen zurückzuverfolgen, anstatt als isolierte Notiz zu verbleiben, die manuell mit dem Projektplan abgeglichen werden muss.

7. Nutzen Sie KI-gestützte Projekterkenntnisse, wo dies relevant ist

Celoxis umfasst Celoxis Lex, eine KI-gestützte Funktion, die Nutzern hilft, effizienter mit Projektinformationen zu interagieren und diese abzurufen. Dazu gehört das Auffinden relevanter Projektdaten und die Unterstützung der Analyse projektübergreifender Vorgänge. Im Kontext des RAID-Managements kann diese Funktion Teams und PMO-Leitern helfen, relevante Informationen zu Risiken, Problemen oder Abhängigkeiten in einer großen, vernetzten Projektumgebung schneller zu finden. Sie ermöglicht einen schnelleren Zugriff auf vorhandene Projektdaten anstelle autonomer Vorhersagen; sie ersetzt jedoch nicht die Notwendigkeit, dass Teams RAID-Elemente selbst identifizieren, bewerten und bearbeiten.

GroundProbe, ein australisches Unternehmen, das Geogefahrenüberwachungstechnologie für den Bergbau und den Tiefbau entwickelt, stand vor einem häufig auftretenden Problem. Die Produktentwicklungs- und Geophysik-Teams betreuten mehrere Projekte gleichzeitig, teilten sich die Mitarbeiter und arbeiteten mit externen Anbietern zusammen. Vor der Einführung von Celoxis wurde all dies über Tabellenkalkulationen, E-Mails und Gespräche dokumentiert – ohne zentrales System.

Die Risiken und Abhängigkeiten waren real, aber niemand konnte sie klar erkennen. Zwei Projekte benötigten oft gleichzeitig dieselbe Person, was erst bemerkt wurde, als es zu Verzögerungen kam. Die Kosten waren schwer nachzuverfolgen, sodass Budgetprobleme erst spät statt frühzeitig auftraten. Projektmanager erfuhren häufig erst von Problemen, nachdem die Fristen bereits überschritten waren.

Die Business-Analystin Laura Yue leitete die Suche nach einem besseren System und verglich Celoxis mit Microsoft Project, Wrike und Smartsheet. Celoxis wurde aufgrund seiner Planungstools, Dashboards und des Supports ausgewählt.

Nach der Umstellung änderte sich alles. Ressourcenkonflikte wurden sichtbar, bevor sie zu Verzögerungen führten. Dashboards zeigten Engpässe frühzeitig an, statt erst im Nachhinein. Kostenüberschreitungen wurden schneller erkannt. Berichte, deren Erstellung zuvor manuell erfolgen musste, waren nun direkt im System verfügbar.

Laura Yue beschrieb Celoxis als funktionsreich, einfach zu implementieren und hochgradig anpassbar, mit starken Berichts- und Supportfunktionen.

Die Lehre daraus: Die Risiken und Abhängigkeiten von GroundProbe verschwanden nicht mit dem Wechsel zu Celoxis. Neu war jedoch, dass das Team sie nun rechtzeitig erkennen und handeln konnte, da die Informationen mit realen Projektdaten verknüpft waren, anstatt in isolierten Tabellenkalkulationen zu liegen.

RAID-Protokolle sind nur dann sinnvoll, wenn Projektteams die darin enthaltenen Informationen aktiv verwalten und nicht nur protokollieren. Ein veraltetes RAID-Protokoll, das nicht mit dem Zeitplan oder den Abhängigkeiten verknüpft ist, in einer Tabellenkalkulation versteckt ist, die niemand sonst nutzt, keine klaren Verantwortlichen hat oder auf Portfolioebene nicht sichtbar ist, hat als Management-Tool nur begrenzten praktischen Nutzen – egal wie detailliert es bei seiner Erstellung auch gewesen sein mag.

Organisationen, die einige wenige einfache Projekte verwalten, kommen oft mit einer gut gepflegten Tabellenkalkulation und disziplinierten Arbeitsweisen aus. Organisationen, die komplexe Portfolios mit mehreren Projekten, gemeinsam genutzten Ressourcen, projektübergreifenden Abhängigkeiten, Lieferantenbeziehungen und Berichtspflichten gegenüber der Geschäftsleitung verwalten, müssen die RAID-Informationen in der Regel direkt mit der Projektdurchführung verknüpfen: Zeitpläne, Abhängigkeiten, Ressourcen, Dashboards, Berichte und die Entscheidungen, die die Portfolioverantwortlichen tatsächlich treffen müssen.

Celoxis integriert Projektplanung, Risiko- und Problem-Workflows, Aufgaben- und projektübergreifende Abhängigkeiten, Ressourcenmanagement, Dashboards und Portfolio-Reporting in eine vernetzte Umgebung. So sind RAID-Informationen nicht von den zugehörigen Projektdaten getrennt. Wenn das RAID-Management in Ihrem Unternehmen eher ein Portfolio-Management-Problem als eine Tabellenkalkulationsaufgabe geworden ist, lohnt es sich, die Vorteile einer vernetzten Plattform zu prüfen.