Risiko Management Juri Urbainczyk 20.04.00 Risiko Management Version 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 Management Version 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 Management Version 1.1

Aufgaben beim Risiko Management (Boehm 1989) 20.04.00 Risiko Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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 Management Version 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) 20.04.00 Risiko Management Version 1.1