How to Select Use Cases for AI Adoption

Selecting use cases for AI adoption means scoring every candidate against the same weighted criteria — business value, implementation feasibility, data readiness, time to value, and risk — then letting a hard gate on data readiness remove anything that cannot survive delivery before it is assigned to a wave. What clears the gate is ranked by composite score and split into a build sequence: Wave 1 for immediate delivery, Wave 2 for later, and a park list for anything not yet viable. None of that happens by seniority, enthusiasm for a demo, or a show of hands in a steering committee.

The Gut-Feel Problem covers why the alternative to this — selection by seniority and narrative appeal — produces the wrong shortlist, and works through the five scoring dimensions and the mechanics of running a scoring session in detail. This post stays one level up: the sequence of steps a programme actually follows end to end, from an empty candidate list to a funded, board-ready Wave 1 — not the inside-the-room scoring choreography.

Step 1: Confirm Where the Organization Already Stands

Use case selection assumes the organization has already decided it is positioned to invest in AI at all. That is a different, earlier question, usually answered by a readiness assessment — and it is worth confirming that answer exists before ranking anything, because a strong Wave 1 shortlist built on top of an organization that is not actually ready to deliver simply fails later instead of failing in the selection meeting. If that baseline has not been established, it comes first. If it has, use case prioritization is the next decision: not whether to invest, but which specific use case to fund first.

Step 2: Set a Minimum Bar Before a Use Case Reaches the Scoring Table

Most of the damage in use case selection happens before scoring starts, when a use case reaches the shortlist on the strength of a slide rather than a description anyone could actually score. A workable intake sets a floor: a named business owner, a written problem statement, and a preliminary view of what data the use case would depend on. A use case missing any of these is not ready to be scored — it is an idea, not yet a candidate. Running this check consistently, across every candidate, before a single score is entered, is what makes the list that follows worth ranking in the first place. Realistically, this works best with a bounded list — a shortlist in the range of eight to twelve candidates keeps scoring from becoming a spreadsheet exercise nobody trusts; a longer raw list should be pre-filtered down to that range first.

Step 3: Score Every Candidate Against the Same Five Dimensions

Once the list is set, every use case gets scored against the same weighted dimensions, not a different rubric per business unit or per sponsor: business value, implementation feasibility, data readiness, time to value, and risk and sensitivity. Each carries its own sub-criteria — revenue impact and strategic alignment under business value; technical complexity, integration burden, and vendor dependency under implementation feasibility; data availability, quality, and access under data readiness; delivery speed and dependency chain under time to value; regulatory and reputational exposure under risk and sensitivity. The output is a composite score per use case, not five separate opinions to reconcile in the room. Scoring consistency matters more than scoring speed here — the same evidence standard has to apply to the flagship idea and the unglamorous one, which is the specific discipline The Gut-Feel Problem works through in depth.

Step 4: Apply the Data-Readiness Hard Gate Before Anyone Gets Attached

Data readiness is not just one of the five scored dimensions — it is also a hard gate. A use case that fails it is removed from Wave 1 consideration regardless of how high it scores everywhere else, including on business value. This step works best run early, immediately after scoring and before any shortlist is circulated for sign-off, because a use case that has already been discussed as a likely Wave 1 pick is much harder to park than one that was never presented as settled. The gate exists precisely because a compelling business case cannot substitute for data that does not yet exist.

Step 5: Rank What Survives Into a Wave

Everything that clears the gate is ranked by composite score and split into a build sequence — typically Wave 1 for immediate delivery, Wave 2 for later, and a park or revisit list for anything with real potential but an unresolved blocker. Before that sequence is finalized, it is worth checking the shape of Wave 1 as a set, not only the individual rankings inside it: a Wave 1 that leans heavily on a single business unit, or clusters around the same underlying data source, carries a concentration risk that no individual use case score would surface on its own. Catching that at the ranking stage is considerably cheaper than catching it mid-delivery.

Step 6: Put the Decision in Writing

A ranked list that lives in one person's head, or in a spreadsheet nobody outside the scoring session has seen, is not a decision — it is a draft. The last step is turning the ranking into a record a steering committee or board can actually review: which use cases made Wave 1 and why, which were parked and on what basis, and what the resulting portfolio looks like as a whole. That one-page summary is what gets carried into budget and resourcing conversations; the scoring session itself should not be the only place this reasoning exists.

Picture a transformation programme evaluating ten candidate use cases ahead of its next planning cycle, as a hypothetical. One candidate — an automated contract-review assistant with a strong executive sponsor — scores well on business value and time to value but fails the data-readiness gate: the contract repository it would depend on has never been indexed, and nobody has actually assessed whether the historical documents are usable. Under a gut-feel process, that use case likely makes Wave 1 on sponsorship alone. Under the gate, it is parked, with the data-indexing work identified as the specific blocker to resolve before it is reconsidered — while three lower-profile, higher-readiness candidates take its place in Wave 1 instead. No single rule here is complicated. What changes is that the process surfaces the blocker before the budget is committed, not after.

Step 7: Carry the Shortlist Forward

A finished Wave 1 shortlist is not the end of the process — it is an input to the next one. Once a use case has cleared the gate and been ranked into Wave 1, the next decision facing the programme is what it will realistically cost to deliver, which is its own scoring exercise with its own criteria, not an extension of the prioritization score. Candidates in Wave 2 and the park list do not disappear from view either: a park-list entry sits there because of a specific, named blocker, not because it was judged a weak idea, and it is worth re-scoring at the next planning cycle once that blocker has actually been resolved, rather than being quietly forgotten in favor of whatever is newest on the list.

None of these seven steps requires reinventing how a programme is governed. It requires applying the same weighted criteria and the same gate to every candidate, in the same order, every time a shortlist is built — and revisiting the candidates that did not make it this time, on purpose, rather than letting them age out of the conversation. That discipline is the difference between a use case list a board can defend and one a board has to take on faith.

The AI Use Case Prioritization Framework provides a weighted scoring matrix across five dimensions — business value, implementation feasibility, data readiness, time to value, and risk and sensitivity — covering up to twelve candidate use cases in a seven-tab Excel workbook, complete with a data-readiness hard gate, a Wave 1 / Wave 2 / park shortlist, and a one-page executive summary.

→ Available at www.viksya.com