Risiken analysieren

Im agilen Ablauf sind bereits Mechanismen vorhanden, die Projektrisiken mindern. Nachdem Sie im siebten Blog-Beitrag neue Domänen im Projekt angelegt haben, lernen Sie heute, wie Sie Risiken 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.

Die Risikoanalyse läuft in mehreren Schritten ab:

• 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 konkrete Risiken ab. Wie findet man 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 das zu entwickelnde System bzw. Produkt. Ihre Hauptursache ist die Komplexität.
• Domänen-bezogene Risiken. Sie entstehen aus der fachlichen Aufgabe und den Gegebenheiten der fachlichen Domäne.
• Technologie-Risiken. Sie sind verbunden mit der einzusetzenden Hardware, System- oder Kaufsoftware, dem Netzwerk, der Kommunikationstechnik etc. Je unbekannter, neuer, unerprobter, umso größer das Risiko.
• Team-Risiken. Sie können sich u.a. aus der Zusammensetzung, Qualifikation, den Soft Skills, der Erfahrung, der Verteilung und dem kulturellen Background der Teammitglieder ergeben.

Ausschnitt aus einer möglichen Projektrisiko-Tabelle

Pro Risikoart sind in der Tabelle mögliche Risikoquellen aufgelistet. Kreuzen Sie in der Tabelle 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.

Diese Projektrisiko-Tabelle ist ein Minimalvorschlag. Sie sollten sie unbedingt ergänzen und zwar gemeinsam mit dem Requirements Engineer.

Risiken identifizieren und bewerten.

Die Risikoidentifikation und -bewertung ist ein weiterer Punkt, an dem der Requirements Engineer dem Projektmanager wichtigen Input liefern kann. Er 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 sollte im Formular des Features oder Epics festgehalten werden. Im Formular gibt es dafür eine spezielle Registerkarte:

Registerkarte für das hauptsächliche Risiko, das mit einem Feature oder Epic verbunden ist.

Der Requirements Engineer kann hier gemeinsam mit dem Stakeholder bereits eine Risikobewertung abgeben und Abwehrmaßnahmen vorschlagen.

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 plädieren dafür, den Anspruch aufzugeben, alle Risiken behandeln zu wollen. Dieser Anspruch ist die Hauptursache dafür, dass Risikomanagement häufig 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.

Unsere Empfehlung: Bilden Sie eine Top-Ten-Liste der Risiken. Definieren Sie die zehn wichtigsten Projektrisiken. So ganz genau sollten Sie es mit der Zahl 10 nicht nehmen: Es können natürlich auch acht, elf oder 14 sein. Aber nicht 50 oder gar 200. Konzentrieren Sie sich darauf, genau diese zehn wichtigsten Risiken zu überwachen und dazu Abwehrmaßnahmen zu definieren. Für jedes Top-Ten-Risiko müssen Sie entscheiden, wie Sie damit umgehen wollen.

Das Tool kennt keinen Artefakttyp Risiko. Was tun, wenn die Analyse und Verfolgung von Risiken sowie die Planung von Gegenmaßnahmen in Ihrem Projekt einen hohen Stellenwert besitzen, so dass Sie zu ausführlicher und nachvollziehbarer Dokumentation verpflichtet sind? Dann empfehlen wir Ihnen folgendes Vorgehen:

• Erweitern Sie Ihre Projekte (oder besser noch die von Ihnen verwendete Projektvorlage) um einen eigenen Artefakttyp Risiko. Erstellen ein Formular zur Beschreibung von Risiken nach Ihren Kriterien. Dann können Sie nicht nur Risiken mit dem Tool anlegen und verwalten, sondern auch Revisionen anlegen und die Historie der Risiken nachvollziehen. Sie können die Risikomerkmale und -beschreibungen außerdem in MS Word-Dokumente hineingenerieren.
• Definieren Sie Beziehungen zwischen Risiken und Aktivitäten (Maß-nahmen). Dann können Sie die Maßnahmen in Ihrer Projektplanung berücksichtigen.
• Definieren Sie Auswertungen der Risiken nach unterschiedlichen Kriterien. Dann können Sie sich jederzeit einen Überblick über die aktuelle Risikolage verschaffen.

Wie Sie eigene Artefakttypen definieren, haben Sie in unserer vorherigen Blogserie erfahren.

Damit haben Sie Ihr Projekt vorbereitet. Wie Sie Ihr Projekt planen, erfahren Sie im nächsten Blog-Beitrag. Wenn Sie bereits Fragen haben, dann melden Sie sich bitte bei uns. Wie immer stehen wir unter service@microtool.de bzw. 030/467086-20 sehr gerne zur Verfügung.

Hinweis:

Alles Wichtige zu objectiF RPM auf einen Blick haben wir für Sie im objectiF RPM Whitepaper zusammengestellt.