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, what kind of project it is, how clear its scope is, how new the work is, how senior the team is, is already in the project history.
How it works
_predict each of six outcomes on every active project: makes money, team stays happy, customer stays happy, lands on time, the thing works, opens a door. Each is conditioned on what is known about the project: its type, manager, team size, budget, duration, priority, contract type, scope clarity, novelty, customer size and team seniority, and each comes back as a probability with $why showing which conditions carry it. A seventh _predict, on outcome_score, gives the combined reading: how many of the three core outcomes are likely to land. The portfolio sorts by the chosen KPI, so the riskiest projects come first.
Beside it, _relate over completed projects answers which properties of the work go with a higher or lower rate for that KPI than the base: project type, priority, contract type, scope clarity, novelty, customer size and team seniority, each as a lift with its sample size. People are deliberately not in that list. A lift seen on 42 projects is a signal worth acting on; the same lift on 7 is weak evidence, and the sample size is on the screen to say so.
{
"from": "projects",
"predict": "outcome_score",
"where": {
"project_type": "audit",
"manager": "M. Hakala",
"team_size": 1,
"duration_days": 10,
"priority": "low",
"budget_eur": 15700.0,
"contract_type": "time_and_materials",
"scope_clarity": "clear",
"novelty": "some_new",
"customer_size": "enterprise",
"team_seniority": "senior_heavy"
},
"select": [
"$p",
"$value",
{
"$why": {
"highlight": {
"posPreTag": "«",
"posPostTag": "»"
}
}
}
],
"limit": 4
}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 the predictions use (project type, manager, team size, budget, duration, priority, contract type, scope clarity, novelty, customer size, team seniority) 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 unclear scope or a short duration pulling an outcome down, so the PM sees which conditions move the estimate. 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, scope, 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 the outcome predictions 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.
