Forecasting a project's cost-to-complete before finance can see the loss

A software project rarely turns unprofitable on the day the P&L reports it. By the time finance closes the period, the engineering decisions that caused the loss are already made. The useful question is earlier: given what we can observe now, what will this project cost to complete, and how sure are we?

The model

We forecast completion time with a lognormal accelerated-failure-time (AFT) model, fit with MCMC and checked with the usual convergence diagnostics (R-hat, effective sample size). Effort and scope enter as covariates. A dependency DAG and a finite-worker capacity constraint keep the forecast physically possible rather than a naïve extrapolation. The AFT model itself produces a distribution over completion time, not cost; we turn that into a distribution over cost by applying the team’s burn-rate, its cost per unit time, together with the capacity and staffing-mix assumptions that set that rate. The cost quantiles come from that map: the output is not a single date but a distribution — a p50, p75 and p90 cost-at-completion, and a probability of direct loss.

Reading the result

Two projects can look identical on a burn-up chart and have very different tails. The one whose p90 crosses the contract value is the one to look at first — not because it is late today, but because the combination of unpriced scope growth and rework has moved its distribution. The point of a distribution is that it makes the tail, and therefore the risk, legible while a manager can still act on it.

What the evidence is

This is backtested, not field-tested. It has run against historical and synthetic delivery data; it has not yet been used as a live intervention trigger with a named client, and it will not be presented as a realised outcome until one measures it against an agreed baseline. A forecast cannot repair a baseline that was never recorded. So the first step of any engagement is establishing one.