Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Profil/Beschreibung

Autoren: Erik Hofbaur, Tim Wunderlich

Ziele: Diese Methodenseite zum Projektrisikomanagement stellt eine über viele Jahre in der Proaxis weiterentwickelte Methode vor. Das Vorgehen hilft dabei in Projekten mit Risiken vorausschauen umzugehen und diese in der Projektplanung entsprechend zu berücksichtigen. Durch die finanzielle Bewertung der Risiken, können Maßnahmen zur Minderung des Risikowertes besser arumentiert werden.

Voraussetzungen: Ein Projektstrukturplan mit klar definierten Arbeitspaketbeschreibungen hilft bei der strukturierten Identifikation und Analyse von Risiken.

Indikatoren: Projektziele müssen fortwährend angepasst werden, weil sich immer wieder Risiken zu Ereignissen werden, die vorher weder bekannt noch eingeplant waren. Leider ist in vielen Organisationen das Einplanen eines Risikopuffers nicht möglich. Diese Methodik hilft bei der Argumentation es doch zu tun.

Vorgehen/Blueprint

1      Zielsetzung

Das Projektrisikomanagement dient dem Bewusstwerden von Risiken in einem Projekt, um Maßnahmen daraus abzuleiten und die Eignung dieser Maßnahmen (Kosten-Nutzen-Abschätzung) zu bewerten. Zusätzlich dient es der Ermittlung eines angemessenen Risikopuffers für realistische Zielgrößen und ermöglicht während der Projektlaufzeit ein Monitoring des vorhandenen und benötigten Risikopuffers.

2      Definitionen

Projektrisiken sind unsichere Ereignisse oder mögliche Situationen mit negativen Auswirkungen

-       auf den Projekterfolg insgesamt

-       auf einzelne Projektziele

-       auf einzelne Ergebnisse oder Ereignisse.

Ein Risikowert ist das Produkt aus Wahrscheinlichkeit und Auswirkungen bei Eintritt des Risikos.

Benötigter Puffer ist die Summe der Risikowerte in der Projektrisikoliste.

Vorhandener/verbleibender Puffer ist der Abstand zwischen der aktuellen Best-Case-Planung und der Real-Case-Planung im Projektplan, der Einsatzmittelplanung und der DB-Rechnung.

Es gelten folgende Regeln für die Betrachtung von Risiken:

-       Risiken mit einer Eintretenswahrscheinlichkeit von <5% werden dabei nicht betrachtet. Ist die Eintretenswahrscheinlichkeit > 70% so wird das Risiko aus der Risikoliste gestrichen und fest in die Projektplanung aufgenommen.

-       Evtl. existierende Risiken einer Pflichtenheftänderung werden in einem realistischen Umfang mit aufgenommen.

-       Risiken, die sich ausschließlich auf Umsatz und/oder DB auswirken (z.B. Falsche Schätzung der Absatzzahlen) werden nicht betrachtet.

 

3      Prozess

3.1     Vorbedingungen

Das Projektrisikomanagement basiert auf den Ergebnissen der folgenden Prozesse:

  • Projektstrukturplan
  • AP Beschreibungen
  • Stakeholderanalyse
  • Projektziele
  • Einsatzmittelplanung
  • Projektablaufplan
  • Technischen Lösungskonzepten

3.3     Beschreibung der Prozessschritte

Das Projektrisikomanagement startet vor Gate 2 (Requirement Freeze) und wird kontinuierlich im Projekt vervollständigt.

  1. Der Projektleiter initiiert das Risikomanagement.
  2. Jeder Arbeitspaketverantwortliche identifiziert Risiken und schätzt deren Wahrscheinlichkeiten und Auswirkung. Zusätzlich ermitteln auch der Vertreter von SCM und der Produktmanager Risiken.

Risiken können ermittelt werden aus:

- Mindmap „Risikoidentifikation in Entwicklungsprojekten“

- FMEA

- Produktrisikoanalyse

- Keykomponentenliste

- Expertenbefragung

Die Risiken werden für das gesamte Projekt in einer gemeinsamen Liste erfasst.

  1. Die Auswirkung auf den Liefertermin ermittelt der Projektleiter mit Hilfe des Projektablaufplans. Es müssen hierfür die Risiken berücksichtigt werden, die auf dem kritischen Pfad liegen oder bei Eintritt des Risikos zum kritischen Pfad werden können. Zumindest für die größten Zeitrisiken ist dieser Wert mit Hilfe der Projektablaufplanung zu ermitteln.
    Alternativ kann zur Ermittlung des Real Case Termins wie folgt vorgegeben werden: Alle Risiken werden entsprechend ihrem Risikowert zeitlich in den Projektplan eingefügt. Der so ermittelte Endtermin ist der Real Case Termin.
  2. Der Projektleiter ermittelt mit den Arbeitspaketverantwortlichen Maßnahmen zur Reduktion von Wahrscheinlichkeiten oder den Auswirkungen der Risiken.
  3. Diese Maßnahmen werden im Team mit dem Entwicklungsleiter bewertet. Eine Maßnahme ist nur sinnvoll, wenn die Reduktion des Risikowertes größer ist als die Kosten der Maßnahme.
  4. Gegebenenfalls muss eine Maßnahme im PLK (Projekt Lenkungs Kreis) genehmigt werden.
  5. Maßnahmen, die umgesetzt werden sollen, fließen in den Projektablaufplan, die Arbeitspaketbeschreibungen und die Einsatzmittelplanung ein.
  6. Anschließend wird in einem Meeting mit Projektleiter, Systemarchitekt, Arbeitspaketverantwortlichen, Produktmanager, SCM und dem Entwicklungsleier die gesamte Risikoliste abgestimmt.
  7. Die Summe der Risikowerte nach den Maßnahmen für Personalkosten, Sachkosten, Investitionen und HK1 wird als Risikopuffer bei der Einsatzmittelplanung und DB-Rechnung für den Forecast und die Plan 2-Zahlen aufgenommen.
  8. Eine sinnvolle Summe aus den Risikowerten für die Lieferterminverzögerung nach den Maßnahmen wird in den Projektablaufplan aufgenommen als ein Gesamtrisikopuffer, der hinter dem Bestcase-Liefertermin liegt und damit zum Realcase-Liefertermin für den Forecast und die Plan 2-Zahlen führt. Bei großen Projekten kann es sinnvoll sein, einen zusätzlichen Risikopuffer nur für die Planungsphase zu ermitteln, der dann am Ende der Planungsphase liegt.
  9. Als Monitoring prüft der Projektleiter mit dem Projektkernteam zu geeigneten Zeitpunkten bei Meilensteinen und zu den Gates die Wahrscheinlichkeiten und Auswirkungen in der Risikoliste, dabei werden auch neue Risiken erfasst.
  10. Tritt ein Risiko ein, werden die vollen dafür nötigen Stunden/Kosten/Dauer dem Risikopuffer (nicht nur der Risikowert!) entnommen und zu dem entsprechenden Arbeitspaket addiert. Der noch verbliebene Puffer reduziert sich damit.
  11. Tritt ein Risiko nicht ein, reduziert sich der benötigte Puffer, der sich aus der Risikotabelle errechnet. Der noch verbleibende Puffer darf jedoch nicht reduziert werden.
  12. Wenn festgestellt wird, dass der benötigte Risikopuffer deutlich (spätestens bei mehr als 40%) vom verbliebenen Risikopuffer abweicht, ist der Forecast anzupassen. Der Forecast im PLK berücksichtigt immer die aktuellen Risikowerte.
    Sollte sich herausstellen, dass das Ziel den Liefertermin der Serie 6 Monate vorher auf ±1 Monat genau zu bestimmen nicht erreicht werden kann, so muss dies mit dem Auftraggeber geklärt werden.
    Ebenso ist eine Klärung mit dem Auftraggeber notwendig, wenn nur wenige dafür aber große Risiken bestehen, so dass keine statistischen Aussagen möglich sind.

 Wichtig!

Bei der Ermittlung der Risiken und deren Auswirkung ist immer ein kritischer Abgleich mit den Aufwandsabschätzungen in den jeweiligen AP durchzuführen. Es muss vermieden werden, dass Risiken doppelt berücksichtigt werden, weil sie schon implizit in den Aufwandsabschätzungen stecken.

Außerdem sind sinnvolle Cluster zu bilden, die z.B. Risiken für abgekündigte Bauteile ein einem Risiko zusammenführen.

4      Ergebnis

Beschlossene Maßnahmen zur Reduktion von Risiken und die ermittelten Risikopuffer fließen in die Einsatzmittelplanung, DB-Rechnung und Ablaufplanung ein und werden damit Bestandteil der Plan 2-Zahlen.

Tool & Template

Template_Projektrisikomanagement.pdf 

Risikoidentifikation in Entwicklungsprojekten.pdf

Erfahrungsberichte

(Beispiele, Lessons Learned aus der Anwendung, etc. Bitte mit Namens-/Quellenangaben)

Erfahrungen die wir in der praktischen Anwendung mit diesem Prozess gemacht haben:

Für uns haben sich zwei besonders wichtige Vorteile aus diesem Vorgehen zum Projektrisikomanagement ergeben. Durch diesen formalen Prozess analysieren alle Projektbeteiligten systematisch, welche potentiellen Risiken es in Ihrem Arbeitspaket gibt. Dieser Erkenntnisprozess ist schon der erste und wichtigste Schritt um Risiken zu vermeiden. Der zweite wichtige Vorteil, ist die Bewertung der Risiken, genauer genommen des Risikowertes, in €. Ist ein Gefühl für die Größenordnung des möglichen Schadens vorhanden, fällt die Argumentation von Maßnahmen zur Minderung des Risikowertes viel leichter. An einigen Stellen haben wir aber auch festgestellt, dass die Maßnahmen teurer werden würden als die Minderung des Risikowertes, also haben wir sie nicht umgesetzt. Die monetäre Bewertung schein zunächst schwierig, man sollte sich darauf verständigen zu nächst die richtige Größenordnung für den Schaden zu ermitteln. Reden wir also über 1000€ , 50.000€ oder gar 1.000.000€.

Zu Beginn eines Projektes funktioniert dieses auf Wahrscheinlichkeiten und Statistik beruhende system recht gut, zum Ende, wenn möglicher weise nur noch  zwei Risiken mit kleiner Eintretenswahrscheinlichkeit aber hoher Auswirkung da sind, wird es Anspruchsvoll. Dafür haben wir bisher noch keinen zufriedenstellenden Umgang gefunden.

Quellen

(Weiterführende Literatur, Links)

Weitere Beiträge auf openPM zu

Search Results
maxLimit5
query