In diesem Artikel beschreibe ich die verschiedenen Schritte, die in der Phase Risikoanalyse innerhalb des Risikomanagements nach V-Modell XT beachtet werden sollten.
 

 
Es wird das Verfahren der semiquantitative Analyse verwendet, mit dessen Hilfe eine formale Klassifizierung der Schadenshöhe und Eintrittswahrscheinlichkeit definiert werden soll. Dies hat zum Ziel, dass Projektrisiken vergleichbar sind und eine Priorisierung erfolgen kann. Hierzu wurden zunächst Skalierungen für die Eigenschaften der Schadenshöhe, der Eintrittswahrscheinlichkeit sowie der Wahrscheinlichkeit der Entdeckung des Problems definiert. Dabei wurde für alle drei Kategorien eine Skala von 1 – 4 gewählt.

Eintrittswahrscheinlichkeit

Stufe	Wahrscheinlichkeit	Interpretation
1	0 ≤ p ≤ 0,25	Es ist eher unwahrscheinlich, dass das Risiko eintritt, aber nicht auszuschließen
2	0,25 < p ≤ 0,5	Das Risiko wird eher nicht eintreten, es ist aber dennoch möglich
3	0,5 < p ≤ 0,75	Das Risiko wird eher eintreten als nicht eintreten, es ist aber keineswegs sicher
4	0,75 < p ≤ 1	Das Risiko wird mit ziemlicher Sicherheit eintreten

Tabelle 1 – Eintrittswahrscheinlichkeiten

 

Wahrscheinlichkeit, dass das Risiko unentdeckt bleibt

Stufe	Wahrscheinlichkeit	Interpretation
1	0 ≤ p ≤ 0,25	Es ist eher unwahrscheinlich, dass das Risiko nicht entdeckt wird, aber es ist nicht auszuschließen
2	0,25 < p ≤ 0,5	Das Risiko wird eher entdeckt, es ist aber dennoch möglich, dass es unentdeckt bleibt.
3	0,5 < p ≤ 0,75	Das Risiko bleibt eher unentdeckt, als dass es erkannt wird.
4	0,75 < p ≤ 1	Das Risiko bleibt mit ziemlicher Sicherheit unentdeckt.

Tabelle 2 – Entdeckungswahrscheinlichkeiten

Schadenshöhe

Für die Definition der Schadenshöhe wurde eine Differenzierung zwischen technischen Schäden und Problemen im Projektverlauf durchgeführt. Für Schäden in Bezug auf die Anwendung dienen die Kernfunktionen des Systems als Grundlage für die Bestimmung der Schadenshöhe, die als Use-Cases definiert wurden.

Abhängig von der Ausführbarkeit dieser Funktionen wird der Schaden in Bezug auf die Anwendung klassifiziert.
Für andere Probleme im Projektverlauf (z.B. Abstimmungsschwierigkeiten) wurde die Komponente Zeit als zu betrachtender Faktor gewählt. Da das fiktive Projekt einen engen zeitlichen Rahmen hat, bei dem eine weitere Bearbeitung des Themas nicht stattfinden wird, wurden entsprechend geringe Abweichungen (zum Beispiel bis 5% Abweichung bei Überschreitung der Projektdauer = Schadensstufe 2) gewählt.

 

Stufe	Schaden in Bezug auf die Anwendung	Schaden in Bezug auf die Projektdauer
1	Das System ist funktionsfähig und es existieren für den Benutzer kaum wahrnehmbare Einschränkungen.	Verzögerungen können aufgeholt werden und der Endtermin ist nicht gefährdet.
2	Die Funktionalität des Systems ist etwas eingeschränkt, aber die wichtigsten Anwendungsfälle sind vom Benutzer durchführbar.	Die Überschreitung der Projektdauer beträgt maximal 5%.
3	Einer oder mehr der wichtigsten Anwendungsfälle sind nur eingeschränkt oder gar nicht benutzbar.	Die Überschreitung der Projektdauer beträgt maximal 10%.
4	Keine der Kernfunktionen ist für den Benutzer verwendbar.	Die Überschreitung der Projektdauer ist größer als 10%.

Tabelle 3 – Bestimmung der Schadenshöhe

 

Risikoprioritätszahl

Auf Grundlage dieser drei Faktoren wird die Risikoprioritätszahl (RPZ) berechnet.

RPZ = Schadenshöhe x Eintrittswahrscheinlichkeit x Entdeckungswahrscheinlichkeit

Eine Risikoprioritätszahl welche größer als 10 ist wird durch die zuvor definierten Skalen als besonders kritisch betrachtet. Für Risiken mit einer entsprechenden Prioritätszahl müssen geeignete Gegenmaßnahmen definiert werden und eine ständige Überwachung und Kontrolle erfolgen. Auf diesen Aspekt wird im Bereich der Risikosteuerung und -überwachung näher eingegangen.

Auf Grundlage der erfassten Risiken aus dem Schritt Identifizierung konnte eine detaillierte Erweiterung der Risikoliste um die genannten Eigenschaften erfolgen. Dieser Prozess erfolgte wieder in zwei Phasen. Zuerst schätzte jedes Teammitglied die Schadenshöhe, Eintritts- und Entdeckungswahrscheinlichkeit unabhängig. Außerdem werden an dieser Stelle schon potentielle Gegenmaßnahmen sowie Indikatoren für die Erkennung des Risikos erfasst. In einer anschließenden Sitzung wird über die Risiken diskutiert, bei denen sehr große Abweichungen der Einschätzungen bestanden.

Ergebnis dieses Prozesses ist eine  detaillierte Risikoliste.

Wie bereits beschrieben, erfolgte die Erfassung der Risiken sowie deren Eigenschaftsbestimmung in einem mehrstufigen Verfahren. An dieser Stelle sollen nun beispielhaft einige Risiken genannt und die Begründung für deren Eigenschaftsdefinition erfolgen. Generell lässt sich jedoch festhalten, dass alle Schätzwerte auf den Erfahrungen der Teammitglieder beruhen, die diese durch Ihre jeweilige berufliche Erfahrung bereits unter Beweis gestellt haben.

 

Nr. 1  – “Liste der möglichen Risiken für das Projekt ist unvollständig”:

Als eines der ersten Risiken wurde die Gefahr der Unvollständigkeit der Risikoliste identifiziert. Das Projektteam war sich dessen schnell bewusst, da nichts den Erfolg eines Projektes so gefährden kann, wie ein plötzlich auftauchendes Risiko, für das im Vorfeld keine Gegenmaßnahmen definiert wurden.

Vor diesem Hintergrund wurde diese Gefahr mit einem relativ hohen Schadenswert (Wert = 3) bewertet. Denn sollte solch eine Gefahr auftauchen werden Kapazitäten für deren Analyse und die Einleitung von Gegenmaßnahmen gebunden sein. Dies kann den Zeitplan verschieben und im schlimmsten Fall ein Projekt scheitern lassen.
Das solch ein Fall eintritt, ist nach Erfahrungen des Projektteams nicht ganz unwahrscheinlich. Da es sich bei diesem Projekt aber um eine relativ abgeschlossene und überschaubare Aufgabe handelt, wird davon ausgegangen, dass dieser Fall eher nicht eintreten wird (Wert = 2).

Ähnlich verhält es sich mit der Entdeckungswahrscheinlichkeit. Sollten Risiken im Umfeld der Anwendung (z.B. Serverabschaltung durch Wartung etc.) auftreten, wird dies relativ schnell auffallen. Anders verhält es sich mit Risiken auf organisatorischer Ebene (zeitliche Verzögerungen, unklare Anforderungen). Diese Probleme sollten aber durch regelmäßige Telefonkonferenzen eher auffallen. Zusammenfassend wurde deshalb ein ähnlich geringer Wert für die Entdeckungswahrscheinlichkeit vergeben (Wert = 2)

Quelle: Projekt des Autors mit Stefan Kleih, Michael Ruhnau, Matthias Köhler, Kim Jansen