310 likes | 1.23k Views
Lessons Learned in Projekten. Wiederverwendung von Erfahrungswissen im Projektmanagement Peter Addor ANCHOR Management Consulting AG 2007. Lessons Learned ist Wissensmanagement.
E N D
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
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 „Patzer“ (Aufmerksamkeit) Regelbasierte Fehler Verhaltensroutinen Regelübertretungen Motivationaler Bereich Beabsichtigtes Handeln „Schnitzer“ Gedächtnis Unbeabsichtigtest Handeln J. Reason, Human Error. Cambridge University Press. Cambridge 1990
Der Wissenszyklus von Lessons Learned Wissensbewertung (Statistik der krisen-beladenen Projekte) Wissensziele (überwachen und bestätigen) strategisch operativ Wissensdokumentation nur Informationen, die in handlungsleitenden Struk-turen gespeichert werden, sind auch neues Wissen Wissensidentifikation projektbezogen in Review- und Abschlussmeetings, Reflexion des Handelns im Projekt 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
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
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 Projektteam Experience Factory Ablage in Experience Base 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
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
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, 2002http://www.uni-klu.ac.at/~gossimit/pap/sd/wb_sysarch.pdfhttp://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.