Projekt abgeschlossen, Wissen weg? Warum komplexe Projekte ein Project Memory brauchen

Projektsteuerung konzentriert sich verständlicherweise auf Delivery.

Wurde der Scope erreicht? Wurde das Budget eingehalten? Sind die Meilensteine geschafft? Funktioniert die Lösung? Sind die Leistungen abgenommen?

Nach Projektende folgt häufig noch ein Lessons-Learned-Termin. Dann wird gesammelt, was gut und was schlecht lief, ein Dokument abgelegt und das Team widmet sich der nächsten Aufgabe.

Formal ist das Projekt damit sauber abgeschlossen.

Organisatorisch kann trotzdem viel verloren gehen.

Denn zwischen Projektstart und Abschluss entstehen täglich Entscheidungen und Erfahrungen, die in keinem klassischen Abschlussbericht vollständig enthalten sind.

Ein Budget wurde erhöht, weil eine technische Annahme falsch war.

Ein bestimmter Dienstleister wurde bewusst anders eingesetzt als ursprünglich geplant.

Eine Schnittstelle funktionierte erst, nachdem zwei Teams ihre Rollen verändert hatten.

Ein ursprünglich attraktiver Lösungsweg wurde nach mehreren Wochen verworfen.

Ein Risiko trat nicht ein, weil jemand früh eine Gegenmaßnahme ergriffen hatte.

Später ist häufig nur noch das Ergebnis sichtbar.

Die Logik, die zu diesem Ergebnis geführt hat, fehlt.

Genau dort beginnt die Idee eines Project Memory.

Viele Unternehmen besitzen bereits große Mengen historischer Projektdaten.

Es gibt Projektpläne, Präsentationen, Verträge, Protokolle, Rechnungen, Tickets, E-Mails, Risiko-Logs, Statusberichte und Abschlussdokumentationen.

Das Problem ist deshalb häufig nicht, dass Informationen vollständig verschwinden.

Das Problem ist, dass sie später nicht mehr im richtigen Zusammenhang auffindbar sind.

Ein Projektarchiv beantwortet:

„Welche Dokumente existieren noch?“

Ein Project Memory sollte eine andere Frage beantworten:

„Was aus diesem Projekt hilft uns bei der nächsten vergleichbaren Entscheidung?“

Das ist ein wesentlicher Unterschied.

Ein 80-seitiger Abschlussbericht kann hervorragend dokumentiert sein und trotzdem wenig Nutzen erzeugen, wenn niemand weiß, dass genau dort eine relevante Entscheidung beschrieben wurde.

Umgekehrt kann eine kurze, sauber strukturierte Information über eine verworfene Alternative für ein späteres Projekt enorm wertvoll sein.

Nicht die Menge gespeicherter Daten entscheidet über organisationales Lernen.

Entscheidend ist ihre Wiederverwendbarkeit.

Die Association for Project Management beschreibt Lessons Learned als dokumentierte Erfahrungen, die zukünftiges Projekt-, Programm- und Portfoliomanagement verbessern können. Gleichzeitig weist APM darauf hin, dass viele Organisationen Lessons zwar dokumentieren, sie aber nicht zuverlässig in veränderte Praxis übersetzen.

Besonders problematisch ist aus Sicht von APM die ausschließliche Erfassung am Projektende. Dann sind Teammitglieder gedanklich häufig bereits beim nächsten Vorhaben, wichtige Details liegen Monate zurück und die Übung droht zum formalen Abschlussritual zu werden. APM empfiehlt deshalb, Learnings während des Projekts und an formalen Phasenenden zu erfassen und möglichst früh wieder nutzbar zu machen.

Das verändert die Logik grundlegend.

Lessons Learned sind dann keine Abschlussdokumentation.

Sie werden Teil der laufenden Projektsteuerung.

Denn Wissen hat den größten Wert nicht dann, wenn es archiviert wird.

Sondern dann, wenn es bei der nächsten relevanten Entscheidung wieder auftaucht.

Nicht alles, was in einem Projekt passiert, muss dauerhaft gespeichert werden.

Ein vollständiges Sitzungsprotokoll jeder Abstimmung würde eher neue Informationslast erzeugen.

Für spätere Projekte sind vor allem sechs Arten von Wissen relevant.

Welche wesentlichen Entscheidungen wurden getroffen?

Warum wurde Option A gewählt und Option B verworfen?

Welche Informationen lagen zu diesem Zeitpunkt vor?

Welche Annahmen waren entscheidend?

Wer war an der Entscheidung beteiligt?

Diese Ebene ist besonders wichtig, weil spätere Teams sonst häufig nur den Endzustand sehen.

Eine Architektur, ein Supplier-Setup oder ein Prozess wirkt Jahre später möglicherweise unnötig kompliziert. Ohne den damaligen Kontext lässt sich kaum beurteilen, ob die Entscheidung tatsächlich schlecht war oder unter den damaligen Bedingungen die sinnvollste Lösung.

Project Memory sollte deshalb nicht nur festhalten, was entschieden wurde, sondern auch warum.

Projektwissen besteht nicht nur aus den Wegen, die funktioniert haben.

Ebenso wertvoll sind Optionen, die geprüft und bewusst nicht weiterverfolgt wurden.

Ohne diese Information passiert in Folgeprojekten häufig etwas Bekanntes:

Ein neues Team entdeckt dieselbe vermeintlich attraktive Idee, investiert erneut Zeit in Analyse und kommt Monate später zum gleichen Ergebnis wie das vorherige Projekt.

Das ist kein individuelles Versagen.

Es ist fehlendes organisationales Gedächtnis.

Zu einem Project Memory gehört deshalb auch:

Bei externen Projekten entsteht zusätzlich Wissen über die tatsächliche Zusammenarbeit mit Dienstleistern.

Nicht nur:

Sondern beispielsweise:

Diese Informationen sind für spätere Beschaffungs- und Projektentscheidungen oft wertvoller als eine allgemeine Bewertung wie „guter Dienstleister“.

Denn Supplier Performance ist kontextabhängig.

Ein Anbieter kann für einen Projekttyp hervorragend geeignet sein und für einen anderen weniger.

Ein klassisches Risikoregister zeigt, welche Risiken während des Projekts beobachtet wurden.

Für spätere Projekte ist zusätzlich relevant:

Woran hätte man früher erkennen können, dass ein Risiko real wird?

Vielleicht gab es vor einer Terminverschiebung bereits wiederholte kleine Verzögerungen.

Vor einer Kostenüberschreitung entstanden mehrere ungeplante Zusatzleistungen.

Vor einem Supplier-Konflikt wurden Informationen zunehmend später geteilt.

Vor einer Qualitätskrise stieg die Zahl der Nacharbeiten.

Nicht jedes dieser Signale wird sich in anderen Projekten wiederholen.

Aber die Verbindung zwischen Signal, Entwicklung und Gegenmaßnahme ist genau die Art von Wissen, die Projektorganisationen mit jeder Durchführung aufbauen können.

In komplexen Projekten liegt kritisches Wissen häufig zwischen Organisationen und Systemen.

Wer muss wann welche Information liefern?

Welche Definitionen führten zu Missverständnissen?

Welche Daten mussten manuell übersetzt werden?

Wo entstanden Wartezeiten zwischen zwei Verantwortungsbereichen?

Welche Abhängigkeit war im ursprünglichen Projektplan unterschätzt?

Gerade bei mehreren externen Partnern kann dieses Schnittstellenwissen entscheidend sein.

Die einzelnen Parteien kennen ihre eigenen Aufgaben oft sehr gut.

Das Projektproblem entsteht dort, wo zwei korrekte Einzelprozesse nicht sauber ineinandergreifen.

Ein Projekt endet organisatorisch häufig früher als sein Nutzen.

Die entwickelte Lösung wird betrieben. Verträge laufen weiter. Systeme werden gewartet. Fachbereiche arbeiten mit den Ergebnissen. Neue Projekte bauen darauf auf.

APM beschreibt erfolgreiche Projektübergabe deshalb ausdrücklich als Prozess und nicht als einzelnen Termin. Wissen und Verantwortung sollten schrittweise vom Projekt in den späteren Betrieb oder die weiterführende Organisation übertragen werden.

Zu einem Project Memory gehört deshalb auch:

Wer am letzten Projekttag versucht, drei Jahre Arbeit rückwirkend zu rekonstruieren, wird zwangsläufig Lücken erzeugen.

Deshalb sollte Project Memory von Beginn an mitgedacht werden.

Nicht als zusätzliches Großprojekt.

Sondern durch wenige definierte Momente, an denen Wissen strukturiert erfasst wird.

Zum Beispiel:

Was wurde entschieden? Warum? Welche Alternative wurde verworfen? Welche Annahme lag zugrunde?

Was hat sich verändert? Warum? Welche Kosten-, Termin- oder Supplier-Auswirkung entstand?

Was war das eigentliche Problem? Welche Frühindikatoren gab es? Welche Entscheidung hat die Situation gelöst?

Welche Annahmen haben sich bestätigt? Welche Learnings sollten unmittelbar in die nächste Phase einfließen?

Welches projektrelevante Wissen muss übertragen werden, bevor die Person die Rolle verlässt?

Welche Erfahrungen sind nicht nur für dieses Projekt interessant, sondern für ähnliche Projekte, Supplier oder Entscheidungssituationen in der Organisation?

Damit wird Lernen zu einem Nebenprodukt guter Steuerung – statt zu einer Erinnerungsübung am Ende.

Viele Lessons-Learned-Initiativen konzentrieren sich auf die Frage:

„Wie bekommen wir mehr Wissen in das System?“

Die wichtigere Frage lautet häufig:

„Wie bekommt das richtige Team das richtige Wissen wieder heraus?“

Ein Project Memory ist nur dann wertvoll, wenn Informationen später nach dem Kontext einer neuen Entscheidung auffindbar werden.

Beispielsweise:

Das ist der Unterschied zwischen einer Wissensdatenbank und nutzbarem Entscheidungswissen.

Eine Datenbank speichert Vergangenheit.

Ein Project Memory macht Vergangenheit für eine aktuelle Entscheidung relevant.

Bei rein internen Projekten bleibt Wissen zumindest theoretisch innerhalb derselben Organisation.

Bei externen Projekten ist das schwieriger.

Mit dem Projektende lösen sich Teams auf. Berater wechseln zum nächsten Kunden. Agenturen wechseln ihre Besetzung. Technologiepartner tauschen Spezialisten aus. Interne Projektleiter übernehmen neue Rollen.

Damit steigt das Risiko, dass entscheidendes Erfahrungswissen an einzelne Personen gebunden bleibt.

Für Auftraggeber entsteht zusätzlich eine strategische Frage:

Welche Projektintelligenz wollen wir dauerhaft selbst besitzen – unabhängig davon, welcher Dienstleister das nächste Projekt umsetzt?

Dazu gehört Wissen über:

Wer diese Informationen nur in den Systemen, Reports oder Köpfen externer Partner belässt, baut mit jedem Projekt zwar Erfahrung auf – aber nicht zwangsläufig organisationales Wissen.

Ein Projektabschluss sollte deshalb nicht nur offene Tasks, Rechnungen und Abnahmen prüfen.

Acht zusätzliche Fragen helfen zu beurteilen, ob das Projekt auch Wissen hinterlässt:

Die letzte Frage ist die entscheidende.

Denn ein Learning, das niemand wiederfindet, ist organisatorisch kaum wertvoller als eines, das nie dokumentiert wurde.

Aus Ramp7-Perspektive ist Project Memory deshalb eng mit Project Intelligence verbunden.

Während ein Projekt läuft, entstehen Informationen zu Budgets, Timings, externen Leistungen, Risiken und Entscheidungen.

Nach Projektende verlieren diese Informationen nicht automatisch ihren Wert.

Im Gegenteil: Erst über mehrere Projekte hinweg können sie einen neuen Kontext bekommen.

Ein einzelner Scope Change ist ein Projektvorgang.

Zehn ähnliche Scope Changes bei vergleichbaren Vorhaben können ein Organisationsmuster sein.

Eine schwierige Supplier-Schnittstelle ist zunächst ein Einzelfall.

Wenn dieselbe Art von Problem in mehreren Projekten wiederkehrt, wird daraus ein Steuerungsthema.

Eine verworfene Lösung ist eine historische Entscheidung.

Wenn ein neues Projekt vor derselben Wahl steht, wird diese Historie plötzlich wieder aktuell.

Genau darin liegt der Unterschied zwischen Projektdokumentation und Entscheidungskapital.

Project Memory bedeutet in diesem Artikel daher nicht, möglichst viel Vergangenheit zu speichern.

Es bedeutet, genügend Kontext zu erhalten, damit zukünftige Entscheider nicht dieselbe Unsicherheit ein zweites Mal vollständig bezahlen müssen.

AutomatedTrain zeigt aktuell, wie komplexe Projektkonsortien über Jahre hinweg Technologie, Organisationen und Wissen zusammenbringen können. Das BMWE nennt neun beteiligte Organisationen; Siemens verweist nach Abschluss des Demonstrationsschritts auf die geschaffenen Grundlagen für Standardisierung und spätere Umsetzung.

Es gibt keinen Hinweis darauf, dass dieses konkrete Projekt ein Problem mit Lessons Learned oder Wissenstransfer hätte.

Als Anlass macht es jedoch eine allgemeine Frage sichtbar, die für jedes große Projekt relevant ist:

Was passiert mit dem Wissen, wenn das Projekt endet?

APM weist darauf hin, dass Lessons Learned zwar häufig dokumentiert werden, aber nicht zuverlässig in zukünftige Praxis einfließen. Wer erst am Projektende mit der Wissenssicherung beginnt, riskiert zusätzlich, dass ein Teil der relevanten Erfahrung bereits verloren oder aus dem Fokus geraten ist.

Deshalb sollte ein Projekt nicht nur drei Dinge hinterlassen:

ein Ergebnis, eine Abrechnung und einen Abschlussbericht.

Es sollte auch hinterlassen:

Denn Organisationen werden nicht dadurch projektintelligenter, dass sie viele Projekte durchführen.

Sie werden es erst, wenn das nächste Projekt vom vorherigen lernen kann.