Lessons Learned in Projekten

Präsentation zum Thema: "Lessons Learned in Projekten"—  Präsentation transkript:

1 Lessons Learned in Projekten
Wiederverwendung von Erfahrungswissen im Projektmanagement Peter Addor ANCHOR Management Consulting AG 2007

2 Lessons Learned ist Wissensmanagement
Mit Lessons Learned will man (negative) Projekt- erfahrungen so formulieren und darstellen, dass daraus (Handlungs-) wissen entsteht, das in künftigen Projekten wieder verwendbar ist, um Fehler zu vermeiden Im Gegensatz zu Best Practices, mit dem Ziel, Verfahren zu entwickeln, die man immer wieder (gedankenlos?) wiederholen kann

3 Fixes that Fail Beispiel Projektmanagement:
Current State: schwere Verzögerungen in der Fertigstellung eines Milestones Desired State: Der Milestone hätte schon zum Termin X in der Vergangenheit fertiggestellt werden sollen Action: Der Projektleiter holt die Leute täglich in ein Meeting, um ihnen Beine zu machen Unintended Consequences: Die Leute haben noch weniger Zeit, der Milestone verzögert sich noch mehr

4 Einfluss des Konzerns

5 Produktereife

6 Mangelnde Expertise

7 Einige Fehlerkategorien
Umgang mit der Zeit Einschätzung exponentieller Entwicklungen Umgang mit Nebenwirkungen Überplanung, Kompetenzschutz, Ignorieren von Signalen Ziele statt Massnahmen und Delegation Überbewertung des aktuellen Motivs

8 Fehlerkategorien nach Reason
Wissensbasierte Fehler Wissen und Problem- lösungsstrategien (Aufmerksamkeit) „Patzer“ Regelbasierte Fehler Verhaltensroutinen Unbeabsichtigtest Handeln „Schnitzer“ Gedächtnis Motivationaler Bereich Regelübertretungen Beabsichtigtes Handeln J. Reason, Human Error. Cambridge University Press. Cambridge 1990

9 Der Wissenszyklus von Lessons Learned
Wissensziele (überwachen und bestätigen) Wissensbewertung (Statistik der krisen-beladenen Projekte) strategisch operativ Wissensidentifikation projektbezogen in Review- und Abschlussmeetings, Reflexion des Handelns im Projekt Wissensdokumentation nur Informationen, die in handlungsleitenden Struk-turen gespeichert werden, sind auch neues Wissen Wissensnutzung in der Risiko- bewertung des nächsten Projekts Wissenserwerb Im laufenden Projekt Wissens(ver)teilung - Aktuellste Wissensdoku-mentation vorstellen - Teamlernen in Workshops und Dialogsitzungen - In Reviewmeetings dokumentierte Projektfallen auf Ereignisse abbilden Wissensentwicklung projektübergreifende generische Krisen- und Handlungs-muster aus den erfahrenen Projekt-fallen extrahieren

10 A. Wissenserwerb und Wissensidentifikation

11 Eine Traktandenliste für ein LL-Meeting
Negative Entwicklungen, Misserfolge, Pannen und Fehlentscheide Ungewöhnliche und unscheinbare Ereignisse / Informationen Schlechte Nachrichten Schwache Signale als voraus geworfene Schatten unerwarteter Ereignisse „Beinahe-Unfälle“ Wappnen auf „Unendliche Geschichte“ Welche Fehler dürfen keineswegs passieren? Mit abweichender Meinung nicht hinter dem Berg halten Skepsis erwünscht, keine Tatsachen! Erwartungen überprüfen Komplexe Denkmodelle entwerfen, bestehende überarbeiten Beweislast: nach K. Weick Annahme Gegenbeweis low risk warten, bis negatives Ereignis eintraf high risk durch Partei, die low risk behauptet

12 B. Wissensentwicklung

13 Aufgaben der Wissensentwicklung
Klassifizieren und Ordnen der Informationen. Abstrahieren von persönlichen Schuldzuweisungen Bereitstellen einer Struktur zur Beschreibung von Erfahrungswissen Methoden zum Engineering von Erfahrungswissen für die Zusammenführung aussagekräftiger Handlungs- pakete siehe Bunse et al.

14 Experience Factory Logische Trennung der Projektarbeit von den Aufgaben des Aufbereitens und Transfer von Erfahrung (z.B. Filtern Schuldzuweisung) Projektübergreifende Aufgabe: Erfahrungen über Projektgrenzen hinweg zu nutzen, überschreitet Fähigkeit eines einzelnen Projekts s. Bunse et al.

15 Experience Factory nach Bunse et al.
20 Experience Factory Mitarbeiter auf 300 Softwareentwickler bei NASA

16 Vorgehen bei Daimler-Chrysler
Projektteam Experience Factory Coaching Identifikation der Projekterfahrungen nach Ch. Bunse et al. Klassifikation der Lessons Learned Coaching Erstellung eines Quality Patterns zu jeder Erfahrung Coaching Internes Review Coaching Ablage in Experience Base Projektteam Experience Factory Externes Review

17 Wissensentwicklung mit Archetypen
Peter Senge („The fifth Disciplin“, 1990/2003): Systemisches Denken als Key Competence bezüglich Steuerung komplexer Systeme Accidental Adversaries Limits to Success Drifting Goals Shifting the Burden Escalation Success to Successful Fixes that Fail Tragedy of the Commons Growth and Underinvestment Attractiveness Principle

18 Die Logik des Misslingens in Projekten

19 Shifting the Burden Beispiel Projektmanagement:
Problem Symptom: Bei Auslieferung wird festgestellt, dass die Produkte einen Mangel aufweisen, der wertmindernd aber nicht wesentlich funktionsbeeinträchtigend ist. Fundamental Solution: Austausch der Produkte, was wesentliche Zusatzkosten seitens des Lieferanten und Verzögerungen verursacht hätte Sympomatic Solution: Mangelhafte Ware ausliefern, Projekt abschliessen Side Effect: Mängel manifestieren sich nach Projektabschluss, schaukeln sich auf und verursachen dem Lieferanten Wartungskosten oder dem Betreiber Verluste. 2. Beispiel: Einsturz des statisch ungenügend dimensionierten Terminals 2E des Pariser Flughafens, Frühling 2004: 4 Tote Problem Symptom: Man braucht Beschäftigung Sympomatic Solution: Man bietet weit unterhalb der Zielkosten an und spart an der Qualität Fundamental Solution: Man engagiert sich für die Abschaffung des Kartellrechts Side Effect: Katastrophe Monate später und Tote • In Wiesbaden stürzt das Dach des 14 Monate alten OBI-Marktes ein • Hauseinsturz in Kairo (Januar 2004) • Hauseinsturz in Konya in der Türkei (Februar 2004) • Drama in Moskauer Schwimmbad 3. Beispiel „Service Desk“: Problem Symptom: Drohende Überlastung des Service Desk Symptomatic Solution: Weiterleitung von Störungscalls an die nachgelagerte Service Ebene nur aufgrund der Überlastung Fundamental Solution: Sofortige Bearbeitung von Störungen durch das Service Desk und Aufbau einer Wissensbasis Side Effect: Service Desk ist immer weniger Imstande, Störungen zu beheben Wo ist der Delay?

20 Shifting the Burden im Projektgeschäft
Beispiel Projektmanagement: Problem Symptom: Bei Auslieferung wird festgestellt, dass die Produkte einen Mangel aufweisen, der wertmindernd aber nicht wesentlich funktionsbeeinträchtigend ist. Fundamental Solution: Austausch der Produkte, was wesentliche Zusatzkosten seitens des Lieferanten und Verzögerungen verursacht hätte Sympomatic Solution: Mangelhafte Ware ausliefern, Projekt abschliessen Side Effect: Mängel manifestieren sich nach Projektabschluss, schaukeln sich auf und verursachen dem Lieferanten Wartungskosten oder dem Betreiber Verluste. 2. Beispiel: Einsturz des statisch ungenügend dimensionierten Terminals 2E des Pariser Flughafens, Frühling 2004: 4 Tote Problem Symptom: Man braucht Beschäftigung Sympomatic Solution: Man bietet weit unterhalb der Zielkosten an und spart an der Qualität Fundamental Solution: Man engagiert sich für die Abschaffung des Kartellrechts Side Effect: Katastrophe Monate später und Tote • In Wiesbaden stürzt das Dach des 14 Monate alten OBI-Marktes ein • Hauseinsturz in Kairo (Januar 2004) • Hauseinsturz in Konya in der Türkei (Februar 2004) • Drama in Moskauer Schwimmbad 3. Beispiel „Service Desk“: Problem Symptom: Drohende Überlastung des Service Desk Symptomatic Solution: Weiterleitung von Störungscalls an die nachgelagerte Service Ebene nur aufgrund der Überlastung Fundamental Solution: Sofortige Bearbeitung von Störungen durch das Service Desk und Aufbau einer Wissensbasis Side Effect: Service Desk ist immer weniger Imstande, Störungen zu beheben Wo ist der Delay?

21 C. Wissensdokumentation und Wissensverteilung

22 Elemente der Wissensdokumentation
Projektunabhängige und –übergreifende Beschreibung von Patterns Übersichtliche Darstellung wählen, vor allem um dynamische Entwicklungen zu visualisieren (Diagramme, Tabellen, etc.) Klassifizierung der Patterns in Kategorien Statistik und Auftretensumfelder der Pattern Methoden, um Patterns zu durchbrechen Ablage nach Patternkategorien unstrukturiert oder in DB Eine Person zuständig für Ablage und Sammlung

23 Elemente der Wissensverteilung
Gecoachte LL- und Risikomanagement Meetings Am Anfang eines Projekts Risikolandkarte entwerfen und darauf Lessons Learned aus anderen Projekten anwenden In Review Meetings eines Projekts Erfahrungen aus anderen Projekten einbringen lassen

24 Der Prozess Lessons Learned – ein Vorschlag
Wann Was Wer Projektende LL sammeln Coach Projektteam LL projektübergreifend abstrahieren und in Patterns darstellen Patterns / Handlungspakete dokumentieren und ablegen; Statistik und Auswertungen Projektbeginn Risikoplan (RP) erstellen Hinterfragen Patterns in RP einfügen Review Meetings Aufgetauchte Ereignisse mit bekannten Patterns abgleichen und PL coachen PL

25 Aufwand Die Grundlagen von LL können in 2 Tagen Ausbildung gelernt werden (Vergleich: Für ein PMP-Zertifizierung benötigt man Tage reine Ausbildungszeit) Für die gecoachte Aufnahme der LL nach einem abgeschlossenen Projekt benötigt man höchstens einen eintägigen Workshop Für die gecoachte Einflechtung der LL in den Risikoplan eines neuen Projekts benötigt man höchstens einen eintägigen Workshop

26 Literatur Dietrich Dörner, Die Logik des Misslingens – Strategisches Denken in komplexen Situationen, Rowohlt Taschenbuchverlag, Reinbek bei Hamburg, 2003 Karl E. Weick und Kathleen M. Sutcliffe, Das Unerwartete managen – Wie Unternehmen aus Extremsituationen lernen, Klett-Cotta, Stuttgart 2003 Senge, Peter, Die Fünfte Disziplin – Kunst und Praxis der lernenden Organisation, Klett-Cotta, Stuttgart 2003 Braun, William, The System Archetypes, Diss. Ch. Rupprecht, Ein Konzept zur projektspezifischen Individualisierung von Prozessmodellen, Karlsruhe Christian Bunse et al. SoftQuali - Ein integrierter Ansatz zur Software-Qualitätsverbesserung. V. Basili et al. Experience Factory. In J. Marciniak (ed.): Encyclopedia of Software Engineering, Band 1, Seiten John Wiley & Sons, NY, 1994. S. Strohschneider/Rüdiger von der Weth (Hrsg.), Ja, mach nur einen Plan – Pannen und Fehlschläge – Ursachen, Beispiele, Lösungen. Hans Huber, Bern, 2001.