Prioritising Machine Learning Projects: RICE Scoring and the Value-Effort Matrix

Why the first project matters more than the model behind it

After identifying several ML-suitable problems, a business faces a harder question: which one to build first, given that budget, time and organisational attention are all limited. The choice of first project is disproportionately important because it is really a test of trust, not technology. A successful first project proves ML works in this specific business (not just at large tech companies), that the promised ROI is real, that the team can actually operate and maintain what gets built, and that the organisation's culture can absorb a data-driven system. A failed first project tends to do lasting damage: loss of leadership confidence, reinforced scepticism from staff ("we told you so"), and ML budgets frozen for a year or more. One frequently cited pattern is that a majority of companies whose first ML project fails do not attempt a second one within two years.

The ideal first project has been described as a "Goldilocks project": fast to deliver (two to four months to a minimum viable product), moderately budgeted ($5,000–25,000 rather than six figures), with a clearly measurable ROI, backed by data that is actually available and reasonably clean, low enough risk that a disappointing result would not be catastrophic, visible enough that leadership and staff can see the result, and reasonably self-contained rather than dependent on several other unfinished projects.

The RICE scoring method

RICE — borrowed from product management and well suited to ranking ML project candidates — scores each project on four factors and combines them into a single comparable number:

RICE score = (Reach × Impact × Confidence) / Effort

• Reach — how many people, transactions or processes will the project touch in a given period, e.g. per quarter? A chatbot handling 15,000 support tickets a quarter has far higher reach than a churn model addressing 500 at-risk customers, even though the churn model may have higher per-customer impact.
• Impact — how much will it move the needle for each unit of reach, scored on a simple scale: 3 for a transformational improvement (50%+), 2 for a high impact (25–50%), 1 for a medium impact (10–25%), 0.5 for a low impact (5–10%), and 0.25 for minimal impact (under 5%).
• Confidence — how sure are you of the Reach and Impact estimates, expressed as a percentage. Confidence rises with existing evidence (a completed pilot, clean available data, comparable case studies, an experienced team, leadership backing) and falls with unknowns (poor data quality, unproven technology, complex legacy integration, anticipated user resistance).
• Effort — the resources required, typically measured in person-months, spanning model development, data preparation, integration, testing, deployment and user training. A rough scale: under 1 person-month for a minimal SaaS-based project, 1–3 for a small custom build, 3–6 for a medium project, 6–12 for a large one, and 12+ for enterprise-scale work.

A worked comparison across candidate projects

Consider a business with five shortlisted ML candidates. Estimating each factor and computing RICE produces a ranked list:

Here the chatbot wins decisively on RICE, primarily because its effort is so low relative to its reach — a SaaS platform requiring configuration rather than custom development changes the effort denominator dramatically. Note that RICE is a decision aid, not an oracle: the churn model has a much higher per-customer impact and might still be the right strategic priority if customer retention is the board's top stated concern this year. RICE should inform the ranking, not replace judgement about strategic fit.

The simpler alternative: a value-versus-effort matrix

If RICE feels like too much precision for an early-stage exercise, a simpler 2x2 matrix works almost as well. Score each project's business value (0–10, where 10 might represent $500,000+ a year in savings or revenue) against its implementation effort (0–10, where 10 represents 12+ months and $100,000+). Projects landing in the low-effort, high-value quadrant are quick wins and should generally go first; high-effort, high-value projects are major projects worth pursuing once the organisation has momentum; high-value, high-effort projects tied to long-term competitive positioning are strategic bets worth doing even if they are not first; and everything low-value should generally be deprioritised regardless of how easy it looks.

Factors that should adjust the ranking beyond the raw score

Several qualitative factors can reasonably override a close RICE ranking. Priority should rise when: a senior leader is personally invested in the outcome and will protect the project's resources; a specific internal champion exists who will drive adoption and handle resistance; the project has synergy with another initiative already underway (for example, deploying lead scoring immediately after a new CRM rollout); the pain is urgent and worsening rather than stable; or a ready-made solution exists that avoids building from scratch. Priority should fall when: the project depends on other unfinished work; it carries meaningful regulatory or compliance risk requiring approvals; the underlying data needs months of cleanup with uncertain payoff even after that investment; there is active resistance from the people who would need to use the system; or it relies on unproven, bleeding-edge technology that adds unnecessary technical risk to an already uncertain first project.

Building a twelve-month roadmap and avoiding common mistakes

A reasonable default roadmap structure runs: quarter one — close any critical readiness gaps and launch a single quick-win project; quarter two — evaluate the first project's actual ROI and either start a second quick win or begin a major project if the first succeeded; quarter three — carry the major project through to completion while keeping the quick wins running; quarter four — assess the full portfolio, retire anything underperforming, scale what works, and optionally start one experimental project in a new direction. Company size should shape the level of parallelism: a small business is usually best served running one project at a time; a mid-sized company can typically sustain one or two quick wins alongside a single major project; a large enterprise can run a genuine portfolio, roughly split 30% quick wins, 50% major projects and 20% experimental work.

The recurring mistakes worth naming explicitly: starting with the most ambitious project to "make a statement," which multiplies the risk of a visible early failure; running too many projects at once and finishing none of them well; choosing a project because good data happens to exist there rather than because it addresses real pain, which produces a technically accurate model nobody uses; chasing a fashionable technique for its own sake rather than the simplest method that solves the problem; and ignoring the people who will actually use the system, on the assumption that leadership support alone will carry adoption.