Lessons Learned: Methode, Vorlage und konsequente Umsetzung

Warum die Lessons Learned Methode wichtig ist

Lessons Learned sind die Erkenntnisse, die ein Team nach einem Projekt festhält: was funktioniert hat, was nicht und warum. Sie verwandeln alltägliche Projekterfahrungen in Wissen, das zukünftige Teams tatsächlich nutzen können.

Im Projektmanagement sind sie aus mehreren praktischen Gründen wichtig:

• Fehler vermeiden: Sie verhindern, dass Teams beim nächsten Projekt dieselben Fehler machen.

• Erfolge wiederholen: Sie helfen dabei, die Vorgehensweisen zu übernehmen, die gute Ergebnisse erzielt haben.

• Fluktuation überstehen: Sie bauen Wissen auf, das über einzelne Teammitglieder:innen hinaus Bestand hat.

• Veränderungen anstoßen: Sie verwandeln Erfahrungen in konkrete Verbesserungen, nicht nur in Beobachtungen.

Die meisten Teams wissen bereits, dass Lessons Learned wichtig sind. Die Herausforderung liegt in der Durchführung, und immer wieder tauchen dieselben drei Fehlerquellen auf:

• Zu spät: Die Sitzung findet statt, nachdem alle schon weitergezogen sind und die Details verblasst sind.

• Zu hastig: Sie wird zu einer Pflichtübung, die in die letzte Projektwoche gequetscht wird.

• Kein Follow-up: Die Erkenntnisse werden zwar aufgeschrieben, erreichen jedoch nie den nächsten Projekt-Kickoff.

Lessons Learned werden nützlich, wenn sie strukturiert, schuldfreiheitsorientiert und mit konkreten nächsten Schritten verknüpft sind. Der Rest dieses Leitfadens zeigt Ihnen, wie Sie dorthin gelangen.

Lessons Learned vs. Retrospectives vs. Post-Mortems

Diese drei Begriffe werden oft synonym verwendet, sind aber nicht dasselbe. Jeder hat einen anderen Zweck und findet zu einem anderen Zeitpunkt in Ihrer Arbeit statt.

Lessons-Learned-Sitzungen betrachten das gesamte Projekt, während Retrospectives, oder „Projektretrospektiven“ (im deutschsprachigen Kontext), sich auf den letzten Sprint konzentrieren. Post-Mortems sind noch enger gefasst und untersuchen einen bestimmten Fehler im Detail. Viele Teams führen sowohl Retrospectives als auch Lessons Learned durch: eine für kurzfristige Sprint-Korrekturen, die andere für projektübergreifendes Wissen, das dauerhaft verankert wird.

Unser Blogartikel konzentriert sich auf Lessons Learned auf Projektebene, die Methode lässt sich jedoch gut auf andere Kontexte übertragen.

Wann eine Lessons-Learned-Sitzung durchgeführt werden sollte

Das Projektende erscheint als natürlicher Zeitpunkt. Doch nur auf das Ende zu warten bedeutet, dass das Team nichts aus dem Gelernten in der aktuellen Arbeit anwenden kann.

Bessere Zeitpunkte sehen so aus:

• Bei wichtigen Meilensteinen: Nach Abschluss einer großen Phase oder eines Lieferobjekts, solange es noch frisch ist.

• Wenn etwas Unerwartetes passiert: Sowohl Erfolge als auch Rückschläge, die das Team nicht vorhergesehen hat.

• Beim Projektabschluss: Eine abschließende Sitzung, die das gesamte Projekt umfasst.

• Bevor Personen das Team verlassen: Ihre Perspektive festhalten, bevor sie ausscheiden.

Sitzungen bei Meilensteinen, nicht nur am Ende, durchzuführen bedeutet, dass Erkenntnisse das laufende Projekt verbessern, nicht nur zukünftige. Als Faustregel gilt: Die Sitzung sollte innerhalb von ein bis zwei Wochen nach dem Meilenstein oder dem Abschluss stattfinden. Das ist früh genug, damit die Details noch frisch sind, und bietet gleichzeitig genug Abstand für eine reflektierte Perspektive.

Eine schuldzuweisungsfreie Atmosphäre geschaffen wird

Zwei Dinge entscheiden darüber, ob eine Sitzung echte Erkenntnisse liefert: wer im Raum ist und wie sicher sich die Teilnehmenden fühlen, offen zu sprechen.

Laden Sie alle ein, die das Ergebnis mitgestaltet haben, nicht nur die Führungsebene:

• Kernteammitglieder:innen, die die praktische Arbeit geleistet haben

• Den Projektmanager

• Wichtige Stakeholder, die Anforderungen oder Feedback gegeben haben

• Fachexpert:innen, die hinzugezogen wurden

• Alle, die ein bedeutendes Problem erlebt oder gelöst haben

Streben Sie fünf bis zehn Personen an. Bei größeren Projekten empfehlen sich mehrere Sitzungen, gegliedert nach Arbeitsbereichen, damit jedes Gespräch fokussiert bleibt.

Die Unternehmenskultur ist genauso wichtig wie die Teilnahme. „Schuldfreiheitsorientiert" bedeutet, dass das Ziel darin besteht, zu verstehen, was im System oder Prozess schiefgelaufen ist, nicht, wer dafür verantwortlich ist. Das SRE-Team von Google bringt es treffend auf den Punkt:

Effektive Post-Mortems gehen davon aus, dass Menschen in guter Absicht gehandelt haben und dabei die Informationen nutzten, die ihnen zum jeweiligen Zeitpunkt zur Verfügung standen. Der Fokus sollte auf System- und Prozessschwächen liegen, nicht auf der Schuldzuweisung an Einzelpersonen oder Teams." – Google SRE Book

Für Moderatoren wird dieses Prinzip zu einigen konkreten Gewohnheiten:

• Frühzeitig den Ton setzen: Klar kommunizieren, dass es in der Sitzung darum geht, das System zu verbessern, nicht darum, Menschen zu beurteilen.

• Schuldzuweisungen umlenken: „Warum hat Sarah den Zeitplan nicht aktualisiert?“ wird zu „Was hat verhindert, dass der Zeitplan aktualisiert wurde?“

• Mit gutem Beispiel vorangehen: Einen eigenen Fehler teilen, um Offenheit vorzuleben.

• Dankbarkeit zeigen: Besonders dann, wenn jemand etwas Unangenehmes anspricht.

Wenn sich Menschen sicher fühlen, teilen sie ihre echten Probleme. Wenn sie sich beurteilt fühlen, teilen sie nur die offensichtlichen, harmlosen Dinge und die wirklich wertvollen Erkenntnisse bleiben verborgen.

Die fünfstufige Lessons-Learned-Methode, der Sie vertrauen können

Diese Lessons-Learned-Methode bietet Ihnen einen wiederholbaren Prozess, damit Erkenntnisse nicht bei einer „guten Diskussion“ stehen bleiben, sondern in etwas Verwertbares für das nächste Projekt umgewandelt werden. Jede Erkenntnis durchläuft alle fünf Schritte unter Begleitung einer namentlich benannten verantwortlichen Person, die sie von Anfang bis Ende begleitet.

1. Die Erkenntnis identifizieren

Das Team bringt konkrete Erfahrungen, gute wie schlechte, an die Oberfläche, die die zukünftige Arbeit beeinflussen könnten. Nicht alles ist eine Erkenntnis, die es wert ist, festgehalten zu werden. Ein Moment ist es wert, wenn er unerwartet war, echte Auswirkungen auf den Zeitplan, das Budget oder das Team hatte, eine Lücke im Prozess aufgedeckt hat oder so gut funktionierte, dass Sie ihn wiederholen möchten.

Zum Beispiel: „Die wöchentliche Stakeholder-Demo hat kurzfristige Scope-Änderungen verhindert“ oder „Die verzögerte rechtliche Prüfung hat drei Wochen hinzugefügt, weil Verträge nicht frühzeitig markiert wurden.“

2. Den Kontext dokumentieren

Eine Erkenntnis hilft nur, wenn jemand, der sie sechs Monate später liest, die Situation versteht. Halten Sie den Kontext kurz, drei bis fünf Sätze reichen, und decken Sie vier Aspekte ab:

• Was passiert ist: Das Ereignis, die Entscheidung oder das Ergebnis.

• Wann: Die Projektphase oder der Zeitraum.

• Wer: Rollen statt Namen (z. B. „das Entwicklungsteam und die Rechtsabteilung des Kunden“).

• Umstände: Rahmenbedingungen oder Annahmen, die das Ergebnis beeinflusst haben.

3. Die Ursache analysieren

Oberflächliche Beobachtungen wie „die Kommunikation war schlecht" führen zu keiner Veränderung. Die 5-Why-Methode hilft Ihnen, tiefer zu graben, indem Sie so lange „warum“ fragen, bis Sie eine Ursache erreichen, die Sie tatsächlich angehen können:

• Das Lieferobjekt war verspätet

• Warum? Der Entwickler hatte die Anforderungen nicht

• Warum? Das Anforderungsdokument wurde nicht geteilt

• Warum? Es gibt keinen standardisierten Übergabeprozess zwischen Produkt und Entwicklung

• Grundursache: fehlender Übergabeprozess

Wenn Ihre Analyse mit „weil jemand es vergessen hat“ endet, graben Sie weiter. Es gibt fast immer einen systemischen Grund.

4. In einem gemeinsamen Register speichern

Erkenntnisse sind nur dann wertvoll, wenn zukünftige Teams sie finden können. Ein gemeinsames, durchsuchbares Register, manchmal auch als Lessons-Learned-Log bezeichnet, verhindert, dass Erkenntnisse in privaten Notizbüchern oder in vergessenen Ordnern verloren gehen.

Ein guter Eintrag enthält den Erkenntnistitel, den Projektnamen und das Datum, den Kontext und die Grundursache, die Auswirkung, die Empfehlung, die verantwortliche Person und den Status. Dieses an einem Ort zu speichern, auf den das gesamte Team zugreifen kann, macht Lessons Learned im Projekt wirklich wiederverwendbar, statt sie zu einer einmaligen Übung zu machen. Die Notizen-Funktion von MeisterTask bietet Ihnen dafür einen gemeinsamen, durchsuchbaren Bereich, und der Abschnitt zur Speicherung weiter unten erläutert die Einrichtung.

5. Follow-up-Maßnahmen zuweisen

Dokumentation ohne Maßnahmen ist verschwendete Mühe. Jede Erkenntnis endet mit mindestens einem konkreten nächsten Schritt, einer namentlich benannten verantwortlichen Person und einem Fälligkeitsdatum. Der Unterschied zwischen einer Erkenntnis und einer Maßnahme sieht so aus:

• Erkenntnis: „Die verzögerte rechtliche Prüfung hat drei Wochen in Anspruch genommen, weil Verträge nicht frühzeitig markiert wurden.“

• Maßnahme: „Einen Schritt ‚Für rechtliche Prüfung markieren' bis zum 15. August zur Projektvorlage hinzufügen, verantwortlich: Projektmanager.“

Vage Maßnahmen wie „Kommunikation verbessern“ führen nirgendwohin. Konkrete, zeitgebundene Maßnahmen schon. Die besten Teams überprüfen offene Punkte monatlich, um die Nachverfolgung auf Kurs zu halten.

Schlüsselfragen, um die wirklichen Erkenntnisse ans Licht zu bringen

Die Qualität einer Sitzung hängt von den Fragen ab, die Sie stellen. Allgemeine Impulse wie „Was lief gut?“ tendieren dazu, allgemeine Antworten hervorzurufen. Diese drei Fragen, der Reihe nach mit jeweils etwa 15 bis 20 Minuten bearbeitet, bringen Erkenntnisse besser ans Licht, die Sie tatsächlich nutzen können.

Was hat funktioniert und warum

Mit Erfolgen zu beginnen setzt einen positiven Ton und markiert, was wiederholt werden sollte. Das „und warum“ ist dabei am wichtigsten; zu wissen, warum etwas funktioniert hat, ermöglicht es Ihnen, es in einen anderen Kontext zu übertragen.

Vergleichen Sie: „Das tägliche Standup hat gut funktioniert“ (schwach) mit „Das tägliche Standup hat Blocker sichtbar gemacht, sodass wir Probleme noch am selben Tag gelöst haben, anstatt auf das wöchentliche Meeting zu warten.“ (stark). Streben Sie nach der zweiten Version. Ziel ist es, drei bis fünf konkrete Praktiken zu identifizieren, die gute Ergebnisse erzielt haben.

Was hat nicht funktioniert und warum

Hier können Sitzungen leicht in Beschwerden abdriften. Die Aufgabe des Moderators ist es, den Fokus auf Systeme statt auf Personen zu lenken und Beschwerden in Fragen nach der Ursache umzuformulieren.

Statt „Der Kunde hat ständig die Anforderungen geändert“ fragen Sie: „Was hat dazu geführt, dass sich die Anforderungen geändert haben, und wie könnten wir uns besser an Änderungen anpassen?“ Statt „Wir hatten nicht genug Zeit“ fragen Sie: „Was hat länger gedauert als erwartet, und was würde uns helfen, genauer zu schätzen?“ Beschwerden ohne Ursachenanalyse führen zu keinen Verbesserungen, sie tauchen einfach im nächsten Quartal wieder auf.

Was werden wir beim nächsten Mal anders machen

Diese Frage verwandelt Beobachtungen in Verpflichtungen. Jede Erkenntnis aus den ersten beiden Fragen führt zu mindestens einer „Wir werden“-Aussage, und jede davon ist konkret:

• Zu vage: „Wir werden besser kommunizieren“

• Umsetzbar: „Wir senden jeden Freitag bis 15 Uhr ein wöchentliches Fortschritts-Update an die Stakeholder“

Halten Sie diese in Echtzeit fest und weisen Sie jeder Aussage noch vor Sitzungsende eine verantwortliche Person zu. Manche sind schnelle Korrekturen, etwa das Aktualisieren einer Vorlage. Andere erfordern umfassendere Änderungen, etwa einen neuen Genehmigungsprozess. Beides ist gültig, solange der Zeitplan realistisch ist.

Wie Erkenntnisse für eine einfache Wiederverwendung dokumentiert und gespeichert werden

Großartige Erkenntnisse sind nutzlos, wenn das nächste Team sie nicht finden kann. Jede dokumentierte Erkenntnis profitiert von denselben fünf Feldern, damit Einträge später leicht zu überfliegen sind:

• Was passiert ist: Zwei bis drei Sätze, die das Ereignis oder das Ergebnis beschreiben.

• Grundursache: Warum es passiert ist, aus Schritt drei.

• Auswirkung: Der Effekt auf den Zeitplan, das Budget, die Qualität oder das Team.

• Empfehlung: Was konkret und umsetzbar anders gemacht werden sollte.

• Verantwortliche Person: Wer dafür zuständig ist, mit Fälligkeitsdatum.

Wo Sie Ihr Log speichern, ist genauso wichtig. Häufige Speicherfehler betreffen persönliche Postfächer, lokale Dateien, archivierte Projektordner und Präsentationen, die nie aktualisiert werden. In jedem Fall verschwindet das Wissen im Moment, in dem jemand die Rolle wechselt.

Die Notizen-Funktion von MeisterTask bietet Teams einen gemeinsamen, durchsuchbaren Bereich. Da Notizen direkt neben Ihren Projekten und Aufgaben liegen, bleibt die Dokumentation mit der Arbeit verbunden, statt in einem separaten Tool zu sitzen. Sie können dedizierte „Lessons Learned“-Notizen pro Projekt erstellen oder ein organisationsweites, nach Projekt oder Abteilung getagtes Log führen. MeisterTask zwingt Sie nicht zu einer starren Lessons-Learned-Vorlage: Sie bauen in Notizen eine Struktur auf, die zur Arbeitsweise Ihres Teams passt, und genau diese Konsistenz macht das Log Monate später durchsuchbar.

Jede Erkenntnis in eine umsetzbare Aufgabe umwandeln

Dokumentation allein schafft keine Veränderung. Dem Scrum-Prinzip folgend, wonach Inspektion ohne Anpassung sinnlos ist, liegt der eigentliche Wert darin, jede Empfehlung in eine Aufgabe mit einer namentlich benannten verantwortlichen Person und einem Fälligkeitsdatum umzuwandeln.

Hier ist ein einfacher Weg, Erkenntnisse in Arbeit umzuwandeln, die tatsächlich erledigt wird:

1. Überprüfen Sie jede Empfehlung aus der Sitzung.

2. Erstellen Sie eine Aufgabe in MeisterTask mit einem klaren, umsetzbaren Titel.

3. Weisen Sie sie der in Schritt fünf der Methode genannten verantwortlichen Person zu.

4. Legen Sie ein Fälligkeitsdatum fest, das an den nächsten Kick-off oder an einen bestimmten Meilenstein geknüpft ist.

5. Verlinken Sie die Aufgabenbeschreibung zurück zur vollständigen Erkenntnis in Notizen für den Kontext.

6. Taggen Sie die Aufgabe mit „Lessons Learned" oder „Prozessverbesserung“ für ein einfaches Filtern.

Erstellen Sie in MeisterTask einen dedizierten Bereich für Lessons-Learned-Follow-up-Maßnahmen. Eine 15-minütige monatliche Überprüfung verhindert, dass Dinge ins Stocken geraten. Wenn das nächste Projekt beginnt, beziehen Sie sich auf das Register und bestätigen Sie, dass die Änderungen umgesetzt wurden. Wenn sie funktioniert haben, gut. Wenn nicht, ist das eine neue Erkenntnis, die dokumentiert werden sollte. Notizen halten das Wissen, Aufgaben halten die Verantwortlichkeit.

Einfache Vorlage und Log zum Kopieren

Diese Lessons-Learned-Vorlage bietet Ihnen einen Ausgangspunkt, den Sie anpassen können. Sie funktioniert in jedem Dokumententool, einschließlich der Notizfunktion von MeisterTask, und erfasst die fünf Felder aus dem vorherigen Abschnitt im einheitlichen Format.

Lessons-Learned-Vorlage

Projektname: [Projekttitel] Datum: [Sitzungsdatum] Teilnehmer:innen: [Namen oder Rollen]

Erkenntnis 1: [Kurzer Titel]

• Was passiert ist: [2-3 Sätze Beschreibung]

• Grundursache: [Warum es passiert ist]

• Auswirkung: [Effekt auf Zeitplan, Budget oder Team]

• Empfehlung: [Was anders gemacht werden sollte]

• Verantwortliche Person: [Name] | Fälligkeitsdatum: [Datum]

• Status: [Offen / In Bearbeitung / Abgeschlossen]

Für Teams, die mehrere Projekte durchführen, hilft ein Master-Log. Dies kann ein MeisterTask-Notizendokument mit Abschnitten pro Projekt sein oder eine Tabelle mit filterbaren Spalten:

Passen Sie die Struktur an Ihren Kontext an. Manche Teams fügen Felder für Abteilung oder Schweregrad hinzu, andere vereinfachen auf nur „Was passiert ist“ und „Was wir anders machen werden“. Der Schlüssel ist Konsistenz, immer dieselbe Struktur, damit das Log Monate später leicht durchsuchbar bleibt.

Beispiele für Lessons Learned aus echten Projekten

Echte Beispiele machen die Methode greifbar. Jedes der vier folgenden Beispiele folgt derselben Struktur und zeigt, wie eine Erkenntnis in eine Maßnahme umgewandelt wird.

Beispiel 1: Kommunikationspanne

• Was passiert ist: Das Entwicklungsteam hat eine Funktion auf Basis veralteter Anforderungen entwickelt, weil die überarbeitete Spezifikation nicht geteilt wurde.

• Grundursache: Kein standardisierter Prozess zur Benachrichtigung der Entwickler über Änderungen an den Anforderungen.

• Auswirkung: Drei Wochen Nacharbeit und ein verzögerter Launch.

• Empfehlung: Ein gemeinsames Anforderungsdokument in Notizen mit Änderungsbenachrichtigungen erstellen; vor Entwicklungsbeginn einen Checkpoint „Anforderungen finalisiert“ hinzufügen.

• Verantwortliche Person: Produktmanager | Status: Abgeschlossen

Beispiel 2: Erfolgreiche Stakeholder-Einbindung

• Was passiert ist: Wöchentliche 15-minütige Demos mit dem Kunden haben kurzfristige Scope-Änderungen verhindert.

• Grundursache: Regelmäßige Transparenz ermöglichte es dem Kunden, frühzeitig gegenzusteuern.

• Auswirkung: Keine Scope-Änderungen in den letzten zwei Wochen; pünktliche Lieferung.

• Empfehlung: Wöchentliche Demos als Standardpraxis für alle Kundenprojekte etablieren.

• Verantwortliche Person: Projektmanager | Status: Abgeschlossen

Beispiel 3: Ressourcenengpässe

• Was passiert ist: Das Design-Team wurde mitten im Sprint für ein dringendes Projekt abgezogen, wodurch drei andere Projekte verzögert wurden.

• Grundursache: Keine Transparenz über die Teamkapazität über Projekte hinweg.

• Auswirkung: Zwei Projekte haben ihre Meilensteine verpasst, und die Stimmung im Team sank.

• Empfehlung: Eine gemeinsame Kapazitätsübersicht in MeisterTask einrichten; einen Eskalationsprozess für dringende Anfragen erstellen.

• Verantwortliche Person: Operations-Leitung | Status: In Bearbeitung

Beispiel 4: Risikomanagement

• Was passiert ist: Ein wichtiger Lieferant hat seinen Termin verpasst, aber das Team hatte Pufferzeit und im Voraus einen Backup-Lieferanten identifiziert.

• Grundursache: Der Projektmanager hatte die Zuverlässigkeit des Lieferanten beim Kickoff als Risiko markiert.

• Auswirkung: Keine Verzögerung des finalen Zeitplans.

• Empfehlung: „Lieferantenrisikobewertung“ zur Kickoff-Checkliste für jedes Projekt hinzufügen.

• Verantwortliche Person: Projektmanager | Status: Abgeschlossen.

Beachten Sie, dass diese Beispiele sowohl Probleme als auch Erfolge umfassen. Der Punkt ist nicht nur, zu dokumentieren, was schiefgelaufen ist, sondern auch zu festhalten, was funktioniert hat, damit Sie es bewusst wiederholen können.

Messen, ob Erkenntnisse wirklich gelernt werden

Die meisten Organisationen verfolgen, ob Sitzungen stattfinden. Sehr wenige verfolgen, ob die Erkenntnisse tatsächlich etwas verändern. Die eigentliche Frage lautet nicht „Haben wir Erkenntnisse festgehalten?“, sondern „Haben wir sie angewendet?“

Einige praktische Kennzahlen helfen, diese Lücke zu schließen:

• Maßnahmenabschlussrate: Wie viel Prozent der Empfehlungen wurden bis zu ihrem Fälligkeitsdatum umgesetzt?

• Wiederkehrende Probleme: Tauchen dieselben Probleme in mehreren Projekten auf? Wenn ja, erreichen die Erkenntnisse nicht die richtigen Personen.

• Übernahme in neue Projekte: Wenn ein neues Projekt beginnt, bezieht sich das Team tatsächlich auf das Register?

• Zeit bis zur Lösung: Löst das Team bekannte Probleme schneller, weil eine Lösung bereits existiert?

Nicht alles lässt sich in Zahlen ausdrücken. Wenn Teammitglieder während der Planung auf vergangene Erkenntnisse zurückgreifen, neue Mitarbeitende mithilfe des Logs eingearbeitet werden und Stakeholder bemerken, dass dieselben Fehler sich nicht wiederholen, funktioniert die Praxis. Eine vierteljährliche Überprüfung hält den Schwung aufrecht: Schauen Sie sich an, was umgesetzt wurde, was nicht und warum. Die Messung selbst sendet ein Signal, dass die Arbeit wichtig ist.

Nächstes Projekt, bessere Ergebnisse mit MeisterTask

Lessons-Learned-Sitzungen zahlen sich nur aus, wenn die Erkenntnisse bis ins nächste Projekt durchreichen. Die meisten Teams scheitern nicht mangels guter Ideen, sondern mangels eines Systems zum Erfassen, Verfolgen und Anwenden dieser Ideen.

Der in diesem Leitfaden beschriebene Workflow besteht aus zwei verbundenen Teilen:

1. Notizen für die Dokumentation: Kontext, Grundursache und Empfehlungen in gemeinsamen, durchsuchbaren Notizen festhalten, die Teil der Wissensbasis des Teams werden.

2. Aufgaben für Maßnahmen: Jede Empfehlung in eine Aufgabe mit einer namentlich benannten verantwortlichen Person und einem Fälligkeitsdatum umwandeln, die neben der alltäglichen Arbeit verfolgt wird.

Vergleichen Sie das mit der häufigen Alternative: Erkenntnisse, die in einer Präsentation festgehalten, einmal geteilt und dann vergessen werden. Mit MeisterTask bleibt die Dokumentation durchsuchbar, die Maßnahmen bleiben nachverfolgbar und die Erkenntnisse fließen tatsächlich in den nächsten Kickoff ein.