AI Use Case Discovery, Readiness and Maturity: A Practical Playbook
Last updated: 2026-08-14
You have a list of candidate AI use cases. It is too long, the estimates are unreliable, and the items were mostly proposed by people who will not have to operate the result.
AI Use Case Discovery, Readiness and Maturity: A Practical Playbook
The decision this page helps you make
You have a list of candidate AI use cases. It is too long, the estimates are unreliable, and the items were mostly proposed by people who will not have to operate the result.
You need to decide which few to start, and you need a defensible reason for the ones you decline. The bottleneck is almost never idea generation. It is the path from working demonstration to something that runs on a Tuesday when its author is on leave.
Rules of thumb
1. Score on four axes, not on value alone. Value, data readiness, decision ownership, and reversibility. Value alone selects the ambitious and undeliverable. The four together select the ones that reach production. Weight them equally at first and adjust once you have evidence from your own portfolio.
2. Kill anything without a named business owner who will accept the output. Not a sponsoring department. A named individual who will act on what the system produces and answer for the result. Use cases without this person fail after the demonstration, every time, and the failure is attributed to the technology rather than to the gap.
3. Run discovery with the people who do the work. Directors describe the process as designed. Practitioners describe it as performed, including the workarounds, the informal exceptions, and the spreadsheet that actually carries the decision. The second description is the one you can build against.
4. Look for high volume, low variety, and tolerable error. The reliable early wins share this shape. Processes that are rare, highly variable, or intolerant of any error make poor first choices regardless of how visible they are.
5. Cap the pilot portfolio at what you can actually put into production. If you can operationalise three systems a year, run four pilots, not fifteen. Pilots with no production path are a training expense, and after two cycles of them the organisation concludes AI does not work here.
6. Test data readiness by looking at the data, not by asking about it. Pull a sample. Check completeness, whether the fields mean what the documentation claims, how far back consistent history extends, and whether the labels you need exist at all. Data quality reported by a system owner and data quality observed in a sample diverge more often than not.
7. Establish the baseline before you build. Measure how the current process performs today: throughput, error rate, cost, cycle time. Without this number you cannot demonstrate improvement, and you will spend the evaluation arguing about the counterfactual instead of the result.
8. Ask what happens when it is wrong, early and specifically. Trace the wrong output through the downstream process. Who receives it, do they have any means of detecting the error, and what does it cost to correct. Cases where a wrong answer flows silently into a consequential decision need a different design, not a faster pilot.
9. Prefer reversible over irreversible for the first cohort. Recommendations a human can reject. Drafts a human edits. Rankings that reorder a queue. Build institutional confidence on systems where the cost of an error is bounded, then move up the consequence ladder with the credit you have earned.
10. Cost the operating year, not the build. Monitoring, retraining, incident response, inference spend, and the staff time to review outputs. Many use cases with positive build economics have negative operating economics, and the only time to discover this is before you commit.
11. Assess maturity against the capability you need next quarter. Global benchmark comparisons produce a score and no action. Assess against the specific capabilities your next three use cases require, and the assessment produces a work plan instead.
12. Reassess the portfolio quarterly and publish what you stopped. Use cases that have not moved in ninety days are consuming attention and returning nothing. Stop them explicitly, state the reason, and record the condition that would restart them. A portfolio that only grows is not being managed.
The artefact: four-axis scoring sheet
Score each axis 1 to 5. Multiply rather than add, so a zero on any axis removes the case rather than being averaged away.
Value 1. Marginal convenience, no measurable effect 2. Efficiency gain in a minor process 3. Measurable improvement in a process that matters 4. Material improvement in a priority outcome 5. Removes a constraint on the organisation's mandate
Data readiness 1. Data does not exist or is not accessible 2. Data exists in fragmented form, quality unverified 3. Data accessible, quality acceptable, labels partially available 4. Data accessible, quality verified by sample, sufficient history 5. Data already in production use for a comparable purpose
Decision ownership 1. No identified owner 2. Owner identified, not consulted 3. Owner engaged, has not committed to act on the output 4. Owner committed, has capacity to review outputs 5. Owner committed and has funded implementation beyond the pilot
Reversibility 1. Irreversible effect on individuals with no appeal route 2. Irreversible operationally, correctable at high cost 3. Correctable within the process at moderate cost 4. Human reviews before effect, correction routine 5. Fully reversible, output advisory only
Interpretation. Scores above 200 are strong candidates. Between 100 and 200, address the weakest axis before proceeding. Below 100, decline and record the reason. Any axis at 1 removes the case regardless of the total.
The artefact: readiness assessment
Six dimensions, assessed as red, amber, or green with evidence. Assess the specific use case, not the organisation in general.
| Dimension | Green requires |
|---|---|
| Data | Sample inspected, quality verified, access granted, lawful basis confirmed |
| Process | Current process documented as performed, baseline measured |
| People | Business owner committed, reviewers identified and available |
| Platform | Deployment path exists, monitoring available, rollback tested |
| Governance | Consequence tier assigned, gate requirements known, stopping condition drafted |
| Funding | Implementation and first operating year funded, not only the pilot |
Any red on Data or People means the use case is not ready to start. Red on Platform or Governance means it can start with a defined remediation plan and a hold at the go live gate.
The artefact: maturity rubric
Five dimensions, five levels. Assess where you are, then mark where your next three use cases require you to be. The gap is the work plan.
| Level | Data | Delivery | Governance | Operations | People |
|---|---|---|---|---|---|
| 1. Initial | Fragmented, no catalogue | Individual experiments | None | None | Isolated enthusiasts |
| 2. Emerging | Catalogue exists, quality uneven | Pilots delivered, few in production | Principles published | Manual monitoring | Small central team |
| 3. Defined | Governed sources, documented lineage | Repeatable path to production | Tiering and gates operating | Monitoring and alerting standard | Roles defined, training in place |
| 4. Managed | Quality measured, issues remediated on cycle | Delivery predictable, platform shared | Register complete, reviews on schedule | Incident process tested, retraining routine | Capability distributed to business units |
| 5. Optimising | Data products with owners and service levels | Portfolio managed against outcomes | Governance informs strategy | Automated detection and response | Internal faculty, capability self-sustaining |
Do not target level 5 across all dimensions. Most organisations need level 4 on Data and Operations and level 3 elsewhere. Targeting uniformly high maturity spends budget on capability that no current use case requires.
Failure signals
- The pipeline contains more pilots than the organisation has ever put into production.
- Discovery workshops produced ideas and no named owners.
- Data readiness was assessed by asking the system owner rather than by inspecting a sample.
- No baseline exists, so improvement claims are contested at every review.
- The maturity assessment produced a score and no work plan.
- The same use case has appeared in three consecutive planning cycles without starting or being formally declined.
- Business units have stopped submitting because the last three submissions received no response.
What this does not cover
This page covers identification, prioritisation, and readiness. It does not cover the delivery methodology once a use case is approved, the technical evaluation design for a specific model class, or benefits realisation accounting under your financial rules. It also assumes you have a functioning route to production. If you do not, build that first, because prioritisation without a delivery path only produces a better ordered backlog.