Projekt-Knowledgebase: Aus abgeschlossenen Projekten besser planen

Die meisten Schätzungen entstehen aus dem Gedächtnis. Die Projektleiterin denkt an das letzte ähnliche Projekt, schlägt etwas Sicherheit auf und trägt eine Zahl ein. Die tatsächlichen Werte liegen derweil im Archiv: als Ist-Daten abgeschlossener Projekte. Eine Projekt-Knowledgebase macht diese Daten für jede neue Planung abfragbar.

Das Video zum Artikel

Was Sie davon haben

Vor jedem Angebot steht dieselbe Frage: Wie lange dauert das wirklich, und was kostet es uns? Eine Knowledgebase liefert die Antwort aus eigenen Daten und bringt Ihnen vier Vorteile.

• Genauere Zeitschätzungen. Jeder Vorgang bekommt die Dauer, die vergleichbare Vorgänge tatsächlich gebraucht haben, getrennt nach Typ, Lieferant, Behörde oder Jahreszeit.
• Puffer mit Begründung. Statt pauschal zehn Prozent auf alles zu legen, setzen Sie Reserve hinter die Vorgänge, deren Dauer in Ihren Daten schwankt.
• Planbare Planungskosten. Sie kennen den Faktor, um den Ihr Team den eigenen Aufwand unterschätzt, und kalkulieren Angebote und Honorare danach.
• Weniger Mehrarbeit. Bekannte Probleme stehen schon im Startregister des nächsten Projekts, samt der Maßnahme, die beim letzten Mal geholfen hat.

Wie groß der Effekt ist, zeigt das Beispielarchiv zu diesem Guide: zwölf Bauprojekte eines Architekturbüros von 2021 bis 2026, rund 1.350 Vorgänge mit Plan- und Ist-Werten. Wir haben das Archiv konstruiert, damit jede Zahl in diesem Artikel nachrechenbar bleibt; die Muster darin kennt jedes Büro aus dem Bauwesen. Besonders deutlich wird der Effekt an zwei Kitas für denselben öffentlichen Auftraggeber. Für die Kita Sonnenschein schätzte das Büro 2022 aus Erfahrung. Als es zwei Jahre später die Kita Regenbogen plante, flossen die Ist-Werte der Vorprojekte ein.

Den Unterschied machten Genehmigungsdauer, Vergabe und Rohbauzeitraum: Das Büro plante sie mit den Lehren aus den Vorprojekten. Über das ganze Archiv bestätigt sich das Bild. Die ersten sieben Projekte endeten im Schnitt 23 Prozent ihrer Plandauer zu spät. Bei den drei folgenden, geplant mit den Lieferanten, Fachplanern und Behördendauern aus der Auswertung, schrumpfte der Verzug auf 8 Prozent.

Die Theorie: Warum Projekte selten aus Projekten lernen

„Wer sich nicht an die Vergangenheit erinnern kann, ist dazu verurteilt, sie zu wiederholen."
George Santayana, The Life of Reason, 1905

Projekte enden, das Team zieht weiter, und was schiefging, bleibt in den Köpfen. Das Project Management Institute fragte 2015 in seiner Studie Pulse of the Profession, wie wirksam Organisationen Wissen zwischen Projekten weitergeben. Nur 14 Prozent nannten sich sehr wirksam. Organisationen mit hoher Erfolgsquote hatten doppelt so oft einen formalen Prozess dafür: 75 gegen 35 Prozent.

Drei Erkenntnisse aus der Forschung erklären die Lücke.

Der Planungsfehlschluss. Daniel Kahneman und Amos Tversky beschrieben 1979, dass Menschen die Dauer eigener Vorhaben systematisch unterschätzen, selbst wenn ähnliche Vorhaben bekanntermaßen länger gedauert haben. In „Schnelles Denken, langsames Denken" (2011) erzählt Kahneman von einem eigenen Lehrbuchprojekt: Das Team rechnete mit rund zwei Jahren, vergleichbare Teams hatten sieben bis zehn gebraucht, viele waren nie fertig geworden. Am Ende dauerte es acht Jahre. Douglas Hofstadter fasste das Phänomen 1979 in „Gödel, Escher, Bach" als Gesetz: „Es dauert immer länger, als man erwartet, selbst wenn man Hofstadters Gesetz berücksichtigt." Warum Menschen im Projekt so entscheiden, wie sie entscheiden, behandelt auch unser Überblick über psychologische Theorien für Projektmanager.

Innensicht und Außensicht. Kahneman unterscheidet zwei Arten zu schätzen. Wer die Innensicht einnimmt, betrachtet das eigene Projekt mit seinen Plänen und Annahmen. Die Außensicht fragt, wie es vergleichbaren Projekten ergangen ist, und enthält damit die Störungen, die vorab niemand kennt. Bent Flyvbjerg baute darauf das Reference Class Forecasting auf: Ein neues Projekt wird anhand der tatsächlichen Ergebnisse einer Klasse ähnlicher Projekte geschätzt. Seine Datenbank umfasst über 16.000 Projekte; laut „How Big Things Get Done" (2023) hielten nur 8,5 Prozent davon Budget und Zeitplan zugleich.

Implizites und explizites Wissen. Ikujiro Nonaka und Hirotaka Takeuchi beschreiben in „The Knowledge-Creating Company" (1995), wie Organisationen lernen: indem sie Wissen, das Menschen haben, aber kaum aussprechen, in dokumentiertes Wissen überführen. Der Satz „Lehmann liefert immer zu spät" lebt im Kopf eines Bauleiters. „Acht bis zwölf Arbeitstage Verzug in sechs von sechs Projekten" kann auch die neue Kollegin nutzen.

Ein abgeschlossener Plan ist damit eine Referenzklasse in Rohform. Die Ist-Werte liefern die Außensicht, Risiko- und Problem-Anhänge das dokumentierte Wissen. Was fehlt, ist die Auswertung über mehrere Projekte.

Merlin Project und der MCP-Server

Merlin Project speichert je Vorgang geplante, erwartete und wirkliche Werte. Hinzu kommen Anhänge an Vorgängen, Zuweisungen und Ressourcen, darunter Risiko, Problem und Information. Wie Sie Ist-Werte im laufenden Projekt erfassen, zeigt die Serie Tatsächlichen Fortschritt aufzeichnen; die Grundlagen erklärt das Lernkapitel Soll/Ist-Vergleich.

Der MCP-Server von Merlin Project gibt einer KI wie Claude Lesezugriff auf diese Daten. Sie schalten ihn je Projekt über den Button „KI-Tools" in der Symbolleiste frei; die Einrichtung beschreibt die MCP-Dokumentation. Für die Knowledgebase zählen zwei Eigenschaften. Der Server arbeitet mit allen geöffneten und freigegebenen Dokumenten, die KI wertet sie Projekt für Projekt aus. Für ein Archiv öffnen Sie also die abgeschlossenen Projekte, die in die Auswertung gehören. Und der Server liest nur: Kein Plan ändert sich, Erkenntnisse übertragen Sie selbst ins nächste Projekt. Was dabei mit Ihren Daten passiert, erklärt der Beitrag zu digitaler Souveränität und Datenschutz.

Neun Lernquellen stecken in einem abgeschlossenen Plan. Die nummerierten Abschnitte nach dem Rechner behandeln sie in dieser Reihenfolge.

Rechner: Was Ihr Archiv schon hergibt

Welche dieser Auswertungen Ihr Archiv heute trägt, hängt an fünf Gewohnheiten in Merlin Project. Der Rechner fragt sie ab und zeigt, welche Auswertungen schon möglich sind, welche noch fehlen und welcher Schritt die meisten erschließt. Jede Zeile führt zum passenden Abschnitt.

1. Soll-Ist-Vergleich: der Schätzfaktor je Vorgangstyp

Der Plan/Ist-Vergleich dient im laufenden Projekt der Steuerung. Über mehrere Projekte wird er zum Lerninstrument: Tatsächliche geteilt durch geplante Dauer ergibt einen Faktor. Liegt er für einen Vorgangstyp in jedem Projekt über 1, steckt System im Schätzfehler. Das ist Kahnemans Außensicht, angewandt auf einzelne Vorgänge. Mit diesem Faktor korrigieren Sie neue Schätzungen, bevor sie ins Angebot gehen. Voraussetzung ist Vergleichbarkeit: Heißt ein Vorgang einmal „Ausführungsplanung Rohbau" und einmal „AP RB", erkennt keine Auswertung den Zusammenhang.

In Merlin Project blenden Sie in der Gliederung die Spalten Geplante Arbeit, Wirkliche Arbeit, Geplantes Ende und Wirkliches Ende ein. Für die Vergleichbarkeit sorgen einheitliche Vorgangsnamen oder ein benutzerdefiniertes Feld wie „Vorgangstyp" oder „Gewerk", das Sie im Inspektor unter Tags & Felder anlegen. Speichern Sie es in einer Projektvorlage oder in der Bibliothek, dann trägt es jedes neue Projekt von Anfang an. Über den MCP-Server liest die KI geplante und tatsächliche Werte je Vorgang.

In unserem Beispielarchiv

Die Genehmigung beim städtischen Bauamt dauerte im Schnitt doppelt so lang wie geplant, beim Landratsamt exakt wie geplant. Mit einem Pauschalwert für „Genehmigung" hätte das Büro beide Behörden falsch geschätzt. Diese externen Faktoren behandeln die nächsten beiden Abschnitte. Bemerkenswert ist der Faktor für die eigene Arbeit: Die Ausführungsplanung dauerte in jedem der zehn abgeschlossenen Projekte 13 bis 15 Prozent länger als geplant. Wer 1,15 aufschlägt, plant also mit dem gemessenen Normalfall.

Soll/Ist-Vergleich in Merlin Project

Der Strukturplan mit den Spalten Geplante Dauer und Erwartete Dauer: Für die Fensterlieferung waren 3 Wochen geplant, gebraucht hat Lehmann 1,35 Monate. Im unteren Bereich steht das Risiko dieses Vorgangs samt Gelernter Lektion.

Der Prompt zum Selbsttesten

Ich habe in Merlin Project zehn abgeschlossene Projekte geöffnet und für
die KI-Tools freigegeben. Lies aus jedem Projekt alle abgeschlossenen
Vorgänge mit geplanter und wirklicher Dauer. Fasse Vorgänge mit gleichem
Namen projektübergreifend zusammen und berechne je Vorgangstyp den Faktor
wirkliche geteilt durch geplante Dauer. Zeige mir eine Tabelle mit Anzahl
Projekte, mittlerem Faktor, kleinstem und größtem Wert. Sortiere nach
dem mittleren Faktor, die größten Abweichungen oben.

2. Lieferanten und Partner: Termintreue in Zahlen

Termine von Lieferanten und Partnern sind externe Abhängigkeiten: Sie liegen außerhalb Ihres Einflusses, und jede Verspätung trifft alle Nachfolger. Im Plan steht die zugesagte Lieferzeit, die Knowledgebase ergänzt die gelieferte. So wählen Sie Lieferanten und Nachunternehmer nach gemessener Termintreue und planen für jeden die Lieferzeit ein, die er tatsächlich braucht. Achten Sie auf den Nenner: Zwei Verspätungen bei zwei Aufträgen wiegen schwerer als zwei bei zwanzig, und erst die Zahl der Aufträge macht aus einem Eindruck eine Quote. Wie Sie Lieferanten von Anfang an steuern, beschreibt der Beitrag zum Beschaffungsmanagement.

In Merlin Project legen Sie externe Firmen als Ressourcen an oder tragen den Firmennamen in ein Feld „Lieferant" ein; so lässt sich jeder Liefervorgang einer Firma zuordnen. Verspätete Vorgänge bekommen einen Anhang vom Typ Problem mit Kategorie, Art und kurzer Beschreibung. Die Ansicht Anhänge listet alle Probleme eines Projekts. Die Knowledgebase braucht beides: den gemessenen Verzug aus den Ist-Werten und die Ursache aus dem Problem-Anhang.

In unserem Beispielarchiv

Fensterbau Lehmann lieferte bei jedem seiner sechs Aufträge zu spät. In den ersten drei Projekten stand das nur als Problem-Anhang im Plan, als Ärger im Einzelfall. Erst der Vergleich zeigt das Muster: acht bis zwölf Arbeitstage nach Zusage, während das Gebäude offen stand und Trockenbau und Estrich warteten. Das Büro wechselte zu Fenster Weber, der höchstens einen Tag nach Zusage lieferte. Bei der Statik lief es ähnlich: Ingenieurbüro Krause lieferte zweimal sechs Arbeitstage zu spät, Becker blieb in zehn Aufträgen im Plan.

Ein Problem-Anhang in Merlin Project

Die Insolvenz des Trockenbauers stand in keinem Register. Als Problem mit Kategorie, Art und Status bleibt sie trotzdem auswertbar, und die KI findet sie bei der Suche nach wiederkehrenden Ausfällen.

Der Prompt zum Selbsttesten

Lies aus allen freigegebenen Projekten die Vorgänge, an denen externe
Firmen beteiligt sind, mit geplantem und wirklichem Ende. Berechne je
Firma die Anzahl der Aufträge, den mittleren Verzug in Arbeitstagen und
den größten Verzug. Nimm die Problem-Anhänge an diesen Vorgängen dazu und
fasse die genannten Ursachen zusammen. Welche Firma ist über mehrere
Projekte hinweg unzuverlässig, und auf welcher Datenbasis beruht das?

3. Behörden und Fristen: Dauer je Stelle

Behördenverfahren liegen früh im Projekt, oft auf dem kritischen Pfad, und jeder Tag Verzug schiebt alles Folgende. Gesetze und Merkblätter nennen dazu Regelfristen, die mit der gelebten Bearbeitungszeit wenig zu tun haben. Wer die Regelfrist einplant, schätzt aus der Innensicht. Planen Sie Genehmigungen, Prüfungen und Vergabefristen stattdessen mit der gemessenen Bearbeitungszeit der zuständigen Stelle, vermeiden Sie den häufigsten Großverzug am Projektanfang.

In Merlin Project modellieren Sie Genehmigungen und Fristen als eigene Vorgänge. Wartezeiten, in denen nur das Amt arbeitet, legen Sie mit Dauer und ohne Zuweisung an, die zuständige Stelle notieren Sie in einem Feld „Behörde". Tragen Sie nach Abschluss das wirkliche Ende ein, auch ohne Arbeit am Vorgang; sonst fehlt der wichtigste Ist-Wert des Projekts. Welche Leistungsphasen und Fristen ein Architekturprojekt prägen, fasst der Leitfaden Projektmanagement in der Architektur zusammen.

In unserem Beispielarchiv

Das städtische Bauamt brauchte in fünf Projekten 59 bis 72 Arbeitstage, geplant waren 30 bis 40. Das Landratsamt hielt in vier Projekten exakt die geplanten 30. Mit einem gemeinsamen Wert für beide Behörden liegt ein Büro bei der Stadt um Wochen daneben oder verschenkt beim Landratsamt Reserve. Daraus folgt: Dauer je Behörde ansetzen. Öffentliche Vergaben folgen derselben Logik. Ein Nachprüfungsantrag kostete die Kita Sonnenschein 20 Arbeitstage; bei der Kita Regenbogen stimmte das Büro die Wertungsmatrix vorab mit der Vergabestelle ab, und der Antrag blieb aus.

Genehmigungsdauer im Plan

Im MFH Am Park plante das Büro 2 Monate für das Genehmigungsverfahren, das Bauamt brauchte 3,6. Das Risiko unten verbucht 32 Tage Verzögerung, die Gelernte Lektion nennt den Wert für das nächste Projekt: 65 Arbeitstage.

Der Prompt zum Selbsttesten

Suche in allen freigegebenen Projekten die Vorgänge zu Genehmigungen,
Prüfungen und Vergabefristen. Gib je Vorgang Projekt, zuständige Behörde
aus der Projektbeschreibung, geplante und wirkliche Dauer aus. Gruppiere
nach Behörde und nenne je Behörde die kürzeste, typische und längste
Dauer. Welchen Wert sollte ich für ein neues Projekt bei derselben
Behörde ansetzen?

4. Spannweiten: Drei-Punkt-Schätzung aus echten Daten

Die Drei-Punkt-Schätzung beschreibt einen Vorgang mit drei Werten: optimistisch (O), wahrscheinlich (M) und pessimistisch (P). Die PERT-Formel (O + 4M + P) / 6 verdichtet sie zu einem Erwartungswert und gewichtet M vierfach; den Hintergrund erklärt unser Leitfaden zu PERT-Diagrammen. Meist rät das Team die drei Werte. Mit einer Knowledgebase messen Sie sie: O als kürzesten beobachteten Wert, M als häufigsten, P als längsten. Wiederkehrende Vorgänge bekommen so eine belastbare Spannweite statt einer Zahl, die nur im Durchschnitt stimmt. Wie daraus eine Verteilung entsteht, zeigt der Guide zur Monte-Carlo-Simulation.

Merlin Project speichert je Vorgang eine Plandauer und einen Ist-Wert, eine native Drei-Punkt-Schätzung gibt es nicht. Legen Sie für O und P zwei benutzerdefinierte Felder an und füllen Sie sie in der Vorlage mit den Werten aus der Knowledgebase; die Plandauer bleibt M. Die KI liest alle drei Werte über den MCP-Server und simuliert damit, wie der Artikel Monte-Carlo-Simulation in Merlin Project zeigt.

In unserem Beispielarchiv

Mittelwert und PERT landen bei rund 66 Arbeitstagen; das Büro setzt seit 2024 65 an. Ein Einzelwert verschweigt allerdings, wie stark ein Vorgang schwankt. Beim städtischen Bauamt liegen 13 Arbeitstage zwischen kürzestem und längstem Verfahren, beim Landratsamt kein einziger. Reserve braucht nur der erste Fall. Die Spannweite von 59 bis 72 ist außerdem die Eingabe für eine Monte-Carlo-Simulation; mit gemessenen Werten ersetzt sie die Pauschalannahme „Plandauer plus minus 20 Prozent".

Der Prompt zum Selbsttesten

Berechne für jeden Vorgangstyp, der in mindestens drei freigegebenen
Projekten vorkommt, eine Drei-Punkt-Schätzung aus den wirklichen Dauern:
O als kürzesten, M als häufigsten und P als längsten Wert. Gib zusätzlich
den PERT-Erwartungswert (O + 4M + P) / 6 aus. Markiere Vorgangstypen mit
weniger als fünf Projekten als unsichere Datenbasis.

5. Puffer: Reserve an die Stellen mit Streuung

Ein Puffer schützt einen Termin vor Unsicherheit. Pauschal verteilt, etwa zehn Prozent je Vorgang, landet er an stabilen Vorgängen und fehlt an den schwankenden. Dazu kommt ein Verhaltenseffekt. Cyril Northcote Parkinson schrieb 1955 im Economist: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht." Wer jedem Vorgang Reserve gibt, sieht sie meist aufgebraucht. Eliyahu Goldratt zog daraus in „Critical Chain" (1997) die Konsequenz, Reserve aus den Vorgängen zu nehmen und gebündelt vor kritische Termine zu legen. Wie groß dieser Puffer sein muss und wo er hingehört, sagt die Knowledgebase: hinter die stark streuenden Vorgänge auf dem kritischen Pfad. Mit derselben Reserve halten Sie Termine dann öfter.

In Merlin Project legen Sie gebündelte Puffer als eigene Vorgänge ohne Zuweisung vor den Meilenstein, den sie schützen, und benennen sie eindeutig, etwa „Puffer Genehmigung". Im Projektverlauf sehen Sie dann, wie viel Reserve verbraucht ist. Wo der Netzplan von sich aus Luft hat, zeigen die Spalten Erwartete gesamte Pufferzeit und Erwartete freie Pufferzeit. Reicht die Reserve nicht für den Wunschtermin, helfen die Techniken aus dem Beitrag zu Fast Tracking, Crashing und Contouring.

In unserem Beispielarchiv

Pauschal verteilt fehlt die Reserve an der Genehmigung, die in den Daten bis zu 13 Arbeitstage schwankt; gezielt gesetzt sitzt sie dort, wo die Streuung sitzt. Die Größe eines Puffers folgt aus der Spannweite. Liegt ein Vorgang im Archiv zwischen 59 und 72 Arbeitstagen und Sie planen 66, brauchen Sie für hohe Termintreue rund sechs Tage Reserve dahinter. Bei einem Vorgang, der in zehn Projekten höchstens einen Tag abwich, sparen Sie sich den Aufschlag. Ob die Reserve insgesamt reicht, beantwortet eine Monte-Carlo-Simulation mit P80 oder P90.

Wo der Netzplan keine Luft hat

Die Spalte Erwartete gesamte Pufferzeit zeigt für das Genehmigungsverfahren 0 Tage. Wie alle Vorgänge auf dem kritischen Pfad hat es keine Luft: Jeder Tag Verzug schiebt das Projektende. Welcher davon einen gebündelten Puffer braucht, entscheidet erst die Streuung aus dem Archiv.

Der Prompt zum Selbsttesten

Lies den Plan des neuen Projekts aus dem aktuellen Dokument. Gleiche
jeden Vorgang auf dem kritischen Pfad mit den Spannweiten aus unserer
Knowledgebase ab, die ich dir als Datei gebe. Schlage vor, hinter welchen
Vorgängen ein gebündelter Puffer sitzen sollte und wie groß er sein muss,
damit der Endtermin mit etwa 80 Prozent Wahrscheinlichkeit hält. Nenne
Vorgänge, deren Plandauer schon Reserve enthält.

6. Jahreszeit und Rahmenbedingungen: Saisonfaktoren

Manche Abweichung hängt am Zeitpunkt eines Vorgangs. Im Bau bremsen Frost und Regen den Rohbau, im Winter trocknet Estrich langsamer; in der Softwareentwicklung wirken Urlaubszeiten oder Quartalsabschlüsse beim Kunden. Solche Einflüsse treffen mehrere Vorgänge zugleich, in der Monte-Carlo-Theorie heißt das Korrelation. Ein Saisonfaktor holt sie auf einfachste Weise in die Schätzung: Sie erkennen, welche Vorgänge zu bestimmten Jahreszeiten länger dauern, und verschieben sie oder planen den Aufschlag ein.

Über den wirklichen Start ordnet die KI jeden Vorgang in Merlin Project einer Jahreszeit zu. Wetterabhängige Trocknungs- und Wartezeiten modellieren Sie als eigene Vorgänge ohne Zuweisung, damit ihre Dauer messbar bleibt. Betriebsferien und Feiertage hinterlegen Sie in den Projekteinstellungen unter Kalender; sonst erscheinen Urlaubswochen in der Statistik als Verzug.

In unserem Beispielarchiv

Der Winter kostete jeden Rohbau Zeit, beim zuverlässigen Rohbauer 15 Prozent, bei Wagner 48. Wagner baute schon im Sommer ein Viertel langsamer als geplant. In einem Projekt stand der Rohbau wegen Frost 15 Arbeitstage still. Die Regel daraus: Rohbau nicht zwischen Dezember und Februar planen oder Winterbau mit Faktor und Kosten einpreisen. Das Wagner-Muster stand in keinem Risikoregister. Sichtbar wird es erst, wenn jemand die Ist-Werte nach Firma und Monat gruppiert.

Ein Winterrisiko im Rohbau

Die Decke über dem EG fiel in den Dezember. Das Risiko Frost und Schlechtwetter ist eingetreten, mit 7 Tagen Zeitverzug und 8.400 Euro Kosten. Mit Datum, Ist-Werten und Risiko liefert der Vorgang alles, was ein Saisonfaktor braucht.

Der Prompt zum Selbsttesten

Gruppiere alle abgeschlossenen Rohbau- und Trocknungsvorgänge der
freigegebenen Projekte nach Monat des wirklichen Starts und nach
ausführender Firma. Berechne je Gruppe den Faktor wirkliche zu geplanter
Dauer. Gibt es Monate oder Firmen, in denen dieselben Vorgänge deutlich
länger dauern? Welche Faktoren sollte ich für einen Rohbau im Januar
ansetzen?

7. Planungsaufwand und Kosten: was die eigene Leistung kostet

Kosten weichen an zwei Stellen ab: bei Fremdleistungen durch Nachträge und Preissteigerungen und bei der eigenen Arbeit. Die zweite Quelle übersehen viele, weil sie auf keiner Rechnung steht. Bei einem Pauschalhonorar trägt das Büro jede unterschätzte Stunde selbst; welche Vertragsform welches Risiko verteilt, erklärt der Beitrag zu Festpreis, T&M und Kostenerstattung. Im laufenden Projekt zeigt die Leistungswertanalyse die Abweichung, der Kostenentwicklungsindex CPI die Leistung je ausgegebenem Euro. Über abgeschlossene Projekte wird daraus ein Kalkulationsfaktor, und Angebote und Honorare spiegeln den Aufwand, den Ihr Team wirklich braucht.

Mit einem Stundensatz je Ressource berechnet Merlin Project aus geplanter und wirklicher Arbeit die Plan- und Ist-Kosten; wie Sie Kosten anlegen, zeigt das Lernkapitel Kosten. Die Kennzahlen der Leistungswertanalyse (PV, EV, AC, CPI, SPI) beziehen sich auf das Statusdatum aus den Projekteinstellungen. Für den projektübergreifenden Blick auf die Auslastung teilen sich alle Projekte einen Ressourcenpool. Zusätzlich liefert der MCP-Server zeitphasierte Werte für Kosten, Arbeit und Leistungswert, also den Verlauf über Wochen oder Monate.

In unserem Beispielarchiv

Das Büro unterschätzte seine Ausführungsplanung in jedem Projekt, im Normalfall um 15 Prozent. Über zehn Projekte summiert sich das auf 118 Arbeitstage oder 86.848 Euro bei einem Stundensatz von 92 Euro, die in keinem Honorar standen. In denselben Daten steckt ein zweites Muster: Lagen drei Projekte gleichzeitig in der Ausführungsplanung, stieg der Faktor auf 1,35 bis 1,37, und die Projektleitung meldete Überlastung. Für die Kalkulation heißt das 15 Prozent Aufschlag auf die eigene Planung und höchstens zwei Projekte parallel in dieser Phase. Bei den Fremdkosten fällt die Baukostensteigerung 2021 und 2022 auf: Sie traf jedes Projekt mit Start in diesen Jahren, mit 20.000 bis 137.800 Euro über der Kostenberechnung.

Planungsaufwand im Soll/Ist-Vergleich

Die Spalten zeigen geplante und wirkliche Arbeit und Kosten. Die LP5 im MFH Am Park kostete 69.920 statt 51.520 Euro. Den Grund nennt das Problem unten: Projektleitung überlastet.

Der Prompt zum Selbsttesten

Lies aus allen freigegebenen Projekten geplante und wirkliche Arbeit
sowie geplante und wirkliche Kosten je Leistungsphase. Berechne je Phase
den Faktor wirklich zu geplant und den Mehraufwand in Euro. Prüfe
außerdem anhand der wirklichen Termine, wie viele Projekte gleichzeitig
in der Ausführungsplanung lagen, und ob der Faktor dann steigt.

8. Risiken und Probleme: Wahrscheinlichkeiten kalibrieren

Ein Risikoregister enthält Schätzungen: Wie wahrscheinlich tritt ein Risiko ein, was kostet es dann? Am Projektende steht fest, was passiert ist. Der Abgleich beider heißt Kalibrierung. Bewertet ein gut kalibriertes Team Risiken mit 30 Prozent, treten davon etwa drei von zehn ein. Weicht die Quote stark ab, lenkt das Register die Aufmerksamkeit an die falschen Stellen. Mit kalibrierten Werten startet das nächste Register mit den Risiken, die bei Ihnen tatsächlich eintreten. Probleme ergänzen das Bild um Ereignisse, die niemand als Risiko erwartet hatte.

In Merlin Project hält der Anhangstyp Risiko neben Wahrscheinlichkeit und Auswirkung vier Felder für den Ausgang: Ist eingetreten, Kosten, Verzögerung und Gelernte Lektionen. Kosten und Verzögerung dokumentieren; in Plan oder Budget rechnet Merlin sie nicht ein. Pflegen Sie die Felder spätestens zum Projektabschluss, sonst bleibt das Register eine Liste von Befürchtungen. Ungeplante Störungen erfassen Sie als Problem. Die Grundlagen erklärt das Lernkapitel Risikomanagement, die Steuerung im laufenden Projekt der Guide zum Risikomanagement mit Merlin Project.

In unserem Beispielarchiv

Das Register reift mit der Zeit. Die ersten vier Projekte enthalten zusammen sieben Risiken; den Fensterverzug führten sie nur als Problem. Ab dem fünften Projekt übernahm das Büro die Lehren der Vorprojekte als Risiken mit Maßnahmen. Die Kalibrierung brachte zwei Korrekturen. Das Baugrundrisiko stand in sechs Neubauten mit 30 Prozent im Register und trat einmal ein, bei einem Grundstück mit Altbestand; für Neubaugebiete sank es auf 15 Prozent. Den Lieferverzug bei Lehmann, der bei allen drei Aufträgen eintrat, löste ein Lieferantenwechsel. Ein drittes Muster, der langsame Rohbauer im Winter, tauchte in keinem Register auf. Eine Knowledgebase braucht deshalb beide Quellen: dokumentierte Risiken und reine Abweichungen in den Ist-Werten.

Ein geschlossenes Risiko

Lieferverzug Fenster, eingetreten mit 12 Tagen Zeitverzug und 10.800 Euro Kosten. Erst die Abschlussfelder, hier als Spalten im Register, machen aus einer Befürchtung einen Datenpunkt für die Kalibrierung.

Der Prompt zum Selbsttesten

Lies aus allen freigegebenen Projekten die Risiko-Anhänge mit Titel,
Wahrscheinlichkeit, Ist eingetreten, Kosten, Verzögerung und Gelernte
Lektionen sowie alle Problem-Anhänge. Fasse gleichartige Risiken
projektübergreifend zusammen. Vergleiche je Risiko die geschätzte
Wahrscheinlichkeit mit der beobachteten Quote. Liste außerdem Probleme,
die mehrfach auftraten, aber in keinem Register als Risiko standen.
Erstelle daraus ein Startregister für ein neues Projekt mit
vorgeschlagener Wahrscheinlichkeit, typischer Wirkung und bewährter
Maßnahme.

9. Lessons Learned: Regeln mit Geltungsbereich

Lessons Learned liefern die Begründung zu den Zahlen: warum etwas länger dauerte und was beim nächsten Mal hilft. Ihr Wert hängt an zwei Dingen. Das erste ist die Haltung im Abschlussgespräch. Norman Kerth formulierte 2001 dafür die „Prime Directive" der Retrospektive: „Was wir auch herausfinden, wir verstehen und glauben fest daran, dass alle die bestmögliche Arbeit geleistet haben, gemessen an ihrem damaligen Wissen, ihren Fähigkeiten, den verfügbaren Ressourcen und der jeweiligen Lage." Wer Schuldige sucht, bekommt keine ehrlichen Antworten. Das zweite ist der Geltungsbereich: Eine Lehre aus einer Altbausanierung gilt nicht automatisch für einen Neubau, und ohne Angabe, wofür sie gilt, bleibt sie eine Anekdote. Mit Geltungsbereich finden auch Kolleginnen und Kollegen die Lehre, die nicht dabei waren. Den formalen Rahmen beschreibt der Projektabschluss.

In Merlin Project hängen Sie an den Meilenstein „Projektabschluss" einen Anhang vom Typ Information mit den Lessons Learned: was schiefging, was funktioniert hat und für welche Projektart die Lehre gilt. Lehren zu einzelnen Risiken gehören in deren Feld Gelernte Lektionen, dort bleiben sie mit Häufigkeit, Kosten und Verzögerung verbunden. Eine eigene Art „Lessons Learned" für Informationen legen Sie in den Projekteinstellungen unter Wertelisten an.

In unserem Beispielarchiv

Wie stark eine Lehre mit Geltungsbereich wirkt, zeigen zwei Altbausanierungen. Im Gründerzeithaus fanden die Handwerker bei der Entkernung Asbest: 22 Arbeitstage Baustopp, 38.000 Euro Nachtrag. Die Lehre lautete „Schadstofferkundung vor der Ausschreibung, gilt für jede Sanierung im Bestand". Beim späteren Fachwerkhaus ließ das Büro die Erkundung vorab durchführen; die Sanierung stand damit schon im Leistungsverzeichnis.

Bei Sonderwünschen privater Bauherren lief es ähnlich. Das Doppelhaus Am Weinberg verlor durch Änderungen im Ausbau 15 Arbeitstage und 37.500 Euro, ein späteres Einfamilienhaus bekam deshalb einen Bemusterungsstichtag vor Ausbaubeginn.

Lessons Learned am Projektabschluss

Ein Information-Anhang am Meilenstein Projektabschluss hält fest, was schiefging und was funktioniert hat. Über den MCP-Server liest die KI ihn zusammen mit den Ist-Werten aus.

Der Prompt zum Selbsttesten

Lies die Information-Anhänge am Meilenstein „Projektabschluss" und das
Feld Gelernte Lektionen aller Risiken aus den freigegebenen Projekten.
Formuliere daraus übertragbare Regeln. Gib je Regel an, für welche
Projektart, Leistungsphase oder welches Gewerk sie gilt, in wie vielen
Projekten sie belegt ist und auf welche Projekte sie sich stützt. Lass
Einzelfälle weg, die nur einmal vorkamen und keine Ursache nennen.

Vom Archiv zur Knowledgebase

Aus den neun Auswertungen entsteht die Knowledgebase. Damit das Team sie nutzt, braucht sie eine feste Form, die nach jedem Projekt wächst. Bewährt hat sich ein Dokumentprojekt mit fünf Kapiteln, das die KI aus den Merlin-Projekten befüllt:

Projekt-Knowledgebase/
├── index.adoc                 Wofür, Datenstand, Nutzung
├── 1-projekte/                ein Steckbrief je abgeschlossenem Projekt
├── 2-kennzahlen/              Schätzfaktoren, Spannweiten, Kosten
├── 3-risiken-und-learnings/   Risikokatalog, Lessons Learned, Startregister
├── 4-vorlagen/                Prompts und Checklisten
└── 5-methodik/                Datenbasis, Pflegeregeln, Glossar

Der Steckbrief je Projekt hält Projekttyp, Zeitraum, Termin und Kosten im Plan-Ist-Vergleich fest, dazu die fünf größten Abweichungen, eingetretene Risiken und Lessons Learned. Kapitel 2 und 3 rechnet die KI aus allen Steckbriefen, und jeder Wert verweist auf die Projekte, aus denen er stammt. Als AsciiDoc-Dateien exportiert adoc Studio die Kapitel als Website, deren Navigation aus Ordnern und Dateien entsteht; eine fertige Struktur zum Anpassen bietet die Projektvorlage für Dokumentation. Weil die Knowledgebase Kundennamen, Kosten und Termine enthält, gehört sie auf einen geschützten Server.

Nach jedem abgeschlossenen Projekt kommt ein Steckbrief hinzu, die KI rechnet Kapitel 2 und 3 neu, und Sie exportieren die Website erneut.

Was Sie ab heute pflegen sollten

Ob Ihr Archiv in einem Jahr Muster zeigt oder Lücken, entscheiden fünf Gewohnheiten. Wo Sie heute stehen, zeigt der Rechner.

1. Ist-Werte zeitnah erfassen: wirklicher Start, wirkliches Ende und wirkliche Arbeit für jeden abgeschlossenen Vorgang, auch für Wartezeiten und Genehmigungen.
2. Vorgänge klassifizieren, am einfachsten über ein Feld für den Vorgangstyp oder Tags in einer gemeinsamen Projektvorlage. Feste Vorgangsnamen aus der Vorlage leisten dasselbe, solange niemand sie abwandelt.
3. Externe Partner zuordnen, als Ressource oder Feld, damit sich ihre Termintreue messen lässt.
4. Risiken schließen mit Ist eingetreten, Kosten, Verzögerung und Gelernte Lektionen, spätestens zum Projektabschluss.
5. Lessons Learned mit Geltungsbereich als Information-Anhang am Meilenstein „Projektabschluss".

Grenzen der Auswertung

Eine Knowledgebase liefert Erfahrungswerte, die mit jedem Projekt genauer werden. Vier Grenzen gehören dazu.

• Kleine Stichproben. Zwei verspätete Lieferungen bei zwei Aufträgen sind ein Hinweis. Lassen Sie die KI zu jedem Wert die Zahl der Projekte nennen, und behandeln Sie Werte aus weniger als fünf Projekten als vorläufig.
• Korrelation ohne Ursache. Ob der Rohbauer im Winter wegen des Wetters, seiner Auslastung oder beidem langsamer war, sagen die Zahlen allein nicht. Die Begründung steht in den Lessons Learned.
• Veränderte Bedingungen. Ein neues Team, ein neues Verfahren beim Bauamt oder ein anderer Markt entwerten alte Werte. Datieren Sie jeden Wert und gewichten Sie jüngere Projekte stärker.
• Nur Lesezugriff. Der MCP-Server von Merlin Project liest derzeit nur. Faktoren, Puffer und Startregister übertragen Sie selbst in den neuen Plan. Cloud-Clients wie Claude schicken die abgefragten Plandaten an den Anbieter; ein lokales Modell hält sie auf Ihrem Mac.

Auf dieser Knowledgebase baut der nächste Schritt auf. Mit dem Startregister aus Kapitel 3 und den Spannweiten aus Kapitel 2 steuern Sie die Risiken des laufenden Projekts; wie das in Merlin Project funktioniert, zeigt der Guide zum Risikomanagement mit Merlin Project und KI.

Haben Sie Fragen zu diesem Blogartikel oder möchten darüber diskutieren, freuen wir uns auf Ihren Beitrag bei uns im Forum.