MeetUp-Vortrag zum Themengebiet Projektmanagement, Daniel Volk, 23.07.2009

1. Eine Einführung in das
Risikomanagement
Daniel Volk
23.07.09

2. Daniel Volk
23.07.09
Warum Risikomanagement?
 Projekterfolg bei IT-Projekten
Quelle: Standish Group 2004
 „If you don‘t actively attack risks, they will
actively attack you.“ [Tom Gilb]

3. Daniel Volk
23.07.09
Was ist Risiko?
 Ein Risiko ist ein „unsicheres Ereignis oder
Bedingung mit positivem oder negativem
Effekt auf die Projektziele.“ [PMBOK]
 D.h.: Ein Risiko ist oftmals gleichzeitig auch
eine Chance (spekulatives Risiko) und damit
Bedingung für den Geschäftserfolg!
 Risiko == Eintrittswahrscheinlichkeit
Auswirkungen
X

4. Daniel Volk
23.07.09
Was ist Risikomanagement?
 Risikomanagement ist ein „systematischer
Prozess der Identifikation, Analyse und
Antwort auf ein Projektrisiko“ [PMBOK]
 Das primäre Ziel ist, Risiken zu
kontrollieren – nicht, sie zu vermeiden!
 D.h., beim Risikomanagement geht es primär
um Aktionen, die ausgeführt werden, bevor
das Risiko zum Problem wird.

5. Daniel Volk
23.07.09
Der Prozess des RM
 Risikomanagement ist ein zyklischer
Prozess aus:
 Risikoidentifikation
 Risikobewertung
 Risikoplanung
 Risikoabschwächung
 Risikoverfolgung
BewertungBeherrschung

6. Daniel Volk
23.07.09
Der Prozess des RM
 Operatives Risikomanagement ist ein
(Teilgebiet des) Projektmanagement:
ManagementProjekt-Management
Beide

7. Daniel Volk
23.07.09
Risikoidentifikation
 IT-Standardrisiken [Boehm 1989]
1. Personelle Defizite
2. Unrealistische Projektplanung
3. Falsche Funktionen werden entwickelt
4. Unbrauchbare Benutzerschnittstelle
5. Over-Engineering/ Gold-Plating
6. Ständige Änderungen der Anforderungen
7. Unzureichende Qualität externer Komponenten
8. Lieferantenverzug
9. Unzureichende Performanz
10. Technologieüberforderung

8. Daniel Volk
23.07.09
Risikoidentifikation
 IT-Standardrisiken [McConnel 1996]
1. Motivationsmangel
2. Problemmitarbeiter
3. Laute und enge Arbeitsplätze
4. Aufgabe der Projektplanung unter Zeitdruck
5. Vernachlässigung von Analyse und Design
6. Vernachlässigung der Qualitätssicherung
7. Fehlende Änderungskontrolle
8. Einführung neuer Entwicklungsmethoden
9. Zeitverlust bei der Projektinitiierung
10. Unzureichende Nutzereinbindung
11. Ehrgeizige Zeitplanung
12. Drastische Personalaufstockung

9. Daniel Volk
23.07.09
Risikoidentifikation
 Risikokategorien (z.B. nach [SWEBOK])
 Software Requirements
 [Boehm] 3. Falsche Funktionen werden entwickelt
 [Boehm] 4. Unbrauchbare Benutzerschnittstelle
 [Boehm] 5. Over-Engineering/ Gold-Plating
 [Boehm] 6. Ständige Änderungen der Anforderungen
 [McConnel] 7. Fehlende Änderungskontrolle
 [McConnel] 10. Unzureichende Nutzereinbindung
 Software Design
 [McConnel] 5. Vernachlässigung von Analyse und Design
 Software Construction
 Software Testing

10. Daniel Volk
23.07.09
Risikoidentifikation
 Risikokategorien (z.B. nach [SWEBOK])
 Software Maintenance
 Software Configuration Management
 Software Engineering Management
 [Boehm] 2. Unrealistische Projektplanung
 [Boehm] 8. Lieferantenverzug
 [McConnel] 4. Aufgabe der Projektplanung unter Zeitdruck
 [McConnel] 9. Zeitverlust bei der Projektinitiierung
 [McConnel] 11. Ehrgeizige Zeitplanung
 [McConnel] 12. Drastische Personalaufstockung
 Software Engineering Process
 Software Engineering Tools and Methods
 [McConnel] 8. Einführung neuer Entwicklungsmethoden

11. Daniel Volk
23.07.09
Risikoidentifikation
 Risikokategorien (z.B. nach [SWEBOK])
 Software Quality
 [McConnel] 6. Vernachlässigung der Qualitätssicherung
 People
 [Boehm] 1. Personelle Defizite
 [Boehm] 8. Lieferantenverzug
 [Boehm] 1. Motivationsmangel
 [McConnel] 2. Problemmitarbeiter
 [McConnel] 3. Laute und enge Arbeitsplätze
 Holistic
 [Boehm] 7. Unzureichende Qualität ext. Komponenten
 [Boehm] 9. Unzureichende Performanz
 [Boehm] 10. Technologieüberforderung

12. Daniel Volk
23.07.09
Risikoidentifikation
 Risikokategorien
 Nach Ursprung
 Interne Risiken
Problemfelder im direkten Einflussbereich (z.B. Personal,
Kommunikation, Entwicklung)
 Externe Risiken
Geschehnisse ohne Möglichkeit der Einflussnahme (z.B.
Gesetzesvorgaben, Marktfluktuation, etc.)
 Nach Kontext
 Operative Risiken
Projekt-spezifische Unsicherheiten mit Auswirkungen auf
die Projektparameter (Zeit, Kosten, Qualität, Quantität)
 Strategische Risiken
Langfristige und unternehmensweiten Gefahren

13. Daniel Volk
23.07.09
Risikoidentifikation
 Techniken zur Identifizierung
 Erfahrungswerte
 Abgeschlossene Projekte werden konsequent auf
entstandene Probleme und deren Ursachen hin
untersucht
 Identifizierte Problemfelder werden zusammen mit
bewährten Lösungsstrategien katalogisiert
 Checklisten
 Alle Risiko-Teilbereiche werden auf Basis von Checklisten
gegen branchen-übliche Standard-Risiken geprüft
 Unternehmens-spezifischen Risiken wird durch Tailoring
und Anpassung der Checklisten (vgl. Erfahrungswerte /
Risikokultur) Rechnung getragen
 Im Bedarfsfall mit Werkzeugunterstützung

14. Daniel Volk
23.07.09
Risikoidentifikation
 Techniken zur Identifizierung
 Bedrohungsszenarien
 Genutzte Geschäftsprozesse/ Arbeitsschritte werden auf
Basis sog. „Was wäre, wenn?“-Szenarien „durchgespielt“
 Zu gefundenen Risikofällen mit entsprechender
Risikoklasse werden zudem Lösungsansätze formuliert
 Brainstorming
 Initialtechnik, um einen ersten Überblick über Risiko-
Potentiale zu erhalten (fehlerträchtig)
 Interviews
 Explizite Befragung einzelner Interessensgruppen im
Projekt bezüglich subjektiver Problemfelder
 Gleicht fehlende Kommunikation im Projekt aus

15. Daniel Volk
23.07.09
Risikoidentifikation
 Techniken zur Identifizierung
 Konfliktanalyse
 Objektive Analyse der Interessenssphären (Bedürfnisse,
Ziele) einzelner Gruppen und Schlüsselpersonen mit
Einfluss auf das Projekt
 Identifikation potentieller Zielkonflikte
 Erarbeitung möglicher Win-Win-Konstellationen
 SWOT-Analyse
 Betrachtung des Projekt aus Sicht der Organisation
bezüglich eigener Stärken und Schwächen sowie sich
ergebender Möglichkeiten und Gefahren
 Fokus liegt auf strategischen/ externen Risiken

16. Daniel Volk
23.07.09
Risikoidentifikation
 Beispiel für eine Checkliste
 Checkliste für Produktanforderungen
 Wer ist der Kunde für das Produkt?
 Wer ist nicht der Kunde? (welche Anforderungen fallen
weg, weil hausgemacht)
 Welche Konflikte herrschen zwischen den Parteien?
 Welches Problem soll das System lösen?
 Welchen Nutzen hat der Kunde vom Produkt?
 Kommen die Anforderungen von der richtigen Seite
(wurde jemand übersehen?)
 Sind die späteren Benutzer bekannt?
 Wie werden die Nutzer mit dem System kommunizieren?
 Wie sieht das Umfeld des Systems aus?
 ...

17. Daniel Volk
23.07.09
Risikoidentifikation
 Beispiel für eine Checkliste
 Checkliste für Produktanforderungen
 Sind die Anforderungen vollständig?
 Sind die Anforderungen korrekt formuliert (gemäss der
Intention des Nutzers)?
 Sind die Anforderungen klar und verständlich formuliert?
 Sind die Anforderungen zur Zielerfüllung notwendig?
 Sind die Anforderungen mit den gegebenen Ressourcen
(Personal / Technik) umsetzbar?
 Sind die Anforderungen test- (und damit verifizier-)bar?
 Wurden die Anforderungen vom Kunden priorisiert?
 Welche Anforderungen werden sich wie stark ändern?
 Wurde eine Änderungsverfolgung etabliert?
 ...

18. Daniel Volk
23.07.09
Risikobewertung
 Allgemeines
 Die Abschwächung aller Risiken ist nicht möglich
(zu hoher Aufwand!)
 Fokussierung ist notwendig (Beschränkung
auf „Top-Ten-Risikoliste“)
 Die Risikobeurteilung hängt stark von der
persönlichen Risikoeinstellung ab
 Ein formalisiertes (und einfaches)
Bewertungsschema hilft beim Angleichen der
Risikowahrnehmung
 Zudem sind mehrere(!), unabhängige(!)
Bewertungen empfehlenswert

19. Daniel Volk
23.07.09
Risikobewertung
 Qualitative Analyse
 Dient einer ersten Abschätzung der Risiken
untereinander und der Konzentration auf
relevante Risiken
 Hierzu erfolgt eine Einteilung in Risikoklassen
Risikoklasse 4
„Peanuts“
Risikoklasse 2
„Serious, but rare“
Risikoklasse 3
„Annoying“
Risikoklasse 1
„Showstopper“
Wahrscheinlichkeit
Schadenshöhe

20. Daniel Volk
23.07.09
Risikobewertung
 Quantitative Analyse
 Detailliert die qualitative Abschätzung durch
 Konkrete Wahrscheinlichkeiten und Schadenshöhen (z.B.
durch Mittelwerte aus ähnlichen bereits durchgeführten
Projekten und Anpassung an Projektrahmen)
 Nutzung „allgemeingültiger“ Formeln
 Stochastische Simulation des Entscheidungsraums
 Ermöglicht damit die Beurteilung einzelner
Projektentscheidungen
 Erlaubt die Anpassung des Projektrahmens an
die bestehenden Projektrisiken

21. Daniel Volk
23.07.09
Risikobewertung
 Detaillierung der qualitativen Abschätzung
Maßnahmen
geplant
25%
50%
75%
<10k € <1.25m €<50k € <250k €

22. Daniel Volk
23.07.09
Risikobewertung
 Beurteilung einer Projektentscheidung

23. Daniel Volk
23.07.09
Risikobewertung
 Anpassung des Projektrahmens
Beispiel Projektdauer
Geplanter Projektbeginn
01.01.2010
Schätzungen Projektende
a) vor Mai 2010 unmöglich
b) wahrscheinlich II/ 2010
c) gute Chance für Juli/ August
2010
d) 100%tig bis März 2011
Geplantes Projektende
30.09.2010

24. Daniel Volk
23.07.09
Risikoplanung
 Integration in das Projektmanagement
 Nach Risikoidentifikation und –bewertung erfolgt
die Einplanung der Risikoabschwächung
 Die Ausprägung ist abhängig vom Geschäftsfeld/
dem Projekt/ der jeweiligen Risikokultur
Risikoavers
„Maus“
Risikopenibel
„Bürokrat“
Risikofreudig
„Cowboy“
Risikobewusst
Kontrolliert agierender
Unternehmer
Risiko
Kontrolle

25. Daniel Volk
23.07.09
Risikoplanung
 Integration in das Projektmanagement
 Allgemeine Umsetzung in Form einer Risikoliste/
Einbettung der Ergebnisse in die Projektplanung
 Beispielhafte Vorlage
 Identifikation Nummer, Namen
 Beschreibung Kurzbeschreibung mit Ursache und Effekt
 Bewertung Mindestens qualitative Beurteilung der
Wahrscheinlichkeit und der Auswirkungen
 Priorität Wichtigkeit des Risikos auf Basis der
Bewertung (Entscheidung der Behandlung)
 Maßnahmen Geplante Risikoabschwächung
 Aufwand Für die Risiko-Maßnahmen kalkulierte
Kosten/ Zeit (für Projektkalkulation)

26. Daniel Volk
23.07.09
Risikoabschwächung
 Die Ebenen der Risikoabschwächung
 Innerhalb eines Projekts (in den Projektphasen)
 Bei früh erkennbaren und leicht zu behebenden Risiken
 Beispiele: falsche Anforderungen, Fehler in Dokumenten
 Auf Projekt-Ebene (im Rahmen der Projektplanung)
 Bei spät erkennbaren, aber projekt-spezifischen Risiken
 Beispiel: Unklare Stakeholder/ Differenzen auf Auftrag-
geberseite
 Projekt-übergreifend (durch Unternehmensstrategie)
 Bei sporadischen Risiken mit im Einzelfall untragbaren
Abschwächungskosten
 Beispiel: Verzögerungen in der Projektlaufzeit

27. Daniel Volk
23.07.09
Risikoabschwächung
 Die Arten der Risikoabschwächung
 Risikovermeidung (präventiv)
 Ansatzpunkt: Eintrittswahrscheinlichkeit
 Vorteile
 Kann als einzige Maßnahme 100%tige Sicherheit und
damit Planbarkeit bringen
 Nachteile
 Nicht immer möglich (wenn inhärent an Projekt gekoppelt)
 Nicht immer erwünscht (verhindert auch Chancen)
 Beispiel
 Risiko: Instabilitäten/ Performance-Probleme durch
„Bleeding-Edge“-Technologie
 Maßnahme: Nutzung praxisbewährter aber weniger
leistungsfähigerer Standardtechnologie

28. Daniel Volk
23.07.09
Risikoabschwächung
 Die Arten der Risikoabschwächung
 Risikobegrenzung (reaktiv)
 Ansatzpunkt: Auswirkungen
 Umsetzung: Pauschalbehandlung der Folgen
 Vorteile
 Erlaubt Beherrschung unkalkulierbarer Risiken
 Die Zusammenfassung und Vereinfachung erlaubt eine
Fokussierung auf relevante Risiken
 Nachteile
 Umsetzung ist deutlich teurer als Risikobehandlung
 Beispiel
 Risiko: Terminverzögerung durch Lieferanten
 Maßnahme: Einplanung eines Projektpuffers
 Risiko: Nutzung von OpenSource-Technologie
 Maßnahme: Bezug über Subunternehmer (Verlagerung)

29. Daniel Volk
23.07.09
Risikoabschwächung
 Die Arten der Risikoabschwächung
 Risikobehandlung (präventiv)
 Ansatzpunkt: Eintrittswahrsch. + Auswirkungen
 Umsetzung: Konkrete Behandlung der Gründe/ Folgen
 Vorteile
 Umsetzung ist deutlich günstiger als Risikobegrenzung
 Nachteile
 Bedarf früh kalkulier- und damit klar bewertbarer Risiken
 Ist schwieriger in der Umsetzung (Kosten-Nutzen-Vgl.)
 Beispiel
 Risiko: Engpass bei kritischen Fähigkeiten/ Mitarbeitern
 Maßnahme: Entwicklung im Pair Programming
 Risiko: Hohe Ausfallraten durch Grippepandemie
 Maßnahme: Ausarbeitung eines Notfallplans

30. Daniel Volk
23.07.09
Risikoabschwächung
 Die Arten der Risikoabschwächung
 Risikoignoranz (inaktiv)
 Ansatzpunkt: Risikowahrnehmung
 Vorteile
 Erlaubt Fokussierung auf relevante Risiken
 Verursacht keinen Aufwand
 Nachteile
 Das Risiko kann bei
falscher Bewertung
zum Problem werden
 Beispiel
 Risiko: Umsetzung einer graphisch nicht ansprechenden
Benutzerschnittstelle

31. Daniel Volk
23.07.09
Risikoabschwächung
 Die Auswahl der Risikoabschwächung
 Risiko (neg. Fall) >> Chance (pos. Fall) [RK 1, 2, 3, 4]
 „unnötige Risiken“ -> Risikovermeidung
 Relevanz des Risikos << Projektkategorie [RK 4]
 „irrelevante Risiken“ -> Risikoignoranz
Risikoklasse 4
„Peanuts“
Risikoklasse 2
„Serious, but rare“
Risikoklasse 3
„Annoying“
Risikoklasse 1
„Showstopper“
Wahrscheinlichkeit
Schadenshöhe

32. Daniel Volk
23.07.09
Risikoabschwächung
 Die Auswahl der Risikoabschwächung
 Bewertbarkeit des Risikos? [RK 1, 2, 3]
 „-“ Risikobegrenzung ... Risikobehandlung „+“
 Verhältnis Investition zu Risiko? [RK 1, 2, 3]
 „=“ Risikobegrenzung ... Risikobehandlung „<<“
Risikoklasse 4
„Peanuts“
Risikoklasse 2
„Serious, but rare“
Risikoklasse 3
„Annoying“
Risikoklasse 1
„Showstopper“
Wahrscheinlichkeit
Schadenshöhe

33. Daniel Volk
23.07.09
Risikoabschwächung
 Abschwächung der IT-Standardrisiken
1. Personelle Defizite
 Maßnahmen zum Team-Building (z.B. durch Coach)
 Fokussierung durch bessere Kommunikation (z.B. durch
Projektzeitung/- homepage)
 Vermeidung zu starker Parallelisierung von Projekten
 Fortbildungsmaßnahmen (auf Basis Ausbildungsprofil)
 Pair Programming (Junior-/ Senior-Mix)
 Externe Wissensträger verpflichten (z.B. Freelancer)
2. Unrealistische Projektplanung
 Mehrfache und unabhängige Schätzungen
 Iterative Vorgehensmodelle
 Design to Cost/ Time-Boxing

34. Daniel Volk
23.07.09
Risikoabschwächung
 Abschwächung der IT-Standardrisiken
3. Falsche Funktionen werden entwickelt
 Nutzer-freundliche Methodik (z.B. Storyboarding)
 Evolutionäre Entwicklungsformen
 Unabhängige Reviews und Inspektionen der Analyse-
Artefakte (z.B. durch beauftragten QA-Dienstleister)
 Frühe Referenz-Installationen (Beta-Testing)
 Entwicklung beim Auftraggeber
4. Unbrauchbare Benutzerschnittstelle
 Entwicklung von GUI-Prototypen
 Detaillierte Nutzer-Analysen (sog. Personas)
 Nutzung von Usability-Guidelines/ Usability-Tests
 Ausweisung einer speziellen Rolle (SW-Ergonom)

35. Daniel Volk
23.07.09
Risikoabschwächung
 Abschwächung der IT-Standardrisiken
5. Over-Engineering/ Gold-Plating
 Striktes Requirements Management (v.a. im Sinne der
Nachvollziehbarkeit einzelner Anforderungen)
 Kostenverfolgung pro Anforderung/ Feature
 Projektverfolgung mittels Earned-Value
6. Ständige Änderungen der Anforderungen
 Striktes Change Management (Change Advisory Board)
 Klare Trennung von Marketing/ Entwicklung
 Iterative Vorgehensmodelle
 Vermeidung von vertraglichen Lücken/ Nachverhandlung

36. Daniel Volk
23.07.09
Risikoabschwächung
 Abschwächung der IT-Standardrisiken
7. Unzureichende Qualität externer Komponenten/
8. Lieferantenverzug
 Einforderung Zertifizierung (ISO 9000/10000, CMMI)
 Externer Projektleiter/ kontinuierliche Reviews
 Service Level Agreements/ Strafzahlungen
 Detaillierte und frühzeitige (Akzeptanz-)tests (auf Basis
klar definierter Meilensteine/ Releases)
9. Unzureichende Performanz
 Frühe Performanz- und Last-Tests mit Prototypen
 Simulation möglicher Realisierungs-Alternativen
 Modulare Architektur für einfachen Komponententausch

37. Daniel Volk
23.07.09
Risikoabschwächung
 Abschwächung der IT-Standardrisiken
10. Technologieüberforderung
 Marktsichtung/ Etablierung von Alternativen
 Rechzeitige Fortbildung von Fachpersonal
 Externe Wissensträger verpflichten (z.B. Consultants)
 Einrichtung R&D-Abteilung/ Forschungsprojekte

38. Daniel Volk
23.07.09
Risikoverfolgung
 Integration in das Projektmanagement
 Systematische und kontinuierliche Verfolgung
der Projektrisiken/ Einbettung der Prüfungen in die
Projektreviews/ -audits
 Pflege von Maßnahmenlisten
 Erweiterung der Vorlage
 Verantwortl. Die über die komplette Projektdauer für
das Risiko verantwortliche Person
 Geplante B. Die geplante Beurteilung des Risikos nach
Umsetzung der Risikoabschwächung
 Aktuelle B. Die tatsächliche, aktuelle Beurteilung
 Status Der aktuelle Status des Risikos
 Prüftermine Die nächsten Prüftermine

39. Daniel Volk
23.07.09
Risikoverfolgung
 Beispiel: RM-Anteil eines Projektreviews
Aktivität Zu bewertende Risiken
Projektmanagement Aufwandsschätzung vs. Plan, Earned Value,
Risikostatus, Prozessfähigkeit
Qualitätsmanagement Restfehler, offene Fehler, Kundenzufriedenheit
Anforderungen Anforderungsstabilität, -vollständigkeit
Design, Implementierung Implementierungsgrad der Anforderungen,
Restaufwand, Zeitverzug, Qualität
Test Restfehler, Zuverlässigkeit, Restaufwand
Auslieferung Restfehler, Zuverlässigkeit, Liefertermin,
Wartungskosten

40. Daniel Volk
23.07.09
Die Vorteile des RM
 Sichernd
 fokussiert auf Risiko-lastige Projektanteile und
benennte Risiko-Verantwortliche
 verringert böse Überraschungen/ Probleme
 verbessert die Qualität und Vorhersagbarkeit
 stabilisiert Schätzungen und Projektpläne
 reduziert den Aufwand (ROI ~ 1:10)
 erhöht die Erfolgswahrscheinlichkeit des Projekts
 Optimierend
 entkriminalisiert Risiken (Kulturänderung)
 erlaubt stärkere Risikoorientierung (Risiken und
Nutzen wachsen parallel)

41. Daniel Volk
23.07.09
Literatur
 Chapman, C., Ward, S. Project Risk Management: Processes,
Techniques and Insights. John Wiley & Sons. 2. Auflage 2003.
 DeMarco, T., Lister, T. Waltzing With Bears: Managing Risk on
Software Projects. Dorset House, März 2003.
 Wallmüller, E. Risikomanagement für IT- und Software-Projekte.
Hanser Fachbuchverlag, April 2004.
 Ebert, C. Risikomanagement kompakt. Elsevier GmbH, Spektrum
Akademischer Verlag, 2006.*
 Charette, R.N. Why Software Fails. IEEE Spectrum, Sep. 2005,
pp.42-49.
*Die Grafiken des Vortrags sind zum Teil genanntem Buch entnommen.