02, Risiko-Controlling

Risiko-Controlling: Risiken in Software-Projekten in den Griff bekommen (Teil 2)


Welche Gründe für die Anwendung von Risikomanagement im Software Life Cycle sprechen, hat (Teil 1) zu diesem Beitrag bereits näher behandelt. Wie ein solcher, im Unternehmen installierter Risikomanagement-Prozess im Optimalfall aussehen könnte, ist im Folgenden Thema.

Risiko-Controlling in Softwareprojekten ist dadurch gekennzeichnet, dass die risikobehaftete Aufgaben- bzw. Problemstellung zumeist nur einmalig auftritt. Zudem unterscheiden sich die einzelnen Entwicklungsphasen im Rahmen des Software Engineering von den für viele Unternehmen bereits bekannten Projektphasen hinsichtlich der klassischen Produktentwicklung. Die Absicherung und Schadensminimierung von dem Softwareprojekt inne wohnenden Risiken ist anzuraten: Siehe auch Risiko-Controlling: Risiken in Softwareprojekten in den Griff bekommen (Teil 1).

Um im Rahmen von Risiko-Controlling Risiken frühzeitig zu erkennen sowie in der Folge dementsprechend zu vermeiden, abzuschwächen oder für den Ernstfall vorzusorgen, genügt in vielen Fällen ein Risikomanagement basierend auf einfachen Methoden. Es beginnt dabei idealerweise bereits in der Projektvorphase – also noch vor dem eigentlichen Projektentscheid bzw. -start – und erstreckt sich über sämtliche nachfolgenden Phasenschritte.

Grundsätzlich kann ein Risiko-Controlling- bzw. Risikomanagementprozess vereinfacht in vier Stufen unterteilt werden. Der Controller sollte in all diesen aktiv mitwirken – zumindest in initiierender und koordinierender Funktion. Da jede Projektphase vom inhaltlichen Standpunkt her andere Schwerpunkte setzt, ist der nachfolgend beschriebene vierstufige Prozess zu Beginn jeder Hauptphase im Software-Lebenszyklus (also u.a. Projektvorbereitung, Business Blueprint, Realisation, Final Preparation, Live-Einsatz, Support) erneut zu durchlaufen.

Stufe 1: Die potentiellen Risiken identifizieren und klassifizieren
Stufe 2: Die Risiken umfassend analysieren und bewerten
Stufe 3: Maßnahmen für die bewerteten Risiken planen und managen
Stufe 4: Die Risiken konsequent und kontinuierlich nachverfolgen

 

Stufe 1: Die potentiellen Risiken identifizieren und klassifizieren

Bevor es an die Identifikation potentieller Risiken geht, steht zunächst erst einmal die Frage im Raum, was genau eigentlich ein Risiko ist. Die in der Literatur dazu teils variierenden Definitionen sind im Kern jedoch identisch: Unter Risiken versteht man derartige Situationen, welche unter gewissen Umständen eintreten und dadurch unterschiedlich gearteten, negativen Einfluss auf ein bestimmtes Projekt bzw. Vorhaben nehmen.

Die Risikoidentifikation hat das Erkennen und Antizipieren solch möglicher Gegebenheiten als Hauptziel. Dabei ist zunächst nur das reine Identifizieren eines Risikos auf dieser Prozessstufe von Relevanz, eine Bewertung zum Beispiel hinsichtlich Eintrittswahrscheinlichkeit und Einfluss auf das Softwareprojekt findet noch nicht statt. Dadurch kann man gleichzeitig verhindern, dass bestimmte Risikofaktoren verfrüht überhaupt nicht in die Risikoanalyse mit einbezogen werden – wegen zum Beispiel (im Nachhinein falscher) subjektiver Bewertung des Risikos durch Einzelne als irrelevant und nicht „kriegsentscheidend” für das Gesamtprojekt.

Um alle denkbaren Risiken zu erfassen, darf die Phase der Risikoidentifikation niemals alleine Aufgabe des Projektleiters sein. Schließlich können projektgefährdende Risikoelemente aus den unterschiedlichsten Unternehmensbereichen und -funktionen erwachsen. Auch können sich Erwartungen über die bereits vorliegenden Voraussetzungen im Projektverlauf als falsch herausstellen. Entsprechend ist insbesondere in der Projektstartphase ein breites, interdisziplinäres Experten-Team gefragt, mögliche Gefahren für das (Teil-)Scheitern des Softwareprojektes aufzudecken – gegebenenfalls je nach Projektgröße auch iterativ über mehrere Projektebenen und verschiedene Personengruppen hinweg.

Jedes Projekt birgt Risiken in sich, andernfalls wäre es kein Projekt. Im Normalfall entscheiden sich Unternehmen dann dafür, ein neues Softwareprojekt zu initiieren, wenn davon ausgegangen werden kann, dass die resultierenden Chancen – beispielsweise Erhöhung von Transparenz oder vereinfachte Abbildung von Geschäftszahlen – diese Risikofaktoren überwiegen. Viele unterschiedliche Stakeholder mit verschiedenen Interessensschwerpunkten bergen jedoch Potential für Zielkonflikte.

Die Ermittlung von sämtlichen Interessen der am Projekt beteiligten und betroffenen Personen sowie Offenlegung potentieller Zielspannungen kann durch mehrere Methodiken vorangetrieben werden: Exemplarische Möglichkeiten sind etwa klassisches Brainstorming in der Gruppe unter Leitung eines Moderators oder aber Anwendung der Delphi-Methode (Experteninterviews) als qualitatives Prognoseverfahren zur Antizipierung zukünftiger Entwicklungen und deren Eintrittswahrscheinlichkeit.

Im Nachgang erstellte Risikolisten/-register zeigen die ermittelten Risiken inklusive zum Beispiel potentieller Symptome für deren Eintreten auf – klassifiziert etwa nach projekt- und/oder produktbezogenen, technischen, management- und organisationsbezogenen, ressourcenorientierten oder extern bedingten Risikoklassen.

 

Stufe 2: Die Risiken umfassend analysieren und bewerten

Auf dieser nachfolgenden Prozessstufe geht es nun primär um das konkrete Beurteilen von Risiken anhand prognostizierter Eintrittswahrscheinlichkeiten sowie deren potentiellen Schadensumfängen bei Eintritt.

Wie auch schon bei der voran beschriebenen Risikoidentifikation gilt: Im Rahmen der Bewertung muss ein vergleichsweise umfangreiches, möglichst interdisziplinäres Team involviert sein. Denn die Wahrnehmung von Risiken geschieht immer subjektiv, ebenso sind manche Menschen von einer sehr optimistischen Grundeinstellung geprägt, wieder andere eher von einem recht pessimistischen Naturell. Gerade die direkten Projektverantwortlichen mögen mitunter eine Spur zu optimistisch sein und Risikopotentiale infolgedessen unterschätzen, wenn es um das eigene „Baby” geht; sowie zu selbstbewusst hinsichtlich der eigenen Stärken der Risikovermeidung sein („wir passen schon auf, dass dort nichts schiefläuft”).

Die Abschätzung von Eintrittswahrscheinlichkeiten sowie von Schadenshöhen kann auf qualitative oder quantitative Weise geschehen. Die quantitative Risikoanalyse ist die deutlich gebräuchlichere Variante. Sie gibt keine konkreten Prozentwerte an und beurteilt das Schadensausmaß auch nicht monetär – etwa in genauen Eurowerten. Stattdessen kommen Skalierungen mit nur wenigen Abstufungen zum Einsatz, siehe exemplarisch die beiden folgenden Tabellen:

Die Verwendung genauer Zahlenwerte würde lediglich eine Scheingenauigkeit vorspielen. Und die Verwendung eher knapp gehaltener Skalenabstufungen kann unter Umständen helfen, längere Diskussionen betreffend der Eingruppierung von Risiken in den Risikomanagement-Meetings zu vermeiden. Diese Vereinfachung mag gerade auch eher unerfahrenen Teams – welche sich nicht auf Erfahrungen aus anderen Softwareprojekten stützen können – die Abschätzung erleichtern.

Die multiplizierten Zahlenwerte hinsichtlich der Risikofaktoren Eintrittswahrscheinlichkeit und Schadenshöhe ergeben schlussendlich eine Risikokennziffer, welche die Wichtigkeit bzw. Priorität des jeweiligen Risikos verdeutlicht. So ist es später möglich, die eigenen Ressourcen auf die Bekämpfung derjenigen Risiken zu legen, welche eindeutig als die schwerwiegendsten bewertet worden sind.

Bei den Risikokennziffern zeigt sich zudem, dass immer beide Risikofaktoren zu betrachten sind: Hat nur einer von diesen einen hohen Skalenwert, der andere hingegen lediglich eine niedrige Ausprägung, so ergibt sich auch eine eher niedrige Risikopriorität. Denn tritt beispielsweise ein Risiko zwar mit hoher Wahrscheinlichkeit ein, verursacht dann allerdings nur geringfügigen Schaden, lohnen sich Gegegnmaßnahmen zur Risikovermeidung tendenziell weniger. Schließlich werden dadurch nämlich immer zeitliche, finanzielle und personelle Ressourcen gebunden, welche sich etwa besser direkt in das Softwareprojekt investieren ließen.

Wie ermittelt man im Projektalltag die Wahrscheinlichkeit und den Einfluss eines Risikos im Detail?
Zunächst ist es für eine genaue Einschätzung dieser beiden Risikofaktoren natürlich notwendig, das potentielle Risiko möglichst gut zu verstehen: Unter welchen Umständen kann in dem Softwareprojekt dieses Risiko auftreten und durch was ist es im Speziellen gekennzeichnet? Es wird darüberhinaus immer wieder vergleichsweise allgemeine Risiken für ein Projekt geben, deren Beschreibung eher schwierig und Auswirkungen nicht genau quantifizierbar sind. In solchen Fällen ist die Möglichkeit zu prüfen, ob sich diese nicht in besser abgegrenzte, speziellere Teilrisiken aufsplitten lassen.

Die einmal identifizierten Risiken werden auch dann nicht aus der „Gesamt-Risikoliste” gestrichen, sofern sich für sie eine Wahrscheinlichkeit von Null errechnet hat. Wie zuvor bereits angesprochen, wird der Risikomanagementprozess fortwährend durchlaufen, und in späteren Durchläufen mag sich die Einschätzung von Eintrittswahrscheinlichkeit und Schadensumfängen ja durchaus ändern.

 

Stufe 3: Maßnahmen für die bewerteten Risiken planen und managen

Nach Abschluss der Risikenbewertung kann mit der eigentlichen Planung von (Gegen-)Maßnahmen begonnen werden. Allgemeine Ziele sind zum einen, die Eintrittswahrscheinlichkeit von Risiken zu senken, und zum anderen, Schäden und deren Auswirkungen zu begrenzen. Als grundsätzliche Formen möglicher Risikobewältigung lassen sich unterscheiden:

a) Vermeiden
Durch geänderte Vorgehensweisen im Rahmen von Prozessschritten bzw. Teilaktivitäten im Projektablauf sollen Risiken inklusive deren Auswirkungen so gut wie möglich vermieden werden.

b) Akzeptieren
Was ist zu tun, wenn zum einen keine Gegenmaßnahme zu existieren scheint (das Eintreten eines Risikos rein exogen bestimmt wird) oder zum anderen ein nur ungenügendes Kosten-Nutzen-Verhältnis für die Durchführung einer solchen Maßnahme besteht? Man arrangiert sich mit dem Risikofaktor und geht das Risiko ganz bewusst ein: Unterstützend werden im Budget Rücklagen finanzieller wie zeitlicher Natur gebildet, gegebenenfalls befinden sich bereits auch schon ausgearbeitete „Notfallpläne” in der Schublade.

c) Reduzieren
Die Eintrittswahrscheinlichkeit von Risiken sowie deren Schadensumfang im Eintrittsfalle kann durch geeignete, frühzeitige Maßnahmen unter Umständen deutlich abgemildert werden. Dabei lässt sich die Wahrscheinlichkeit des Risikoeintritts häufig einfacher und wirksamer mittels entsprechender Maßnahmen eindämmen, als dies bei der Schadenshöhe im Vorfeld gelänge.

d) Transferieren
Als letzte hier vorgestellte Form der Risikobewältigung ist ferner eine Risikoübertragung denkbar: Das Eintreten des potentiellen Risikos wird unternehmensintern akzeptiert, durch Outsourcing einzelner (besonders) risikobehafteter Aktivitäten werden Risikofaktoren und deren Ausmaße jedoch nach außen hin „abgewälzt”. Das extern beauftragte Unternehmen ist im Optimalfall darauf spezialisiert, derartige Risiken handzuhaben und zumindest zu vermindern. Nicht vergessen werden sollte allerdings der häufig nicht unerhebliche Kostenfaktor für die Auslagerung gerade risikoreicher Aktivitäten, deren Übernahme sich der externe Partner dafür natürlich gut vergüten lässt.

Nach Prüfung dieser vier Varianten unter den Gesichtspunkten der Kosten-Nutzen-Relationen sowie hinreichender Korrelation mit den Projektzielen sollte sich auf eine Form der Risikobewältigung verständigt werden. Im Anschluss sind die Maßnahmen zur Reduzierung, Umgehung oder Akzeptanz umfangreich zu erarbeiten und zu dokumentieren, verantwortliche Personen sowie eventuelle Terminvorgaben festzulegen.

 

Stufe 4: Die Risiken konsequent und kontinuierlich nachverfolgen (Risk Monitoring)

Die Gegenmaßnahmen sind festgelegt – doch das beste Risikomanagement nützt nur dann etwas, sofern die einzelnen Risiken im Rahmen von Statusreports auch kontinuierlich weiterverfolgt werden (im zeitlichen Korsett der regelmäßigen Projektsitzungen oder durch speziell einberufene Risikomeetings). Die Berichterstattung muss sich dabei insbesondere um die folgenden Fragen drehen:

  • Wann sind welche Maßnahmen ergriffen worden?
  • Wie schlagen bzw. schlugen diese Maßnahmen kostenmäßig zu Buche?
  • War(en) die bisherige(n) Maßnahme(n) von Erfolg gekrönt?
  • Welchen Status haben die Risiken aktuell inne und wie hoch fällt das noch bestehende Restrisiko aus?

Die einzelnen Risiken werden hinsichtlich ihrer Faktoren Eintrittswahrscheinlichkeit und Auswirkungen kontrolliert sowie gegebenenfalls anders bewertet. Neu hinzugekommene, identifizierte Risikopotentiale sind in die Risikolisten aufzunehmen, einer Bewertung zu unterziehen und je nach Fall mit unterschiedlichen Maßnahmen zu behandeln.

Um auch bei Vorliegen mehrerer Risiken hinreichende Transparenz und Übersicht der Zusammenhänge zwischen den Risikofaktoren zu gewährleisten, empfiehlt sich die Darstellung zum Beispiel im Rahmen eines Risikoportfolios (Vierfelder-Matrix). Die dem Softwareprojekt innewohnenden Risikopotentiale können mittels vier verschiedener Risikozonen (begrenzt von den Achsen „Schadensausmaß” und „Eintrittswahrscheinlichkeit”) entsprechend eingruppiert werden – was nicht zuletzt einen schnellen Überblick über die Risikolage des Projektes sicherstellt.

 

Das Risikoportfolio wird in der Praxis häufig für die visuelle Abbildung von Risiken angewandt. In Abhängigkeit von der Eingruppierung des offenen Risikos in eine der Risikozonen sind unterschiedliche Aktionen angeraten:

  • Risikoklasse 1: Das Risiko ist weder (bestands)gefährdend, noch Bestandteil eines negativen Gesamttrend-Verlaufes (= es hat nur eine niedrige Eintrittswahrscheinlichkeit). Zwar regelmäßiges Monitoring auf etwaige Statusänderungen hin, aktuell sind jedoch keine aktiven Korrekturmaßnahmen erforderlich.
    ——
  • Risikoklasse 2: Risiken sind zwar vergleichsweise wenig gefährlich (= geringer Schadensumfang), aber ein negativer Trend ist erkennbar – das Risiko kann damit mit zunehmendem Verlauf auch zu einem größeren Problem für das Unternehmen heranwachsen. Daher sind kürzere Monitoring-Zyklen und eine Prüfung der Initiierung risikovermeidender bzw. schadenreduzierender Aktivitäten durchaus sinnvoll (mittlere Priorität).
    ——
  • Risikoklasse 3:Ein hoher bis sehr hoher Gefährdungs- bzw. Schadensgrad des Risikos geht einher mit einer im Vergleich relativ niedrigen Eintrittswahrscheinlichkeit. Dennoch kein Grund für Passivität, sondern aktive Suche nach Maßnahmen zur schrittweisen Beseitigung oder zumindest Reduzierung (mit hoher Priorität), da die Wahrscheinlichkeit eines Eintritts im Zeitverlauf zunehmen kann.
    ——
  • Risikoklasse 4: Bereits auf kurze Sicht hohe bis sehr hohe Ausprägungen sowohl beim Schadensausmaß im Eintrittsfall als auch bei der Eintrittswahrscheinlichkeit selbst. Eine Bestandsgefährdung des Unternehmens ist bei Vorliegen eines solchen Risikos nicht mehr auszuschließen. Gegenmaßnahmen für Risiken in diesem Feld besitzen daher oberste Priorität!

 
Top