SlideShare ist ein Scribd-Unternehmen logo
Eine Einführung in das
Risikomanagement
Daniel Volk
23.07.09
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]
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
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.
Daniel Volk
23.07.09
Der Prozess des RM
  Risikomanagement ist ein zyklischer
Prozess aus:
  Risikoidentifikation
  Risikobewertung
  Risikoplanung
  Risikoabschwächung
  Risikoverfolgung
BewertungBeherrschung
Daniel Volk
23.07.09
Der Prozess des RM
  Operatives Risikomanagement ist ein
(Teilgebiet des) Projektmanagement:
ManagementProjekt-Management
Beide
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
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
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
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
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
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
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
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
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
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?
  ...
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?
  ...
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
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
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
Daniel Volk
23.07.09
Risikobewertung
  Detaillierung der qualitativen Abschätzung
Maßnahmen
geplant
25%
50%
75%
<10k € <1.25m €<50k € <250k €
Daniel Volk
23.07.09
Risikobewertung
  Beurteilung einer Projektentscheidung
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
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
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)
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
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
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)
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
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
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
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
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
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)
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
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
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
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
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
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)
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.

Weitere ähnliche Inhalte

Was ist angesagt?

Risk assessment principles and guidelines
Risk assessment principles and guidelinesRisk assessment principles and guidelines
Risk assessment principles and guidelines
Haris Tahir
 
PMI-RMP Exam Prep Presentation
PMI-RMP Exam Prep PresentationPMI-RMP Exam Prep Presentation
PMI-RMP Exam Prep Presentation
scottdreynolds
 
Enterprise risk & risk management - I
Enterprise risk & risk management - IEnterprise risk & risk management - I
Enterprise risk & risk management - I
Dr. Shiv S Tripathi
 
Risk assessment presentation
Risk assessment presentationRisk assessment presentation
Risk assessment presentation
mmagario
 
127017438_RMA_OperationalRiskAppetite_v1.0
127017438_RMA_OperationalRiskAppetite_v1.0127017438_RMA_OperationalRiskAppetite_v1.0
127017438_RMA_OperationalRiskAppetite_v1.0
Rachael Phelan
 
Project risk management
Project risk managementProject risk management
Project risk management
Er Swati Nagal
 
Risk Culture – Under the microscope
Risk Culture – Under the microscopeRisk Culture – Under the microscope
Risk Culture – Under the microscope
TPP Recruitment
 
Risk management
Risk managementRisk management
Risk management
Harold Malamion
 
Unidad 9 - Gestión de riesgos estratégicos
Unidad 9 - Gestión de riesgos estratégicosUnidad 9 - Gestión de riesgos estratégicos
Unidad 9 - Gestión de riesgos estratégicos
ToTCOOPiTech
 
Risk Management Maturity Model (RMMM)
Risk Management Maturity Model (RMMM)Risk Management Maturity Model (RMMM)
Risk Management Maturity Model (RMMM)
Adnan Naseem
 
Introduction to Risk Management ISO31000:2009
Introduction to Risk Management ISO31000:2009Introduction to Risk Management ISO31000:2009
Introduction to Risk Management ISO31000:2009
Ahmad Azwang Aisram Omar
 
Risk Identification Process PowerPoint Presentation Slides
Risk Identification Process PowerPoint Presentation SlidesRisk Identification Process PowerPoint Presentation Slides
Risk Identification Process PowerPoint Presentation Slides
SlideTeam
 
Risk leadership - implementing a risk strategy that works
Risk leadership - implementing a risk strategy that worksRisk leadership - implementing a risk strategy that works
Risk leadership - implementing a risk strategy that works
Clarkson Alliance
 
Introduction To Risk Management Powerpoint Presentation Slides
Introduction To Risk Management Powerpoint Presentation SlidesIntroduction To Risk Management Powerpoint Presentation Slides
Introduction To Risk Management Powerpoint Presentation Slides
SlideTeam
 
Einführung: Lernen und Kompetenzentwicklung
Einführung: Lernen und KompetenzentwicklungEinführung: Lernen und Kompetenzentwicklung
Einführung: Lernen und Kompetenzentwicklung
Sandra Schön (aka Schoen)
 
Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...
Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...
Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...
Hossam Elamir
 
Retrospective , Scrum, Agile,
Retrospective , Scrum, Agile,Retrospective , Scrum, Agile,
Retrospective , Scrum, Agile,
Asheesh Vashisht
 
Iso 31000 presentation
Iso 31000 presentationIso 31000 presentation
Iso 31000 presentation
christianaegerter1
 
Zarządzanie ryzykiem
Zarządzanie ryzykiemZarządzanie ryzykiem
Zarządzanie ryzykiem
MANDARINE Project Partners
 
Iso 31000.pdf
Iso 31000.pdfIso 31000.pdf
Iso 31000.pdf
AdykMargaRaharja
 

Was ist angesagt? (20)

Risk assessment principles and guidelines
Risk assessment principles and guidelinesRisk assessment principles and guidelines
Risk assessment principles and guidelines
 
PMI-RMP Exam Prep Presentation
PMI-RMP Exam Prep PresentationPMI-RMP Exam Prep Presentation
PMI-RMP Exam Prep Presentation
 
Enterprise risk & risk management - I
Enterprise risk & risk management - IEnterprise risk & risk management - I
Enterprise risk & risk management - I
 
Risk assessment presentation
Risk assessment presentationRisk assessment presentation
Risk assessment presentation
 
127017438_RMA_OperationalRiskAppetite_v1.0
127017438_RMA_OperationalRiskAppetite_v1.0127017438_RMA_OperationalRiskAppetite_v1.0
127017438_RMA_OperationalRiskAppetite_v1.0
 
Project risk management
Project risk managementProject risk management
Project risk management
 
Risk Culture – Under the microscope
Risk Culture – Under the microscopeRisk Culture – Under the microscope
Risk Culture – Under the microscope
 
Risk management
Risk managementRisk management
Risk management
 
Unidad 9 - Gestión de riesgos estratégicos
Unidad 9 - Gestión de riesgos estratégicosUnidad 9 - Gestión de riesgos estratégicos
Unidad 9 - Gestión de riesgos estratégicos
 
Risk Management Maturity Model (RMMM)
Risk Management Maturity Model (RMMM)Risk Management Maturity Model (RMMM)
Risk Management Maturity Model (RMMM)
 
Introduction to Risk Management ISO31000:2009
Introduction to Risk Management ISO31000:2009Introduction to Risk Management ISO31000:2009
Introduction to Risk Management ISO31000:2009
 
Risk Identification Process PowerPoint Presentation Slides
Risk Identification Process PowerPoint Presentation SlidesRisk Identification Process PowerPoint Presentation Slides
Risk Identification Process PowerPoint Presentation Slides
 
Risk leadership - implementing a risk strategy that works
Risk leadership - implementing a risk strategy that worksRisk leadership - implementing a risk strategy that works
Risk leadership - implementing a risk strategy that works
 
Introduction To Risk Management Powerpoint Presentation Slides
Introduction To Risk Management Powerpoint Presentation SlidesIntroduction To Risk Management Powerpoint Presentation Slides
Introduction To Risk Management Powerpoint Presentation Slides
 
Einführung: Lernen und Kompetenzentwicklung
Einführung: Lernen und KompetenzentwicklungEinführung: Lernen und Kompetenzentwicklung
Einführung: Lernen und Kompetenzentwicklung
 
Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...
Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...
Enterprise Risk Management in Healthcare Organisations “Going Beyond Patient ...
 
Retrospective , Scrum, Agile,
Retrospective , Scrum, Agile,Retrospective , Scrum, Agile,
Retrospective , Scrum, Agile,
 
Iso 31000 presentation
Iso 31000 presentationIso 31000 presentation
Iso 31000 presentation
 
Zarządzanie ryzykiem
Zarządzanie ryzykiemZarządzanie ryzykiem
Zarządzanie ryzykiem
 
Iso 31000.pdf
Iso 31000.pdfIso 31000.pdf
Iso 31000.pdf
 

Ähnlich wie Eine Einführung in das Risikomanagement

ASIS - Training #4 - Risikomanagement und soziale Innovation
ASIS - Training #4 - Risikomanagement und soziale InnovationASIS - Training #4 - Risikomanagement und soziale Innovation
ASIS - Training #4 - Risikomanagement und soziale Innovation
armelleguillermet
 
1x1 der Szenario-Entwicklung
1x1 der Szenario-Entwicklung1x1 der Szenario-Entwicklung
1x1 der Szenario-Entwicklung
Arne Gerdes
 
Impact Mapping - strategische Steuerung agiler Entwicklung
Impact Mapping - strategische Steuerung agiler EntwicklungImpact Mapping - strategische Steuerung agiler Entwicklung
Impact Mapping - strategische Steuerung agiler Entwicklung
Christian Hassa
 
Einfuehrung Projektmanagement
Einfuehrung ProjektmanagementEinfuehrung Projektmanagement
Einfuehrung Projektmanagement
Jürgen Bruns
 
2016-07-20 stresstest
2016-07-20 stresstest2016-07-20 stresstest
2016-07-20 stresstest
Bankenverband
 
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Markus Harrer
 
Move slow and fix things
Move slow and fix thingsMove slow and fix things
Move slow and fix things
Screamin Wrba
 
Project Management - Projekte erfolgreich konzipieren, planen und umsetzen
Project Management - Projekte erfolgreich konzipieren, planen und umsetzenProject Management - Projekte erfolgreich konzipieren, planen und umsetzen
Project Management - Projekte erfolgreich konzipieren, planen und umsetzen
PDAgroup
 
Modul 4 - Suche nach Frühwarnsignalen.pptx
Modul 4 - Suche nach Frühwarnsignalen.pptxModul 4 - Suche nach Frühwarnsignalen.pptx
Modul 4 - Suche nach Frühwarnsignalen.pptx
caniceconsulting
 
Projektleiter ärgere dich nicht
Projektleiter ärgere dich nichtProjektleiter ärgere dich nicht
Projektleiter ärgere dich nicht
FCT Akademie GmbH
 
MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...
MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...
MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...
MiPo-Konferenz / Hochschule Aalen
 
[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)
[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)
[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)
Sandra Schön (aka Schoen)
 
Projektmanagement
ProjektmanagementProjektmanagement
Projektmanagement
Andreas Hebbel-Seeger
 

Ähnlich wie Eine Einführung in das Risikomanagement (13)

ASIS - Training #4 - Risikomanagement und soziale Innovation
ASIS - Training #4 - Risikomanagement und soziale InnovationASIS - Training #4 - Risikomanagement und soziale Innovation
ASIS - Training #4 - Risikomanagement und soziale Innovation
 
1x1 der Szenario-Entwicklung
1x1 der Szenario-Entwicklung1x1 der Szenario-Entwicklung
1x1 der Szenario-Entwicklung
 
Impact Mapping - strategische Steuerung agiler Entwicklung
Impact Mapping - strategische Steuerung agiler EntwicklungImpact Mapping - strategische Steuerung agiler Entwicklung
Impact Mapping - strategische Steuerung agiler Entwicklung
 
Einfuehrung Projektmanagement
Einfuehrung ProjektmanagementEinfuehrung Projektmanagement
Einfuehrung Projektmanagement
 
2016-07-20 stresstest
2016-07-20 stresstest2016-07-20 stresstest
2016-07-20 stresstest
 
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
 
Move slow and fix things
Move slow and fix thingsMove slow and fix things
Move slow and fix things
 
Project Management - Projekte erfolgreich konzipieren, planen und umsetzen
Project Management - Projekte erfolgreich konzipieren, planen und umsetzenProject Management - Projekte erfolgreich konzipieren, planen und umsetzen
Project Management - Projekte erfolgreich konzipieren, planen und umsetzen
 
Modul 4 - Suche nach Frühwarnsignalen.pptx
Modul 4 - Suche nach Frühwarnsignalen.pptxModul 4 - Suche nach Frühwarnsignalen.pptx
Modul 4 - Suche nach Frühwarnsignalen.pptx
 
Projektleiter ärgere dich nicht
Projektleiter ärgere dich nichtProjektleiter ärgere dich nicht
Projektleiter ärgere dich nicht
 
MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...
MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...
MiPo'11: Reflexive Technologie. Eine neue Logik der Softwareentwicklung (Manf...
 
[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)
[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)
[lehre] Vorlage für Projektarbeit (Kompetenzentwicklung in Unternehmen)
 
Projektmanagement
ProjektmanagementProjektmanagement
Projektmanagement
 

Mehr von Daniel Volk

Praktikum Game Development an der UniBw 2008
Praktikum Game Development an der UniBw 2008Praktikum Game Development an der UniBw 2008
Praktikum Game Development an der UniBw 2008
Daniel Volk
 
Studienprojekt Game Development & Virtual Worlds
Studienprojekt Game Development & Virtual WorldsStudienprojekt Game Development & Virtual Worlds
Studienprojekt Game Development & Virtual Worlds
Daniel Volk
 
Digitale Produkttechnologien
Digitale ProdukttechnologienDigitale Produkttechnologien
Digitale Produkttechnologien
Daniel Volk
 
Evaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game PrototypingEvaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game Prototyping
Daniel Volk
 
Strategy Games - Introduction
Strategy Games - IntroductionStrategy Games - Introduction
Strategy Games - Introduction
Daniel Volk
 
Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...
Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...
Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...
Daniel Volk
 
Open Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented RealityOpen Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented Reality
Daniel Volk
 
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, SpieleentwicklungOpen Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Daniel Volk
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Daniel Volk
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Daniel Volk
 
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger DigitalDie Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Daniel Volk
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Daniel Volk
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Daniel Volk
 
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Daniel Volk
 

Mehr von Daniel Volk (14)

Praktikum Game Development an der UniBw 2008
Praktikum Game Development an der UniBw 2008Praktikum Game Development an der UniBw 2008
Praktikum Game Development an der UniBw 2008
 
Studienprojekt Game Development & Virtual Worlds
Studienprojekt Game Development & Virtual WorldsStudienprojekt Game Development & Virtual Worlds
Studienprojekt Game Development & Virtual Worlds
 
Digitale Produkttechnologien
Digitale ProdukttechnologienDigitale Produkttechnologien
Digitale Produkttechnologien
 
Evaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game PrototypingEvaluating Processing as a Platform for Game Prototyping
Evaluating Processing as a Platform for Game Prototyping
 
Strategy Games - Introduction
Strategy Games - IntroductionStrategy Games - Introduction
Strategy Games - Introduction
 
Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...
Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...
Inversion of Control - Oder: "Wie man Flexibilität durch Verlagerung von Kon...
 
Open Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented RealityOpen Games Workshop - Hybride Spiele / Augmented Reality
Open Games Workshop - Hybride Spiele / Augmented Reality
 
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, SpieleentwicklungOpen Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
Open Games Workshop - Spielemarkt, Spieleindustrie, Spieleentwicklung
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
 
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
Ravensburger Digital - wie der europäische Marktführer bei traditionellen S...
 
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger DigitalDie Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
Die Rolle eines modernen Publishers am Beispiel der Ravensburger Digital
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
 
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
Ravensburger Hybrid-Spiele - Im Grenzbereich zwischen klassischem und digital...
 
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
Schlüsselbereiche der Konvergenz aus der Perspektive eines traditionellen un...
 

Eine Einführung in das Risikomanagement

  • 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 €
  • 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.