Lessons Learned: So wird aus Projekterfahrung ein System

Drei Messen, dreimal derselbe Ärger. Der Stand kommt zu spät, weil die Grafik erst eine Woche vor Aufbau freigegeben wird. Die Prospekte reichen bis Tag zwei. Und am Ende weiß keiner, welche Gespräche Termine geworden sind, weil jeder Verkäufer seine Visitenkarten in die eigene Jackentasche gesteckt hat.

Nach jeder Messe sagt jemand: „Nächstes Mal machen wir das anders.“ Nächstes Mal kommt. Es läuft genau gleich. Das ist kein Pech. Das ist das Fehlen von Lessons Learned — oder, noch häufiger, Lessons Learned, die zwar gemacht wurden, aber nie beim nächsten Projekt angekommen sind.

Ich habe in 35 Jahren Vertrieb und Unternehmertum eine Sache gelernt: Erfahrung ist nur dann etwas wert, wenn sie das nächste Mal etwas verändert. Sonst machst du dieselben Fehler zum fünften Mal und nennst es Routine.

Hier bekommst du das Handwerkszeug: den Lessons-Learned-Workshop in fünf Schritten, die richtigen Fragen, eine Vorlage — und den Weg vom Protokoll zum Wissensspeicher, den dein Team tatsächlich nutzt.

Was bedeutet Lessons Learned?

Lessons Learned heißt wörtlich „gelernte Lektionen“, im Deutschen meist „gewonnene Erkenntnisse“. Gemeint ist das systematische Sammeln, Bewerten und Festhalten von Erfahrungen aus einem Projekt — Fehler, Erfolge, Risiken, Hinweise —, damit das nächste Projekt davon profitiert. Der Begriff stammt aus dem Projektmanagement und dem Wissensmanagement; der Wikipedia-Artikel zu Lessons Learned führt ihn auf den Projektmanagement-Standard des Project Management Institute zurück.

Wichtig ist das letzte Wort: learned. Gelernt hast du erst, wenn sich beim nächsten Mal etwas im Ablauf ändert. Ein Protokoll voller Erkenntnisse, das niemand liest, ist keine Lessons Learned. Es ist eine Aktenleiche.

Im Projektmanagement gehören Lessons Learned zum Projektabschluss — dort habe ich die vier Handgriffe beschrieben, mit denen du ein Projekt sauber beendest. Hier geht es um die Tiefe: wie du den Termin führst, was du festhältst und wie die Erkenntnisse den Weg zurück in den Alltag finden.

Lessons Learned und Retrospektive: was der Unterschied ist

Beide fragen: Was lief gut, was nicht, was ändern wir? Der Unterschied liegt im Takt. Eine Retrospektive ist ein fester, regelmäßiger Termin — alle zwei Wochen, jeden Monat —, in dem ein Team, das weiter zusammenarbeitet, seine Zusammenarbeit verbessert. Lessons Learned blicken am Ende eines Projekts oder Abschnitts zurück, und die Erkenntnisse sind für Menschen gedacht, die beim nächsten Vorhaben vielleicht gar nicht mehr dabei sind. Die Retrospektive verbessert das laufende Team. Lessons Learned verbessern die Organisation. Deshalb spielt bei Lessons Learned die Dokumentation eine viel größere Rolle.

Was eine Erkenntnis ist — und was nicht

Der häufigste Grund, warum Lessons Learned nichts bewirken, ist nicht Faulheit. Es ist die Qualität der Sätze, die am Ende auf dem Papier stehen. Schau dir den Unterschied an:

• „Die Kommunikation war schlecht.“
• „Die Abstimmung mit dem Kunden hat nicht gut funktioniert.“
• „Wir müssen früher anfangen.“

Das sind Gefühle. Keiner dieser Sätze sagt dir, was du beim nächsten Mal anders machen sollst. Jetzt dieselben Punkte als echte Erkenntnis:

• „Die Grafik für den Messestand wurde eine Woche vor Aufbau freigegeben, weil die Freigabe beim Geschäftsführer lag und der zwei Wochen im Urlaub war. Nächstes Mal: Freigabe spätestens sechs Wochen vorher, Vertretung benannt.“
• „Der Kunde hat drei verschiedene Ansprechpartner bei uns gehabt und dreimal unterschiedliche Liefertermine gehört. Nächstes Mal: ein Ansprechpartner je Auftrag, im Angebot mit Namen genannt.“

Eine brauchbare Erkenntnis hat immer drei Teile: Beobachtung (was genau ist passiert?), Ursache (warum?) und Konsequenz (was machen wir beim nächsten Mal anders — und wer sorgt dafür?). Fehlt einer der drei Teile, ist es noch keine Erkenntnis. Diese Formel ist das wichtigste Werkzeug in diesem Artikel. Alles andere baut darauf auf.

Warum Lessons Learned fast immer versanden

Die meisten Unternehmer haben Lessons Learned schon gemacht. Einmal, zweimal. Dann ist es eingeschlafen. Laut dem erwähnten Wikipedia-Artikel, der sich auf eine Untersuchung aus dem Jahr 2005 stützt, führen etwa zwei Drittel der Unternehmen nach Projektende Lessons Learned in irgendeiner Form durch — die strukturierte Nutzung für Folgeprojekte findet aber nur beschränkt statt. Das deckt sich mit dem, was ich im Mittelstand sehe. Sechs Gründe tauchen immer wieder auf:

1. Der Termin wird zur Schuldfrage. Sobald es darum geht, wer den Fehler gemacht hat, schweigen alle. Wer sich rechtfertigen muss, liefert keine Erkenntnisse, sondern Verteidigungsreden.
2. Er kommt zu spät. Drei Monate nach Projektende erinnert sich keiner mehr an Details. Übrig bleiben Eindrücke — und Eindrücke sind keine Erkenntnisse.
3. Die Ergebnisse sind zu allgemein. „Besser planen“ steht dann in jedem Protokoll. Und ändert nie etwas.
4. Es gibt keinen Verantwortlichen für die Umsetzung. Die Maßnahme steht auf dem Papier. Niemand hat sie. Also passiert sie nicht.
5. Die Ablage ist ein Friedhof. Die Datei liegt in einem Ordner namens „Projekt Müller final_v3“. Beim nächsten ähnlichen Projekt sucht keiner danach, weil keiner weiß, dass es sie gibt.
6. Der Kreis schließt sich nicht. Die Erkenntnis fließt nicht in eine Checkliste, eine Kalkulation oder einen Standard. Sie bleibt Text. Text ändert kein Verhalten.

Die ersten drei Gründe löst du im Lessons-Learned-Workshop. Die letzten drei mit dem, was danach passiert.

Der Lessons-Learned-Workshop: Ablauf in fünf Schritten

Ein Lessons-Learned-Workshop ist ein moderierter Termin mit allen, die am Projekt beteiligt waren. Er dauert bei kleinen Projekten 60 bis 90 Minuten, bei größeren einen halben Tag. Mehr braucht es im Mittelstand fast nie. Wie du Workshops grundsätzlich leitest — Vorbereitung, Fragetechnik, Umgang mit Vielrednern und Schweigern —, steht im Artikel über Moderation. Hier geht es um das, was diesen speziellen Termin ausmacht.

Vorbereitung: wer, wann, wie lange

• Wann: spätestens zwei Wochen nach Projektende, solange die Erinnerung frisch ist. Bei langen Projekten zusätzlich nach jedem großen Meilenstein.
• Wer: alle, die substanziell mitgearbeitet haben. Auch der Innendienst, auch der Monteur, auch die Buchhaltung, wenn sie die Rechnungen gestellt hat. Die besten Erkenntnisse kommen oft von den Leuten, die sonst nie gefragt werden.
• Wer moderiert: nicht der Projektleiter. Er ist Beteiligter und hat ein Interesse daran, wie das Projekt dasteht. Nimm jemanden aus einem anderen Bereich oder eine Führungskraft, die nicht direkt involviert war.
• Vorbereitung für die Teilnehmer: Schick zwei Tage vorher drei Fragen raus. Was lief gut? Was hat gehakt? Was würdest du beim nächsten Mal anders machen? Jeder bringt seine Stichpunkte mit. So redet im Termin nicht nur der Lauteste.
• Material: Projektauftrag, Zeitplan, Budget gegen Ist, wichtige Mails oder Reklamationen. Fakten schlagen Erinnerung.

Schritt 1: Ziel und Ergebnis auf den Tisch

Starte mit dem Soll. Was war das Ziel des Projekts, schwarz auf weiß? Welcher Termin, welches Budget, welches Ergebnis? Dann das Ist: Was ist tatsächlich herausgekommen? Zehn Minuten, die verhindern, dass der Workshop in ein Stimmungsbild abrutscht.

Klingt banal. In vielen Workshops stellt sich genau hier heraus, dass verschiedene Leute verschiedene Ziele im Kopf hatten. Das ist bereits die erste Erkenntnis — und eine, die du beim nächsten Kick-off-Meeting direkt abstellen kannst.

Schritt 2: Zeitstrahl — was ist passiert?

Zeichne auf einem Flipchart oder Whiteboard einen Zeitstrahl vom Projektstart bis zum Abschluss. Jeder Teilnehmer klebt seine wichtigsten Ereignisse darauf: Entscheidungen, Probleme, Wendepunkte, gute Momente. Du erzeugst damit ein gemeinsames Bild der Geschichte. Dabei tauchen Zusammenhänge auf, die keiner allein gesehen hat: „Ach, deshalb kam die Lieferung zu spät — der Einkauf wusste gar nicht, dass sich die Menge geändert hatte.“

Schritt 3: Was lief gut, was hat gehakt?

Jetzt sammelst du. Zwei Spalten: „Beibehalten“ und „Ändern“. Jeder schreibt seine Punkte auf Karten, eine Karte pro Punkt, und stellt sie kurz vor. Keine Diskussion in dieser Phase — nur sammeln und gruppieren.

Vergiss die erste Spalte nicht. „Was hat funktioniert?“ ist genauso wertvoll wie die Probleme. Wenn ein Angebot schnell gewonnen wurde, weil der Verkäufer vorab ein Telefonat mit dem technischen Leiter des Kunden geführt hat, dann ist das eine Erkenntnis, die du wiederholen willst. Erfolge, die niemand festhält, sind beim nächsten Mal Zufall.

Schritt 4: Ursachen statt Schuldige

Jetzt wird es ernst. Nimm die drei bis fünf wichtigsten Punkte aus der Spalte „Ändern“ und frag nach der Ursache. Nicht einmal — mehrmals. „Die Lieferung kam zu spät.“ Warum? „Weil die Bestellung spät raus ist.“ Warum? „Weil die Mengen erst nach der Freigabe feststanden.“ Warum? „Weil der Kunde die Freigabe nicht rechtzeitig erteilt hat — und wir keinen Freigabetermin im Vertrag hatten.“ Da ist die Ursache. Und sie ist lösbar.

Für komplexere Probleme hilft das Ishikawa-Diagramm: Du ordnest mögliche Ursachen nach Kategorien wie Mensch, Methode, Material und Umfeld und siehst, wo sich die Pfeile häufen. Geht es um eine wiederkehrende Reklamation beim Kunden, ist der 8D-Report das strengere Werkzeug.

Die Regel in diesem Schritt ist hart: Du suchst Ursachen im System, nicht Schuldige im Team. Wenn ein Mitarbeiter einen Fehler gemacht hat, lautet die Frage nicht „Warum hat Thomas das falsch gemacht?“, sondern „Was hat es Thomas leicht gemacht, das falsch zu machen?“ Fehlte eine Checkliste? War die Information nicht da? Hatte er zu viele Projekte gleichzeitig? Wer so fragt, bekommt ehrliche Antworten. Wer Schuldige sucht, bekommt nie wieder eine.

Schritt 5: Maßnahmen mit Namen und Termin

Jede Ursache bekommt eine Konsequenz. Und jede Konsequenz bekommt drei Dinge: was genau, wer und bis wann. „Freigabetermin für Kundengrafiken in die Vertragsvorlage aufnehmen — Sabine, bis 15. Oktober.“ Das ist eine Maßnahme. „Wir sollten auf Freigaben achten“ ist keine.

Begrenze die Maßnahmen. Drei umgesetzte Änderungen sind mehr wert als fünfzehn, die im Protokoll verstauben. Priorisiere nach Wirkung: Was hat am meisten Geld, Zeit oder Kundenzufriedenheit gekostet? Das zuerst.

Regeln, die den Workshop tragen

Ein Lessons-Learned-Workshop lebt davon, dass die Leute offen reden. Das passiert nur, wenn ein paar Regeln gelten — und du als Chef sie vorlebst:

• Der Chef spricht zuletzt. Sagst du zuerst, was du denkst, stimmen alle zu. Dann hast du deine Meinung gehört, nicht die des Teams.
• Was im Raum gesagt wird, hat keine Folgen für die Beurteilung. Sag das laut zu Beginn. Und halte dich daran, auch wenn dir etwas nicht gefällt.
• Fakten vor Meinungen. Wer „immer“ oder „nie“ sagt, wird nach dem konkreten Fall gefragt.
• Kein Rechtfertigen. Wer einen Punkt vorstellt, wird nicht unterbrochen. Wer sich angegriffen fühlt, schreibt eine Karte.

Wie du Kritik so formulierst, dass sie ankommt, steht im Artikel über Feedback geben.

Lessons-Learned-Fragen: der Fragenkatalog

Die richtigen Fragen machen den Unterschied zwischen einem netten Rückblick und echten Erkenntnissen. Du musst nicht alle stellen. Wähl pro Workshop fünf bis acht aus, passend zum Projekt.

Zum Ergebnis:

• Haben wir das Ziel erreicht? Woran messen wir das?
• Was hat der Kunde bekommen, was er nicht erwartet hat — positiv wie negativ?
• Würde der Kunde uns für ein ähnliches Projekt wieder beauftragen? Warum?

Zu Planung und Ablauf:

• Wo lag unsere Schätzung für Zeit und Kosten daneben, und warum?
• An welcher Stelle haben wir am längsten gewartet? Auf wen oder was?
• Welches Risiko ist eingetreten, das wir hätten vorhersehen können?

Zu Zusammenarbeit und Kommunikation:

• Wer hatte wann welche Information nicht, die er gebraucht hätte?
• Wo gab es Doppelarbeit oder Lücken zwischen zwei Abteilungen?

Zum nächsten Mal:

• Wenn du das Projekt morgen noch einmal starten müsstest: Was machst du als Erstes anders?
• Was davon sollten wir als Standard festschreiben?
• Wer im Unternehmen sollte diese Erkenntnisse unbedingt kennen?

Die letzte Frage wird fast immer vergessen. Dabei entscheidet sie, ob die Erkenntnis im Projektteam bleibt oder ins Unternehmen wandert.

Lessons Learned dokumentieren: die Vorlage

Ein zwanzigseitiger Abschlussbericht wird nicht gelesen. Eine Zeile „War gut“ hilft auch keinem. Das richtige Maß ist eine Seite, maximal zwei. Hier ist das Gerüst, das ich empfehle:

1. Kopf

• Projektname und Kurzbeschreibung in einem Satz
• Zeitraum, Projektleiter, Beteiligte
• Stichworte für die Suche (Kunde, Branche, Art des Projekts)

2. Soll gegen Ist

• Ziel laut Auftrag — erreicht, teilweise, nicht erreicht
• Termin geplant gegen tatsächlich
• Budget oder Stunden geplant gegen tatsächlich

3. Beibehalten (drei bis fünf Punkte)

• Jeweils: Was haben wir gemacht, und warum hat es funktioniert?

4. Ändern (drei bis fünf Punkte)

• Jeweils: Beobachtung, Ursache, Konsequenz — die Formel von oben

5. Maßnahmen

• Was genau, wer, bis wann, wo wird es verankert (Checkliste, Vorlage, Kalkulation, Vertrag)?

6. Hinweis für das nächste ähnliche Projekt

• Ein bis drei Sätze: Das musst du wissen, bevor du anfängst.

Punkt sechs ist der wichtigste: Was muss ein neuer Projektleiter in fünf Minuten wissen, der in einem Jahr ein ähnliches Vorhaben übernimmt?

Schreib die Dokumentation noch am Tag des Workshops. Nicht „nächste Woche“. Wer das Protokoll zwei Wochen später schreibt, schreibt es aus der Erinnerung — und dann wird aus einer Ursache wieder ein Gefühl.

Der Wissensspeicher: damit Erkenntnisse beim nächsten Projekt ankommen

Ein Workshop plus Protokoll ist Handwerk. Was danach passiert, macht daraus ein System.

Eine Ablage, die jemand findet

Leg alle Lessons Learned an einer Stelle ab. Nicht im Projektordner, nicht im Mail-Postfach des Projektleiters. Ein gemeinsamer Ordner, eine Seite im Intranet, ein Bereich in deinem Projektwerkzeug — egal, Hauptsache ein Ort. Mit einheitlichem Dateinamen und Stichworten, damit jeder nach „Messe“ oder „Kunde Müller“ oder „Montage Dach“ suchen kann.

Konzerne bauen dafür ganze Datenbanken. Dein Betrieb braucht einen Ordner, eine Vorlage und die Regel, dass beides genutzt wird.

Rückführung in Standards: aus Text wird Ablauf

Eine Erkenntnis, die nur im Protokoll steht, ändert nichts. Sie muss dorthin, wo gearbeitet wird:

• In Checklisten. „Freigabe sechs Wochen vorher“ steht ab jetzt auf der Messe-Checkliste.
• In Vorlagen. Der Freigabetermin kommt in die Vertragsvorlage, der Ansprechpartner in die Angebotsvorlage.
• In die Kalkulation. Wenn Montagen in Altbauten regelmäßig länger dauern als geplant, rechnest du den Mehraufwand ab jetzt ein — mit der echten Zahl aus deinen eigenen Projekten.
• In die Einarbeitung. Was neue Mitarbeiter wissen müssen, gehört ins Onboarding, nicht in einen Ordner.

Das ist nichts anderes als der PDCA-Zyklus: planen, umsetzen, prüfen, verankern. Lessons Learned sind der „Prüfen“-Schritt. Ohne das Verankern bleibt der Kreis offen. Wer diesen Kreis zur Gewohnheit macht, betreibt einen kontinuierlichen Verbesserungsprozess (KVP) — nicht als Projekt, sondern als Haltung.

Pflichtlektüre beim Projektstart

Der einfachste Hebel überhaupt: Mach das Lesen der passenden Lessons Learned zum festen Punkt beim Projektstart. Bevor das nächste Messeprojekt beginnt, liest der Projektleiter die Erkenntnisse der letzten drei Messen. Im Kick-off-Meeting gibt es einen Tagesordnungspunkt: „Was haben wir beim letzten Mal gelernt?“ Fünf Minuten. Mehr nicht. Die meisten scheitern genau hier, weil niemand diesen Punkt einfordert. Fordere ihn ein.

Die Risikoliste füttern

Eingetretene Risiken sind das wertvollste Material für dein Risikomanagement. Wenn ein Lieferant zweimal hintereinander ausgefallen ist, gehört das nicht nur in die Lessons Learned, sondern in deine Risikoliste — mit Gegenmaßnahme. So wird aus einer schmerzhaften Erfahrung ein Frühwarnsystem.

Lessons Learned beim Projektabschluss — und an anderen Stellen

Der klassische Ort für Lessons Learned ist der Projektabschluss. Das Prinzip funktioniert aber überall, wo etwas einen Anfang und ein Ende hat:

• Nach einem verlorenen Großauftrag. Warum hat der Kunde sich für den Wettbewerber entschieden? Die Antwort ist Gold für dein nächstes Angebot.
• Nach einem gewonnenen Großauftrag. Was hat den Ausschlag gegeben? Genauso wertvoll — und fast nie festgehalten.
• Nach einer Messe oder einem Event. Aufwand, Kontakte, Termine, Aufträge — und was du nächstes Mal anders organisierst.
• Nach einer großen Reklamation. Ergänzend zur Ursachenanalyse: Was lernen wir als Unternehmen daraus, über den Einzelfall hinaus?
• Nach Meilensteinen in langen Projekten. Wer zwölf Monate bis zum Ende wartet, hat vieles vergessen. Ein kurzer Termin nach jeder Phase hält die Erkenntnisse frisch.

Die Kurzform: das After Action Review

Nicht jede Situation braucht einen Workshop. Für kurze Einsätze gibt es eine schlanke Form, die die US-Armee entwickelt hat: das After Action Review. Es wird direkt nach dem Einsatz als kurze Teambesprechung gemacht und folgt vier Fragen:

1. Was war geplant?
2. Was ist tatsächlich passiert?
3. Warum gab es Abweichungen — was waren Erfolgsfaktoren, was Fehler?
4. Was nehmen wir mit?

Fünfzehn Minuten nach dem Kundentermin, nach dem Montagetag, nach dem Messetag. Im Stehen, ohne Folien. Die Ergebnisse notierst du in drei Zeilen. Das ist Lessons Learned im Kleinformat — und wer es zur Gewohnheit macht, braucht die großen Workshops seltener.

Beispiel: Lessons Learned nach einem verlorenen Großauftrag

Szenario, zur Veranschaulichung: Ein Metallbaubetrieb mit 45 Mitarbeitern bewirbt sich um einen großen Auftrag bei einem Logistikunternehmen — Hallentore und Überladebrücken für ein neues Verteilzentrum. Drei Monate Vorarbeit, zwei Besichtigungen, ein ausführliches Angebot. Der Auftrag geht an einen Wettbewerber.

Der Geschäftsführer setzt einen Lessons-Learned-Workshop an: Vertriebsleiter, Kalkulator, technischer Leiter, die Innendienstmitarbeiterin, die das Angebot zusammengestellt hat. Moderiert von der kaufmännischen Leiterin, die nicht am Angebot beteiligt war. Neunzig Minuten.

Soll gegen Ist: Ziel war der Auftrag. Nicht erreicht. Aber: Der Vertriebsleiter hat beim Kunden nachgefragt und eine ehrliche Antwort bekommen. Der Preis lag im Rahmen. Den Ausschlag gab, dass der Wettbewerber einen verbindlichen Wartungsvertrag mit Reaktionszeit angeboten hatte.

Zeitstrahl: Beim Aufzeichnen fällt auf, dass die Frage nach Wartung beim zweiten Besichtigungstermin gestellt wurde. Der technische Leiter hatte sie gehört, sie aber für eine Nebenfrage gehalten. Im Angebot stand ein Satz: „Wartung auf Anfrage.“

Beibehalten: Die zwei Besichtigungstermine vor Ort. Der Kunde hat ausdrücklich gelobt, dass der Betrieb sich die Halle angesehen hat.

Ändern, mit Ursache: Die Wartungsfrage ist untergegangen, weil es keinen festen Ablauf gab, in dem Erkenntnisse aus Kundenterminen ins Angebot fließen. Jeder hatte seine Notizen, keiner hatte sie zusammengeführt.

Maßnahmen:

• Nach jedem Besichtigungstermin ein Kurzprotokoll mit „Kundenfragen und Wünsche“ — technischer Leiter, ab sofort.
• Vor Abgabe jedes Angebots über einer festgelegten Summe ein 20-Minuten-Termin, in dem alle Kundenfragen gegen das Angebot geprüft werden — Vertriebsleiter, ab sofort.
• Ein Standardangebot für Wartungsverträge mit Reaktionszeit entwickeln — technischer Leiter und Kalkulator, bis Ende des Quartals.

Hinweis für das nächste Projekt: „Bei Logistik- und Industriekunden ist Ausfallsicherheit oft wichtiger als der Anschaffungspreis. Frag aktiv nach Wartung und Reaktionszeit und biete sie verbindlich an.“

Der Auftrag ist weg. Aber aus dem Verlust wird eine Investition in die nächsten Angebote.

Die häufigsten Fehler bei Lessons Learned

• Nur nach gescheiterten Projekten. Wer Lessons Learned nur macht, wenn etwas schiefgelaufen ist, macht daraus ein Tribunal. Mach sie nach jedem wichtigen Projekt — auch nach erfolgreichen.
• Der Projektleiter moderiert selbst. Er ist Partei. Die Leute reden anders, wenn ein Neutraler den Termin führt.
• Zu viele Maßnahmen. Fünfzehn Punkte auf der Liste heißt: keiner wird umgesetzt. Drei reichen.
• Maßnahmen ohne Namen. „Wir“ setzt nichts um. Ein Name, ein Termin, sonst ist es keine Maßnahme.
• Keine Nachverfolgung. Prüf nach vier Wochen, ob die Maßnahmen umgesetzt sind. Setz dir dafür einen Termin in den Kalender, direkt nach dem Workshop.

Die gemeinsame Wurzel: Lessons Learned werden als Pflichtübung behandelt statt als Werkzeug. Sobald dein Team erlebt, dass aus dem Workshop echte Änderungen entstehen, kommen die Leute freiwillig — und bringen ihre besten Beobachtungen mit.

Und das hat mit Teamführung mehr zu tun als mit Methodik. Ein Team, das Fehler offen anspricht, weil es weiß, dass daraus Verbesserung wird statt Bestrafung, ist ein Team, das mit jedem Projekt besser wird. Ein Team, das Fehler versteckt, macht sie wieder.

Wie du morgen anfängst

Du brauchst kein Programm und kein Handbuch. Du brauchst drei Dinge:

1. Such dir das letzte abgeschlossene Projekt aus — ein Kundenauftrag, eine Messe, eine Einführung. Setz innerhalb der nächsten zwei Wochen einen 60-Minuten-Termin an.
2. Nutze die fünf Schritte — Soll gegen Ist, Zeitstrahl, Beibehalten und Ändern, Ursachen, Maßnahmen mit Namen. Und die Formel: Beobachtung, Ursache, Konsequenz.
3. Leg eine Stelle für die Ablage fest und mach das Lesen beim nächsten Projektstart zur Pflicht.

Nach drei, vier Projekten hast du einen Wissensspeicher mit dem gesammelten Wissen deines eigenen Unternehmens.

Wenn du dein Unternehmen nicht nur Projekt für Projekt, sondern im Ganzen auf System stellen willst — Vertrieb, Führung, Abläufe —, dann hol dir das Unternehmer-Paket mit sieben Anleitungen für mehr Umsatz. Es enthält die Werkzeuge, mit denen ich meine eigenen Unternehmen führe. Sicher es dir jetzt.

Häufige Fragen zu Lessons Learned

Was bedeutet Lessons Learned auf Deutsch?

Lessons Learned heißt wörtlich „gelernte Lektionen“ und wird meist mit „gewonnene Erkenntnisse“ übersetzt. Gemeint ist das systematische Sammeln und Festhalten von Erfahrungen aus einem Projekt, damit künftige Projekte davon profitieren. Entscheidend ist, dass die Erkenntnisse tatsächlich in den nächsten Ablauf einfließen.

Wann macht man Lessons Learned?

Klassisch beim Projektabschluss, spätestens zwei Wochen nach Projektende. Bei langen Projekten zusätzlich nach wichtigen Meilensteinen. Im Unternehmen lohnen sie sich auch nach Messen, verlorenen oder gewonnenen Großaufträgen, großen Reklamationen und Einführungen neuer Systeme.

Was ist der Unterschied zwischen Lessons Learned und Retrospektive?

Die Retrospektive ist ein regelmäßiger Termin eines Teams, das weiter zusammenarbeitet, und verbessert die laufende Zusammenarbeit. Lessons Learned blicken am Ende eines Projekts zurück und halten Erkenntnisse für künftige Projekte fest — oft für Menschen, die beim nächsten Mal gar nicht dabei sind. Deshalb ist die Dokumentation bei Lessons Learned wichtiger.

Wie dokumentiere ich Lessons Learned richtig?

Auf einer, höchstens zwei Seiten: Soll gegen Ist, was beibehalten wird, was geändert wird — jeweils mit Beobachtung, Ursache und Konsequenz —, Maßnahmen mit Namen und Termin sowie ein Hinweis für das nächste ähnliche Projekt. Leg alle Dokumente an einer zentralen Stelle ab und mach das Lesen beim nächsten Projektstart zur Pflicht.