Katalog / Prognose- und Vorhersage-Anwendungsfälle / PRED-023

Prognose von Terminverzug und Kostenüberschreitung in Projekten

Aus historischen Projektterminplänen und ihren tatsächlichen Ergebnissen lernen, um PMOs, Auftragnehmern und öffentlichen Auftraggebern probabilistische Fertigstellungstermine und Kostenspannen zu liefern, dazu die Vorgänge, die am wahrscheinlichsten verzögert werden, und die Treiber dahinter.

Die meisten Projektpläne sind optimistisch, und der genehmigte Terminplan ist selten der, der geliefert wird. KI-Modelle, die auf tausenden historischen Terminplänen und ihren realen Ergebnissen trainiert wurden, prognostizieren für ein laufendes oder geplantes Projekt eine Wahrscheinlichkeitsverteilung von Fertigstellungsterminen und Kosten, markieren die Vorgänge, die wahrscheinlich verzögert werden, und erklären warum. Der Nutzen sind früheres Eingreifen, eine bessere Dimensionierung der Reserven und eine ehrlichere Portfoliosteuerung statt einer einzelnen „grün/gelb/rot"-Meinung.

Problem & Nutzen

  • Wer: PMOs, Auftragnehmer, Bauherren und öffentliche Auftraggeber von Investitionsprojekten (Hochbau, Schiene, Energie, Anlagenbau) sowie IT-/Softwareentwicklungsorganisationen.
  • Heute: ein deterministischer Terminplan mit kritischem Pfad, ein von Hand geführtes Risikoregister und manchmal eine Monte-Carlo-Simulation mit von Experten geschätzten Dauern. Die „Innensicht"-Verzerrung nach Kahneman und Tversky führt dazu, dass Planer sich auf die Besonderheiten ihres eigenen Projekts konzentrieren und unterschätzen, wie ähnliche Projekte tatsächlich endeten; die Referenzklassenprognose (die „Außensicht": Vergleich mit einer Verteilung vergleichbarer früherer Projekte) wurde entwickelt, um das zu korrigieren, und wird seit 2004 in britischen Leitlinien sowie bei Projekten wie Crossrail verwendet [2]. Die Straßenbahn in Edinburgh ist das dokumentierte Beispiel: Prognose 320 Mio. £, Eröffnung drei Jahre zu spät bei 776 Mio. £ [2].
  • KI-Nutzen: die Außensicht automatisch aus vielen Terminplänen lernen, auf Vorgangsebene, und mit jeder Fortschrittsmeldung aktualisieren. nPlan gibt an, seine Modelle seien auf 750.000 historischen Terminplänen trainiert, die über 2 Billionen US-Dollar Bauausgaben repräsentieren, und nennt Kunden wie BAM, Network Rail, HS2, Skanska, Kier und Costain; das sind Herstellerangaben, nicht unabhängig überprüft [1]. Betrachten Sie jede genannte Genauigkeit als unbewiesen, bis Sie sie an Ihren eigenen abgeschlossenen Projekten rückwirkend getestet haben.

Varianten

  • Investitionsprojekte (Bau, Infrastruktur): Prognose auf Basis des Terminnetzwerks aus P6-/MS-Project-Exporten; die Perspektiven von Auftragnehmer und Auftraggeber unterscheiden sich (Nachträge, Vertragsstrafen).
  • Portfoliosteuerung / PMO: Risiken über hunderte Projekte aggregieren, Reserven verteilen, Frühwarn-Dashboards.
  • IT- und Softwareprojekte: Release-Termine und Budgetverbrauch aus Ticket-Historie, Velocity und Änderungsraten des Umfangs prognostizieren; Tabellen- und Zeitreihenmodelle statt Terminnetzwerken.
  • Vorab- / Angebotsphase: Prognose aus dem vorgeschlagenen Basisplan und den Leistungsunterlagen (kombinierbar mit DOC-030 und DOC-015); einige Anbieter erzeugen Terminplanentwürfe aus dem Leistungsumfang.
  • Öffentliche Auftraggeber: Benchmarking mit Referenzklassen für Budgetfreigaben und geförderte Projekte.
  • Private Nutzung: Hausrenovierung oder Bauvorhaben: einfache Puffer nach Referenzklassen; kein eigener Produktmarkt.

So funktioniert es

  1. schedule exports (XER/PMXML/MPP) + cost/EVM + project metadata + progress updates
  2. parsing & schedule-quality checks (logic, constraints, durations)
  3. feature engineering (activity type, float, predecessors, trade, season, location, contractor)
  4. models: activity-duration distributions + project-level outcome model
  5. probabilistic simulation over the network (P50/P80/P90 finish, cost range)
  6. driver attribution (what pushes the date) + LLM-written narrative
  7. human review by planner/PMO
  8. mitigation actions, contingency decision
  9. new actuals fed back
  10. recalibration
  • Dauer-/Ergebnismodelle: Gradient-Boosted Trees oder Tabellen-Foundation-Modelle (z. B. TabPFN) für Vorgangs- und Projektergebnisse; Quantil- oder Conformal-Verfahren für kalibrierte Spannen; Zeitreihen-Foundation-Modelle wie Chronos-2 für Burn-down- und S-Kurven-Prognosen [5][7].
  • Netzwerksimulation: Die vom Modell vorhergesagten Dauerverteilungen werden per Monte-Carlo durch das Vorranggraphen-Netzwerk propagiert, sodass Kritikalität und Verzugsrisiko je Vorgang abgeleitet statt geraten werden.
  • LLMs erzeugen die Prognose nicht; sie fassen Treiber zusammen, lesen Risikoregister und Leistungstexte und entwerfen die Vorlage für den Lenkungsausschuss.
  • Mensch-in-der-Schleife (Human-in-the-Loop): Planer prüfen die Logik und genehmigen Änderungen am Basisplan; die Prognose ist beratend, und das PMO entscheidet über Reserve und Gegenmaßnahmen.

Datenaufbereitung

Die Prognose braucht den Basisterminplan und den Kostenplan, Fortschrittsmeldungen, Nachträge, Istkosten, Ressourcendaten und idealerweise eine Historie abgeschlossener Projekte mit ihrem Endergebnis. In einem KMU liegt das in Excel-Plänen, MS-Project- oder Primavera-Dateien, den Kostenstellen des ERP, Bautagebüchern und E-Mails. Typische Lücken sind überschriebene Basispläne, uneinheitliche Projektstrukturpläne zwischen Projekten, Kostenbuchungen ohne Projektbezug und Erfahrungswissen, das nur in den Köpfen der Mitarbeitenden existiert.

Schritte der Aufbereitung: die Quellen inventarisieren (PREP-001, PREP-003), ERP- und Terminplandaten exportieren (PREP-005), Tabellenkalkulationen in saubere Tabellen mit festen Spalten umbauen (PREP-011), eine einheitliche Projekt- und Kostenstellenstruktur samt Glossar festlegen (PREP-012) und Ergebnis-Labels wie „verspätet abgeschlossen" aus früheren Projekten markieren (PREP-020). Stellen Sie mit Fachexperten einen Testdatensatz abgeschlossener Projekte zusammen (PREP-018).

Grober Aufwandsanteil: 50 bis 60 Prozent des Projekts, weil die Historie knapp und uneinheitlich ist; bei weniger als 20 abgeschlossenen Projekten beginnen Sie mit Referenzklassen- und Monte-Carlo-Methoden statt mit maschinellem Lernen. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

  • KMU: Weg B. Produkte sind preislich und funktional auf Investitionsprogramme ausgelegt, während die Daten eines KMU in Excel-Terminplänen und eigenen Werkzeugen liegen; ein kleines Modell auf Cloud-KI-Diensten, gespeist aus den eigenen Projektdaten, passt besser.
  • Großunternehmen: Weg B. Projektdaten sind strategisch und verteilen sich auf mehrere Systeme (ERP, Terminplanung, Kostenkontrolle), daher ist der Aufbau auf Cloud-KI-Diensten oder einer internen Plattform besser als ein festes Produkt.
  • Entwickler: Weg C. Bibliotheken für Monte-Carlo und Gradient Boosting laufen auf HW1 und geben volle Kontrolle über die Prognoselogik.
  • Öffentlicher Sektor: Weg C. Projektdaten öffentlicher Gebäude und Infrastruktur sollten unter souveräner Kontrolle bleiben, und offene Werkzeuge vermeiden Abhängigkeit vom Anbieter bei Ausschreibungen.

Weg A — Kaufen (Standardsoftware)

  • KI-basiertes Terminrisiko: nPlan (UK; Produkte Portfolio, Decision Intelligence, Insights und Schedule Studio) [1].
  • Etablierte Terminplanungs-/Risikosuiten: Oracle Primavera Cloud und Primavera Risk Analysis, Safran Risk (Safran Software Solutions, Norwegen), Deltek Acumen, InEight und ALICE Technologies (in der Recherche als relevant genannt; aktuelle KI-Funktionen je Anbieter prüfen). Bau-ERP-/5D-Plattformen wie RIB iTWO (Stuttgart) decken Terminplanung und Kosten in einem Modell ab.
  • Prüfen: Import Ihrer nativen Dateien, ob das Modell auf vergleichbaren Projekten trainiert ist, EU-Hosting, Umgang mit Ihren Daten (werden sie zum Training eines gemeinsamen Modells genutzt?), Erklärbarkeit je Vorgang.
  • Wählen Sie A, wenn: Sie viele Projekte mit P6-/MS-Project-Terminplänen betreiben und Ergebnisse in Wochen wollen.

Weg B — Auf Cloud-KI-Diensten aufbauen

  • Terminpläne mit MPXJ parsen (liest XER, PMXML, MPP und Primavera Cloud; LGPL) [3], in einem Data Warehouse speichern, mit AutoML in einer europäischen Cloud-Region trainieren (AutoGluon oder verwaltete ML-Dienste) und eine LLM-API für Texte und das Lesen des Risikoregisters ergänzen.
  • Monatliche Prognoseläufe mit einer Workflow-Engine orchestrieren; in Power BI oder einem PMO-Portal veröffentlichen.
  • Wählen Sie B, wenn: Sie einige hundert abgeschlossene Projekte besitzen und ein auf Ihre Vertragsarten zugeschnittenes Modell wollen.

Weg C — Selbst betreiben (Open Source)

  • Stack: MPXJ zum Parsen [3], AutoGluon (Apache 2.0) für Tabellen- und Zeitreihenmodelle [6], Chronos-2 (Apache 2.0, 120 Mio. Parameter) für Zeitreihenprognosen [5], LightGBM/CatBoost, eine Monte-Carlo-Engine in Python, optional ein kleines Open-Weight-LLM für Zusammenfassungen. Hinweis: Der TabPFN-Code steht unter Apache 2.0, aber aktuelle Modellgewichte tragen nicht kommerzielle Lizenzen; die kommerzielle Nutzung braucht eine Enterprise-Lizenz [7].
  • Hardware: HW1 (CPU-Server) reicht für Training und Simulation; HW2 nur, wenn ein LLM ergänzt wird.
  • Wählen Sie C, wenn: Projektdaten vertraulich sind (verteidigungsnah, kritische Infrastruktur, Angebotsdaten) oder das Unternehmen nicht verlassen dürfen.

Weg D — Eigenes Training

  • Lohnt sich für Bauherren oder Auftragnehmer mit einem großen, einheitlichen Archiv (mehrere hundert bis tausende abgeschlossene Projekte mit Basis- und Ist-Terminen). Erfordert eine saubere Zuordnung von Vorgangscodes (PSP/Gewerke-Taxonomie), Snapshots des Basisplans und Istdaten; die Hauptarbeit ist Datenengineering, nicht Modellierung. Graph Neural Networks über das Terminnetzwerk sind eine Forschungsrichtung; Bäume auf konstruierten Merkmalen erzielen bei kleinen Datenmengen meist vergleichbare Ergebnisse.

Stand der Technik (2026)

  • Lernen der Außensicht im großen Maßstab: Anbieter trainieren auf gepoolten historischen Terminplänen und berichten, dass der Prognosefehler sinkt, wenn mehr Terminpläne hinzukommen [1]; unabhängige öffentliche Benchmarks sind selten, daher ist ein eigener Rückwärtstest an abgeschlossenen Projekten (Prognose bei 25/50/75 % Fortschritt gegen tatsächliche Fertigstellung) die verlässliche Bewertung.
  • Foundation-Modelle für Tabellen und Zeitreihen (TabPFN, Chronos-2) liefern brauchbare Prognosen mit wenigen gelabelten Projekten und senken die Datenhürde für mittelgroße Organisationen [5][7].
  • Generative Terminplanentwürfe aus Leistungsunterlagen entstehen in Produkten [1]; die Qualitätskontrolle bleibt manuell.
  • Grenzen und Fehlerbilder: Seltene, einmalige Großprojekte haben wenige echte Vergleichsfälle; Terminpläne mit schlechter Logik erzeugen unbrauchbare Prognosen; Modelle lernen aus vergangenem Verhalten, einschließlich schlechter Praxis; Prognosen lassen sich manipulieren, sobald sie Anreize oder Boni steuern; kausale Aussagen („diese Ursache verzögert um x Tage") erfordern kausale Methoden, nicht nur Merkmalswichtigkeit; Fortschrittsdaten werden oft verspätet oder zu optimistisch gemeldet.

Gemeinsame Bausteine & Kombinationen

  • Gemeinsamer Stack (tabular-ml + time-series + simulation): PRED-024 (prädiktives Prozessmonitoring auf Ereignisprotokollen, gleiche Modellierung auf Fallebene), PRED-016 (Cashflow-Prognose, gespeist aus der Kostenprognose), PRED-018 (Prognose der Lieferzeit für Materiallieferungen), PRED-011 (Ressourcenbedarf).
  • Vorgelagerte Daten: DOC-030 (Mengenermittlung und Kostenschätzungen), DOC-015 (Ausschreibungsanforderungen), ROBO-009 (visuelle Fortschrittsmessung als Istdaten), ANOM-011 (Risikosignale von Lieferanten), OPT-002 (Produktionsplanung).
  • Hardware und Werkzeuge: Server der CPU-Klasse und ein Data Warehouse; derselbe AutoML-/Zeitreihen-Stack und dieselbe Workflow-Engine (AGENT-002) bedienen mehrere PRED-Anwendungsfälle.
  • Datenpipeline: Terminplan-Parser (MPXJ), ein Projekt-Data-Mart mit Basisplänen und Istdaten sowie eine gemeinsame PSP-/Vorgangstaxonomie sind wiederverwendbare Bausteine.

Aufwand, Kosten & Kennzahlen

  • Weg A: Wochen bis zur Einführung; Abopreise je Projekt oder Portfolio, typischerweise auf Großunternehmensniveau.
  • Weg B: 3–6 Monate inkl. Datenaufbereitung (größter Kostenblock) und PMO-Integration.
  • Weg C: ähnlicher Aufwand wie B plus bescheidene Infrastruktur.
  • Weg D: 6–12 Monate, überwiegend Datenbereinigung und Zuordnung der Taxonomie.
  • Kennzahlen: rückwirkend getesteter Prognosefehler von Fertigstellungstermin und Endkosten an festen Fortschrittspunkten; Kalibrierung von P80 (sollte in etwa 20 % der Fälle überschritten werden); Vorlaufzeit zwischen Warnung und tatsächlichem Verzug; Anteil der markierten Vorgänge, die tatsächlich verzögert wurden; verbrauchte Reserve gegenüber Prognose; Anzahl ausgelöster Gegenmaßnahmen.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsführung und dem Projektcontrolling, die festlegen, welcher Prognose für Entscheidungen vertraut wird. Projektleiter sind die Hauptnutzer und zugleich die Quelle der Daten, binden Sie sie daher von Anfang an ein; wenn sie fürchten, dass die Prognose zu ihrer Beurteilung dient, sinkt die Qualität der Meldungen. Die IT und die Datenverantwortlichen (Controlling, Bauleiter) stellen Exporte und Zugriffsrechte bereit. Lieferanten müssen unter Umständen vertraglich Fortschrittsdaten teilen. Die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte prüft Ressourcen- und Zeiterfassungsdaten, die personenbezogen sind; eine DSFA ist meist nicht nötig, wenn Prognosen auf Projektebene bleiben.

Betriebsrat: kommt darauf an. Prognosen auf Projektebene allein lösen keine Mitbestimmung aus, aber die Verknüpfung mit individuellen Stunden oder Leistungen kann unter § 87 Abs. 1 Nr. 6 BetrVG fallen; informieren Sie den Betriebsrat rechtzeitig nach § 90 Abs. 1 Nr. 3. Öffentliche Auftraggeber beteiligen den Personalrat.

Pilotieren Sie auf zwei oder drei laufenden Projekten im Schattenbetrieb und vergleichen Sie die Prognose an jedem Meilenstein mit der Realität. Typische Bedenken sind „die Prognose wird gegen mich verwendet" und „ein Algorithmus kann meine Baustelle nicht kennen". Begegnen Sie ihnen, indem Sie Prognosen für frühe Unterstützung statt für Schuldzuweisung nutzen, die Treiber hinter jeder Warnung zeigen und Entscheidungen über Umplanung bei der Projektleitung belassen. Fördern Sie die KI-Kompetenz durch einen kurzen Workshop (KI-Verordnung Art. 4). Siehe GUIDE-008, GUIDE-009 und GUIDE-004.

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): meist minimales Risiko, da die Prognose von Projektterminen und -kosten nicht in Anhang III steht. Relevant wird sie, wenn (a) das System eine Sicherheitskomponente bei der Verwaltung kritischer Infrastruktur ist oder (b) die Ausgaben genutzt werden, um Aufgaben zuzuweisen, einzelne Beschäftigte zu überwachen oder zu bewerten, was Anhang III Nr. 4 (Beschäftigung und Management der Arbeitnehmer) entspricht [4]. Halten Sie Prognosen auf Vorgangs-/Projektebene und schließen Sie individuelle Leistung aus. KI-Kompetenz (Art. 4) gilt.
  • DSGVO: Terminpläne enthalten überwiegend Unternehmensdaten, aber Ressourcennamen, Zeiterfassungen und Daten von Personen bei Auftragnehmern sind personenbezogene Daten; die Mitbestimmung des Betriebsrats in Deutschland (BetrVG § 87) greift, wenn die Leistung von Beschäftigten berührt wird.
  • Handels-/Vertragsrecht: Prognosen können in Verzugsansprüchen zum Beweismittel werden; versionieren und archivieren Sie sie. Gepoolte Anbietermodelle werfen Vertraulichkeitsfragen auf; verhandeln Sie die Bedingungen der Datennutzung.
  • Governance-Risiken: Prognose als Zielvorgabe (Goodhart-Effekt), Scheingenauigkeit, Automatisierungsverzerrung. Gegenmaßnahmen sind Rückwärtstests, Spannen statt Einzeldaten, dokumentierte Annahmen und Freigabe durch die Planer.

Erste Schritte

  1. Inventarisieren Sie abgeschlossene Projekte mit Basis- und Ist-Terminen; prüfen Sie den Export von XER-/MPP-Dateien und einheitliche Vorgangscodes.
  2. Führen Sie einen Rückwärtstest durch: Prognose abgeschlossener Projekte bei 50 % Fortschritt, mit einer einfachen Referenzklassenmethode als Vergleichsmaßstab.
  3. Pilotieren Sie ein oder zwei Anbieterwerkzeuge (Weg A) an 5–10 historischen und 2–3 laufenden Projekten und vergleichen Sie mit Ihrer eigenen Monte-Carlo-Simulation.
  4. Legen Sie die Governance fest: wer die Prognose verantwortet, wie P80 in die Reserve einfließt, und schließen Sie Überwachung auf Einzelpersonenebene aus.
  5. Etablieren Sie einen monatlichen Zyklus: Istdaten aktualisieren, neu prognostizieren, die zehn Vorgänge mit dem höchsten Verzugsrisiko im PMO-Termin besprechen.

Quellen

  1. nPlan — company and product site (750,000 schedules, customers, products) — https://www.nplan.io/
  2. Wikipedia — Reference class forecasting (Kahneman/Tversky, Flyvbjerg/COWI, Edinburgh tram, Crossrail) — https://en.wikipedia.org/wiki/Reference_class_forecasting
  3. MPXJ — project schedule file library (XER, PMXML, MPP; LGPL) — https://www.mpxj.org/
  4. AI Act Explorer — Annex III high-risk AI systems — https://artificialintelligenceact.eu/annex/3/
  5. Amazon Science — Chronos forecasting models incl. Chronos-2 (Apache-2.0) — https://github.com/amazon-science/chronos-forecasting
  6. AutoGluon — AutoML for tabular and time-series data (Apache-2.0) — https://github.com/autogluon/autogluon
  7. Prior Labs — TabPFN tabular foundation model, licences and limits — https://github.com/PriorLabs/TabPFN