Der Umgang mit Risiken in agilen Projekten

by | 12.09.2018 | Requirements Engineering

In agilen Projekten gibt es verschiedene Mechanismen, die frühzeitig Risiken mindern können. Denken Sie zum Beispiel an die Sprint-Reviews zur Abnahme der Sprint-Ergebnisse, die es erlauben, frühzeitig gegenzusteuern, wenn die Lösung am tatsächlichen Bedarf der Anwender vorbeigeht oder sich die Rahmenbedingungen für das Projekt kurzfristig geändert haben. Auch quantitative Metriken wie das Burn-up Chart helfen noch während eines Sprints zu erkennen, dass etwas nicht rund läuft. Doch reichen diese Optionen bereits für eine wirksame Risikominimierung aus oder benötigen Sie nicht eine zusätzliche, systematische Vorgehensweise, um Risiken zu identifizieren?

Als Projektmanager übernehmen Sie die initiale Risikobewertung des Projekts. Ein Risiko ist ein potenzielles Problem, dem man präventiv begegnen sollte. Alles, was Kosten, Termine, Lösungsqualität und damit den Projekterfolg negativ beeinflussen kann, stellt ein Risiko für das Projekt dar. Um es deutlich zu sagen: Hier sind die Risiken für Ihr Projekt gemeint, nicht die Geschäftsrisiken, denen das Unternehmen ausgesetzt ist, wenn das Projekt scheitern sollte. Im ersten Schritt geht es darum, Risiken zu identifizieren, mit denen Ihr Projekt konfrontiert ist. In den nächsten Schritten müssen Sie dann die Risiken bewerten und schließlich darüber entscheiden, mit welchen Maßnahmen Sie die Risiken abwehren wollen.

Wo lauern Risiken? Wenn die Risiken Ihres Projekts nicht gerade auf der Hand liegen, brauchen Sie eine systematische Vorgehensweise, um sie zu identifizieren. Dafür haben wir einen Vorschlag:

Risiken identifizieren

Ermitteln Sie – zunächst ganz grob – mögliche Risikoquellen. Leiten Sie von den gefundenen Risikoquellen dann konkrete Risiken ab. Das klingt leicht, doch wie finden Sie mögliche Risikoquellen? Dazu können Sie eine Projektrisiko-Tabelle verwenden. Verschaffen Sie sich mit dieser Tabelle zunächst Klarheit darüber, welche Arten von Risiken für Ihr Projekt überhaupt relevant sind. Die Tabelle unterscheidet vier potenzielle Risikoarten:

  • System-/Produkt-Risiken. Sie beziehen sich direkt auf die zu entwickelnde Software. Ihre Hauptursache ist Komplexität.
  • Anwendungsbereichsbezogene Risiken. Sie entstehen aus der fachlichen Aufgabe und den Gegebenheiten des Anwendungsbereichs.
  • Technologie-Risiken. Sie sind verbunden mit der einzusetzenden Hardware, System- oder Kaufsoftware, dem Netzwerk, der Kommunikationstechnik etc. Je unbekannter, neuer, unerprobter, desto größer das Risiko.
  • Team-Risiken. Sie können sich aus der Zusammensetzung, Qualifikation und Zusammenarbeit der Teammitglieder ergeben.

Listen Sie in der Tabelle pro Risikoart mögliche Risikoquellen auf. Kreuzen Sie anschließend pro Risikoquelle die Eigenschaft an, die für Ihr Projekt gilt. Sie sehen dann sofort, ob sich daraus ein niedriges, mittleres oder hohes Risiko ableitet.

Zur besseren Übersicht finden Sie nachfolgend vier Tabellen für die genannten vier potenziellen Risikoarten. Die Tabelle für System-/Produktrisiken könnte wie folgt aussehen:

Die Tabelle für Domänen-bezogene Risiken beinhaltet folgende Risikoquellen:

DOMÄNEN-BEZOGENE RISIKEN NIEDRIG MITTEL HOCH
Fachliche Aufgabe einfach durchschnittlich komplex
Wesentliche Features/Epics bekannt und ziemlich stabil teilweise bekannt unklar
IT-Erfahrung der zukünftigen Anwender groß durchschnittlich keine
Unterstützung durch das Management groß normal gering
Grad der fachlichen Innovation gering durchschnittlich hoch

Natürlich gibt es auch Technologie-Risiken:

TECHNOLOGIE-RISIKEN NIEDRIG MITTEL HOCH
Technologie (Hardware, Netzwerk, System- und Fertigsoftware, Bibliotheken und Frameworks etc.) einfach durchschnittlich komplex
Zielumgebung bekannt und erprobt teilweise bekannt noch unklar
Entwicklungsumgebung bekannt und erprobt teilweise bekannt noch unklar
Grad der technischen Innovation gering durchschnittlich hoch

Und auch es auch Risiken in Bezug auf Ihr Team:

TEAM-RISIKEN NIEDRIG MITTEL HOCH
Teamgröße 1 – 5 6 – 10 mehr als 10
Projektdauer 1-3 Zeitmonate 4-6 Zeitmonate länger als 6 Zeitmonate
Technologieerfahrung des Teams groß durchschnittlich keine
Entwicklungserfahrung des Teams groß durchschnittlich keine
Kenntnisse des Teams über den Anwendungsbereich fundiert durchschnittlich keine
Mitarbeit des Kunden Vollzeit Teilzeit sporadisch
Externe oder nur zeitweise beschäftigte Mitarbeiter keine einige viele
Konfliktpotenzial im Team gering normal hoch
Arbeitsumfeld und technische Infrastruktur sehr gut befriedigend unzureichend

Diese Projektrisiko-Tabelle ist ein Minimalvorschlag. Sie sollten sie unbedingt ergänzen, idealerweise gemeinsam mit einem Requirements Engineer.

Risiken identifizieren und bewerten

Requirements Engineering hilft Ihnen bei der Produktentwicklung, Werte für Stakeholder zu schaffen. Welche Ziele verfolgen Ihre Stakeholder? Welche Anforderungen ergeben sich daraus? Welche Abhängigkeiten bestehen zwischen einzelnen Anforderungen und welche zu technischen Komponenten? Dieses Wissen um Zusammenhänge ist wichtiger Input für Ihre Risikoidentifikation und -bewertung. Der Requirements Engineer kann insbesondere dazu beitragen, differenzierte System-/Produktrisiken zu identifizieren, indem er in der Diskussion mit den Stakeholdern über Features und Epics immer auch die Frage stellt: Welches Hauptrisiko sehen Sie in Zusammenhang mit diesem Feature für die Lösung bzw. das Projekt? Das Ergebnis können Sie anschließend als separate Information – wenn Sie mit Werkzeugen für das Requirements Engineering arbeiten beispielsweise im Formular des Features oder Epics – festhalten.

Die Erfassung von Risiken bei einem Feature

Die Erfassung von Risiken bei einem Feature

Der Requirements Engineer kann natürlich gleich gemeinsam mit dem Stakeholder bereits eine Risikobewertung abgeben und Abwehrmaßnahmen vorschlagen.

Fokus auf die Top-Risiken

Nachdem Sie Risiken identifiziert haben, bedenken Sie bitte: Nicht jedes mögliche Risiko ist auch ein tatsächliches Risiko. Und nicht alle Risiken sind in gleichem Maße bedrohlich. Analysieren und bewerten Sie die erkannten Risiken. Wir schlagen Ihnen vor, den Anspruch aufzugeben, alle Risiken behandeln zu wollen. Dieser Anspruch ist die Hauptursache dafür, dass Risikomanagement gar nicht mehr stattfindet, wenn es im Projekt eng wird. Aufwand und Nutzen des Risikomanagements müssen in einem vernünftigen Verhältnis zueinander stehen. Bilden Sie stattdessen eine Top-Ten-Liste der Risiken. Definieren Sie die zehn wichtigsten Projektrisiken. So ganz genau sollten Sie es damit nicht nehmen: Es können natürlich auch acht, elf oder 14 sein. Aber nicht 50 oder 200. Konzentrieren Sie sich darauf, die für Sie wichtigsten Risiken zu überwachen und genau dazu Abwehrmaßnahmen zu definieren. Für jedes Top-Risiko müssen Sie entscheiden, wie Sie damit umgehen wollen. Grundsätzlich haben Sie folgende Alternativen:

  • Sie können versuchen, das Risiko zu vermeiden oder doch wenigstens die Eintrittswahrscheinlichkeit zu reduzieren.
  • Sie können versuchen, den Schaden zu begrenzen.
  • Sie können versuchen, Risikoreduzierung und Schadensbegrenzung zu kombinieren.
  • Oder Sie akzeptieren das Risiko und verzichten auf die Planung von Maßnahmen. Sollte das Risiko eintreten, dann bestimmen Sie das weitere Vorgehen aus der aktuellen Projektsituation heraus.

Wohin mit den Top-Risiken und den beschlossenen Maßnahmen? Machen Sie sie am besten für alle Beteiligten sichtbar in Form eines Risiko-Boards.

Das Risiko-Board als einfaches Kommunikationsmittel

Das Risiko-Board als einfaches Kommunikationsmittel

Die Einschätzungen werden nicht stabil bleiben. Es werden Risiken hinzukommen und von der Liste verschwinden. Sobald das Team mit der Entwicklungsarbeit beginnt und der Requirements Engineer parallel dazu immer mehr Features zu User Stories verfeinert, geht nicht nur Verantwortung für die Lösung, sondern auch die für das Risikomanagement auf das gesamte Team über. Das Risiko-Board wird zum Arbeitsmittel für das ganze Team. Was soll passieren, wenn die angestrebte Lösung nicht so umgesetzt werden kann wie gedacht, wenn die gekauften Control anders funktionieren als der Anbieter auf seiner Web-Site verspricht, wenn die wichtigste Know-how Quelle des Teams für ein spezielles Thema ausfällt, etc.? – Technologische und personelle Risiken müssen während der Entwicklung im Team ermittelt und bewertet sowie Maßnahmen geplant und beschlossen werden. Das kann zum Beispiel bei der Sprint-Planung geschehen.