Risikomanagement in IT-Projekten:

Transkript

1 Risikomanagement in IT-Projekten: Eine Delphi-Studie bei der Allianz Deutschland Sebastian Pongratz & Gerhard Haybach in Kooperation mit Page 1 1

2 Agenda 2

3 I Risikomanagement - Allgemein nach Boehm (1991) 3

4 I Motivation Risiken??? Was sind die Risiken? Berücksichtigung in der Praxis? 4

5 I Risikomanagement - Literatur Chaos Studie, KPMG-Studien, etc. analysieren Ursachen für Scheitern Einige Studien zu Risiken in IT-Projekten: Meist allgemeine Befragung auf Managementebene Unstrukturiertes Vorgehen Viele Literaturarbeiten Viele unterschiedliche Ergebnisse in den Bewertungen Immer allgemein, keine Betrachtung von konkreten Projekten Welche Risiken stehen im Vordergrund? In wieweit unterscheiden sich verschiedene Projekttypen hinsichtlich der auftretenden Risiken? Gibt es generische und projekttypenspezifische Risiken? 5

6 II Untersuchungsumfeld Allianz Deutschland 6

7 II Projekttypen Softwareentwicklung Firmen- und Produkt-spezifische Informationssysteme Hoher Eigenentwicklungsanteil Standardsoftware Virtualisierung Softwareverteilung Datenbanksysteme Betriebssysteme Motivation 7

8 III Untersuchungsmöglichkeiten Datenanalyse Keine Datensammlungen vorhanden 8

9 III Untersuchungsmöglichkeiten Datenanalyse Umfrage Eine Umfrage ungeeignet für zwei aufeinander aufbauende Fragestellungen 9

10 III Untersuchungsmöglichkeiten Datenanalyse Umfrage Interview Zu hoher Zeitaufwand Gruppeninterview ungeeignet aufgrund von Gruppendynamiken 10

11 III Untersuchungsmöglichkeiten Datenanalyse Umfrage Interview Delphi-Methode Kombination der Vorteile von Interview und Umfrage Mehrstufige schriftliche Befragungsmethode von Experten Strukturierter Informationsfluss Anonymität der Experten Regelmäßige Informationsrückkoppelung Kaum Gruppendynamiken 11

12 III Delphi-Methode 12

13 IV Angewandtes Vorgehen Auswahl der Experten Identifikation Vorauswahl Bewertung I Bewertung II 18 Teilnehmer (3 Gruppen a 6 Projektleiter) Kriterien: Möglichst erfahrene und interessierte PLs Selbstkritische Haltung Unterschiedliche Projektumfelder Projekt mind. 2/3 abgeschlossen und nicht älter als 2 Jahre 19,8 Jahre IT-Erfahrung, 13,4 Jahre PL-Erfahrung Projektaufwand durchschnittlich 246 PM 6 Projekte mit mehr als 500 PM 13

14 IV Angewandtes Vorgehen Auswahl der Experten Identifikation Vorauswahl Bewertung I Strukturierte Einzelinterviews Risiken anhand des letzten/aktuellen Projektes identifiziert Risikoliste verwendet (sofern vorhanden) Duplikate entfernt und zusammengefasst 100 verschiedene Risiken Bewertung II 14

15 IV Angewandtes Vorgehen Auswahl der Experten Identifikation Vorauswahl Bewertung I Bewertung II Per Trennung der Teilnehmer in die 3 Projekttypen Auswahl der wichtigsten Risiken für den Projekterfolg (mindestens 10 aus 100) Wichtig = Auswirkung x Eintrittswahrscheinlichkeit Min. 3/6 Projektleitern ausgewählt für Bewertung Intern getriebene: 18 Extern getriebene: 19 Standardsoftware: 13 15

16 IV Angewandtes Vorgehen Auswahl der Experten Identifikation Vorauswahl Bewertung I Einzelinterviews Bewertung durch sortieren in Rangfolge Erfassung der Bewertungsgründe Berechnung der durchschnittlichen Ränge Auswertung des Konsens mit Kendall W Intern getriebene: 0,28 (sehr schwach) Extern getriebene: 0,34 (schwach) Standardsoftware: 0,38 (schwach) Bewertung II 16

17 IV Angewandtes Vorgehen Auswahl der Experten Identifikation Vorauswahl Bewertung I Bewertung II Per Feedback aus 1. Bewertungsrunde Anpassung der Bewertung mittels Gründe der anderen Teilnehmer Intern getriebene: 0,43 (schwach) Extern getriebene: 0,45 (schwach - moderate) Standardsoftware: 0,69 (fast stark) Abbruchkriterium erfüllt Intern getriebene: starke Unterschiede Extern getriebene: 2 unveränderte Bewertungen Standardsoftware: Starker Konsens 17

18 IV Ergebnisse 100 identifizierte Risiken Team Unternehmensumfeld Sponsoren externe Partner Relationship Management Abschluss Projekt externe Einflüsse Projektorganisation Anforderungen Planung Technologie Entwicklungsprozess Testen 18

19 IV Ergebnisse Verteilung der Risiken Team Unternehmensumfeld Sponsoren Viele verschiedene technische Risiken externe Partner 10 Relationship Management Intern getriebene Projekte in fast allen Kategorien am vielfälltigsten Abschluss 0 externe Einflüsse Extern getriebene Projekte in den Anforderungen risikoreich Projektorganisation Anforderungen Planung Technologie Entwicklungsprozess Testen intern getriebene Softwareentwicklung extern getriebene Softwareentwicklung Infrastruktur- & Standardsoftware 19

20 IV Ergebnisse Bewertungen Viele technischen Risiken ausgewählt Extern getriebene Projekte sehr viele Teamrisiken Infrastrukturprojekte nur beim Projektabschluss mehr Risiken Instabile Anforderungen 1 6 Abhängigkeiten zu anderen Projekten 1 15 Personalmangel

21 IV Ergebnisse - Bewertungen Projektumfeld 8 Ausgeglichenes Verhältnis verschiedener Risikotypen mit Tendenz zu technischen Risiken 4 0 Projektmanagement intern getriebene Softwareentwicklung extern getriebene Softwareentwicklung Infrastruktur- & Standardsoftware Technische Risiken 21

22 IV Vergleich mit bisherigen Studien Projektumfeld 8 4 Ausgeglichenes Verhältnis verschiedener Risikotypen mit Tendenz zu technischen Risiken Vollständig gegensätzlich bei technischen Risiken im Vergleich zu Schmidt et. al. (2001); Kappelman, McKeeman und Zhang (2006) 0 Projektmanagement intern getriebene Softwareentwicklung extern getriebene Softwareentwicklung Infrastruktur- & Standardsoftware Schmidt et. al Kappelman, McKeeman und Zhang 2006 Technische Risiken 22

23 V Schlussfolgerungen Wahrnehmung der Risiken durch Risikolisten deutlich gesteigert SW-Entwicklungen mehr (verschiedene) Risiken als bei Standardsoftwareeinführung Technische Risiken spielen eine wichtige Rolle Projektumfeldrisiken haben hohen Einfluss und zugleich schwer beherrschbar durch Projektleiter Sichtweise auf die Risiken stark abhängig von Erfahrungen 23

24 V Erfahrungen mit der Delphi-Methode Vorteile Sehr gut für Informationsgewinnung Gut anpassbar auf Fragestellung Deutlich mehr Resultate durch Informationsrückkoppelung Teilweise in Interviews führt zu detaillierteren und umfangreicheren Infos Zu beachten Hoher Zeitaufwand Rücklaufquote bei kleiner Panelgröße Einfluss einzelner Stimmen auf Gruppenmeinungsbild Tendenz zu Nicht-Ändernden Einzelmeinungen Abbruchkriterium mit Kendall W alleine nicht ausreichend 24

25 V Benefits Theorie Praxis 25

26 Vielen Dank für Ihre Aufmerksamkeit! Fragen? 26

27 A Quellen Boehm, Barry W. Software risk management. ESEC (European Software Engineering Conference) (1989): Wallace, Linda, Mark Keil, and Arun Rai. How Software Project Risk Affects Project Performance: An Investigation of the Dimensions of Risk and an Exploratory Model. Decision Sciences 35, no. 2 (May 2004): Hörmann, Stefan, Michael Schermann, and Helmut Krcmar. Towards Understanding the Relative Importance of Risk Factors in IS Projects: A Quantitative Perspective. In 18th European Conference on Information Systems, 1-18, Schmidt, Roy C., Kalle Lyytinen, Mark Keil, and Paul E. Cule. Identifying Software Project Risks: An International Delphi Study. Journal of Management Information Systems 17, no. 4 (2001): Kappelman, Leon A., Robert McKeeman, and Lixuan Zhang. Early Warning Signs of IT Project Failure: The Dominant Dozen. Information Systems Management 23, no. 4 (September 2006):

28 Backup 28

29 II Risikomanagement bei der Allianz Deutschland 29

30 IV Angewandtes Vorgehen Intern Extern Infrastr./Standard 1 Runde 1 Runde 2 Perfekter Konsens 1 Runde 1 Runde 2 Perfekter Konsens 1 Runde 1 Runde 2 Perfekter Konsens

31 IV Ergebnisse Vorauswahl externe Partner Team Unternehmensumfeld Sponsoren Relationship Management Viele technischen Risiken ausgewählt Extern getriebene Projekte sehr viele Teamrisiken Abschluss 0 externe Einflüsse Infrastrukturprojekte nur beim Projektabschluss mehr Risiken Projektorganisation Anforderungen Planung Technologie Entwicklungsprozess Testen intern getriebene Softwareentwicklung extern getriebene Softwareentwicklung Infrastruktur- & Standardsoftware 31

32 IV Ergebnisse Bewertungen (Auszug) Instabile Anforderungen 1 6 Fachliches Konzept verzögert sich 2 Abhängigkeiten zu anderen Projekten 1 15 Verfügbarkeit der Testinfrastruktur 2 4 Unklare Anforderungen 3 6 Unrealistische zeitliche Vorgaben 3 7 Komplexität der Schnittstellen 5 2 Personalmangel Fachbereichsübergreifende Entscheidungen 7 4 Komplexität des Systems 5 5 Aufwände kaum schätzbar 7 Konkurrenz mit anderen Projekten

33 IV Vergleich mit bisherigen Studien Schmidt et. al. (2001) bislang umfangreichste Ergebnisse bei der Risikoidentifikation in IT-Projekten 13 Risiken nicht mehr gefunden: Unternehmensumfeld Prozesse im Projektmanagement Vorgehensmodell Viele neue Risiken bei Technologien und Testen, Projektabschluss, Team Allianz-Spezifika 33

34 V Verbesserungspotentiale Berechnung der Projektkosten und Entscheidungen Unterschiede bei StandardSW vs. Eigenentwicklung Alle Statusberichte mit aktuellen Risiken Eventl. Projektanträge mit Risiko(-gruppen) Risikomatrix als Werkzeug für die Risikoidentifikation Projektabschlussbericht mit Risikobetrachtung Agile Projekte enthalten auch Risiken! Wieso kein RM? 34

35 V Ausblick für zukünftige Forschung Risikomanagement: Sind Standardsoftwareprojekte weniger kritisch? Wechselwirkung zwischen den Risiken Begriffsdefinition (Ursache vs. Folge) Kategorisierung In wie weit nimmt die Sichtweise Einfluss auf die Bewertung? Delphi-Studie: Nimmt Anzahl der Vorauswahl Einfluss auf Konsens Abbruchkriterium mit Beachtung wer wie seine Meinung ändert Gründe für Ändern/Nicht-ändern Tendenz in Richtung Nicht-ändern 35