Risikomanagement in agilen Projekten

Zusammenfassung

Agile Vorgehensweisen berücksichtigen in Projekten bereits ein implizites Risikomanagement, z.B. fällt beim Scrum-Guide schon in der Einleitung die Aussage „Scrum employs an iterative, incremental approach to optimize predictability and to control risk“. Oftmals bezieht sich die Risikobetrachtung auf einen zeitlichen Horizont von nur wenigen Sprints und auf eher technische Herausforderungen. Bei großen und komplexen Projekten mit agiler Vorgehensweise kommen jedoch auch Release-Planungen (Agile Release Train) ins Spiel, es existieren auch viele interne wie externe Abhängigkeiten, der Produktionsfluss wird heterogener und das Umfeld komplexer. Es ist zu hinterfragen, ob hier solch ein implizites Risikomanagement ausreichend ist. Ein explizites Projekt-Risikomanagement mit der Rolle Risikomanager und entsprechend etablierter Risiko-Kultur kann auch in agile Vorgehensweisen eingebettet werden, ohne dass dies als Verschwendung, Overhead oder gar Störung empfunden wird, sondern viel mehr als weitere Absicherung des Projekterfolgs. Hierzu bedarf es aber auch der Ausrichtung des Risikomanagers und des Risikomanagements entsprechend des agilen Mindsets und der agilen Werte.
 

Motivation

Explizites Risikomanagement ist in großen Projekten unerlässlich, ja, es sollte fester Bestandteil in Projekten sein, denn der Projekterfolg wird sehr oft von Gefahren und Risiken bedroht.

Die Ziele des Projektrisikomanagements sind:

• Das proaktive Erkennen und Behandeln von Risiken verhindert das Entstehen von Problemen und steigert die Produktivität der Mitarbeiter. Diese können sich auf Wertschöpfung und Qualität konzentrieren.
• Ein professionelles Risikomanagement im Projekt erlaubt, vorausschauend und frühzeitig auf Abweichungen zu reagieren, und ermöglicht somit ein effizientes Projektmanagement.
• Das Projektmanagement erhält durch das Risikomanagement Entscheidungsgrundlagen, um Zeit-, Ressourcen- und Budget-Planung zu optimieren.
• Durch ein transparentes Risikomanagement wird für alle Mitarbeiter ein motivierendes Arbeitsumfeld geschaffen, das zu Leistung und Erfolg führt.
• Die Projektgesamtkosten sinken durch den Einsatz des proaktiven Risikomanagements.
• Risikomanagement soll kein Selbstzweck sein, sondern den Prozess zur Erzeugung des Outcomes für die Kunden und Nutzer unterstützen.

Risikomanagement im traditionellen Projektmanagement nach z.B. PRINCE2 oder PMI / PMBOK beschreibt die frühzeitige Risikoidentifikation und Risikoanalyse von potenziellen Projektrisiken mithilfe eines Risikomanagementprozesses. Aufgabe des Risikomanagements ist es hier ebenfalls, auf ein potenzielles Risiko mit einer proaktiven Reaktion zu antworten.

Agile Vorgehensmodelle bzw. Frameworks wie Scrum, Kanban, XP, FAST-Agile (Fluid Scaling Technology) oder SAFe (Scaled Agile Framework) machen keine Aussagen dazu, wie ein Projekt aufgesetzt wird. Stattdessen konzentrieren sich diese auf die empirische Prozesssteuerung von Projekten. Entsprechend existieren in den jeweiligen Communities unterschiedliche Ansätze für das implizite Risikomanagement im Projekt, wenn denn überhaupt darauf eingegangen wird. Im Scrum Guide fällt beispielsweise schon in der Einleitung die Aussage “Scrum employs an iterative, incremental approach to optimize predictability and to control risk”. Was bei Scrum das Lieferrisiko ist, sind bei Ansätzen wie XP technische Risiken. Kommunikationsrollen wie z.B. die des Scrum Masters, haben die Aufgabe, Risiken der Kommunikation und der Zusammenarbeit zu finden und zu adressieren. Flowbasierte Techniken wie Kanban und FAST-Agile haben das Ziel, Ineffizienzen, Lastspitzen und andere Formen der Verschwendung zu vermeiden, was ebenfalls als eine Form des Risikomanagements gesehen werden muss.

Es geht also nicht darum, Risikomanagement den agilen Vorgehensweisen überzustülpen, sondern mit einem expliziten Risikomanagement zu ergänzen und dieses in die Vorgehensweise einzubetten, wobei Besonderheiten bei agilen Vorgehensweisen, wie z.B. gewollte oder akzeptierte Änderungen des Scopes, im Risikomanagement zu berücksichtigen sind. Denn, wenn Risiken nicht überwacht werden, kann nicht beurteilt werden, ob Risiken angemessen gemanagt werden oder nicht. Daher ist ein explizites Risikomanagement gerade in Großprojekten notwendig.
 

Explizites Risikomanagement

Der klassische Risikomanagementprozess ist das Kernstück eines jeden Risikomanagementsystems. Wie in anderen Prozessen werden für jeden Schritt Rollen und Verantwortlichkeiten sowie In- und Outputs definiert. In- und Outputs sind im Sinne des Risikomanagements zumeist Dokumente und Informationen. Inputs sind die notwendigen Voraussetzungen für die Durchführung eines Prozessschrittes. Der Output wird als Ergebnis dieser Durchführung verstanden und bildet den Input für den nächsten Prozessschritt. In jeder Variation eines Risikomanagementprozesses finden sich jedoch folgende Kernaktivitäten wieder, die die Basis eines jeden Risikomanagementprozesses darstellen und gleichzeitig in sich einen Kreislauf bilden (siehe Abbildung 1). Der Risikomanager stellt sicher, dass dieser Prozess eingehalten wird.

Abbildung 1: Risikomanagement-Prozess

Der Risikomanagementprozess wiederum ist eingebettet in das Risikomanagementsystem (siehe Abbildung 2). Zu einem Risikomanagementsystem gehört mehr als nur der eigentliche Prozess, der Risiken bearbeitet. Es gilt nämlich, eine Risikomanagementorganisation in Projekten, Portfolien und Strategien zu schaffen, die es erlaubt, die Projektstruktur und alle relevanten existierenden Prozesse auf die neuen Anforderungen des Risikomanagements einzustellen. Des Weiteren ist eine passende Risikomanagementkultur zu etablieren, denn Risiko muss sich neben den klassischen Dimensionen Kosten, Zeit, Qualität und Leistung als weitere wichtige Kenngröße im strategischen und operativen Denken und Handeln von Mitarbeitern und Führungskräften finden. Bausteine des RMS sind:

• Strategisches Risikomanagement für Projekte: Strategisches Risikomanagement für Projekte soll Risiken, welche die Strategie der Projekte eines Unternehmens betreffen, identifizieren und steuern sowie Impulse in die strategische Planung des Unternehmens geben, sodass negative Auswirkungen abgemildert und Chancen ergriffen werden können. Hierzu zählen auch sog. Querschnittsrisiken, Ereignisse oder Entwicklungen, die sich beim Eintritt in mehreren Projekten gleichzeitig negativ auswirken oder unabhängig voneinander in mehreren Projekten gleiche oder ähnliche Auswirkungen auf die Zielerreichung haben können. Das strategische Projektrisikomanagement basiert auf Daten und Erfahrungen des operativen Projektrisikomanagements, um sich kontinuierlich verbessern und weiterentwickeln zu können. Hier ist das Portfoliomanagement federführend aktiv, indem z.B. wiederkehrende Projektrisiken als Risikofelder (Sammlung Risikofelder), Risikokategorien und Checklisten dokumentiert, gepflegt und bereitgestellt werden.

• Risikomanagement-Strategie: Diese setzt sich aus Risikopolitik, Risikokultur und Richtlinien zusammen. Das Risikomanagement kann nur effizient und effektiv funktionieren, wenn alle Mitarbeiter einer Organisation sich des Nutzens des Risikomanagements bewusst sind. Dies bedarf einer Vorbildfunktion der Führungskräfte. Weiterhin sind strategische Vorgaben aus der Organisation in dem Risikomanagement abzubilden.
  • Risikokultur: Um ein erfolgreiches und umfassendes Risikomanagement zu gewährleisten, muss es in vollem Umfang in der Organisation integriert sein und durch alle Menschen dort werden. Die Risikokultur bildet die Grundlage für ein effektives und effizientes Risikomanagement. Die Risikokultur beschreibt den Umgang mit Risiken auf Basis eines gemeinsamen Verständnisses für Werte des Projektes, einer Risikokommunikation, eines geeigneten Managementstils. Sie nimmt Einfluss darauf, wie Risiken behandelt und gemeldet werden, wer Risiken oder Zweifel im Zusammenhang mit der Form ihrer Identifikation, Analyse, Bewertung und Behandlung melden kann und was passiert, wenn Risiken gemeldet werden. Eine gelebte Risikokultur ist essenziell für die erfolgreiche Umsetzung von Projekten in time, quality und budget, mit entsprechendem Kundennutzen und Wert. Sie zeichnet sich dadurch aus, darzustellen, WARUM Risikomanagement in Projekten wichtig ist und welchen Beitrag jeder einzelne in diesem Kontext leisten kann. Als Fundament des Risikomanagements dient die Risikokultur. Diese zielt auch auf Werte, welche aus der agilen Welt bekannt sind. Hierzu zählen, Transparenz/Offenheit, Mut, Fokus, Commitment und kollaborative Zusammenarbeit. Diese Grundwerte ermöglichen ein effektives Risikomanagement, in welchem jeder Projektbeteiligte bereit ist, sich aktiv einzubringen.
  • Risikopolitik: Die Risikopolitik spiegelt das Verhalten in konkreten Risikosituationen wider und legt fest, wie im Rahmen von risikoreichen Entscheidungen unter Berücksichtigung der Auswirkungen auf die Projekttätigkeit vorgegangen wird. Sie ist daher eine Aufgabe für alle Projekt-Mitarbeiter und sollte sich auch in der Projektphilosophie und im Führungsstil widerspiegeln. Hierbei sind 2 Begriffe sehr wichtig:
    • Risikobereitschaft: (Risk Appetite) dies ist der Grad der Unsicherheit, den ein Projekt bereit ist einzugehen, in Erwartung eines entsprechenden Nutzens. Der Grat zwischen dem Zulassen von Innovation und dem Kontrollieren von Risiken ist sehr schmal. Wie viel Risiken die Teams oder das Projekt tragen kann, ist sehr unterschiedlich.
    • Risikotoleranz: (Risk Tolerance) dies ist der Grad, Menge oder Wert eines Risikos, dem ein Projekt oder Team noch standhalten kann. Wird die Risiko-Toleranzgrenze überschritten, ergeben sich entweder markante Verzögerungen oder entsprechend Mehrbedarf an Budget, der Scope muss ggf. gekürzt oder aber das Projekt muss abgebrochen werden.

• Risikokontext-Identifikation: Der Schritt „Risikokontext-Identifikation“ nimmt eine Sonderstellung im Risikomanagementprozess ein, da dieser bei der Initialisierung des Risikomanagements eines Projektes und bei Änderungen eines Projektes durchgeführt wird. Hier geht es um die Abgrenzung des Projektes, die Stakeholder/Anspruchsgruppen, Umfeldanalysen (POSTUR), Stärken und Schwächen, Projekt-Annahmen, -Informationen und -Einschränkungen, Risiko-Neigung und -Toleranz.

Abbildung 2: Risikomanagementsystem
 

Einbettung von explizitem Risikomanagement in agile Projekte

„Agile“ ist eine Methode, die iterative und inkrementelle Praktiken anwendet, welche mit Hilfe von Feedbackzyklen und flexiblen, eng zusammenarbeitenden Organisationsstrukturen einen Mechanismus erzeugen, um mit Veränderungen und Unsicherheiten umgehen zu können.

Entsprechend mehreren Publikationen und eigener Erfahrungen mit agilen Projektteams scheint es zwei Ansätze rund um Risikomanagement zu geben:

1. Beim Wechsel auf agile Vorgehensweisen lassen mehrere Unternehmen die systematische Betrachtung von Risiken einfach fallen. Dies funktioniert bei kleineren Projekten, bei größeren ist diese Sichtweise jedoch oftmals für „kopfloses agiles Chaos“ verantwortlich.
2. Bei einem restlichen Teil von großen Projekten wird ein klassisches Risikomanagement übergestülpt, was zu Spannungen und Konflikten in der agilen Projektorganisation führen kann, da in agilen Projekten eine andere Sichtweise als bei klassischen Vorgehensweisen existiert – z.B. sind bei agilen Vorgehensweisen laufende Änderungen des Scopes willkommen, bei klassischen sieht man dies nicht so und würde diesen Fakt als Risiko betrachten. Man spricht oft von hybriden Vorgehensweisen, wenn die agile Vorgehensweise mit Rollen wie Projektmanagement und Risikomanagement versehen wird.

Der zweite Ansatz kann jedoch sehr gut gelingen, wenn man explizites Risikomanagement in agile Vorgehensweisen einbettet und eine entsprechende Risiko-Kultur fördert. Hierbei muss die Rolle des Risikomanagers klare Anforderungen erfüllen, Anforderungen, welche auch Werten der agilen Vorgehensweisen entsprechen.

Das agile Manifest fordert dazu auf, Veränderungen zu begrüßen und mit ihnen umzugehen, den Kunden aktiv einzubinden und wertvolle Software zu schaffen, die möglichst früh geliefert werden kann. Das Team soll den Fokus auf Einfachheit legen und das Prinzip „the amount of work not done“ maximieren. Die tägliche Projektarbeit zeigt wiederum: je weiter in die Zukunft geplant wird, desto größer ist die Wahrscheinlichkeit, dass ein Ereignis eintritt, mit dem in der Planungsphase nicht gerechnet wurde. In time-boxed Vorgehensweisen wie Scrum und XP wird deshalb in der Planungsphase der nächste Sprint (1 bis 4 Wochen) fokussiert. Risiken, die während eines Sprints erkannt werden, können schon bei der Planung des Folgesprints berücksichtigt werden. Das gemeinsame agile Wertesystem fordert alle Projektbeteiligten dazu auf, Herausforderungen und Hindernisse aktiv anzugehen, Risiken direkt aus dem Weg zu räumen und den Erfolg des Projektes nachhaltig zu sichern.

Agile Methoden liefern zwar einen Ansatz für implizites Risikomanagement, jedoch muss zumindest für größere Projekte hinterfragt werden, ob dieser Ansatz genügt.

• Werden die Risiken in den Teams genügend berücksichtigt und verfolgt?
• Werden Risiken, die in der weiteren Zukunft liegen oder die sich im Laufe der Zeit entwickeln, frühzeitig erkannt?
• Meist werden Risiken im Team-Fokus gesehen, z.B. technische Risiken, mit welchen sich ein Team auseinandersetzen muss
• Umfeldanalysen und einhergehende Wirkungsanalyse: diese liegen meist außerhalb des Fokus von einzelnen Teams. Hier geht es darum, neben internen auch externe (direkte oder indirekte) Faktoren in Abhängigkeit ihrer Nähe zum Projekt zu analysieren. Denn den sich aus dem Projektumfeld ergebenden Risiken muss auch in agilen Projekten begegnet werden.
• Die Identifizierung von Risikoquellen schafft eine Grundlage für die systematische Untersuchung sich allmählich ändernder Situationen, um Umstände aufzudecken, die sich auf die Fähigkeit des Projektes auswirken, seine Ziele zu erreichen. Risikoquellen können für das Projekt intern oder extern sein.

Daher ist es sehr wichtig schon bereits zum Projektstart, besser noch beim Validieren des strategischen Portfolios bzw. bei der Projekt-Initiierung, Risikomanagement explizit zu betreiben, um sich ein klares Bild über die Risikoexposition im Gesamt-Projekt zu verschaffen.  Mit dem sog. „Risk Scoping“ sollen die Projekt-Ziele und der Projekt-Kontext mit dem Verständnis, was Risiken im Projekt sein könnten, abgeglichen werden. Weiterhin sollten bereits hier die Schlüssel-Risikotreiber mit dem Portfolio-Risikomanagement abgeglichen werden. Spätestens nach der Definition des Product-Goals oder bei einem Anforderungs-Workshop muss daher notwendigerweise ein Risikoworkshop mit dem gesamten Team stattfinden. Release-Planungen (Mittelfristplanung) müssen von Risikobetrachtungen oder Workshops begleitet werden, indem auch die existierende Risikosituation einschließlich der Maßnahmen überprüft wird. Auch Retrospektiven sollten für Risikobetrachtungen genutzt werden.

Mögliche Betrachtungsfelder für potenzielle interne und externe Risiken bzw. Einflussfaktoren können auch bei agilen Projekten z.B. sein:

Abbildung 3: Mögliche Betrachtungsfelder für potenzielle Risiken

Prototypische Risikokategorien bzw. Risikotreiber könnten sein:

Ein sog. „Agile Chart“ kann benutzt werden, um die Events und Artefakte auf den Ebenen täglich, Iteration und Inkrement (z.B. Release) abzubilden. Hier können bzw. sollten auch die Aktivitäten und Artefakte zum Risikomanagement hinterlegt werden, um somit Transparenz und Awareness zu fördern.
 

Agile Werte für das Risikomanagement

Der Risikomanager muss seine Handlung entsprechend des agilen Mindsets ausrichten:

• Respekt: die Teams sind selbstorganisierende Einheiten, welche entsprechend dem Product-Goal für die Inkremente verantwortlich sind. Jetzt ist zwar Transparenz ein Wert agiler Vorgehensweisen, jedoch gibt es auch geschützte Team-Bereiche bzw. Team-Events wie Daily Scrum oder Sprint-Retrospektiven, welche das Team im „geschlossenen Raum“ durchführen möchte. Dies und das Knowhow der Team-Mitglieder müssen akzeptiert und respektiert werden. Es müssen also die bestehenden Prozesse, Rollen und Verantwortlichkeiten respektiert werden (4. Prinzip bei Kanban).
• Mut: Unangenehme Situationen im Projekt aber auch im Projekt-Umfeld müssen sachlich angesprochen werden. Sich an Werten zu orientieren und die dabei praktizierte, offene und direkte Kommunikation erfordern Mut. Eine kontinuierliche Anpassung an Veränderungen sind besonders für die Projektbeteiligten, die das Handeln nach diesen Werten nicht gewohnt sind, eine Herausforderung. Andererseits muss ein Risikomanager auch Team-Mitglieder ermutigen, offen über Risiken zu sprechen, diese zu adressieren. Hierfür muss er das Umfeld der Risiko-Kultur etablieren und vorleben.
• Konfliktmanagement: Der Risikomanager muss firm im Konfliktmanagement sein.
  • Der strukturierte Umgang mit Konflikten entsprechend z.B. dem sog. BALU-Vorgehen (Bemerken eines Konflikts, Ansprechen eines Konflikts, Lösung finden, Umsetzen der Lösungsfindung) muss beherrscht werden.
  • Konflikte müssen auf der objektiven (sachlichen) Ebene ausgetragen werden. Viele Konflikte haben ihre Ursachen auf der psychosozialen (emotionalen) Ebene, diese müssen auf die objektive Ebene transformiert werden.
  • Der Risikomanager selbst kann Ursache von Konflikten werden, da sachliche Konflikte zielbezogen, bewertungsbezogen oder aber auch ressourcenbezogen sind. Zu bewertungsbezogenen Konflikten: Diese Konflikte entstehen in einem Projekt, wenn die Beteiligten Sachverhalte unterschiedlich bewerten, weil sie Informationen auf unterschiedliche Weise wahrnehmen und verarbeiten. Ein Aspekt der Projektarbeit, der häufig zu Konflikten führt, ist das Ergebnis von Schätzungen. Ein Risikomanager könnte Risiken anders bewerten als ein Team oder ein Risikoverantwortlicher.
• Transparenz: Die Risikosituation eines Projektes und die Risiko-Aktivitäten müssen für alle Team-Mitglieder transparent gemacht werden (Risk-Walling), dies gilt auch für den Umgang mit den Risiken. Dies gilt nicht für den Fall von Personen-bezogenen Risiken.
• Feedback und Kommunikation: durch ein direktes, zeitnahes und kontinuierliches Feedback kann Akzeptanz und Vertrauen in das Risikomanagement erhöht werden. Hierzu ist auch eine kollaborative Zusammenarbeit mit den Teams notwendig, sodass schlussendlich die Verantwortung für Risikomanagement auch in den Teams angenommen wird. Der Risikomanager muss Dialoge und den Abgleich von Annahmen und Blickwinkeln fördern.
• Facilitator: Der Risikomanager darf nie in die Situation kommen, von Team-Mitgliedern als Ballast wahrgenommen zu werden. In einem hochspezialisierten Arbeitsumfeld lässt sich oftmals weder das Erkennen noch das Untersuchen noch das Adressieren eines Risikos von der eigentlichen fachlichen Arbeit trennen. Der Risikomanager ist auf die Team-Mitglieder angewiesen, muss diese aber beim Umgang mit Risiken unterstützen und diese ggf. eskalieren oder als Mediator wirken. Diskussionen über Risiken können nur begrenzt werden, wenn der Risikomanager ein entsprechendes Projekt-Knowhow aufgebaut hat. Der Entscheiderkreis (Projektleitung, PLA …) muss spüren, dass er die Risiken durchdrungen hat und Bewertungen eines entsprechenden Informationsstandes durchführen konnte. Maßnahmen zur Mitigation von Risiken dürfen also nie ohne entsprechende Sachkenntnis beschlossen werden.
• Simplicity: Nicht die Menge an Risiken, sondern die Qualität der Risiko-Beschreibungen macht Sinn. Mit einer überbordenden Liste an Risiken verliert man den Überblick, es entsteht Verschwendung. Der Risikomanager muss fähig sein, Risiken entsprechend zusammenführen zu können. Aufgeblähte und ineffiziente Risikolisten führen nur zu enormen Ressourcenverbrauch.
• Flow: In Projekten sind Risiken unvermeidbar, aber wenn man sie kennt, versteht und weiß, wie man mit ihnen umgeht, kann das Projekt ohne gravierende Störungen weitergeführt werden.

Risiken beherrschbar machen: dies ist Kernmerkmal agiler Methoden. Je risikoreicher ein Vorhaben ist, desto wichtiger wird das Anwenden agiler Prinzipien auch im Risikomanagement in seiner Durchführung und somit steigt die Akzeptanz für das Risikomanagement bei agilen Teams. Wirkliches „options thinking“ ist die Entscheidung, wie man mit Risiken umgeht und diese so lange wie möglich zulässt. Letzteres braucht Mut und eine Risiko-offene Kultur.  Ein Risikomanager muss Zeit investieren, um bei einem Risiko-Assessment die Risikobereitschaft und Risikoneigung der unterschiedlichen Team- bzw. Projektmitglieder zu verstehen und zu berücksichtigen.

Hinweis: bei SAFe (Scaled Agile Framework) und DSDM (Dynamic Systems Development Model) gibt es die Rolle des „Release Train Engineer“, welcher auch für Risikomanagement zuständig ist.

Agiles Risikomanagement basiert auf den Prinzipien von Transparenz, Balance und Fluss. Transparenz verfolgt das Ziel, Risiken sichtbar und zugänglich zu machen, damit die Kontrollierbarkeit gewährleistet wird. Risiken und das bewusste Eingehen von Risiken sollten daher im Gleichgewicht sein. Risiken (und Risikomanagement) dürfen auf keinen Fall den Fluss des kontinuierlichen Lieferns verhindern.
 

Risikomanagement in der agilen Organisation

Projekte werden aus einem Projektportfolio heraus gestartet und gesteuert. Das Projektportfolio selbst sollte sich aus der Unternehmensstrategie entwickeln. Alle drei Ebenen und deren Arbeits- und Abstimmungsprozesse müssen entsprechend aufeinander abgestimmt sein, um somit wirklich das „Time to Market“ zu erhöhen. Hierbei muss sich auch das Risikomanagementsystem entsprechend in die drei Ebenen einfügen und die fünf Aktivitäten, die auf einem kontinuierlichen Zyklus basieren und auch zwischen den drei Ebenen eingehalten werden sollten, durchführen:

1. Situation visualisieren
   Risiken werden in Projekten durch die Riskmap visualisiert. Diese schafft einen sichtbaren Überblick über die aktuelle Risikosituation in Projekten. Die Risiken der Projekte müssen auf Portfolio-Ebene zusammengeführt werden, wobei nur die wichtigsten Risiken zwecks Übersichtlichkeit in der Riskmap dargestellt werden sollten. Auf Strategie-Ebene gibt es eine Riskmap, welche die wichtigsten Risiken aus dem Projektportfolio aber auch weitere Geschäftsrisiken beinhaltet.
2. Fokus schaffen
   Auf allen drei Ebenen gilt es, sich auf die wichtigsten bzw. kritischsten Risiken zu konzentrieren und diese schnellstmöglich zu reduzieren. Haben mehrere Risiken die gleiche Ursache, dann sollte auf dieses Bündel von Risiken fokussiert werden.
3. Regelmäßig kommunizieren
   Gerade im Portfoliomanagement können Synergien geschaffen und koordinierende Aktionen veranlasst und Maßnahmen ergriffen werden, die auf einzelne Projektrisiken ausstrahlen. Hierzu sollten sich zum einen die Risikomanager der Projekte untereinander austauschen, aber es muss auch ein Format gefunden werden, die Risiken im Projektportfolio unter Führung des Portfoliomanagers zu besprechen. Denn gerade aus Inter-Projekt-Abhängigkeiten ergeben sich auch des Öfteren Risiken, oder mehrere Projektrisiken haben ihre Ursache in der Ablauf-Organisation. Bei den Kommunikationsformaten und -Inhalten geht es um:
   1. Kommunikation zur Organisation: Wie schaffen wir eine Koordination in kurzen Schleifen?
   2. Kommunikation zum Inhalt: Wie entscheiden wir, was zu tun ist?
   3. Kommunikation zu Zuständigkeiten und Abläufen: Wie entscheiden wir, wie wir etwas tun?
   4. Kommunikation über die Qualität: Wie werden wir besser?
4. Fortschritt messen
   Messungen sind nichts anderes als eine ständige Feedbackschleife: Sie zeigen, ob wir einem Ziel nähergekommen sind oder nicht, ob das Team sich verbessert oder verschlechtert hat. Sinnvolle Messungen zum Risikomanagement und dessen Wirkungen auf die Projekte sind Unternehmensindividuell festzulegen.
5. Verbessern
   Auch das Risikomanagement an sich muss offen für Verbesserungen und Anpassungen sein, auf allen Ebenen. Es geht um die zentralen Fragen, wie sich Risikomanagement in die Organisation, die Abläufe und die Projekte einfügt, welche Ergebnisse hat das Risikomanagement für die Ebenen gebracht und entspricht das Risikomanagement noch den gesetzlichen Anforderungen? Diese Fragen betreffen alle drei Ebenen.

Risikomanagement in den Teams

 
Risiken sind nur die eine Hälfte der möglichen Ereignisse, auf die man reagieren möchte. Chancen für eine Verbesserung der Projekt-Ergebnisse werden hingegen allzu oft nicht wahrgenommen bzw. genutzt. Dabei stellt die Chance ein positives Risiko in der Risikomanagement-Literatur dar. Bei der Chance handelt es sich um eine positive Abweichung von einem Ziel, die mit einer gewissen Wahrscheinlichkeit im Projektverlauf eintreten kann.

In Sprint-Retrospektiven z.B. steht die Arbeitsweise eines Teams im Vordergrund, sie dient dem Team in erster Linie zur Produktivitäts- und Prozessverbesserung, es kann aber auch das gesamte Team von der Durchführung profitieren. In solch einem Rahmen (kollaborativer Arbeitstermin) wäre es möglich, in regelmäßigen Abständen mögliche Ereignisse in der Zukunft, die sich auf das Team und sein Vorhaben auswirken könnten, zu betrachten. Hierzu können auch weitere Stakeholder und v.a. der Risikomanager eingeladen werden. In Team-Arbeit könnten mögliche Ereignisse in der Zukunft gesammelt werden:

Abbildung 4: Chancen- Risiken-Diagramm

Für die Maßnahmenfindung könnte man sich anschließend auf die drei Bereiche, nämlich auf Chancen mittlerer Wahrscheinlichkeit und auf Risiken hoher bis mittlerer Wahrscheinlichkeit konzentrieren. Die Risiken und gefundenen Maßnahmen könnten in ein Team-spezifisches Risiko-Backlog aufgenommen werden. Hierbei sollte der Risikomanager unterstützen, auch bei der Analyse und Bewertung der Risiken. Die Priorisierung der Maßnahmen sollte im Team entschieden werden, wobei auch hier der Risikomanager involviert werden sollte. Denn bei den Maßnahmen kann es sich um sofortige Umsetzungen, normale Arbeiten oder auch um längerfristige Maßnahme handeln.

Gerade zum Beginn eines Projektes sollte ein initialer Risiko-Workshop basierend auf einer Umfeldanalyse durchgeführt werden, um die internen wie extern induzierten Risiken zu identifizieren und zu sammeln. Solche Workshops sollten in regelmäßigen Abständen wiederholt werden, da sich das Projektumfeld und die Situation im Projekt geändert haben könnte. Durch solche Workshops wird auch eine Transparenz der Risiken gegeben.
 

Mehrstufiges Risikomanagement

 
Ziel und Zweck einer guten Risikokultur ist, dass jeder Projektbeteiligte

• Jederzeit Risiken melden kann bzw. auf Risiken aufmerksam macht, auch anonym
• Verantwortung für Risikomaßnahmen übernehmen kann
• für das Projekt und jedes einzelne Team sollte im Rahmen einer Risikopolitik eine Risiko-Toleranzgrenze definiert werden. Hiermit ist auch jedes Team verpflichtet, Verzögerungen/Mehraufwände/verminderte Qualität, die über eine zeitliche/monetäre Toleranzgrenze gehen, an die Projektleitung und den Risikomanager zu melden. Hierzu müssten je Team die Risiko-Toleranzgrenzen (das Maximum, das ein Team tragen kann, damit nicht das gesamte Projekt in existentielle Schwierigkeiten kommt), definiert werden. Gleiches gilt für das Gesamt-Projekt.
• Gleiches gilt für die Risikobereitschaft: Bei der Definition der Risikobereitschaft geht es darum, das akzeptierte unternehmerische Gesamtrisiko im Projekt festzulegen. Im Zentrum steht die Frage, wieviel Risiko ein Team / ein Projekt einzugehen bereit ist, um die damit verbundenen Chancen wahrzunehmen.

Es bietet sich daher an, Risikomanagement auf 3 Stufen zu etablieren:

• Stufe 1: jedes Team managed „seine“ Risiken inklusive Maßnahmen und führt somit sein eigenes Risk-Backlog. Das Team muss seine Risiken, die es eingeht, im Rahmen seiner Eigenverantwortlichkeit mit dem definierten Risiko-Appetit und der Risiko-Toleranzgrenze abgleichen. Hierzu zählen auch Abhängigkeiten zu Lieferanten, zu Linienorganisationen, anderen Projekten oder aber auch den anderen Projekt-Teams, wenn durch diese Abhängigkeiten entweder Verzögerungen im Team erzeugt werden oder entgegengesetzt, wenn Verzögerungen auf der anderen Seite erzeugt werden.
• Stufe 2: der Risikomanager ist zuständig für:
  • Team-übergreifende und externe Risiken. Diese werden als Projektrisiken geführt.
  • Team-Risiken, die über die Risikobereitschaft gehen, also solche, die zu merklichen Verzögerungen im Team und damit auch ggf. im Projekt führen können, sollten ebenfalls in Stufe 2 geführt werden
  • Führt Team-spezifische Risiken, wenn gleiche oder ähnliche Risiken zwischen den Teams bestehen, zu Projekt-Risiken zusammen und bewertet solche aggregierten Risiken mit ausgewählten Team-Mitgliedern
  • Markiert bestimmte Projekt-Risiken als Berichtsrisiken
  • Versieht jedes Projektrisiko mit einer Risikokategorie (dies hilft, Risiken zu strukturieren und somit Transparenz zu schaffen, Risiken zu überwachen, nach Wirkzusammenhängen zu analysieren, zu aggregieren und Risikoberichte zu clustern)
  • Führt eine quantitative Bewertung bei den Projektrisiken durch, wo es möglich ist
• Stufe 3: Das Portfoliomanagement hat mit den Informationen der Projektrisiken die Möglichkeit, aus ähnlichen Risiken unterschiedlicher Projekte Querschnittsrisiken zu bilden und zu bewerten. Hier ist Synergie auch ein wichtiger Aspekt. Wenn mehrere Projekte ähnlich gelagerte Risiken mit z.B. Zulieferungen oder Fluktuation oder Mangel an fachlicher Expertise haben, könnte auf solche Risiken koordinierte Maßnahmen abgestimmt und initiiert werden. Ziel ist es, mit dieser Vereinheitlichung eine grundsätzliche Verbesserung hinsichtlich der Transparenz zu schaffen. Auch können hier horizontale, also operative Zusammenhänge und Wechselwirkungen im Unternehmenskontext deutlich gemacht werden.

Der Risk first Ansatz

 
Zuerst versucht man in kurzen Sprints mit einigen Proof-of-Concepts, Prototypen etc, die Risiken zu identifizieren und auszuräumen. Auch das ist schon Wertschöpfung, folgt aber anderen Prinzipien. Einen ähnlichen Ansatz verfolgen DSDM (Dynamic Systems Development Model) mit einer vorgelagerten Machbarkeits- und Foundations-Phase und DAD (Disciplined Agile Delivery) mit einer vorgelagerten Inception-Phase, um somit Architektur-, Requirements- oder Organisations-Risiken zu reduzieren.

1. Projekt-Definitions-Phase (Projekt-Initiierung): es erfolgt eine sehr grobe Schätzung mit z.B. T-Shirt-Sizes (oder Fibonacci). Diese grobe Schätzung dient zunächst nur, um ein initiales Budget zu bestimmen. Die Eintrittswahrscheinlichkeit sollte bei 50% liegen, also alles andere als genau.
2. Im Projekt eine erste Phase bis zum Point-of-no-Return: Das ist der Punkt, bis zu dem ein Projekt noch relativ gefahrlos komplett abgesagt oder neu aufgesetzt werden kann, ohne dass „das Kind schon in den Brunnen gefallen“, also zu viel Geld verbrannt ist. Dieser Punkt sollte nur maximal 10% der initial geplanten Projektlaufzeit ausmachen. In dieser Phase arbeitet man nach der „Risk first“ Methode, man tut also alles, um die Risiken zu bewerten und auszuräumen. Denn nach dieser Phase sollte man über das Projekt ca. 80% Sicherheit erlangen. In dieser Phase geht es nicht darum, irgendwelchen Business Value zu generieren, sondern nur darum Gewissheit über die Machbarkeit des Projektes zu erlangen.
3. Kreieren des MVP (Minimal Viable Product): Also Umsetzung des Kernprozesses der Anwendung. In dieser Phase wird nur Business Value geschaffen. Aber auch hier gilt es, die Anforderungen im Backlog nach Risiken zu klassifizieren und zu priorisieren.

Die Risikokultur fordert jedes Projekt-Mitglied auf, sich aktiv am Risikomanagement zu beteiligen. Hierbei gibt es aber auch Schwerpunkte einzelner Rollen.

Die Alternative ist das sog. „risk driven model“. Das „risk driven model“ leitet Entwickler an, einen minimalen Satz an Architekturtechniken anzuwenden, um ihre dringendsten Risiken zu reduzieren. Es deutet auf einen immerwährenden Frageprozess hin: „Was sind meine Risiken? Was sind die besten Techniken, um sie zu reduzieren? Ist das Risiko gemindert und kann ich mit dem Codieren beginnen (oder es wieder aufnehmen)?“ Das Modell kann in 3 Schritten zusammengefasst werden:

1. Identifiziere und priorisiere die Risiken
2. Wähle ein Set von Techniken aus und wende diese an
3. Bewerte die Risikoreduktion

Es sollen weder Zeit mit Techniken mit geringer Auswirkung verschwendet noch projektbedrohende Risiken ignoriert werden. Teams möchten erfolgreiche Systeme aufbauen, indem Sie einen Weg einschlagen, der Ihre Zeit am effektivsten nutzt. Das bedeutet, Risiken durch die Anwendung von Architektur- und Designtechniken zu begegnen, aber nur, wenn sie durch Risiken motiviert sind. Zu beobachten ist, dass Teams, die sich auf Funktionen konzentrieren, anderen Bereichen, einschließlich Risiken, weniger Aufmerksamkeit schenken.
 

Risikomanagement in Scrum

 
Ken Schwaber, einer der Autoren von Scrum, ist der Meinung, dass Scrum und insbesondere das Risikomanagement darin, Lücken aufweisen (AgileCollab 2008). Vergleicht man Scrum mit dem klassischen, expliziten Risikomanagement, fallen fehlende Schritte auf, sowie Richtlinien, Prozessdefinitionen und Strategien, weshalb nicht von einem expliziten Risikomanagement gesprochen werden kann. In der aktuellen Fassung (Schwaber, Beedle, Sutherland) wird nur noch von Problemen und Impediments gesprochen.

1. Im agilen Projektmanagement versucht man oftmals, Administration auf ein Minimum zu senken und man geht davon aus, dass schon das agile Vorgehen Risiken automatisch stark verringert, was erfahrungsgemäß nur teilweise stimmt. Z.B. ist die Gefahr, ein Produkt am Markt vorbei zu entwickeln, mit den Iterationen und Releases kleiner. Auch durch konstante Kommunikation innerhalb der Scrum-Teams und mit dem Kunden werden Risiken reduziert. Die Abstimmung zwischen Scrum-Teams wiederum birgt Gefahren der ungenügenden Abstimmung.
2. Risikomanagement wird durch das Impediment-Backlog abgedeckt: Das Impediment-Backlog ist eine Sammlung aktueller Projekt-Hindernisse. Impediments sind Probleme, die gelöst werden müssen. Risiken sind Unsicherheiten, die, wenn sie eintreten, zu Problemen werden.
3. Risiken werden alleine schon durch die enge Teamzusammenarbeit vermieden: Dies fördert zwar bessere Projektergebnisse. Es gibt jedoch auch übergeordnete Risiken, die dadurch nicht abgedeckt werden, wie z.B. „die angedachte Architektur oder Lösung könnte nicht zum Projekterfolg führen“, oder „Fehlendes Knowhow bei den Projektmitarbeitern“, oder „Unzureichende Testpyramide“…

Es wäre daher sinnvoll, die expliziten Risikomanagement-Aktivitäten mit den agilen Frameworks zu verbinden.
 

Abdeckung von Risikomanagement-Aktivitäten in Scrum

 
Scrum bietet dem Product Owner, (PO) dem Scrum Master und den Entwicklern vier wesentliche Eingriffspunkte für das Risikomanagement, nämlich die Scrum-Events:

1. im Sprint-Planning stellen sich die Teams die Fragen „Wieso ist der Sprint wertvoll“, „Was kann in dem Sprint erledigt werden“ und „Wie sollen die ausgewählten Tasks umgesetzt werden“. Hierzu wird vom PO ein Sprintgoal erarbeitet, wonach sich das Team die User-Stories aus dem priorisierten Backlog zieht, die dem Sprintgoal entsprechen und die innerhalb eines Sprints abgearbeitet werden können (abhängig von der Team-Velocity und den Ressource-Verfügbarkeiten). Risiken werden durch das Team direkt in der Planung für den nächsten Sprint berücksichtigt. Durch diese Selbstorganisation im Team erhöht sich das Verantwortungsbewusstsein und damit auch die gelieferte Qualität.
2. Das Daily Scrum bietet dem Team die Möglichkeit, den Fortschritt auf einer täglichen Basis abzuschätzen und zu beobachten, um frühzeitig steuernd einzugreifen. Risiken können so während der Entwicklung erkannt und entweder direkt im Team gelöst werden.
3. Der Sprint-Review gibt den Projekt-Stakeholdern die Möglichkeit, die geleistete Arbeit zu sichten und zu testen und hinsichtlich ihres Nutzens zu bewerten. Somit kann frühzeitig festgestellt werden, ob das Projekt noch auf dem richtigen Kurs ist und wie ggf. das Produkt noch weiter verbessert werden kann. Technischen Schulden (technical debt) entstehen, wenn eine User Story aus Zeitgründen etwa nicht perfekt umgesetzt wurde und in Zukunft nachgebessert werden muss. Das Wachstum der Technical Debt mit jedem neuen Increment erhöht die Komplexität des Produkts und reduziert die Velocity, was ein Risiko darstellt.
4. Bei der Sprint-Retrospective steht die Arbeitsweise des Teams im Vordergrund. Die Sprint-Retrospective dient in erster Linie den Developern zur Produktivitäts- und Prozessverbesserung, es kann aber auch das gesamte Scrum Team von der Durchführung profitieren. Im Mittelpunkt stehen also Lessons Learned und kontinuierliche Verbesserung („Was lief gut während des Sprints“, „Was lief weniger gut während des Sprints“ und „Wie können wir uns verbessern“).

Abbildung 5: Agile Chart um Risikomanagement erweitert

Es gibt Ansätze, die eine implizite Behandlung und Abdeckung typischer Risiken im Scrum-Framework adressieren.

Schwaber und M. Beedle:

DeMarco u. T. Lister

Boehm nach M. Ásgeirrson

Es gibt einige Stellen im Scrum-Prozessframework, an welchen auf Risiken geachtet werden kann. Zuerst soll das Framework als Grundlage dargestellt werden:

Abbildung 6: Prozessframework Scrum

Die einzelnen Risikomanagement-Aktivitäten, die von jedem Projektmitglied durchgeführt werden können (bis auf RM-Planung und quantitative Risikoanalyse), können den Scrum-Prozessschritten in dieser Art zugewiesen werden:

Abbildung 7: Risikomanagement-Aktivitäten im Scrum Prozessframework

Roadmap- und Release-Planung sowie Backlog-Refinements sind nicht explizite Events von Scrum, sollen hier aber berücksichtigt werden, da diese Aktivitäten wichtiger Bestandteil von agilen Skalierungs-Modellen bei großen Projekten sind (J. Highsmith: „Agile Project Management“).

Schematisch können auch immer wiederkehrende Risiken auch den Scrum-Aktivitäten zugewiesen werden:

Abbildung 8: Scrum erweitert um die adressierten Risiken
 

Rollen im Risikomanagement mit Scrum

 
Risikomanagement wird vom gesamten Scrum Team bestehend aus dem Product Owner (PO), dem Scrum Master (SM) und den Entwicklern betrieben. Es ergeben sich jedoch aus den Rollenbeschreibungen und deren jeweiligen Aufgabenspektren unterschiedliche Schwerpunkte für das Risikomanagement.

Chief Product-Owner (CPO)

Der Chief Product Owner ist der übergeordnete Product Manager der POs in dem Falle, dass das Projekt aus mehreren Teams besteht. Er trägt damit die Gesamt-Verantwortung über die Risiken und deren Behandlung.

Product-Owner (PO)

Der Product Owner ist für den wirtschaftlichen Erfolg des Produkts verantwortlich und er muss dabei den Wert des Produkts maximieren, das aus der Arbeit des Entwicklungsteams entsteht. Er organisiert, verwaltet und priorisiert den Backlog mit all seinen Anforderungen und hat damit großen Einfluss auf das Risikomanagement. Er steht mit dem Kunden und weiteren Stakeholdern in ständigem Kontakt und erschließt sich dadurch viele Quellen für die Identifikation von Risiken.

Bei jeder Release-Planung sollte der PO mit dem Entwicklungs-Team und evtl. anderen Stakeholdern (fachlicher und technischer Teilprojektleiter, Projektexterne Stakeholder) die bereits erfassten Risiken überprüfen, und wenn notwendig neu bewerten. Der PO benötigt den Risikowert einer Anforderung, denn der Risikowert ist neben dem Business-Value ein wichtiges Kriterium, wenn er die umzusetzenden Anforderungen priorisiert.

Scrum Master (SM)

Der Scrum Master sichert die Einhaltung der Scrum-Spielregeln, hilft der Organisation Scrum zu verstehen und zu leben, wählt geeignete Praktiken aus, um maximale Transparenz der Artefakte zu schaffen und hilft so, die Risiken zu mindern. Darüber muss er Impediments beseitigen, bevor diese zum Risiko werden. Der Scrum-Master ist die geeignete Person, das Risikomanagement im Scrum-Team zu etablieren.

Entwicklungsteams

Die Entwicklungsteams als selbst-verwaltende, selbst-organisierende Teams sind für die technische Analyse und Umsetzung der Anforderungen (das Wie) in das Produktinkrement verantwortlich. Alle daraus resultierende Risiken sind von diesen Teams zu klären.

Im Estimation Meeting, aber spätestens bei jedem Sprint-Planning sollte das Scrum-Team die Risiken jeder einzelnen Anforderung nochmals kurz überprüfen, evtl. neue Risiken identifizieren und bewerten und Maßnahmen definieren. Damit ist sich das Entwicklungsteam bei der Umsetzung der User-Stories / Aufgaben der Risiken bewusst und kann geplante Maßnahmen umsetzen.

Tester / Testmanagement (optional)

Testspezialisten können zur Qualität des Produkts sehr viel beitragen, indem sie eine Brücke zwischen PO/Kunde und Entwickler darstellen. Sie sprechen beide Sprachen, sowohl die des Kunden, als auch die technische des Entwicklers. Sie können auf Schwachstellen im Projekt als auch auf Usability-Anforderungen des Kunden hinweisen. Sie können Testinfrastruktur zur Verfügung stellen oder zumindest dafür sorgen, dass diese zur Verfügung stehen. In dieser Schlüsselposition können Tester frühzeitig auf qualitative Risiken hinweisen

Risikomanager

Der Risikomanager steuert, koordiniert und überwacht den gesamten Risikomanagementprozess aber auch die Elemente des RMS. Er ist Ansprechpartner für alle Projektbeteiligten, um neu identifizierte Risiken aufzunehmen und mit entsprechenden Kompetenzträgern zu analysieren wie auch zu bewerten. Weiterhin ist er für die Planung, Koordination und Überwachung der Risiko-Maßnahmen verantwortlich. Da der Risikomanagement-Prozess ein lernender Prozess ist, müssen die Risiken und deren Maßnahmen zyklisch neu analysiert und bewertet werden.

Ein wichtiger Aspekt ist die Zusammenführung von Risiken aus unterschiedlichen Teams und die Zusammenstellung wie auch Bewertung auch der zusammengeführten Risiken für die Risikoberichte (Stichwort Berichtsrisiko).

>> zum Seitenanfang