Das ROAM Risikomodell in agilen Projekten und seine Mängel

Die Bedeutung des Risikomanagements in Projekten kann nicht genug betont werden. Dies scheint offensichtlich, aber leider haben die meisten Projektmanager oder agilen Teams dies noch nicht erkannt. In den letzten Jahren hat sich das ROAM-Risikomodell in agilen Projekten auf Teamebene, aber auch auf höheren Ebenen in skalierten Frameworks, wie z.B. in SAFe, etabliert. Ich habe viele Jahre Erfahrung im Risikomanagement in Projekten und habe das ROAM-Modell vor einigen Monaten kennengelernt. Aber ich muss sagen, es überzeugt mich nicht! Möchten Sie wissen, warum? Lesen Sie weiter und finden Sie heraus, warum.

Was ist das ROAM Risikomodell?

Bevor ich am Schluss dieses Artikels auf die negativen Punkte von ROAM eingehe, erhalten Sie zuerst eine detaillierte Beschreibung dieses Modells, wie es propagiert wird.

Das ROAM Risikomodell ist ein kollaborativer, leichtgewichtiger Risikomanagement-Ansatz, der bei agilen Projekten hilft, Risiken zu identifizieren und angemessen mit ihnen umzugehen. Das SAFe-Framework (Scaled Agile Framework) hat ROAM durch seine Verwendung während dem PI-Planung populär gemacht.

ROAM ist eine Abkürzung für Resolve, Own, Accept, und Mitigate. Dies sind die vier Stati, in welche die Risiken, zu ihrer Bewältigung eingeteilt werden. Das ROAM-Modell fördert die Zusammenarbeit auf allen Ebenen, da die gesamte agile Organisation aufgerufen ist, bei der Identifizierung und Priorisierung von Risiken mitzuwirken. Außerdem schafft das ROAM-Modell ein System der Verantwortlichkeit für das Risikomanagement, das Zeit, Mühe, Geld und Stress spart. Die Implementierung eines einfachen Risikomanagement-Modells wie ROAM, zum proaktiven managen von Risiken, kann für ein ganzes Unternehmen den Unterschied zwischen Erfolg und Misserfolg ausmachen.

Was bedeutet ROAM?

ROAM ist ein Kurzbegriff für Resolve, Own, Accept, and Mitigate. Hier finden Sie eine detaillierte Erklärung aller vier Buchstaben:

1. Resolved (gelöst/behoben): Das festgestellte Risiko stellt keine Bedrohung mehr dar. Es sind keine Maßnahmen erforderlich.

Dieser Status ist zutreffend, wenn das Team Maßnahmen ergriffen hat, um das Risiko zu beseitigen, oder weil festgestellt wurde, dass das Risiko nicht mehr besteht. In jedem Fall bedeutet “Resolved”, dass keine Bedenken mehr bestehen.

2. Owned (besitzen): Der Status “Owned” zeigt, dass jemand die Verantwortung übernommen hat das Risiko zu managen.

Owned ist der einzige Status, der bedeutet, dass das Risiko noch bearbeitet werden muss. Die anderen drei Stati sind alles Varianten von “Done”. Im Idealfall hat das Team einen Plan zur Risikominderung der Owned-Risiken schon besprochen. Der Owner übernimmt die Verantwortung für die Ausführung des Plans und ist somit Eigentümer des Risikos. Wenn bisher kein Risiko-Vermindersungsplan definiert wurde, wird der Owner gemeinsam mit dem Team einen Plan erarbeiten und das Risiko dann überwachen, bis es nicht mehr notwendig ist.

3. Accepted (akzeptiert): Ein akzeptiertes Risiko ist ein Risiko, dass das Team zur Kenntnis genommen und beschlossen hat, keine Maßnahmen zu ergreifen, um es zu beseitigen. Wenn es passiert, dann passiert es!

Diese Entscheidung kann angemessen sein, wenn die Bemühungen, um eine Risikominderung mehr kosten würde als wenn das Risiko eintritt.
Das Risiko zu akzeptieren ist auch eine angemessene Entscheidung in Situationen, in denen es keine Möglichkeiten zur Verminderung oder Eliminierung des Risikos gibt. Wenn man nichts tun kann, um das Problem zu verhindern, dann dokumentieren wir, dass wir uns des Problems bewusst sind und gehen weiter.

4. Mitigated (vermindert): Ein vermindertes Risiko ist zwar verkleinert, aber nicht beseitigt.

Der Status “Mitigated” wird verwendet, wenn alles getan wurde, um das Risiko zu bewältigen. Das Team kann das Risiko aber nicht vollständig eliminieren, weil z.B. die für die vollständige Eliminierung erforderlichen Maßnahmen zu kostspielig sind. Eine Bedrohung gilt als eingedämmt, wenn die Eintrittswahrscheinlichkeit oder die Auswirkungen des Risikos massgeblich verringert wurden, das Team jedoch keine weiteren Schritte zur Behebung unternehmen will.

Die Stati “Resolved” und “Mitigated” werden oft miteinander verwechselt. Der Hauptunterschied zwischen diesen beiden ist, dass “Resolved” bedeutet, dass es kein Risiko mehr gibt; es wurde beseitigt. Mitigated bedeutet, dass das Team alles in seiner Macht habende getan hat, um das Risiko zu verringern, aber ein gewisses Element des Risikos bestehen bleibt.

Das ROAM-Board

Unten sehen Sie ein Beispiel für ein ROAM-Board mit den vier Quadranten (Resolved / Owned / Accepted / Mitigated) und einer Spalte “Neu”, in der neue Risiken eingetragen werden, die das Team noch nicht besprochen hat. Nach der Besprechung der neuen Risiken wird deren Karte, je nach Ergebnis an die entsprechende Stelle des Boards verschoben.

Wenn sich das Team einig ist, dass keine Maßnahmen ergriffen werden können oder sollten, wird die Karte in die Spalte “Accepted” übertragen. Wenn das Team das Risiko in der unmittelbaren Diskussion nicht bewältigen konnte, wird die Karte in den Quadranten “Owned” übergehen, sobald eine Person die Verantwortung für das Managen der Risikos übernommen hat.

ROAM im SAFe PI-Planning

In einer agilen Planungssitzung, z.B. im SAFe PI-Planning (Quartalsplanung), werden die identifizierten und diskutierten Risiken während der Planungssitzung in die ROAM-Kategorien eingeordnet. Dann wird mit einer Abstimmung (Confidence Vote) über die Priorisierung der zu bearbeitenden Risiken entschieden.
Wenn ein Risiko als Resolved, Accepted oder Mitigated eingestuft wird, gilt es im Laufe der PI-Planungssitzung – und in der Zeit danach – effektiv als erledigt. Die einzige Ausnahme ist “Owned”, das weitere Maßnahmen durch den “Owner” des Risikos erfordert. Es ist wichtig, einen Prozess zur Weiterverfolgung von Risiken der Kategorie “Owned” zu definieren, um sicherzustellen, dass die Maßnahmen für diese Risiken effektiv geplant, ausgeführt und überwacht werden.

Vielleicht verwendet Ihre agile Organisation bereits eine Kanban-Lösung, um ihre Arbeit zu visualisieren und zu verwalten, dann sollten Sie in Erwägung ziehen, Ihr Risikomanagement an derselben Stelle zu visualisieren. Für die PI-Planung ist es jedoch sinnvoller, das ROAM-Board zu verwenden, auf dem Sie ein Brainstorming durchführen und die Risiken kategorisieren können. Verschieben Sie dann alle ausstehenden Aufgaben im Zusammenhang mit dem Risikomanagement auf die entsprechenden Ausführungsboards, damit sie visualisiert werden.

ROAM Risikomanagement auf jeder Ebene

Das ROAM-Risikomodell kann auf jeder Ebene eines skalierten agilen Frameworks wie SAFe oder Scrum@Scale eingesetzt werden. Die meisten Praktiker sind sich einig, dass Risiken auf Teamebene behandelt werden sollten, idealerweise während des PI Planning. Aber Risiken, die den gesamten Agile Release Train (ART) betreffen könnten, sollten auf die ART-Ebene eskaliert werden.

Effektive Eskalationspraktiken zu haben bedeuten, dass Teams nicht mehr mit demselben Risiko konfrontiert werden oder diese mehrmals managen müssen. Das bedeutet auch, dass Massnahmen für Risiken auf höherer Ebene mit größerer Wahrscheinlichkeit erfolgreich sein werden, da sie den gesamten Umfang des Risikos berücksichtigen.

Was ist der Nutzen des ROAM Risikomodells?

Was die Befürworter des ROAM-Risikomodells sagen: Das ROAM-Modell ist flexibel und agil: Es passt gut zu den agilen Prinzipien, da es die Anpassungsfähigkeit und Reaktionsfähigkeit auf sich ändernde Risikofaktoren fördert. Es fördert die Zusammenarbeit auf allen Ebenen, da die gesamte agile Organisation aufgerufen ist Risiken zu identifizieren und zu priorisieren. Außerdem schafft das ROAM-Modell ein System der Verantwortlichkeit für das Risikomanagement, das Zeit, Aufwand, Geld und Stress spart. Ein einfaches Risikomanagementmodell wie ROAM zum proaktiven Managen von Risiken zu implementieren kann für ein ganzes Unternehmen den Unterschied zwischen Erfolg und Misserfolg ausmachen.

Mit meiner Erfahrung im Risikomanagement sehe ich einige Probleme mit dem ROAM-Risikomanagementmodell. Lesen Sie weiter und erfahren Sie welche.

Die Mängel beim ROAM Risikomodell

Die agile Art des Risikomanagements mit dem ROAM-Risikomodell hat viele Nachteile gegenüber den traditionellen Risikomanagementansätzen. Hier finden Sie die offensichtlichsten Probleme und geeignete Lösungen.

1. Einfachheit: ROAM konzentriert sich auf die Einteilung von Risiken in vier Kategorien (Resolve, Own, Accept, Mitigate), was die Risikobewertung im Vergleich zu umfassenderen Risikomanagementkonzepten stark vereinfacht. Ihm fehlt jedoch die Tiefe, die für komplexe Projekte oder Situationen erforderlich ist.
2. Begrenzte Risko-Identifikation und -Analyse: ROAM fördert keine gründliche Identifizierung und Analyse von Risiken, da oft nur wenig Zeit dafür aufgewendet wird. Es identifiziert und kategorisiert Risiken schnell, übersieht aber möglicherweise kritische Details oder potenzielle Auswirkungen, die ein umfassenderer Risikomanagementansatz identifizieren könnte.
3. Überbetonung der Akzeptanz: Bei dem schnellen, agilen ROAM-Ansatz besteht die Tendenz, Risiken schnell und ohne angemessene Analyse zu akzeptieren, was später zu potenziellen und unerwarteten Problemen führt.
4. Risiken werden unterschätzt: Maßnahmen werden nur für kritische Risiken definiert. Die anderen Risiken werden als unkritisch mit einer geringen Eintrittswahrscheinlichkeit eingestuft und ohne detaillierte Analyse schnell auf die Quadranten Resolved, Accepted oder Mitigated des ROAM-Boards verschoben. Dies ist effizient, aber, aus meiner Sicht “unverantwortlich”.
5. Mangel an formeller Dokumentation: ROAM ermutigt zu gemeinsamen Diskussionen, legt aber keinen Wert auf eine formale Dokumentation der Risiken. Bei größeren Projekten können unzureichend oder gar nicht dokumentierte Risiken zu Verwirrung und Missverständnissen führen und auch bei Audits Probleme bereiten.
6. Keine regelmäßige Überprüfung und Neubeurteilung: Agile Teams sollten die, anhand des ROAM-Modells identifizierten Risiken, regelmäßig neu bewerten und überprüfen. Dadurch wird sichergestellt, dass die Risiken kontinuierlich bewertet werden und im Laufe des Projekts Anpassungen möglich sind. Dies gilt nicht nur für die Owned Risiken, sondern auch für die Accepted und Mitigated Risiken. Dazu gehört auch periodisch neue Risiken zu identifizieren, idealerweise bei jedem Sprint Planning.
7. Keine Schulung und Kompetenzentwicklung: Den an der Risikobewertung beteiligten Teammitglieder sollten Schulungen und Unterstützung angeboten werden. Vermitteln Sie ihnen die notwendigen Fähigkeiten und Kenntnisse, um Risiken umfassend zu identifizieren, zu bewerten und zu steuern. Kennen die Teammitglieder zum Beispiel Basics, wie z.B. den Unterschied zwischen Risiko, Issue und Impediment?

Der Unterschied zwischen Risiko, Problem, Issue und Impediment

Zusammenfassung

Das ROAM-Modell bietet zwar eine einfache und schnelle Möglichkeit, Risiken zu bewerten und zu kategorisieren, doch fehlt ihm die Tiefe und Detailgenauigkeit eines umfassenderen Risikomanagementansatzes. Um diese Limitierungen zu verringern, können agile Teams es mit einer detaillierten Analyse und ausreichender Dokumentation kombinieren, identifizierte Risiken regelmäßig überprüfen und eine offene Kommunikation fördern. Aber auch Teams schulen, damit diese die Fähigkeiten haben für ein effektives Risikomanagement.

Im Allgemeinen habe ich jedoch den Eindruck, dass ROAM ein “Risk Management on the fly” ist. Zu einem detaillierteren Risikomanagement höre ich schon das Gegenargument: “Das ist aber nicht mehr agile!” Hier meine Antwort dazu:

Wollen Sie lieber agil sein oder zukünftig weniger Probleme haben?

Mehr zum Risikomanagement in Projekten