Risiko und Risikomanagement (RM)

Transkript

1 8. Risikomanagement Begriffsklärung: Risiko und Risikomanagement Beispiel: Denver International Airport Phasen des Risikomanagements Erkennung von Risiken Bewertung von Risiken Literatur: [DL03] T. DeMarco, T. Lister, Bärentango Mit Risikomanagement Projekte zum Erfolg führen, Hanser, München, 2003 E. Wallmüller, Risikomanagement für IT- und Software-Projekte, Hanser, München

2 Risiko und Risikomanagement (RM) Risiko (italienisch): Wagnis, Gefahr (Brockhaus) The possibility of loss, injury, disadvantage, or destruction (Websters Dictionary) Strictly speaking, risk involves only the possibility of suffering harm or loss. In the project context, however, risk identification is also concerned with opportunities (positive outcomes) as well as threats (negative outcomes). (A Guide to the Project Management Body of Knowledge, Project Management Institute 1996) Risikomanagement: Erkennung von Risiken, systematische Behandlung von Risiken, Verwaltung von Erfahrungen mit dem Umgang mit Risiken RM muss die Verbindungen zwischen Prozessen, wie Entwicklung, Projektmanagement, Kundenmanagement, Unternehmensführung berücksichtigen 198

3 Beispiel: DIA (1/7) [DL03] Ab 1988 Bau eines neuen Flughafens für Denver (Denver International Airport, DIA) geplante Eröffnung am Flughafen stand zum geplanten Termin, nur die SW lief nicht genauer ein System zur automatischen Gepäckabfertigung war nicht fertig, ohne die der Flughafen nicht funktionieren konnte Mehrkosten von $ im Monat Teileröffnung von DIA in

4 Beispiel: DIA (2/7) F1 : Warum konnte der Flughafen nicht ohne das Gepäcksystem eröffnet werden? Die Antwort darauf ist einfach: Die Software zur Gepäckabfertigung lag auf dem kritischen Pfad des Gesamtprojekts für die Flughafeneröffnung. Sie war für den Flughafenbetrieb so wichtig, dass die verantwortlichen Organisatoren wussten, es würde nicht möglich sein, die Passagiere auch nur einen Tag lang ohne dieses System abzufertigen. F2: Warum lag das automatische Gepäcksystem auf dem kritischen Pfad? Nun ja, weil es keine andere Möglichkeit gab, das Gepäck zu befördern. Das System aus softwaregesteuerten Gepäckkarren, so genannten Telecarts, Barcodelesern, Scannern, Rangierbereichen und Cart-Entladern war die einzige Möglichkeit, Gepäck in die Flugzeuge und von den Flugzeugen zu den Terminals zu befördern. 200

5 Beispiel: DIA (3/7) F3: Gibt es keine andere Möglichkeit, Gepäck zu befördern? Doch, natürlich. Da ist zum Beispiel die altbewährte Methode, das Zeug von großen kräftigen Männern transportieren zu lassen. Und es gibt den konventionellen Ansatz, dass kleine Zugmaschinen von Hand beladene, aneinander gekettete Ladekarren ziehen. F4: Warum konnte der Flughafen dann nicht ohne das automatische Gepäcksystem eröffnen und vorübergehend eine der Alternativmethoden zur Gepäckbeförderung nutzen? Hm. Tja. (Verlegenes Herumdrucksen.) Die Tunnel, die für das automatische Telecart-System entworfen waren, waren für Menschen zu niedrig und für Zugmaschinen nicht ausgelegt. Deshalb musste das automatische System funktionieren. 201

6 Beispiel: DIA (4/7) F5: Hätte man die Tunnel nicht verändern können, so dass auch Zugmaschinen und Anhänger durch sie hindurchgepasst hätten? Ja, aber dafür reichte die Zeit nicht aus. Als man feststellte, dass die Gepäcksoftware im Rückstand lag, waren die Tunnel bereits gebaut. Es herrschte die Meinung, sie aufzurüsten würde länger dauern, als die Software fertig zu stellen. F6: Hätte man nicht früher mit dem Aufrüsten der Tunnel beginnen können? Ja, aber das wurde nicht als sinnvoll erachtet. Die Erweiterung der Tunnel hätte einen unnötigen Zeit- und Geldaufwand bedeutet, wenn die Software doch so rechtzeitig fertig geworden wäre, wie das obere Management es damals behauptete. 202

7 Beispiel: DIA (5/7) F7: Wurde der Rückstand der Gepäcksoftware nicht als mögliches Risiko gesehen? Erst nachdem er eingetreten war. Vorher unterlag die Software einem aggressiven Zeitplan und wurde rein erfolgsorientiert gemanagt. F8: Gab es nicht schon früher Verzögerungen bei Softwareprojekten? Ja, aber diesmal sollte alles anders sein. F9: Konnte man auf frühere Erfahrungen bei der Entwicklung ähnlicher Systeme zurückgreifen? Ja. Der Franz-Josef-Strauß-Flughafen (MUC) in München hatte als erster eine Gepäcksoftware installiert, die auf einem ähnlichen Entwurf beruhte. 203

8 Beispiel: DIA (6/7) F10: Sah sich das DIA-Team das Münchner Projekt an? Falls ja, welche Schlüsse zog es daraus? Einige Mitarbeiter des Denver Projekts waren in München. Das Münchner Softwareteam plante ganze zwei Jahre für Tests sowie einen sechsmonatigen Einsatz des Systems im 24-Stunden- Dauerbetrieb ein, um eine Feinabstimmung vor der Übergabe vorzunehmen. Sie rieten den DIA-Leuten, mindestens so viel Zeit, besser mehr einzukalkulieren. F11: Folgte das DIA-Management dieser Empfehlung? Da für so umfangreiche Tests und Feinabstimmungen keine Zeit vorhanden war, entschloss man sich dagegen. 204

9 Beispiel: DIA (7/7) F12: Kündigte das Projektteam die drohende Verzögerung rechtzeitig an? Im Grunde genommen morste der Markt von Anfang an SOS. Als das Gepäcksystem ausgeschrieben wurde, war niemand bereit, ein Angebot für den geplanten Liefertermin abzugeben. Alle Bieter waren der Meinung, ein Projekt mit diesem Terminplan zu übernehmen, käme einer Herausforderung des Schicksals gleich 205

10 DIA-Analyse: Risiko Risiko: Flughafen nach Bauabschluss nicht nutzbar, wenn Gepäck-SW nicht läuft Kosten: $ pro Monat Risikomanagementansatz: Fertigstellungsgrad der SW muss überwacht werden Kommentar: Maßnahme sicherlich wichtig, reicht aber in der Form nicht aus 206

11 DIA-Analyse: direkte Ursachen Ursachenanalyse für das Risiko: SW liegt auf dem kritischen Entwicklungspfad keine alternative Gepäckabfertigung möglich Maßnahmen: SW vom kritischen Pfad nehmen Alternative zur geplanten Gepäckabfertigung zusätzlich einplanen Kommentar: erste Maßnahme klingt simpel (war sie realisierbar?), zweite Maßnahme garantiert möglich (kostet aber!) 207

12 DIA-Analyse: indirekte Ursachen Ursache: SW mit engem Fertigstellungstermin liegt auf dem kritischen Pfad Ursache der Ursache: Mangelnder Planungsprozess der SW-Entwicklung ohne Risikopuffer Maßnahmen: SW-Entwicklung anhand von Prototypen planen für Neu-Entwicklungen Erfahrungen von anderen Projekten einholen 208

13 DIA-Analyse: weiteres Risiko Achtung: Vergleichsprojekt in München wurde betrachtet, warum griff zumindest diese Maßnahme nicht? Aus dem Vergleichsprojekt abgeleitete Maßnahme zur Risikominimierung war eine Verlängerung der ursprünglich geplanten/kalkulierten Testzeiten Problem: Die aus dem Risikomanagement abgeleitete notwendige Maßnahme wurde von der Projektleitung ignoriert Risiko: Projektleitung nicht formal in den Risikomanagementprozess eingebunden Gegenmaßnahme: Management muss zu Anforderungen aus dem Risikomanagement formal Stellung nehmen 209

14 DIA: abgeleitete Risikomanagementkenntnisse Art M MC Ursache verursacht durch NC N erzeugt durch M risikogemanagt durch Kosten Risiko N Maßnahme Art Eintrittswahrscheinlichkeit Kosten häufig vereinfacht zu: Risiko N M Maßnahme 210

15 Umgang mit Risiken Entweder: in die Schätzung einbauen Oder: Risiken nachträglich als %-Aufschläge aufrechnen Achtung: hier nur Entwicklungsrisiken beachtet Gesamte Projektrisiken müssen eingerechnet werden Gewinn Risiko Aufwand Verhandlung Projekt 211

16 Querschnittsprozess: Projekt-Risikomanagement Projekte stoßen häufig auf Probleme, die man frühzeitig hätte erkennen und auf die man dann reagieren könnte; dieser Prozess heißt (Projekt-) Risikomanagement (RM) Idee: frühzeitig über potenzielle Probleme nachdenken, genauer: Vermeidungsmöglichkeiten Maßnahmen zur Verringerung der Eintrittswahrscheinlichkeit Maßnahmen beim Eintreffen des Problems ersten beiden Ansätze heißen pro-aktives RM, letzter Ansatz reaktives RM oder Notfall-Plan 212

17 Beispiel RM bei Projektplanung Risiko: Mangelnder Austausch von Know-How im Projektteam Auswirkungen: Arbeiten werden doppelt gemacht, vorhandenes Wissen nicht eingesetzt Ursache: Neues Projektteam, dass noch nicht zusammengearbeitet hat Maßnahme: (Verringerung) Erste Projektveranstaltung (Kickoff) findet in kleinem Hotel außerhalb des Unternehmens statt; moderierte Workshops zum Aufbau des Verständnisses der Projektaufgabe und zur Findung vorhandener Kompetenzen Messung des Maßnahmenerfolgs: Kontrolle auf Doppelarbeiten; Verfolgung der Qualität der Ergebnisse, die von mehreren Personen erstellt wurden (nur weiches Maß) Hinweis: Ursache und Risiko können verwischen, da Ursachen wieder Ursachen haben können (... irgendjemand in den Apfel gebissen hat ) 213

18 Risikoquellen Firmenprozesse Projektprozesse Firmenstrategie Angebotserstellung Vertragsgestaltung Mitarbeiterauswahl Maßnahmenbewertung Identifikation Maßnahmen Aufwandsschätzung Analyse/ Bewertung Entwicklung Unterauftragnehmerauswahl Anforderungsanalyse IT- Risikomanagement Qualitätsmanagement Multiprojektmanagement Controlling Test und Abnahme 214

19 Risikomanagement Risiken identifizieren Risiken analysieren Maßnahmen planen Optimieren Risiko- Datenbank Maßnahmen durchführen Maßnahmen bewerten 215

20 Phasen des Risikomanagements (1/3) Risiken identifizieren Identifikation eines Risikos, Festlegung der Risikoaussage und des Risikokontextes Aufnahme in die Risikoliste Risiken analysieren Festlegung der Eintrittswahrscheinlichkeit, der Auswirkungen, der erwarteten Tendenz und des Ursachenfeldes Priorisierung der vorhandenen Risiken unter Berücksichtigung der Gesamtrisikolage 216

21 Phasen des Risikomanagements (2/3) Maßnahmen planen Passende Maßnahmen definieren Festlegen der verantwortlichen Personen/Rollen Erfolgsfaktoren für Maßnahmen festlegen Maßnahmen durchführen Sammeln von Informationen/Daten zu den Veränderungen der Risiken und dem Erfolg der Maßnahmen Erstellen von Risikomeldungen für das Management 217

22 Phasen des Risikomanagements (3/3) Maßnahmen bewerten Bewertung der Veränderung von Risiken und des Erfolgs der angewendeten Maßnahmen Entscheidungsfindung zur weiteren Behandlung der Risiken und Anpassung der Maßnahmen Informationsverteilung zu den Risiken in Richtung Team und Vertragspartnern/Kunde Optimieren Maßnahmen zielgerichtet anpassen Hinweise/ Optimierungspotenziale für zukünftige Projekte erkennen 218

23 Risiko-Analyse Ziel: Qualitative und quantitative Bewertung und Priorisierung der Risiken Eintrittswahrscheinlichkeit je Risiko Schadensausmaß Bewertungsskala für jedes Risiko: Wahrscheinlichkeit sehr wahrscheinlich relativ wahrscheinlich könnte passieren unvorstellbar Schadensauswirkungen katastrophal erheblich gering unbedeutend 219

24 Risikomatrix Bewertung der einzelnen Risiken erfolgt in Form einer Risikomatrix Schadenshöhe Risikomatrix katastrophal kein mittel hoch sehr hoch erheblich kein gering mittel hoch gering kein gering gering mittel unbedeutend kein kein kein kein unvorstellbar könnte passieren relativ wahrscheinlich Eintrittswahrscheinlichkeit sehr wahrscheinlich Konzentration auf die hohen und sehr hohen Risiken, weitere Risiken werden in ihrer Entwicklung beobachtet (Risikomanagementzyklus) 220

25 Risiko-Behandlung Ziel: Erstellung eines Maßnahmenplanes zur Risikobehandlung Klassen von Maßnahmen Maßnahmen zur Reduktion der Eintrittswahrscheinlichkeit eines Risikos: Präventionsmaßnahmen (proaktiv) Maßnahmen zur Reduktion des Schadensausmaßes: Vorsorgemaßnahmen (Katastrophenplan, reaktiv) Keine Maßnahmen Ursachen werden angegangen Auswirkungen werden angegangen generell gilt: Verhältnismäßigkeit zwischen Schadenshöhe und Aufwand/Kosten der Maßnahmen muss gewahrt sein 221

26 Arten von Maßnahmen Vermeidungsmaßnahmen wie kann frühzeitig die Gefahr, dass ein Risiko eintreten könnte, verringert werden Delegationsmaßnahmen können Risiko auf andere Projektbeteiligte, möglichst Kunden oder Unterauftragnehmer delegiert werden, so dass ein eintretendes Risiko nicht unseren Projekterfolg gefährdet Beobachtungsmaßnahmen wenn man keine aktiven Maßnahmen ergreifen kann/will, muss explizit festgehalten werden, wie man eine Veränderung der Eintrittswahrscheinlichkeit des Risikos erkennen will Eventualfallmaßnahmen was muss bzw. kann noch gemacht werden, wenn das Risiko eintritt, um den Schaden dann noch minimieren zu können (typischerweise mit den anderen Maßnahmenarten verknüpft genutzt) 222

27 Umgang mit Spielverderbern Spätestens in der Analysephase wird oft deutlich, dass es einzelne Risiken gibt, deren Eintreten ein Projekt unmittelbar zum Scheitern bringen, z.b. wird der einzige DB-Experte Gustav in das kritische Projekt X abgezogen, steht das Projekt solche Risiken können meist auf Projekt-Niveau nicht mehr gemanagt werden, da sie zu einem zu großen Risikoaufschlag führen können Solche Risiken müssen an die obere Ebene delegiert werden und werden dadurch zu Randbedingungen des Projekts ( Gustav steht zur Verfügung ) -> Hier ist oft das Rückgrat des Risikomanagers (Projektleiters) gefordert 223

28 Risikomanagement in laufenden Projekten Ein initialisiertes Risikomanagement macht nur Sinn, wenn es aktiv im laufenden Projekt durch den Risiko-Verantwortlichen (häufig dem Projektleiter) aufdatiert wird Zur Feststellung des Projektstands gehört neben den Daten zum Fertigstellungsgrad und dem Verbrauch an Ressourcen eine Kontrolle, wie es um die Indikatoren der Risiken steht Es ist wichtig, dass neue Risiken, die erst im Laufe des Projekts sichtbar werden, mit in das Risikomanagement aufgenommen werden -> häufig ist ein formaler Projekt-Review-Prozess zu bestimmten Meilensteinen mit einer Betrachtung der Risikolage sinnvoll 224

29 Vorgehen bei Großprojekten Bei Großprojekten ist es sinnvoll, ein firmeneigenes Vorgehen zum Risikomanagement zu definieren Das Risikomanagement findet in den Projekten statt, soll aber extern durch Erfahrungsträger im Projektmanagement begleitet werden Das Vorgehen muss verpflichtend für alle Projektteilnehmer werden Das Vorgehen muss dazu beitragen, dass eine firmenspezifische, also an die Firmenkultur angelehnte, Erfahrungsbasis zum Risikomanagement aufgebaut wird Bei kleineren Projekten ist eine passende vereinfachte Version des Risikomanagements durchzuführen Die Führung eines eigenen Risikomanagementplans kann sinnvoll sein 225

30 IT-Projekte im Spannungsfeld der Firma Beschaffung Firmenkomponente Personalwesen Geschäftsführung Controlling IT-Projekt Y Abteilung deren mögliches Ziel möglichst späte, konsolidierte Beschaffung flexibel einsetzbare Mitarbeiter klare Zahlen für einzelne Entwicklungsphasen Werkzeug B als Firmenstandard etablieren hohe Faktura neue Kunden gewinnen Wunsch/Sachstand IT-Projekt SW/HW steht immer sofort zur Verfügung Experten mit großer Erfahrung inkrementelle Entwicklung, kurzfristiger Fokuswechsel Entwicklung und Wartung mit Werkzeug A Ausbildung on demand langfristige Zusammenarbeit mit Altkunden 226

31 Widerstände gegen Risikomanagement 1. We have no risk. 2. Give us an hour and we ll tell you our top ten risk item. 3. Making risks public will kill the program. 4. The customer goes ballistic whenever he/she hears of a potential problem. 5. We deal with problems as they arise. 6. My customer doesn t want to hear that he/she is the source of risk. 7. Identifying risks is bad for my career. 8. This is development why should we worry about supportability and maintainability risks? Ausschnitt aus Little Brown Book of Program Manager Bad Excuses, 227

32 Übung Führen Sie ein Risikomanagement für Ihr Projekt ein, bzw. ergänzen Sie Ihren Ansatz um das systematische Vorgehen. Erstellen Sie eine Risikoliste und geben Sie neben den üblichen Attributen einen Kommentar dazu, wie sich das Risiko im laufenden Projekt verändert hat und welche Veränderungen Sie weiterhin erwarten. Erstellen Sie einen Fragenkatalog, mit dem Sie möglichst viele Risiken einer Bachelor-Arbeit erkennen können. 228

33 Übung Entwerfen Sie eine Risikomanagement-Datenbank, lassen Sie dabei die Informationen über Entitäten und Attribute (vielleicht sind einige der bisher genannten Attribute besser Entitäten) aus den vorherigen Veranstaltungen einfließen. Lassen Sie in ihr Modell die Möglichkeit zur Risikoverfolgung (und damit Maßnahmenverfolgung) im Projektverlauf einfließen. Schaffen Sie die Möglichkeit, dass Risiko-Erfahrungen aus anderen Projekten mit in Ihre DB einfließen können. Überlegen Sie sich, mit welchen anderen Projektmanagementwerkzeugen oder anderen Werkzeugen in Unternehmen Ihre DB zusammen arbeiten sollte. Welche Informationen werden über diese Schnittstellen fließen? 229