Download - Risiko Management
20.04.00 Risiko ManagementVersion 1.1
Risiko Management
Juri Urbainczyk
20.04.00 Risiko ManagementVersion 1.1
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.
20.04.00 Risiko ManagementVersion 1.1
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.
20.04.00 Risiko ManagementVersion 1.1
Aufgaben beim Risiko Management
Risiko Managem ent
Risiko Beurteilung
Risiko Kontrolle
Identif izierung
Analyse
Priorisierung
Planung
Behandlung
Monitoring
(Boehm 1989)
20.04.00 Risiko ManagementVersion 1.1
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).
20.04.00 Risiko ManagementVersion 1.1
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.
20.04.00 Risiko ManagementVersion 1.1
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“).
20.04.00 Risiko ManagementVersion 1.1
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.)
20.04.00 Risiko ManagementVersion 1.1
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
20.04.00 Risiko ManagementVersion 1.1
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).
20.04.00 Risiko ManagementVersion 1.1
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
20.04.00 Risiko ManagementVersion 1.1
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).
20.04.00 Risiko ManagementVersion 1.1
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.
20.04.00 Risiko ManagementVersion 1.1
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?)
20.04.00 Risiko ManagementVersion 1.1
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.
20.04.00 Risiko ManagementVersion 1.1
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?
20.04.00 Risiko ManagementVersion 1.1
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)