Why Most AI Use Case Selection Processes Produce the Wrong Shortlist

Most AI use case selection is a politics exercise dressed up as a strategy exercise. Real prioritisation is evidence-based — and the evidence usually disqualifies the favourites.

Every enterprise AI programme eventually faces the same conversation. A working group of senior stakeholders convenes, a long list of candidate use cases is circulated, and the discussion begins.

Seventy minutes later, a shortlist of five use cases has been agreed. The most vocal business unit leader got two of them. The CTO's personal priority made it in despite everyone's doubts. The one use case with genuinely strong data foundations — boring, unglamorous, a back-office automation — was deprioritised because it lacked executive sponsorship.

Six months later, Wave 1 is in trouble. The data is not there. The change management load was underestimated. The flagship use case turns out to require a model architecture the team has never built. And the CTO's priority has consumed 40% of programme capacity without producing a single output in production.

This is not an unusual outcome. It is the default outcome when AI use case selection runs on gut feel.

EXECUTIVE SUMMARY

Four failure modes that produce the wrong AI shortlist — and why they compound at the worst possible moment:

1.    Seniority substitutes for data — the loudest voice in the room determines Wave 1 composition, not evidence.

2.    Data feasibility is assumed, not assessed — the most consistent predictor of AI project failure is discovered mid-delivery.

3.    Complexity is underweighted — ambitious first-wave builds consume capacity without producing production-grade outputs.

Portfolio balance is ignored — Wave 1 dominated by one business unit, one model type, or uniformly high complexity is a structural programme risk.

What Gut-Feel Selection Actually Looks Like

Gut-feel use case selection has several recognisable signatures. None of them are obvious in the room where they happen — they only become obvious when the programme hits the wall they created.

The HIPPO Effect

HIPPO stands for Highest Paid Person's Opinion. In AI use case selection sessions, HIPPOs win. Not because their use cases are better — but because the selection process has no mechanism to challenge their preference with evidence. Seniority substitutes for scoring. That is not strategy. It is hierarchy.

The Flagship Trap

Every AI programme has at least one flagship use case — the one that makes the best slide, the most compelling executive narrative, and the most impressive demo. These use cases are disproportionately selected for Wave 1 not because they have the best data or the clearest path to production, but because they are the easiest to sell internally.

Flagship use cases are frequently the most technically ambitious and the least data-ready. They generate the most expectation and the most exposure. When they fail to deliver on timeline — which they usually do — the reputational damage to the entire programme is severe.

The Completeness Illusion

Practitioners who have spent careers in data know the gap between 'the data exists' and 'the data is ready'. In gut-feel selection processes, this distinction is rarely pressed. A business unit owner will describe their data as 'reasonably clean' or 'largely available' — and those characterisations enter the record without challenge.

By the time a data engineer runs actual profiling on the dataset, the use case is already committed and budgeted. The surprises that follow — null rates in key feature fields, inconsistent historical labelling, unresolved compliance constraints — are not surprises to someone who asked the right questions. They are surprises because nobody asked them.

Portfolio Blindspot

Even when individual use cases are reasonably selected, the composition of the Wave 1 portfolio is rarely assessed as a whole. The result is frequently a Wave 1 dominated by a single business unit, or by uniformly high-complexity builds with no quick-win counterbalance, or by a cluster of use cases that all share the same data dependency — so that a single data pipeline failure affects the entire wave simultaneously.

Portfolio blindspot is the most insidious failure mode because no single use case decision is obviously wrong. The risk is structural, not individual — and it is invisible without a deliberate portfolio-level review.

Why This Problem Is Getting Worse

The proliferation of Generative AI tooling has dramatically expanded the candidate use case pool for most enterprise AI programmes. Where a programme in 2021 might have evaluated a shortlist of eight to twelve machine learning use cases, a programme in 2025 routinely confronts thirty or forty candidates — including LLM integrations, agent-based workflows, computer vision applications, and legacy ML use cases still waiting for execution.

More candidates do not produce better Wave 1 shortlists. They produce more confident gut-feel selection — because the sheer volume of options increases the pressure to decide quickly and reduces the likelihood that any individual use case is scrutinised rigorously.

The business case pressure has also intensified. Boards that approved AI strategy in 2023 and 2024 are now asking for production outputs. That urgency is legitimate. But urgency directed at a gut-feel shortlist does not accelerate value delivery — it accelerates commitment to the wrong things.

What Structured Scoring Changes

The antidote to gut-feel selection is not more discussion. It is a scoring methodology that replaces seniority with criteria, replaces assumption with evidence, and replaces individual advocacy with a structured composite view.

Structured scoring does not remove judgement from AI use case selection. It disciplines judgement — forcing every participant to justify a score with evidence rather than assert a preference with authority.

There are five dimensions that a complete AI use case scoring methodology must address. They are not interchangeable. They are not equally weighted. And the most important rule in applying them is that no dimension can compensate for a catastrophic failure in another.

The Five Dimensions of AI Use Case Prioritisation

The Data Feasibility Hard Gate

Dimension 2 — Data Feasibility — is not just a scored criterion. It is a hard gate.

Any use case scoring below 2.0 on data feasibility cannot enter Wave 1, regardless of how high it scores on every other dimension. A use case that promises transformative business value but has data that has not been assessed, is subject to unresolved compliance constraints, or requires data that does not yet exist is not a Wave 1 candidate. It is a data preparation project disguised as an AI project.

HARD GATE

A use case scoring 1 on Data Feasibility is automatically parked. No composite score, no executive sponsor, and no amount of business case optimism overrides this. Data is the irreducible foundation — and unknown data is the most reliable predictor of AI programme failure.

The evidence prompt that forces this discipline is deceptively simple: has a data engineer assessed this dataset? Not a business unit owner's assertion that 'the data is there'. An actual technical assessment of completeness, quality, labelling feasibility, and compliance status.

If the answer is no, the score for data feasibility is 2 at best — and the Wave 1 assignment changes accordingly.

The Inverted Dimensions Most Programmes Get Wrong

Two of the five scoring dimensions use an inverted scale — and this is the source of the most common scoring errors in facilitated sessions.

For Technical Complexity (Dimension 3) and Change Management Demand (Dimension 4), a score of 5 does not mean highly complex or highly demanding. It means the opposite. Score 5 means low complexity — the use case is straightforward to build. Score 5 on change management demand means low disruption — the affected population is small, engagement is high, and no structural resistance is anticipated.

The reason for this design is deliberate: across all five dimensions, a score of 5 consistently represents a positive outcome. A high composite score always means a good candidate. That interpretability matters when you are presenting results to an executive committee that did not attend the scoring session.

That is not a prioritisation shortlist. It is a wish list with a ranking attached. The difference only becomes clear when Wave 1 enters delivery.

The practical implication: when scoring technical complexity, ask 'how easy is this to build?' Score a gradient boosting classifier on clean tabular data at 5. Score a custom transformer architecture on novel unstructured data at 1 or 2. The use case that generates the most excitement in a selection session is frequently the one with the lowest Technical Complexity score — and that dissonance is exactly what structured scoring is designed to surface.

Portfolio Balance: The Check Nobody Runs

Individual use case scores tell you which candidates are strongest. Portfolio composition tells you whether Wave 1, as an assembly, is structurally sound.

Three automated checks are worth running on any Wave 1 shortlist before it is committed.

• Complexity balance: if more than 60% of Wave 1 use cases have a Technical Complexity score of 2 or below, Wave 1 is dominated by hard builds with insufficient quick-win counterbalance. The delivery risk is high, and the time to first production output is long.
• Business unit concentration: if more than 60% of Wave 1 use cases belong to the same business unit, Wave 1 is structurally dependent on a single stakeholder relationship. A change in sponsorship, a business unit priority shift, or a resource conflict collapses Wave 1 simultaneously.
• Data readiness average: even if no individual use case fails the data feasibility hard gate, a Wave 1 cohort with an average data feasibility score below 3.5 signals a fragile data foundation that will surface as delivery risk within the first sprint.

None of these checks require complex analysis. All three require looking at the Wave 1 shortlist as a portfolio rather than a ranked individual list.

The Scoring Scale — What Each Score Actually Means

A structured scoring methodology is only as useful as the shared understanding of what each score represents. Aspirational scoring — rating a use case at 4 because the team intends to have data ready, rather than because data is ready today — is one of the most destructive habits in prioritisation sessions.

The scoring discipline is simple: score the current state, not the intended state. If the evidence does not exist today, the score reflects that.

Scoring Reference — Composite Scale (applies across all five dimensions)

RULE

A score of 3 that is honest is worth ten times a score of 4 that is aspirational. The objective of a scoring session is not to produce the highest scores — it is to produce the most accurate scores. The composite ranking protects programmes that score honestly. It cannot protect programmes that inflate their inputs.

How to Run a Structured AI Use Case Scoring Session

The mechanics of a well-run scoring session are straightforward. The discipline is harder than the mechanics.

Before the Session

• Set the dimension weights before scores are visible. Adjusting weights after scores are entered — even with principled rationale — creates the appearance of fitting the framework to a preferred outcome. Agree weights with governance leadership, document them, and treat them as fixed for the session.
• Collect use case intake forms from business unit owners before scoring begins. A use case without a named business owner, a clear problem statement, and a preliminary view of required data is not ready to be scored.
• Assign the Data Feasibility score to someone with actual technical knowledge of the data. A business unit owner's assertion of data availability is not evidence. A data engineer's profiling assessment is.

During the Session

• Score evidence, not intention. The evidence prompt for each dimension specifies exactly what artefact or assessment justifies each score. If the artefact does not exist, the score reflects that.
• Challenge D3 and D4 scores explicitly. These are the dimensions most commonly scored in the wrong direction. For each, ask the scoring question aloud: 'How easy is this to build?' and 'How disruptive is this change?' before anyone enters a score.
• Allow the business unit to challenge composite scores — but only by providing evidence, not by asserting preference. A stakeholder who disagrees with a D2 score should be invited to present data engineering evidence, not simply to lobby for a higher number.

After the Session

• Review portfolio balance before finalising Wave 1 assignments. Run the three composition checks — complexity balance, business unit concentration, data readiness average — before committing.
• Save a dated copy of the scoring output as the governance record for that gate. Document any decisions that deviate from the framework's wave recommendations and record the rationale.
• Re-run the scoring at the next programme gate. The correct candidates for Wave 1 at programme kick-off are not necessarily the correct candidates three months later. Data readiness changes. Business priorities shift. The scoring is a snapshot, not a permanent assignment.

The Point of the Framework Is Not the Scores

Structured AI use case scoring does not remove difficult conversations from the selection process. It changes where those conversations happen. In gut-feel selection, the difficult conversation happens six months later, in a programme review, when everyone is trying to explain why Wave 1 is behind. In structured scoring, it happens in the session — before any commitment is made.

That is a materially better time to have it. For the full sequence that leads up to that session — from building the candidate list through to the funding decision — see How to Select Use Cases for AI Adoption.

The business unit leader who pushed for the flagship use case still gets to make their case. The CTO's priority still enters the scoring. The difference is that both have to earn their Wave 1 position against the same evidence-based criteria as every other candidate — and that a single low score on data feasibility cannot be overridden by any amount of seniority or enthusiasm.

The programme that produces the right Wave 1 shortlist does not necessarily have better use cases than the one that produces the wrong one. It has a better selection process. That is entirely within the programme team's control.

AI Use Case Prioritisation Framework — viksya.com

Stop building the wrong shortlist. The AI Use Case Prioritisation Framework is a structured Excel tool that scores up to 12 candidate use cases across 5 dimensions, produces a composite priority ranking, assigns wave sequencing recommendations, and flags Wave 1 portfolio risks before leadership commits.

Built for Programme Managers, CIOs, Strategy Leads, and Management Consultants. No macros. No code. Instant download.

→ Download the AI Use Case Prioritisation Framework

Frequently Asked Questions

What is AI use case prioritisation?

AI use case prioritisation is the process of evaluating and ranking candidate AI use cases across structured criteria — including business value, data feasibility, technical complexity, change management demand, and time to value — to determine which use cases should enter an AI programme's first delivery wave and in what sequence. Structured prioritisation replaces intuition-based shortlisting with a reproducible, evidence-anchored scoring methodology.

Why do most AI use case selection processes produce suboptimal shortlists?

Most AI use case selection processes rely on stakeholder consensus and executive preference rather than structured scoring. The result is a systematic bias toward flagship use cases with strong narrative appeal but weak data foundations, and against modest use cases with strong data readiness and clear paths to production. Data feasibility — the single most consistent predictor of Wave 1 failure — is rarely assessed before shortlisting decisions are made.

What is a Wave 1 data feasibility hard gate?

A Wave 1 data feasibility hard gate is a rule that prevents any AI use case from entering the first delivery wave if its data readiness falls below a defined threshold, regardless of how high it scores on other dimensions. In the AI Use Case Prioritisation Framework from Viksya, any use case scoring below 2.0 on the Data Feasibility dimension is automatically assigned to a later wave or parked for foundational data work. This rule cannot be overridden by business value score, executive sponsorship, or composite ranking.

How many use cases should an enterprise AI programme evaluate at once?

A structured scoring session is most effective with a realistic shortlist of eight to twelve candidate use cases. More than twelve introduces diminishing returns — the scoring becomes unwieldy and the session loses analytical rigour. If the initial candidate pool is larger, a pre-filter session should reduce it to the strongest candidates before formal scoring begins, eliminating any use case with an obvious fatal constraint such as unavailable data or no identifiable business owner.

Can management consultants use structured AI use case scoring frameworks with clients?

Yes. Structured scoring frameworks such as the AI Use Case Prioritisation Framework from Viksya are designed for direct use in client-facing prioritisation sessions. The framework produces a ranked output, wave assignments, and portfolio balance checks that are suitable for presentation to steering committees and executive sponsors. Consultants should run the scoring session with business unit owners and data representatives present, rather than completing scores independently.