A mandate is not a question
Being told to do AI is an objective without a problem attached. The first job is converting it into a question that has a denominator and an owner, and the temptation is to skip straight to tooling.
- Do something with AI is an objective, not a problem statement. An objective cannot be solved, only performed.
- A usable question needs three things: a process rather than a function, a denominator that already exists, and an owner whose own targets move.
- Start from processes that are already instrumented. They are candidates because you can prove what happened, not because they suit the technology.
- An owner who will not name a failure threshold in advance has not agreed to anything.
The mandate usually arrives in one sentence, from someone senior, after a board meeting or a competitor announcement. Do something with AI. Come back in six weeks. It is an objective, and an objective is not yet a problem statement, which means it cannot yet be solved, only performed.
Performing it looks like a tool selection, a vendor bake-off, a centre of excellence, and a slide with nine use cases scored on a two by two. All of this is defensible, produces artefacts on schedule, and answers no question, because none was asked.
The conversion
A usable question has three parts, and a mandate has none of them.
- A subject that is a process, not a function. “Legal” is a department. “Contract review for renewals under a hundred thousand” is a process, and it has a volume, a cycle time and a cost per unit that somebody already tracks.
- A denominator that exists before you start. If nobody can tell you what the process costs today, you will not be able to tell anyone what it costs after. Finding the current number is often the majority of the work and is almost always skipped.
- An owner who feels the number. Not a sponsor. The person whose targets move when the process moves. If that person is not in the room by the second meeting, you are building for an audience rather than a customer.
What to do with the six weeks
Spend the first two finding processes that already have instrumentation. Somewhere in the organisation, a handful of processes are measured properly, usually because they were outsourced once, or because a regulator required it, or because a previous programme left a dashboard behind. Those are your candidates, and the reason has nothing to do with their suitability for the technology. They are candidates because you can prove what happened.
Spend the next two confirming that a named owner will accept the measurement as the test. Get them to say, in advance, what number would count as success and what number would count as failure. An owner who will not name a failure threshold has not agreed to anything.
Spend the last two on the smallest build that moves the named number. The output of six weeks is not a strategy. It is one instrumented process, one owner, one agreed threshold, and evidence about which side of it you landed on.
Saying no to the rest
The nine use cases will not go away, and the request to rank them will keep coming. Rank them on a single axis: does a named owner already measure this today. Everything that fails the test goes into a list called needs a baseline first, which is honest, actionable, and quietly does most of the prioritisation for you.