Potenzielle Risiken erkennen
Zweck:
|
Alles auflisten, was im Projekt "schief gehen" kann.
|
Gehen Sie zum Erstellen der Liste der Risiken (in der Konzeptionsphase) wie folgt vor:
Versammeln Sie das Projektteam. (Das Team dürfte zu diesem Zeitpunkt noch recht klein sein. Wenn im Projektteam mehr
als fünf Personen arbeiten, beschränken Sie den Prozess für die Risikoeinschätzung auf die Leiter der Disziplinen).
Bei der Identifizierung der Risiken wird das, was "schief gehen" kann, in Augenschein genommen. Im Prinzip kann
natürlich alles schiefgehen. Der Punkt ist, kein pessimistisches Bild des Projekts zu zeichnen, sondern die
potenziellen Hürden auf dem Weg zum Erfolg aufzuzeigen, um diese zu minimieren bzw. ganz auszuschalten. Weitere
Informationen hierzu finden Sie im Abschnitt Liste der Risiken.
Risiken sind, genauer ausgedrückt, die Ereignisse, die die Wahrscheinlichkeit verringern, dass das Projekt mit den
richtigen Funktionen und der erforderlichen Qualität rechtzeitig und im Rahmen des Budgets geliefert werden kann.
Führen Sie ein Brainstorming durch, und fordern Sie jedes Mitglied auf, ein Projektrisiko zu identifizieren. Fragen zur
Klärung sind erlaubt, die Risiken sollten von der Gruppe jedoch nicht bewertet oder kommentiert werden. Fragen Sie so
lange, bis keine neuen Risiken mehr identifiziert werden können.
Beteiligen Sie alle Parteien an diesem Prozess, und kümmern Sie sich nicht zu sehr um die Form oder um Duplikate, Sie
können die Liste später bereinigen. Bilden Sie homogene Personengruppen (Kunden, Benutzer, Techniker usw.). Das
vereinfacht den Prozess der Risikoerfassung, denn einzelne Personen sind im Beisein ihrer Kollegen weniger gehemmt als
in einer bunt gemischten Gruppe.
Machen Sie den Teilnehmern klar, dass niemand, der ein Risiko benennt, damit die Verpflichtung eingeht, dieses Risiko
auch zu bearbeiten. Sollten die Teilnehmer das Gefühl haben, Verpflichtungen eingehen zu müssen, werden sie keine
Risiken nennen (oder nur solche, die trivial sind).
Beginnen Sie am besten mit der generischen Liste der Risiken aus der Veröffentlichung Assessment and Control of
Software Risks von Capers Jones [JON94] oder The
Taxonomy-Based Risk Identification des Software Engineering Institute [CAR93]. Geben Sie
die Liste der Risiken weiter, bereits genannte Risiken helfen oft dabei, weitere Risiken zu identifizieren.
Liste der Risiken aktualisieren (in späteren Phasen):
Sie können die Teilnehmer natürlich anregen, Beiträge zu leisten, wie oben beschrieben. Im Allgemeinen werden Risiken
von den Teammitgliedern jedoch basierend auf der vorhandenen Beispielliste identifiziert und bei der regulären
Statusbewertung erfasst. Siehe Aufgabe:
Iteration auswerten.
|
Risiken analysieren und nach Priorität ordnen
Zweck:
|
Ähnliche Risiken kombinieren (um den Umfang der Liste der Risiken zu mindern).
Risiken in Bezug auf ihre Auswirkung auf das Projekt einstufen.
|
Wenn keine Risiken mehr gefunden werden, sollten Sie die Risikoliste prüfen, um festzustellen, ob es logische
Gruppierungen gibt (Auftreten desselben Risikos), und, sofern möglich, Risiken kombinieren, um Duplikate auszuschalten.
Manchmal sind die identifizierten Risiken Symptome eines grundlegenderen Risikos. In diesem Fall sollten Sie die
zusammengehörenden Risiken unter dem grundlegenderen Risiko zusammenfassen.
Bei Techniken des quantitativen Risikomanagements wird empfohlen, Risiken entsprechend den Gesamtauswirkungen auf das
Projekt nach Priorität zu ordnen. Um die Auswirkungen der einzelnen Risiken zu bestimmen, sollte die Gruppe die
folgenden Parameter schätzen:
Auswirkungen des Risikos
|
Abweichungen von Zeitplan, Aufwand oder Kosten, wenn das Risiko eintritt
|
Risikowahrscheinlichkeit
|
Die Wahrscheinlichkeit, dass das Risiko zu einer realen Gegebenheit wird (normalerweise in Prozent
ausgedrückt)
|
Risikofaktor
|
Ergibt sich aus der Multiplikation der Werte für die Auswirkungen des Risikos und der Risikowahrscheinlichkeit.
|
Die Bestimmung des Risikofaktors sollte einstimmig in der Gruppe erfolgen. Wichtige Meinungsunterschiede sollten weiter
diskutiert werden, um festzustellen, ob alle Teilnehmer das Risiko in gleicher Weise interpretieren. Normalerweise
werden diese Informationen spaltenweise in einer Tabelle mit der Liste der Risiken erfasst.
Es ist normal, dass man sich über die Risiken, die die größten Auswirkungen haben, Gedanken macht. Wenn es jedoch
unwahrscheinlich ist, dass diese Risiken überhaupt auftreten, sind sie weniger wichtig als mäßigere Risiken, die oft
übersehen werden. Wenn Sie sowohl die Risikobewertung als auch die Wahrscheinlichkeit seines Auftretens
berücksichtigen, hilft dieser Ansatz Projektleitern, ihr Risikomanagement auf Bereiche zu konzentrieren, die sich am
stärksten auf die Lieferung des Projekts auswirken.
Sobald Sie für jedes Risiko den Risikofaktor ermittelt haben, können Sie die Risiken in absteigender Reihenfolge
sortieren und so die Liste der 10 wichtigsten Risiken erstellen.
Da es aufwändig und riskant ist, die Risikowahrscheinlichkeit zu schätzen, macht es im Allgemeinen nur Sinn, die
Auswirkungen der 10 bis 20 wichtigsten Risiken zu messen. Bei kleineren Projekte werden möglicherweise weniger Risiken
berücksichtigt, wohingegen größere Projekte naturgemäß eine größere Zahl relevanter Risiken beinhalten.
Sie können die Risiken nicht nur in absteigender Reihenfolge nach Risikofaktor ordnen, sondern sie darüber hinaus auch
in Kategorien zusammenfassen, basierend auf dem Ausmaß ihrer Auswirkungen auf das Projekt (Risikobewertung). In den
meisten Fällen sind fünf Kategorien ausreichend:
-
Hoch
-
Bedeutend
-
Mäßig
-
Gering
-
Niedrig
Dokumentieren Sie die Risiken und geben Sie die Informationen an die Projektteammitglieder weiter.
|
Risikovermeidungsstrategien identifizieren
Zweck:
|
Das Projekt reorganisieren, um Risiken auszuschalten
|
In manchen Fällen besteht die Möglichkeit, alle Risiken zu umgehen. Risiken entstehen oft, weil der Systemumfang falsch
eingeschätzt wird. Sie können den Umfang des Systems reduzieren, indem Sie unwesentliche Anforderungen entfernen. Auf
diese Weise entfallen ganze Abschnitte in der Liste der Risiken. Nicht zuletzt stellt auch der Mangel an Ressourcen
(einschließlich Zeit) für eine bestimmte Arbeit ein gewisses Risiko dar.
In anderen Fällen kann Technologie erworben werden, um das Risiko, dass bei der eigenen Entwicklung von Funktionen
besteht, zu reduzieren. Bei dieser Form der Risikovermeidung wird eine Risikogruppe (Entwicklung einer eigenen
Technologie) gegen eine andere ausgetauscht (Abhängigkeiten von externen Kräften, die sich der eigenen Kontrolle
entziehen).
Schließlich besteht auch die Möglichkeit, das Risiko auf andere Organisationen zu übertragen.
|
Risikominderungsstrategien identifizieren
Zweck:
|
Pläne entwickeln, um Risiken zu mindern, d. h., deren Auswirkungen zu reduzieren
|
Bei direkten Risiken, d. h., Risiken, für die das Projekt ein gewisses Maß an Kontrolle erlaubt, müssen Sie angeben,
welche Aktionen ausgeführt werden, um die Risikowahrscheinlichkeit oder die Auswirkungen des Risikos auf das Projekt zu
verringern (Risikominderungsstrategien). Normalerweise ergibt sich das Risiko selbst aus dem Mangel an Informationen,
häufig besteht die Risikominderungsstrategie darin, dass man das Thema weiter untersucht, um die Unsicherheit zu
reduzieren.
Es gibt Risiken, bei denen man Maßnahmen ergreifen kann, die das jeweilige Risiko entweder deutlich zutage treten
lassen oder bewirken, dass das Risiko in den Hintergrund tritt. In einem iterativen Entwicklungsprozess müssen Sie
solche Aktionen den ersten Iterationen zuordnen, um das Risiko so früh wie möglich zu mindern. Nehmen Sie die Risiken
so früh wie möglich in Angriff. Wenn ein Risiko sich mit der Formel "X funktioniert möglicherweise nicht wie geplant"
ausdrücken lässt, dann sollten Sie X so früh wie möglich unter die Lupe nehmen.
Beispiele:
-
Um das Risiko, dass die Produkte X und Y nicht integriert werden können, zu reduzieren, wird ein Prototyp erstellt,
an dem das Problem hinsichtlich der Integration untersucht wird. Die folgenden Funktionen (Aufzählung in einer
Liste) werden getestet, um sicherzustellen, dass die Integration erfolgreich ist.
-
Um das Risiko, dass Datenbank A nicht ordnungsgemäß ausgeführt wird, zu verringern, wird ein Leistungstest mit
einer Testsuite durchgeführt, die die Arbeitslast der Zielanwendung modelliert.
-
Um das Risiko, dass Testtool Z den Regressionstest der Anwendung nicht effektiv durchführen kann, zu reduzieren,
wird für die anstehende Iteration ein erworbenes Tool verwendet.
Das Ergebnis dieser Aktionen sollte sein, die Risikowahrscheinlichkeit auf einen Wert nahe null zu reduzieren. In den
Fällen, in denen das Risiko bestätigt wird, kann ein Plan für unvorhersehbare Ereignisse eingesetzt werden (siehe Strategien für unvorhersehbare Ereignisse identifizieren).
|
Strategien für unvorhersehbare Ereignisse identifizieren
Zweck:
|
Alternativpläne entwickeln
|
Unabhängig davon, ob Sie für die einzelnen Risiken einen Plan für unvorhersehbare Ereignisse haben, müssen Sie
entscheiden, welche Maßnahmen zu ergreifen sind, wenn bzw. falls das Risiko auftritt, d. h., wenn es zu einem Problem,
oder wie man im Versicherungsjargon sagt, zu einem "Schadenfall" wird. Diese Maßnahmen bezeichnet man als Plan für
unvorhersehbare Ereignisse oder auch als "Plan B". Ein Plan für unvorhersehbare Ereignisse ist erforderlich, wenn die
Risikovermeidung und die Risikoübertragung als Strategien versagt haben, außerdem die Risikominderung nicht wirklich
erfolgreich war und das Risiko jetzt direkt angegangen werden muss. Das ist häufig der Fall bei indirekten Risiken, d.
h., den Risiken, die im Rahmen des Projekts nicht gesteuert werden können, oder wenn die Implementierung der
Risikominderungsstrategien zu aufwändig ist.
Der Plan für unvorhersehbare Ereignisse sollte folgende Punkte berücksichtigen:
Risiko
|
Indikatoren
|
Maßnahme
|
Was ist das Risiko?
|
Wie können Sie erkennen, dass das Risiko real besteht? Wie können Sie den "Schadenfall" erkennen?
|
Was kann getan werden, um auf den Schadenfall zu reagieren?
|
Risikoindikatoren identifizieren
Einige Risiken können anhand von Projektmetriken überwacht werden, dabei werden Trends und Grenzwerte verfolgt.
Beispiele:
-
Der Umfang der Nacharbeit ist zu groß
-
Das System bricht zu oft zusammen
-
Die tatsächlichen Kosten liegen zu weit über der Planung.
Einige Risiken können basierend auf Projektanforderungen und Testergebnissen überwacht werden:
-
Antwortzeiten liegen eine Größenordnung über der Anforderung.
Einige Risiken sind einem spezifischen Ereignis zugeordnet, z. B.:
-
Softwarekomponente wird von Dritten nicht rechtzeitig geliefert.
Es gibt noch viele andere, subtilere Indikatoren, von denen sich keiner für eine vollständige Diagnose des Problems
eignet. Beispielsweise besteht immer das Risiko, dass die Motivation einbricht (tatsächlich ist das an bestimmten
Punkten des Projekts beinahe schon vorhersehbar). Dafür gibt es verschiedene Anzeichen wie Murren, Galgenhumor, nicht
eingehaltene Endtermine, schlechte Qualität usw., die zwar alle keine hundertprozentige Aussagekraft haben - sich über
die Sinnlosigkeit eines Liefergegenstands lustig zu machen, kann auch einfach nur gesunde Stressbewältigung sein -, die
aber, wenn sie wiederholt auftreten, ein Hinweis darauf sein können, dass das Team mehr und mehr einer
Untergangsstimmung verfällt.
Es empfiehlt sich, auf alle Indikatoren zu achten, ohne gleich zu werten. Es ist leicht, den "Überbringer schlechter
Nachrichten" als jemanden mit einer negativen Einstellung einzustufen. Oft verbirgt sich hinter Zynismus jedoch ein
gewisses Maß an Wahrheit. Nicht selten ist die betreffende Person so etwas wie das "Gewissen" des Projekts. Sie können
davon ausgehen, dass die meisten Teammitglieder sich den Erfolg des Projekts wünschen und frustriert sind, wenn sie
feststellen, dass es sich in die falsche Richtung entwickelt.
Aktionen für "Schadenfall" bzw. "Plan B" entwickeln
In einfachen Fällen zählt der Plan für unvorhersehbare Ereignisse Alternativlösungen auf. Die Auswirkungen
manifestieren sich normalerweise in Kosten und Verzögerungen beim Verwerfen der aktuellen Lösung und beim
Implementieren der neuen Lösung.
In anderen Fällen, wenn die Risiken schwerer zu fassen sind, müssen im Schadenfall mehrere Aktionen ausgeführt werden.
Wenn z. B. die Motivation einbricht, ist es am besten, diese Tatsache einfach anzuerkennen und die in der Gruppe
vorherrschenden Meinungen zum Projekt zu diskutieren. Hören Sie auf Einwände, identifizieren Sie die Probleme und geben
Sie den Mitarbeitern Gelegenheit, sich zu äußern. Anschließend müssen Sie jedoch auf die Ursachen zu sprechen kommen.
Verwenden Sie die Liste der Risiken, um die Diskussion auf bestimmte Punkte zu konzentrieren. Setzen Sie die
Problemstellungen in einen konkreten Aktionsplan um, indem Sie die Risiken erneut nach Priorität ordnen und die
Iterationspläne dann erneut formulieren, um die wichtigsten Risiken systematisch zu bearbeiten. Konstruktives Handeln
hat immer eine größere Wirkung als gute Worte, denen aber keine Taten folgen.
Die Stimmung zu diesem Zeitpunkt mag schlecht sein, ein Schadenfall hat jedoch immer auch einen positiven Aspekt: Er
zwingt zum Handeln. Risiken werden zu oft aufgeschoben, aus Selbstzufriedenheit ignoriert. Wenn ein Schadenfall
eintritt, muss gehandelt werden, denn das Risiko ist zu einem realen Problem geworden, es gibt keinen Spielraum mehr.
Ein Schadenfall bedeutet immer auch, dass es nicht gelungen ist, ein Risiko zu vermeiden oder zu mindern. Also sollte
die Liste der Risiken erneut geprüft werden, um festzustellen, ob das Projektteam möglicherweise systematische
Schwachpunkte aufweist. So schwierig ehrliche Selbsteinschätzung ist, sie kann spätere Probleme vermeiden.
|
Risiken während der Iteration nochmals bearbeiten
Zweck:
|
Sicherstellen, dass die Liste der Risiken während des Projekts auf dem neuesten Stand bleibt.
|
Die Risikobewertung ist ein fortlaufender Prozess und findet nicht nur in bestimmten Intervallen während des Projekts
statt. Die Mindestanforderung ist folgende:
-
Die Liste einmal wöchentlich erneut überprüfen, um festzustellen, welche Änderungen sich ergeben haben.
-
Informieren Sie das gesamte Projektteam über die 10 wichtigsten Punkte und bestehen Sie auf deren Bearbeitung. Oft
können Sie die aktuelle Liste der Risiken einfach den Statusbewertungsberichten beifügen.
|
Risiken am Ende der Iteration nochmals bearbeiten
Zweck:
|
Sicherstellen, dass die Liste der Risiken während des Projekts auf dem neuesten Stand bleibt.
|
Konzentrieren Sie sich am Ende der Iteration auf die Iterationsziele in Bezug auf die Liste der Risiken. Achten Sie
insbesondere auf folgende Punkte:
-
Schalten Sie die Risiken, die zur Gänze gemindert werden konnten, aus.
-
Führen Sie neue, kürzlich entdeckte Risiken ein.
-
Überarbeiten Sie die Risikobewertung und ordnen Sie die Liste der Risiken neu (siehe Abschnitt Risiken analysieren und nach Priorität ordnen).
Seien Sie nicht allzu besorgt, wenn Sie feststellen, dass die Liste der Risiken während der Konzeptions- und
Ausarbeitungsphase länger wird. Während Projektmitarbeiter ihre Arbeit tun, stellen sie oft fest, dass vermeintlich
triviale Aspekte Risiken enthalten. Wenn Sie mit der Integration beginnen, stoßen Sie möglicherweise auf verdeckte
Probleme. Gegen Ende der Ausarbeitungs- und während der Konstruktionsphase sollten die Risiken jedoch kontinuierlich
abnehmen. Ist das nicht der Fall, bedeutet das möglicherweise, dass Sie Ihre Risiken nicht richtig handhaben oder dass
Ihr System zu komplex ist bzw. nicht systematisch und planmäßig aufgebaut werden kann. Weitere Informationen hierzu
finden Sie im Abschnitt Richtlinie für
Arbeitsergebnis: Liste der Risiken.
|
|