Risiko Management

20.04.00 Risiko ManagementVersion 1.1

Risiko Management

Juri Urbainczyk


Was ist ein Risiko?

• Definition Risiko: „Wahrscheinlich des Eintretens von Verletzung oder Verlust“

• In Software-Projekten „Verlust“ in der Form von Budget-Überzug oder Nichterreichung von Projektzielen (sog. „Planungsrisiken“).

• Gemeint sind die ursächlichen Risiken, die zu großen Problemen und in letzter Konsequenz zum Scheitern des Projektes führen können.


Was ist Risiko Management?

Die Aufgabe des Risiko Managements ist es, Risiken • zu identifizieren, • zu behandeln und

• zu beseitigen, bevor sie zu konkreten Problemen für das Projekt

führen können (Präventives Risiko Management).

Risiko Management ist bei der Aufwandsschätzung mit einzuplanen.


Aufgaben beim Risiko Management

Risiko Managem ent

Risiko Beurteilung

Risiko Kontrolle

Identif izierung

Analyse

Priorisierung

Planung

Behandlung

Monitoring

(Boehm 1989)


Risiko Identifizierung

• Benennung und Beschreibung von Risiken.• Verwendung einer Liste potentieller allgemeiner

Risiken (s. Beispiel)• Durchführung eines Risiko Workshops.• Bei größeren Projekten: Einsetzung eines Risiko

Beauftragen.• Einführung eines anonymen Informationskanals

(z.B. Briefkasten).


Beispiele für allgemeine Risiken

• Kein Engagement des Top-Managements

• Endbenutzer sind nicht in das Projekt involviert und fühlen sich nicht verpflichtet.

• Anforderungen werden von Entwicklern falsch verstanden.

• Notwendige Skills und Erfahrungen sind nicht vorhanden.

• Anforderungen sind nicht klar definiert.

• Es ist nicht genügend Personal vorhanden.

• Zwischen Abteilungen des Kunden gibt es Interessenskonflikte hinsichtlich des Projekts.

• Es wird eine neue Technologie eingeführt.

• Die Erwartungen des Kunden und der Endbenutzer werden nicht gesteuert.


Risiko Analyse

• Beurteilung der einzelnen identifizierten Risiken, um die spezifischen Auswirkungen zu erkennen.

• Für jedes Risiko wird die Wahrscheinlichkeit des Auftretens geschätzt (sehr gering, gering, mittel, hoch, sehr hoch).

• Für jedes Risiko wird der Schaden bei Eintreten geschätzt.

• Multiplizierung der beiden Faktoren für jedes Risiko (Ergebnis sog. „Impact“).


Beispiel f. Risiko-Analyse

• Risiko: Zielmarkt für das zu erstellende Produkt wird sich verändern.

• Auswirkung: Produkt macht (in Teilen) keinen Sinn mehr bzw. wird überflüssig.

• Wahrscheinlichkeit: gering (0,2)• Schaden: groß (100)• Impact: 20(Aufschlüsselung der Werte für Wahrscheinlichkeit und Schaden sowie

Definition von „Schaden“ muß im Projekt geschehen.)


Risiko Priorisierung

• Ordnen der Risiken, um zu bestimmen in welcher Reihenfolge sie behandelt (gelöst) werden sollten.

• Anordnung nach „Impact“ (Schaden x Wkt.).• Eventuell Höherbewertung von Risiken mit

großem potentiellem Schaden.• Eventuell Höherbewertung von Risiken mit

Synergien (wenn a dann wahrscheinlich auch b).• Achtung: Reihenfolge nicht mathematisch genau!Ergebnis: Risikoliste


Risiko Management Plan

• Jedes Risiko auf der Risikoliste sollte behandelt werden.

• Inhalt: – Beschreibt das Risiko und seine Auswirkungen.

– Antizipiert das erste Symptom, mit dem das Risiko sich vermutlich ankündigen wird.

– Enthält alle Schritte, die zur Behandlung des Risikos notwendig sind, inkl. Personen, Zeitplanung und Budget.

– Konkrete ToDo‘s mit Verantwortlichen!

– Erläutert Alternative Verfahrensweisen (die verworfen wurden).


Beispiel f. Risiko Planung

• Risikobeschreibung: Marktveränderungen (s.o.)• Gegenmaßnahmen:

– Regelmäßige Markbeobachtungen (verantwortlich:...)

– Kurzbericht in jedem Review Board (verantwortlich:...)

– Durchführung einer separaten Marktstudie per Umfrage bis ... (verantwortlich:...)

• Budget f. Abstimmung mit Projektteam: ....• Anzeichen:

– Geringe Beteiligung der Endkunden während Entwicklung und Betatest.

– Negatives Feeback von Endnutzern bei Betatest


Risiko Behandlung

• Risiko vermeiden: Aktivitäten nicht durchführen.• Aktiv die Ursachen für das Risiko ausschalten.• Risiko in weniger empfindliche Regionen transferieren

(z.B. unqualifiziertes Personal arbeitet nicht an der Architektur, sondern im Test).

• Risiko publizieren, um die Überraschung zu mildern und Bewußtsein f. Risiken zu schaffen.

• Auswirkungen beschränken, falls das Risiko doch eintritt (z.B. zusätzliche Testphasen einplanen).


Risiko Monitoring

• Kontrolle des Fortschritts bei der Behandlung der Risiken und Aufspüren neuer Risiken.

• Die Risikoliste wird regelmäßig vom Projektleiter, Projekt Manager und vom Risiko Beauftragtem aktualisiert.

• Das Risiko weiter untersuchen (z.B. Prototyp)• Bei größeren Projekten: Einsetzen eines Risiko

Beauftragen.• Aktueller Stand wird im Review Board

kommuniziert.


Der Risiko Beauftragte

• Muß neu entstehende Risiken aufspüren.• Soll in Planungsmeetings „Teufels Advokat“ sein.• Reviewed die Risiko Management Pläne.• Sollte die entsprechende Anerkennung des

Managements besitzen (sonst nur „Pessimist vom Dienst“).

• Entbunden von der „Das-Schaffen-Wir-Haltung“• Sollte nicht gleichzeitig der Projektleiter sein

(abhängig von Projektgröße?)


Risiko Workshop

• Mögliche Beteiligte: Projektleiter, Projektmanager, Stakeholder, Projektverantwortliche des Kunden

• Identifizieren von Risiken durch Brainstorming (Methode: Moderationskarten)

• Beschreibung der Risiken und der Auswirkungen.• Priorisieren (Punkte verteilen).• Ergebnis: Risikoliste, Risiko Management Planung

für die wichtigsten Risiken• Durchführbarkeit von Einstellung des Kunden

abhängig.


Offene Punkte

• Risiko Management eigene Task im Projektplan?• Wie genau ist der „Schaden“ eines Risikos

definiert?• Ab welcher Projektgröße ist ein Risiko

Beauftragter sinnvoll?• Soll die Risikoliste öffentlich sein?• Hat der Kunde ein Bewußtsein für Risiken - sollte

man das Wort „Risiko“ überhaupt verwenden?


Quellen

• Rapid Development (Steve McConnell)• Der Termin (Tom DeMarco)• Software Risk Management (Barry W. Boehm)• Software Project Survival Guide (Steve

McConnell)• Risiko Workshop (SFD Projekt)

Documents

Risiko Management