Forty ideas on a spreadsheet. A workshop where each one got scored against the same four boxes: business value, technical feasibility, data readiness, risk and compliance. A ranked list came out the other end, the top five got approved, and everyone left feeling like the AI strategy question had been answered.
It wasn't answered. It was answered as of that Tuesday.
The Framework Isn't Wrong. It's Missing an Expiration Date.
Score business value against feasibility, data readiness, and risk. That structure is correct, and it belongs to nobody. You will find a version of it in every consulting framework, every training firm's course outline, and the resources page of every AI vendor selling into your category. When that many independent sources converge on the same four factors, the factors are almost certainly right.
Which is also why they are not an advantage. If every company in your sector can run the identical session and produce a similar-looking ranking, the ranking is table stakes. What separates the companies getting real returns from AI from the ones holding a tidy deck is not the quality of the scoring workshop. It's whether anybody ever runs it a second time.
Why AI Use Case Prioritization Goes Stale: Three of the Four Scores Aren't About the Use Case
The standard matrix hides something by putting four columns side by side, same width, same font, as if they were the same kind of number.
Business value is a property of the use case. Cutting churn is worth roughly what it's worth whether you score it in January or in November.
The other three are not properties of the use case at all. They are properties of your company on the day of the workshop, filed under a use case's name.
Feasibility is a reading of your current stack, and your stack changes every time a vendor ships an integration you didn't have last quarter. Data readiness is a reading of whether your CRM and your ERP currently agree on a customer ID, which is true or false depending on whether an integration project running for entirely unrelated reasons happened to finish. Risk is a reading of your present regulatory and contractual exposure, and it moves when a state passes AI-specific legislation or a customer adds an AI-use clause to a renewal.
So three quarters of your scoring matrix is telemetry about a company that has since changed. The four columns look symmetric. They decay at wildly different rates, on schedules set by people who have never heard of your AI roadmap.
None of this is hypothetical, and none of it is one client. In a composite pattern that recurs across data-and-analytics engagements: a churn-prediction use case is scored "not feasible, no clean customer history" at the kickoff workshop and drops into the deferred pile. Eleven months later a data warehouse project finishes. It was funded for a completely unrelated reason -- finance wanted a faster monthly close, and nobody involved was thinking about AI -- and customer history is suddenly clean and joinable. The use case is now feasible. Nobody reopens the spreadsheet, because nothing anywhere on the roadmap ever said that this specific condition changing was the trigger to look again. The idea voted down in month one was the right call by month twelve, and it is still in the same folder, still marked no.
The same composite pattern runs in reverse, and that direction gets even less attention. An approved Priority 1 use case clears the feasibility bar partly because a vendor's published roadmap says the integration ships next quarter -- then the vendor gets acquired and the integration quietly leaves the roadmap. Or a major customer adds an AI-use clause at renewal and the top-ranked use case becomes a contract negotiation nobody budgeted for. Scores don't only ripen. They rot. Rot is the harder one to catch, because approved items stop being scored and start being built: the re-examination finally happens in a steering committee, where someone is explaining a slipped date instead of a changed score.
Everyone Agrees on the Boxes. Nobody Publishes the Clock.
The gap is structural, not an oversight. A framework built to answer "what should we build first" is answering a genuinely useful one-time question. It was never built to answer "what changed since we scored this," because that is a different question, and it needs somebody to own a standing practice rather than run a workshop -- the same standing-practice-versus-workshop gap that shows up in why a price realization rate keeps drifting back after a one-time governance fix.
Look at how the average company handles decisions generally. Across most industries, something like 40-45% of recurring operational and financial decisions are made with real BI support behind them -- a dashboard, an automated report, a live extract -- rather than a spreadsheet, an email thread, or a gut call. Bottom-quartile companies are closer to 20%.
Now notice what your use case list actually is: a decision-support artifact. In the average company it sits with the majority of decisions that never make it into a dashboard, reviewed when somebody remembers rather than on a cadence. The document meant to govern the entire AI investment is managed exactly like the reorder threshold nobody ever instrumented.
Data maturity has the same problem. On a 1-to-5 scale spanning data platform, BI, governance, AI readiness, and talent, the average company sits around 2.5 -- in the gap between "ad hoc spreadsheets, reactive reporting" and "centralized BI, defined process." That composite moving even half a point is usually enough to flip a couple of use cases from data-dependent-and-deferred into ready-to-build. But only if somebody is re-scoring maturity on a schedule. Most companies scored it once, in the same workshop that produced the use case list, and haven't touched either number since.
What a Use Case Inventory Has to Do Instead
Technology Architecture & Analytics Investment Planning is built around this specific gap, which is why the use case matrix is never scored in isolation. It's fed by the same five-dimension maturity assessment -- platform, BI, governance, AI readiness, talent -- re-run against the company's own long-range plan or exit thesis KPIs rather than a generic industry weighting. Each use case is scored on four things: business impact in dollars, implementation feasibility, time to value in months, and strategic alignment to a specific KPI the business is already managed against. Not "aligned to strategy." A named metric with an owner.
Three things the engagement does differently with that list.
The deferred pile is treated as the more valuable half of the output. The approved top five were mostly obvious before the workshop started -- somebody in that room could have named four of them in the parking lot. What only a scoring exercise can produce is the set of ideas that are good and currently blocked, each with its blocker named. That is a watchlist. Almost nobody treats it as one; it gets filed as the reject pile. So the classification is four tiers, not a binary: Priority 1 (build now), Priority 2 (planned), Priority 3 (build toward), and Deferred -- where Deferred carries a specific, named enabling-data requirement instead of a silent "not yet."
Data-dependent means prerequisite, not parallel workstream. The common move is to draw the data work and the AI build as two swimlanes running side by side, because it compresses the timeline and looks decisive in a steering deck. Then the model ships against data that still doesn't join. If a use case needs data that doesn't exist in usable form, the data investment goes in front of it on the critical path, and the use case inherits that date -- a sequencing discipline that matters more, not less, once the build itself is agentic rather than a one-off model.
The roadmap outputs triggers, not just dates. The decisions package splits into DECIDE NOW, DECIDE WITHIN 6 MONTHS (with the condition that makes the decision ready named up front), DECIDE AT HORIZON 1 COMPLETION (tied to a maturity milestone rather than a calendar date), and DO NOT DECIDE YET. That trigger is the thing a one-time scoring matrix structurally cannot produce. A workshop output is a snapshot. What you need is an alarm.
None of this is really about picking the right five in the room on day one. Companies moving from Level 1-2 to Level 3-4 maturity through this kind of work typically see three-year returns in the 200-400% range, with a 12-18 month payback on the first horizon of investment. A meaningful share of that comes from catching a use case the quarter it becomes buildable, rather than six quarters after the blocker quietly resolved itself.
Three Questions Before You Trust Your Own Use Case List
- Has your data maturity score moved since the workshop that scored feasibility? If nobody is tracking the composite number, you can't answer this, which means your feasibility scores are already out of date by default.
- Which "Deferred" use cases were deferred for a reason that no longer exists? Take the specific blocker named at the time -- a missing integration, an ungoverned data set, an unresolved risk -- and check it against what is true today.
- Do you have a named trigger for re-scoring, or a filed spreadsheet? "We'll revisit this eventually" is not a trigger. "We revisit when data maturity crosses 3.0" is.
A scoring matrix answers what to build first, once. It was never built to tell you that the ground under the ranking moved. That gets checked on purpose, on a cadence tied to something real, or it gets rediscovered by accident when somebody happens to notice that a use case that used to be impossible isn't anymore.
If your AI use case list hasn't been re-scored since the workshop that produced it, start a Technology Architecture & Analytics Investment Planning engagement and find out which of your "someday" use cases quietly became "now" -- and which of your approved five quietly became "no."