Risikomanagement. Dr. Klaus Hörmann. Managing Software Risks with World-Class Customers. Denmark France Germany Ireland Norway Sweden UK USA

Transkript

1 Managing Software Risks with World-Class Customers Risikomanagement Dr. Klaus Hörmann Denmark France Germany Ireland Norway Sweden UK USA Doc. number : Revision A 19. Dezember 2000 Date BMA Approved Q Template 6.0

2 Inhalt Q-Labs in Kürze Motivation Begriffe Häufige Risikoquellen Methodik des Risikomanagements Beispiel: Luftwaffenprojekt bei Honeywell, Inc. Anwendungs- u. Erweiterungsmöglichkeiten Literatur, Links 2

3 Q-Labs in Kürze 1989 in Schweden gegründet Global vertreten Firmenzentrale in Dänemark Deutschland England Frankreich Irland Schweden USA ca. 200 Berater Hoch qualifizierte Mitarbeiter - im Durchschnitt mehr als 10 Jahre Industrieerfahrung Breiter internationaler Kundenstamm Lösungen basieren auf industrieerprobten Praktiken und praxisbezogenen Ansätzen aus der Forschung Partnerschaftsnetzwerk mit Forschungsinstituten und Industrie Anteilseigner sind Ericsson (20%), das norwegische Zertifizierungsunternehmen Det Norske Veritas (40%), und die schwedische Investmentfirma Ratos (40%). 3

4 Q-Labs Service Portfolio Projekt management Software Entwicklungsprozesse Beschaffungsmanagement Reviews und Testing Performance Management Accelerating Change 4

5 Software-Krise Termine Massive Terminüberschreitungen (100% u. mehr keine Seltenheit) Kosten Massive Kostenüberschreitungen (100% u. mehr keine Seltenheit) Qualität/Funktionalität mehr als 50% der entstehenden Anwendungen entsprechen nicht den Benutzererwartungen bzw. sind schlichtweg unbrauchbar zu hohe Fehlerrate nach Auslieferung ca. 75% aller Projekte geht von Entwicklung direkt in die Wartung (weil nur scheinbar fertig bzw. erhebliche Mängel) 5

6 Continuing Chaos in IT organizations $250 billion/year spent on Information Technology 175,000 Software Projects are Started "CHAOS" Project Study: Company Size Large (> $500m) Medium ($ m) Small ($ m) Impaired or Canceled "Challenged" (Cost or Schedule Overruns ) "Successful" (Based on Cost & Schedule) Planned Function Actually Delivered 30 % 62 % 9 % 42 % 37 % 47 % 16 % 65 % 32 % 50 % 28 % 74 % Source: Standish Group -- CHAOS Study, Untersuchungsumfang: 365 Unternehmen, Projekte

7 Levers for moving out of chaos Percent of Projects by Outcomes 1994 (see previous chart) 16% 31% 53% Successful Failed Challenged % 28% 46% Source: Standish Group (Cited in Software Magazine, December 1999) Recent focus on process and people are changing industry by reducing the numbers of failed and challenged projects 7

8 Ursachen f. Software-Krise (u.a.) Mangelnde Planung, mangelnde Steuerung Mängel in Anforderungen Kein richtiges Change Request Management: Nicht- Umgehen-Können mit Änderungen Mangelndes Risikomanagement (ca. 55% von runaway-projekten betrieben kein Risikomanagement, 20% betrieben es halbherzig) 8

9 Begriffe Was ist ein Risiko? Ein Risiko ist ein Ereignis, dessen Eintritt das Projekt gefährden kann hinsichtlich gefordertem Leistungsumfang und Qualität Kostenüberschreitung Terminüberschreitung Welche Tätigkeiten umfaßt Risikomanagement? Alle Aktivitäten, um Risiken zu identifizieren, zu bewerten, zu verfolgen sowie Gegenmaßnahmen einzuleiten. 9

10 Häufige Risikoquellen Anforderungen Anforderungen an Benutzerschnittstelle instabil Sich ständig ändernde Anforderungen Technik, Anwendungsdomäne Hohe Komplexität Hohe Performanceforderungen Hoher Neuigkeitsgrad, z.b. Einsatz neuer Techniken, Systeme, Tools Fehlende Erfahrung in neuer Anwendungsdomäne 10

11 Häufige Risikoquellen Kunde Unklarheit über Anforderungen Konkurrierende Interessengruppen, Widerstände (z.b. von Anwendern) Keine Erfahrung mit DV-Projekten Mangelnde Kooperationsfähigkeit oder -bereitschaft Projektauftrag, -abwicklung Unklare Aufgabenstellung Nicht haltbare Vereinbarungen in Angebot und Vertrag Unrealistische Termine und Budgets 11

12 Häufige Risikoquellen Projektorganisation Nicht genügend Unterstützung in eigener Organisation Einsatz von Unterlieferanten Ressourcen Nicht die richtigen Mitarbeiter (Mangelnde Qualifikation oder Erfahrung) Nicht der richtige Projektleiter (unerfahren, ungeeignet, nicht anerkannt,...) Drohender Ausfall von Mitarbeitern 12

13 Risikomanagement im Überblick Angebotsabgabe Projektentscheidung Projekt prozesse Vorphase Projekt einrichten Projekt planen Projekt überwachen u. steuern Projekt abschließen Entscheidungsgrundlage Risiko- management- Aktivitäten Erstes Erstes Risikoassessment Risikoassessment Gründliches Gründliches Risikoassessment Risikoassessment an Meilensteinen Erneutes Erneutes Risikoassessment Risikoassessment Risiken Risiken verfolgen verfolgen Hilfsmittel Checkliste Checkliste Risiko- Risiko- Assessment Assessment Projektplan 13

14 Risikomanagement im Überblick Wie geht man bei einem Risiko-Assessment vor? Risiken identifizieren Risiken analysieren und bewerten Gegenmaßnahmen planen Dokumentieren 14

15 Risiken identifizieren Risiken systematisch (anhand von Produkt- und Projektstrukturplan) ermitteln Hilfsmittel: Checklisten aufgrund von Erfahrungen vergangener Projekte Risiko-Brainstorming Erfolgsbestimmend: erfahrene Experten! (die Risiken förmlich riechen können) evtl. Einbringung von externen Sichten (Berater, Projektleiter anderer Projekte,...) 15

16 Risiken analysieren und bewerten Was ist die Ursache (Woher kommt es?) Was sind die Auswirkungen (Was bewirkt es?) Sind beim Eintreten des Risikos weitere Risiken zu erwarten, wirkt es sich auf andere aus? Abschätzen der Eintrittswahrscheinlichkeit auf einer Skala zwischen 0 und 1 Abschätzen der Kritikalität (wie hoch ist der Schaden?) auf einer Skala von 1 bis 10 Bewertung des Risikos durch Risikokennzahl = Eintrittswahrscheinlichkeit x Kritikalität 16

17 Gegenmaßnahmen planen Bei Gegenmaßnahmen sind zu unterscheiden Präventive oder vorbeugende Maßnahmen (verringern die Eintrittswahrscheinlichkeit des Risikos) Korrektive oder Eventual-Maßnahmen (verhindern oder begrenzen im Eintrittsfall Schaden) 17

18 Gegenmaßnahmen planen Beispiele für vorbeugende Maßnahmen: Bei technischen Risiken: Simulation oder Prototyping von Systemen Beratung, Reviews durch Unabhängige Anbieten alternativer Funktionen/Konzepte (wobei das Risiko nicht auftritt) Erprobung von neuen Techniken und Werkzeugen Bei Risiken bezügl. Anforderungen/Kunde: Verstärktes Bemühen um den Kunden, Kontaktpflege Kundenworkshops (Frühzeitige) Abnahme von Zwischenergebnissen vereinbaren Pflichten des Kunden vertraglich absichern 18

19 Gegenmaßnahmen planen Beispiele für vorbeugende Maßnahmen: Bei Ressourcenproblemen: Schulung, Coaching von Mitarbeitern/Projektleiter Ausleihen von Mitarbeitern in ähnliche Projekte im Vorfeld Abwanderungsgefährdete Mitarbeiter umwerben Verstärkte Akquisition neuer Mitarbeiter Management sensibilisieren und Ressourcenzusage abringen Bei Risiken bezüglich Projektabwicklung Vertrag modifizieren Preisaufschläge einkalkulieren Outsourcen von Risiken an Subunternehmer 19

20 Gegenmaßnahmen planen Beispiele für korrektive Maßnahmen: Bei technischen Risiken: Aufbau von Rückzugspositionen, z.b. Statt der Neuentwicklung die alte SW-Komponente einsetzen und aufbohren Alternative SW- oder HW-Konzepte bei Performanzproblemen Bei drohendem Versagen von Zukaufprodukten: Alternativen in der Hinterhand haben Bei Ressourcenproblemen: Aufbau von Ersatz-Mitarbeitern Komponenten an Subunternehmer outsourcen oder fertig zukaufen 20

21 Gegenmaßnahmen planen Weitere Schritte: Kosten für Gegenmaßnahmen und für den Eintrittsfall (Schadenskosten) ermitteln Einfluß der Gegenmaßnahmen auf Projektplan untersuchen Einschätzung der Wirksamkeit von vorbeugenden Maßnahmen Entscheidung bezüglich Gegenmaßnahmen treffen Bei vorbeugenden Maßnahmen: Abwägen Eintrittswahrscheinlichkeit/ neue Eintritts-wahrscheinlichkeit / Schadenskosten/ Maßnahmenkosten Verantwortlichen bestimmen und Maßnahme einleiten Bei korrektiven Maßnahmen Abwägen Wirksamkeit / Schadenskosten/ Maßnahmenkosten Verantwortlichen bestimmen und ggf. vorbereitende Schritte einleiten Für den Eintrittsfall verkürzten Entscheidungsweg mit Management vereinbaren 21

22 Risiken dokumentieren Beispiel einer Risikoliste Nr Bezeichnung Neue Netzmanagementkomponenten machen Probleme Projektmitarbeiter kommen mit neuer Datenbank nicht zurecht Key-Player stehen nicht rechtzeitig zur Verfügung Datum des Eintrags Kritikalität* Wahr- Scheinlichkeit* * Risikokennzahl*** Neue Technologien, bisher keine praktischen Erfahrungen Unzureichend e Schulung der Projektmitarb eiter Es werden zu viele Projekte gleichzeitig durchgeführt, freie Stellen sind unbesetzt Ursache Wirkung Gegen- Maßnahmen Einsatz von neuen Netzmanagementkomponen -ten verursacht Probleme und Mehraufwand, Zeitliche Verzögerung Langsame Entwicklung, Viele Nachfragen der Entwickler untereinander Zeitliche Verzögerung gegenüber Planung Schulung der Mitarbeiter, Einsatz erfahrener Berater als Coach Nein Nein 22 * Kritikalität von 1 bis 10 (1-2 : Unbedeutend, 3-4: Akzeptabel, 5-8 Kritisch, 9-10: Katastrophal) ** Wahrscheinlichkeit in % : % : Das Risiko wird mit ziemlicher Sicherheit eintreten % : Das Risiko wird eher eintreten als nicht eintreten, es ist aber keineswegs sicher 11-50% : Das Risiko wird eher nicht eintreten, es ist aber dennoch möglich 1-10 % : Es ist eher unwahrscheinlich, daß das Risiko eintritt, aber nicht auszuschließen *** Risikokennzahl = Kritikalität * Wahrscheinlichkeit

23 Risiken verfolgen Risiken visualisieren, z.b. bei großen Projekten Top- Ten-Risiko-Liste ins Besprechungszimmer hängen Verantwortlichen für die Verfolgung eines jeden Risikos benennen Regelmäßige Kontrolle, je nach Kritikalität (je kritischer, desto kürzer die Frequenz), z.b auf wöchentlichen techn. Projektbesprechungen Bei Erreichen von Meilensteinen: Erneut Risikoassessments durchführen 23

24 Beispiel: Luftwaffenprojekt bei Honeywell, Inc. Großes Engineering-Projekt, , 87M$ Risiken(Chancen) identifiziert im Wert von 19,8M$(5,4M$) Reduktion der Risiken auf 3,9 M$ durch Gegenmaßnahmen im Wert von 1,3 M$ Projektresultate: 5M$ Risiken+Chancen am Ende realisiert Alle Meilensteine rechtzeitig oder vorzeitig erreicht Inhaltlich voll erfolgreich Budget um 300 K$ unterschritten Quelle: A.R. Bedillion, T.H. Orr: How Risk Management Has Become a Way of Life in Project Management, Proc. 30th Annual Project Management Institute 1999 Seminars & Symposium, Philadelphia, USA 24

25 Anwendungs- u. Erweiterungsmöglichkeiten Oft kombiniertes Risk and Opportunity Management Bei sehr großen Projekten/Programmen hinzukommende Themen: Propagierung der Risiken von Teilprojekten, evtl. über mehrere Ebenen auf Gesamtprojektebene, damit verbundene Bewertungsprobleme Erreichen von Prozessdisziplin, z.b. durch Schulung, Überzeugungsarbeit, Coaching Unübersehbare Menge von Anwendungen außerhalb des Engineering- u. Projektgeschäfts, z.b. Anwendung auf Nicht-Projekttätigkeiten, z.b. Luftverkehr/operativen Betrieb Anwendung auf viele Branchen, z.b. Banken, chemische Industrie, öffentlichen Sektor 25

26 Literatur, Links Barry W. Boehm, Software Risk Management, Computer Society Press, 1989 Carr, M.J, Konda, S.L., Monarch, I.A., Ulrich, F.C., Walker, C.F. 1993: Taxonomy-Based Risk Management Identification. SEI Technical Report SEI-93-TR-006, Pittsburgh, PA: Software Engineering Institute Dorofee, A.J, Walker, J.A., Alberts, C.F., Higuera, R.P., Murray, T.J., Williams, R.J. 1996: Continuous Risk Management Guidebook, Pittsburgh, PA: Software Engineering Institute Kontio, J. 1997: The Riskit Method for Software Risk Management, version 1.00., Computer Science Technical Report CS-TR-3782 / UMIACS-TR-97-38, University of Maryland. College Park, Maryland PMI Risk Management Specific Interest Group Software Engineering Institute (SEI) Home Page 26