How to scope an AI use case

Most AI initiatives start with a list. Summarize this, automate that, put a chatbot on the website. Lists like this are easy to write and hard to act on, because they describe technology and say nothing about the problem.

A better starting point is whatever slows people down in their actual work. Here’s how we get from there to a project that can be built.

Watch the work

Go and sit with the team. Watch the process, ask where the time goes, what goes wrong, what they’ve learned to work around, and what they’d happily never do again. Look at the systems and documents they use.

It takes longer than a workshop and it’s far more reliable. In a workshop, people describe the process as it’s supposed to run. At their desks, they show you how it really runs, exceptions included, and the exceptions are usually what decide whether software will cope. It’s the main reason we work as forward-deployed engineers.

We write up what we find as a simple map: each problem, who it affects, how often it happens, roughly what it costs, and what’s causing it.

Choose one problem

Then rank the problems. Two things matter. First, value: what the problem costs in time, money, errors or risk, and how many people it touches. Second, difficulty: how well software could deal with it, whether the necessary data exists and can be reached, how many systems are involved, and how soon a usable version could be in someone’s hands.

The best first project is valuable enough that people care and simple enough to deliver well. A modest problem solved properly does more for an AI program than an ambitious one that drags on.

Write the requirements

Requirements for AI software need more than a feature list. Describe what it should do from the user’s point of view. Be just as clear about what it must never do: actions that always need a person’s approval, data it mustn’t expose. List the exceptions it has to handle, taken from what you saw at people’s desks. Note the systems and data it depends on and their quality, and the limits it has to work within, whether security, privacy, regulation, cost or speed.

Most important of all, agree how success will be measured before anything is built. Without that, nobody can say whether the finished software works, and the project drifts.

Check whether to buy

Before designing anything, test whether an existing product already meets the requirements well enough. If one does, that’s usually the better route. There’s more on this in build or buy AI.

Design it and build a prototype

If building is the answer, sketch the design: architecture, data, AI components, integrations and security. Then build a rough working version against your own data and give it to the people who’ll use it.

The prototype is really a test of the scope. It shows whether the approach works, which requirements were wrong, and where the difficult parts are, all before the main spend. What users say about it decides what changes before the production build.

This is the core of our AI strategy work, and the first stages of our approach.