Use case on web-based integrated project-monitoring platform

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   Predicting overrun from a project's current cost and schedule position risks leaking the outcome into the features — a project already showing revised cost has partly declared its overrun, so build the feature set from what was known at the prediction point or your accuracy is an illusion

2. It gets worse

   The published monthly reports are the practical source and assembling a project-level historical panel from them is real data engineering, so start there rather than with the modelling

3. Still reading?

   Large infrastructure projects overrun for reasons the monitoring form never captures — land acquisition, litigation, contractor disputes, clearances — so there is a genuine ceiling here, and finding it is the answer to the sponsor's third question rather than a failure

4. And the finisher

   Nine indicative outcomes will tempt teams to attempt all of them; two done rigorously with honest baselines beats nine shallow modules against this particular sponsor

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  4/5

  Actually buildable, which on this slate is rarer than it sounds. Do not squander it on scope.

  The data position is excellent and unusual — the portal publishes project-level original cost, revised cost, expenditure, timelines and status monthly across nearly two thousand projects, with a predecessor system providing almost two decades of history, and both target variables are arithmetic on published fields rather than labels you have to construct.

• Innovation scope

  4/5

  There is something genuinely new here. Do not bury it under another dashboard.

  The statement explicitly states its suggested techniques are indicative and non-exhaustive and invites alternative methodologies, and the three technical dimensions it poses are genuine open questions rather than a specified architecture.

• Clarity

  5/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  Unusually well written — it explains the data ecosystem and its history, quantifies the monitored portfolio precisely, poses three specific technical dimensions including a genuinely sophisticated question about attributing predictive power to captured versus uncaptured variables, and lists nine indicative outcomes while stating they are not exhaustive.

• Acceptance potential

  4/5

  Strong footing before you have written a line. Try not to waste it.

  Real public data with a directly computable target variable, a sponsor who has thought carefully enough to ask whether machine learning is even the right tool, and an infrastructure monitoring domain almost no team will choose — the honest answer to the ministry's own question is worth more here than a marginal accuracy gain.

• Effort

  Heavy

  Heavy. Somebody on this team is not sleeping in week three. Pick who, on purpose.

  Assembling a project-level historical panel from monthly reports, engineering stage-aware features, training and honestly comparing several model classes, and building the risk scoring and early warning interface is four workstreams, with the historical panel assembly the slowest.

• Demo-ability

  Medium

  Demoable, if you rehearse it. Nobody rehearses it.

  A ranked risk list validated against what actually happened to those projects is genuinely persuasive to an administrator and is checkable against public reports, but the output is tables and rankings rather than anything visual.

The demo they will have already seen 🪞

Somewhere around 120–270 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• Both target variables are arithmetic on published fields, so unlike almost every prediction statement on this portal you have real labels for thousands of real projects without constructing anything
• The statement asks whether machine learning actually beats conventional statistics here, which is an unusually honest question from a sponsor — answering it rigorously, even if the answer is that a well-specified regression wins, is a genuinely valuable finding and most teams will avoid asking
• The question about how much predictive power comes from currently captured fields versus uncaptured variables is directly actionable for the ministry, since the answer tells them what to add to the monitoring form — very few submissions produce a recommendation the sponsor can implement immediately