The problem
Project success is the most consequential prediction in a services-heavy ERP. The portfolio team needs to know, before staffing decisions are locked and before the project is too far along to course-correct, which projects are at meaningful risk and which are on track. The answer drives staffing, escalation, customer communication, and the renewal forecast.
Most teams answer this with a mix of PM intuition, RAG-status reporting, and a quarterly portfolio review. The intuition is informed but inconsistent across PMs, RAG status lags reality by weeks, and the quarterly review is too slow for active intervention. The signal that predicts project outcomes, who is on the team, who manages it, what kind of project it is, is already in the project history.
How it works
_predict success on each active project, conditioned on its manager, project type, team size, budget, duration and priority. The result is a calibrated P(success) with $why showing which conditions carry it, and the portfolio sorts by it, so the riskiest projects come first.
Beside it, _relate over completed projects answers the staffing question directly: which people, managers, project types and priorities go with a higher or lower success rate than the base, as a lift with its sample size. A person at ×0.84 over 19 projects is a signal worth a conversation; the same lift over 3 projects is not, and the sample size is on the screen to say so.
{
"from": "projects",
"where": {
"project_type": "implementation",
"manager": "J. Lehtinen",
"team_size": 5,
"budget_eur": 120000,
"duration_days": 90,
"priority": "high"
},
"predict": "success",
"select": ["$value", "$p", "$why"]
}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.
Frequently asked
How early in a project is P(success) useful?
From kickoff, because the conditions it uses (manager, project type, team size, budget, duration, priority) are known before work starts. As the project runs, add what you learn, such as budget burn or scope changes, to the where and the prediction updates on the next query. How sharp it gets depends on your history; measure it with _evaluate on your own completed projects rather than trusting a generic figure.
What if our project history is small?
The probabilities stay close to the base rate until the history supports a difference, which is the honest answer on little data. The success-factors panel shows the sample size behind every lift, so a factor seen on a handful of projects reads as weak evidence rather than as a finding.
Can the prediction explain WHY a project is predicted to fail?
Yes. $why returns the base probability and a multiplicative lift per condition, for example a manager at ×0.94 or a project type at ×0.93, so the PM sees which conditions pull the estimate down. The success-factors panel shows the same kind of lift at portfolio level, with its sample size.
How does this handle clients we have never worked with before?
A new client has no history of its own, so the prediction rests on everything else about the project: its type, manager, team and budget. Nothing is invented for the client; its effect enters once projects with that client complete.
Does this integrate with our PM tool?
Over HTTP/JSON or SQL. The PM tool (or a sync job) writes project records to Aito and queries P(success) when a project is opened or changed; the answer comes back with its $why to show in the project view. There is no model to retrain when projects complete: the next query already includes them.
