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

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

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

Einfluss des Konzerns

Produktereife

Mangelnde Expertise

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

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

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

A. Wissenserwerb und Wissensidentifikation

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

B. Wissensentwicklung

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.

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.

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

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

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

Die Logik des Misslingens in Projekten

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?

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?

C. Wissensdokumentation und Wissensverteilung

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

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

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

Aufwand Die Grundlagen von LL können in 2 Tagen Ausbildung gelernt werden (Vergleich: Für ein PMP-Zertifizierung benötigt man 35-40 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

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, 2002 http://www.uni-klu.ac.at/~gossimit/pap/sd/wb_sysarch.pdf http://www.anchor.ch/archetypen.pdf Diss. Ch. Rupprecht, Ein Konzept zur projektspezifischen Individualisierung von Prozessmodellen, Karlsruhe 2002. http://www.ubka.uni-karlsruhe.de/vvv/2002/wiwi/5/5.pdf Christian Bunse et al. SoftQuali - Ein integrierter Ansatz zur Software-Qualitätsverbesserung. http://www.ergonomic.de/files/softwarequalitaet.pdf V. Basili et al. Experience Factory. In J. Marciniak (ed.): Encyclopedia of Software Engineering, Band 1, Seiten 469-476. 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.