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, before commitments are made, 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; the quarterly review is too slow for active intervention. The signal that actually predicts project outcomes — team composition, client engagement, scope-creep velocity, similar-project history — is already in the data.
How it works
_predict success on each active project conditioned on team composition (roles, seniority, prior project ratings), client engagement signals, scope baseline and revisions, budget burn, and similar-project outcomes. The result is a calibrated P(success) with $why factor decomposition showing which signals carry the prediction.
The staffing simulator is the workflow on top. Swap a team member in the UI, watch P(success) move. Add a senior architect, see the predicted lift. The user runs what-if mid-project changes against the prediction without committing them, which makes the decision visible before the staffing call is made.
{
"from": "projects",
"where": {
"status": "active",
"phase": "delivery",
"lead_pm": "Sara Toivanen",
"team_size": 7,
"budget_consumed_pct": 45
},
"predict": "success",
"select": ["$p", "$why", "success"]
}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. Source is on GitHub under Apache 2.0.
Frequently asked
How accurate is P(success) at kickoff vs mid-project vs near-close?
Kickoff predictions (team, scope, client, similar-project signals) typically reach 50-70% confidence. Mid-project predictions (scope-revision velocity, budget burn, engagement) typically 75-90%. Near-close predictions are very high confidence but intervention windows are limited. The system is most useful in phase 2 of delivery, where the prediction is informative and the intervention window is still open.
What if our project history is small (under 50 projects)?
Conditional probability works on small data too — the threshold is "what signals do you have, how varied are the projects?" With 50 projects, the system can usually identify the strongest predictive factors. With under 30, predictions are wide bands rather than point estimates. Confidence is naturally lower; the system says so honestly.
Can the prediction explain WHY a project is predicted to fail?
Yes. $why decomposition shows the base success probability, per-factor lift, and highlighted signals. "P(success) is 62% (baseline 78%); contributing factors: scope revised twice (lift −0.15), junior architect (lift −0.08), client unresponsive 14 days (lift −0.07)." The PM gets an actionable diagnostic, not a black-box score.
How does this handle clients we have never worked with before?
New clients get the population-baseline prediction plus whatever signals the project itself shows. P(success) reflects the project's team and scope; the client-specific signal is uninformative until similar projects accumulate. New-client predictions tend to be lower-confidence; the system explicitly says it has no client history yet.
Does this integrate with PM tools like Jira, Asana, or MS Project?
Yes, via HTTP/JSON. The PM tool pushes project state to Aito (or queries Aito on demand); Aito returns the prediction; the PM tool surfaces it in the project view. Integration patterns exist for Jira, Asana, MS Project, and custom internal PM systems.
