Project schedule & cost-overrun risk forecasting

Most project plans are optimistic, and the schedule that was approved is rarely the one that is delivered. AI models trained on thousands of historical schedules and their real outcomes forecast, for a running or planned project, a probability distribution of finish dates and costs, flag the activities that are likely to slip and explain why. The benefit is earlier intervention, better contingency sizing and more honest portfolio steering, rather than a single "green/amber/red" opinion.

Problem & value

• Who: PMOs, contractors, owners and public clients of capital projects (building, rail, energy, plant engineering), and IT/software delivery organisations.
• Today: a deterministic critical-path schedule, a hand-built risk register, and sometimes a Monte Carlo simulation with durations estimated by experts. Kahneman and Tversky's "inside view" bias means planners focus on the specifics of their own project and under-weigh how similar projects actually ended; reference class forecasting (the "outside view": compare against a distribution of comparable past projects) was developed to correct this and has been used in UK guidance since 2004 and on projects such as Crossrail [2]. The Edinburgh tram line is the documented example: forecast £320m, opened three years late at £776m [2].
• AI value: learning the outside view automatically from many schedules, at activity level, and updating it with every progress update. nPlan states that its models are trained on 750,000 historical schedules representing over $2tn of construction spend, and names customers including BAM, Network Rail, HS2, Skanska, Kier and Costain; these are vendor claims, not independently verified [1]. Treat any quoted accuracy as unproven until you back-test on your own completed projects.

Variants

• Capital projects (construction, infrastructure): schedule-network forecasting from P6/MS Project exports; contractor and client perspectives differ (claims, liquidated damages).
• Portfolio steering / PMO: aggregate risk across hundreds of projects, contingency allocation, early-warning dashboards.
• IT and software projects: forecast release dates and budget burn from ticket history, velocity and scope-change rates; tabular and time-series models rather than schedule networks.
• Pre-tender / bid phase: forecast from the proposed baseline and scope documents (combine with DOC-030 and DOC-015); some vendors generate draft schedules from scope.
• Public clients: reference-class benchmarking for budget approval and grant projects.
• Private use: home renovation or building projects: simple reference-class buffers; no dedicated product market.

How it works

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

• Duration/outcome models: gradient-boosted trees or tabular foundation models (e.g. TabPFN) for activity and project outcomes; quantile or conformal methods for calibrated ranges; time-series foundation models such as Chronos-2 for burn-down and S-curve forecasts [5][7].
• Network simulation: model-predicted duration distributions are propagated through the precedence network by Monte Carlo, so criticality and slip-risk per activity are derived, not guessed.
• LLMs do not produce the forecast; they summarise drivers, read risk registers and scope text, and draft the steering-committee note.
• Human-in-the-loop: planners validate logic and approve changes to the baseline; the forecast is advisory and the PMO decides contingency and recovery.

Data preparation

Forecasting needs the baseline schedule and cost plan, progress updates, change orders, actual costs, resource data and, ideally, a history of finished projects with their final outcome. In an SMB this lives in Excel plans, MS Project or Primavera files, the ERP cost centres, site diaries and e-mail. Typical gaps are baselines that were overwritten, inconsistent work-breakdown structures between projects, cost bookings without a project reference, and lessons learned that exist only in people's heads.

Preparation steps: inventory the sources (PREP-001, PREP-003), export ERP and scheduling data (PREP-005), restructure spreadsheets into tidy tables with fixed columns (PREP-011), align one project and cost-code structure and glossary (PREP-012), and mark outcome labels such as "finished late" from past projects (PREP-020). Gather a test set of completed projects with domain experts (PREP-018).

Rough share of effort: 50 to 60 percent of the project, because history is scarce and heterogeneous; with fewer than 20 finished projects, start with reference-class and Monte Carlo methods rather than machine learning. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path B. Products are priced and built for capital programmes, while an SMB's data sits in Excel schedules and its own tools, so a small model on cloud APIs fed from your own project data fits better.
• Enterprise: Path B. Project data is strategic and mixes several systems (ERP, scheduling, cost control), so building on APIs or an internal platform beats a fixed product.
• Developer: Path C. Monte Carlo and gradient-boosting libraries run on HW1 and give full control over the forecasting logic.
• Public: Path C. Project data of public buildings and infrastructure should stay under sovereign control, and open tools avoid vendor lock-in in tenders.

Path A — Buy (off-the-shelf)

• AI-first schedule risk: nPlan (UK; Portfolio, Decision Intelligence, Insights and Schedule Studio products) [1].
• Established scheduling/risk suites: Oracle Primavera Cloud and Primavera Risk Analysis, Safran Risk (Safran Software Solutions, Norway), Deltek Acumen, InEight and ALICE Technologies (named in the research sweep as relevant; verify current AI features per vendor). Construction ERP/5D platforms such as RIB iTWO (Stuttgart) cover scheduling and cost in one model.
• Check: import of your native files, whether the model is trained on comparable projects, EU hosting, treatment of your data (is it used to train a pooled model?), explainability per activity.
• Choose A when: you run many projects with P6/MS Project schedules and want results in weeks.

Path B — Build on cloud APIs

• Parse schedules with MPXJ (reads XER, PMXML, MPP and Primavera Cloud; LGPL) [3], store in a warehouse, train with AutoML on a European cloud region (AutoGluon, or managed ML services), and add an LLM API for narrative and risk-register reading.
• Orchestrate monthly forecast runs with a workflow engine; publish to Power BI or a PMO portal.
• Choose B when: you own a few hundred completed projects and want a model tailored to your contract types.

Path C — Self-host (open source)

• Stack: MPXJ for parsing [3], AutoGluon (Apache 2.0) for tabular and time-series models [6], Chronos-2 (Apache 2.0, 120M parameters) for time-series forecasts [5], LightGBM/CatBoost, a Monte Carlo engine in Python, optionally a small open-weight LLM for summaries. Note: TabPFN code is Apache 2.0 but recent model weights carry non-commercial licences; commercial use needs an enterprise licence [7].
• Hardware: HW1 (CPU server) is enough for training and simulation; HW2 only if an LLM is added.
• Choose C when: project data is confidential (defence-adjacent, critical infrastructure, bid data) or must not leave the company.

Path D — Custom training

• Worth it for owners or contractors with a large, consistent archive (several hundred to thousands of completed projects with baseline and actual dates). Needs clean mapping of activity codes (WBS/trade taxonomy), baseline snapshots and actuals; the main work is data engineering, not modelling. Graph neural networks over the schedule network are a research direction; trees on engineered features usually perform comparably on small data.

State of the art (2026)

• Outside-view learning at scale: vendors train on pooled historical schedules and report that forecast error falls as more schedules are added [1]; independent public benchmarks are scarce, so own back-testing on completed projects (forecast at 25/50/75 % progress vs actual finish) is the reliable evaluation.
• Tabular and time-series foundation models (TabPFN, Chronos-2) give usable forecasts with few labelled projects, lowering the data barrier for mid-size organisations [5][7].
• Generative schedule drafting from scope documents is emerging in products [1]; quality control remains manual.
• Limits and failure modes: rare, one-off megaprojects have few true comparables; schedules with poor logic produce garbage forecasts; models learn from past behaviour, including past bad practice; forecasts can be gamed once they drive incentives or bonuses; causal claims ("this cause delays by x days") need causal methods, not just feature importance; progress data is often reported late or optimistically.

Shared resources & combinations

• Shared stack (tabular-ml + time-series + simulation): PRED-024 (predictive process monitoring on event logs, same case-level modelling), PRED-016 (cash-flow forecasting fed by the cost forecast), PRED-018 (delivery-time prediction for material supply), PRED-011 (resource demand).
• Upstream data: DOC-030 (quantity takeoff and cost estimates), DOC-015 (tender requirements), ROBO-009 (visual progress measurement as actuals), ANOM-011 (supplier risk signals), OPT-002 (production scheduling).
• Hardware and tooling: CPU-class servers and a data warehouse; the same AutoML/time-series stack and workflow engine (AGENT-002) serve several PRED use cases.
• Data pipeline: schedule parsers (MPXJ), a project data mart with baselines and actuals, and a shared WBS/activity taxonomy are reusable assets.

Effort, cost & KPIs

• Path A: weeks to onboard; subscription pricing per project or portfolio, typically enterprise-level.
• Path B: 3–6 months incl. data preparation (the largest cost) and PMO integration.
• Path C: similar effort to B plus modest infrastructure.
• Path D: 6–12 months, mostly data cleaning and taxonomy mapping.
• KPIs: back-tested forecast error of finish date and final cost at fixed progress points; calibration of P80 (should be exceeded about 20 % of the time); lead time between warning and actual slip; share of flagged activities that really slipped; contingency used vs forecast; number of mitigations triggered.

People & change

Start with management and project controlling, who define which forecast is trusted for decisions. Project managers are the main users and also the source of the data, so involve them from the start; if they fear the forecast will be used to judge them, quality of updates drops. IT and the data owners (controlling, site managers) provide exports and access rights. Suppliers may need to share progress data under contract. The data protection officer checks resource and timesheet data, which is personal data; a DPIA is usually not needed if forecasts stay at project level.

Works council: depends. Project-level forecasts alone do not trigger co-determination, but linking them to individual hours or performance can fall under §87(1) no. 6 BetrVG; inform the council in good time under §90(1) no. 3. Public clients involve the Personalrat.

Pilot on two or three running projects in shadow mode and compare forecast against reality at each milestone. Typical concerns are "the forecast is used against me" and "an algorithm cannot know my site". Address them by using forecasts for early support rather than blame, showing drivers behind each warning, and keeping decisions on re-planning with the project lead. Support AI literacy through a short workshop (AI Act Art. 4). See GUIDE-008, GUIDE-009 and GUIDE-004.

Risks, regulation & compliance

• EU AI Act: usually minimal risk, since forecasting project dates and costs is not in Annex III. It becomes relevant when (a) the system is a safety component in managing critical infrastructure, or (b) outputs are used to allocate tasks, monitor or evaluate individual workers, which is Annex III point 4 (employment and worker management) [4]. Keep forecasts at activity/project level and exclude individual performance. AI literacy (Art. 4) applies.
• GDPR: schedules mainly hold company data, but resource names, timesheets and contractor-person data are personal data; works-council co-determination in Germany (BetrVG §87) applies if staff performance is touched.
• Commercial/contract: forecasts may become evidence in delay claims; version and archive them. Pooled vendor models raise confidentiality questions; negotiate data-use terms.
• Governance risks: forecast as target (Goodhart effect), false precision, automation bias. Mitigate with back-testing, ranges instead of dates, documented assumptions, and planner sign-off.

Getting started

1. Inventory completed projects with baseline and as-built dates; check export of XER/MPP files and consistent activity codes.
2. Run a back-test: forecast completed projects at 50 % progress with a simple reference-class method as the benchmark.
3. Pilot one or two vendor tools (Path A) on 5–10 historical and 2–3 live projects, comparing against your own Monte Carlo.
4. Define governance: who owns the forecast, how P80 feeds contingency, and exclude individual-level monitoring.
5. Establish a monthly loop: update actuals, re-forecast, review the top-10 slip-risk activities in the PMO meeting.

Sources

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