The problem
A services revenue forecast is usually the delivery schedule summed by month. The schedule assumes every project lands on time and on budget, and the finance team adds a haircut from experience. When projects slip, the forecast learns about it at month end.
Whether a project will slip is predictable from the projects before it: its type, manager, team size, duration, priority and budget. That prediction belongs in the forecast.
How it works
For each active project, _predict returns the probability of on-time and of on-budget delivery, each with its $why. The application spreads the project's remaining value over the months it is scheduled for, then moves the share at risk of slipping, one minus P(on-time), to the month after the scheduled end. The scheduled line and the predicted line sit side by side and sum to the same total; nothing is invented or lost, only moved in time. Projects already past their scheduled end are reported separately as overdue.
A project whose prediction moves shows up in the gap between the two lines, with the drivers that moved it.
{
"from": "projects",
"predict": "on_time",
"where": {
"project_type": "implementation",
"manager": "L. Lounela",
"team_size": 4,
"duration_days": 106,
"priority": "high",
"budget_eur": 31800.0
},
"select": [
"$p",
"$value",
{
"$why": {
"highlight": {
"posPreTag": "«",
"posPostTag": "»"
}
}
}
],
"limit": 2
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 📋 ERP demo today. Click through to the live application and inspect the queries that produce the result.
