AI strategy consulting. The order to do it in.

A short list of the jobs worth handing over, in the order worth doing them, with a rough cost beside each and a note on what has to be true before any of them can start.

AI strategy consulting is the naming and the ordering, and it is finished when something is being built rather than when a document is delivered.

Not a document about artificial intelligence, and not a survey of the market. A page that says: this job first, because it costs this much and it stops happening in the weeks you are busiest. Then this one, because it waits on the first.

What is on the page

• The jobs, ranked by what they cost.

  In hours or in lost work, roughly. That number decides the order rather than anybody's opinion.

• What has to be true first.

  The job written down, the information existing somewhere, somebody owning the output. Missing any of the three, it goes back down the list.

• What to leave alone.

  The jobs that look automatable and are not worth it, named, with the reason each one was left off.

• What it depends on.

  Which items are waiting on another item, so the order is a sequence rather than a wish list.

It fits on a page and the owner can read it. Anything longer is a document written to justify a fee rather than to be acted on.

Buying tools before naming the problem, automating the interesting job instead of the expensive one, and expecting the first thing built to change the month it goes live.

Every one of these is common, none of them is stupid, and all of them cost the same thing: months. The pattern is always the same, which is that the deciding got skipped because the products were easier to look at.

The four that cost the most

• Buying before the problem is named.

  A tool bought first becomes the thing everything else has to fit around, whether or not it suits.

• Automating the interesting job.

  It demonstrates well and it saves an hour a month. The dull one saves a day a week.

• Automating a process nobody wrote down.

  What gets built is a faster version of something that was already wrong, and now it is harder to change.

• Expecting the first month to show it.

  Most of these compound. The one that pays back immediately is the exception rather than the rule.

The CSIRO's work on responsible AI makes the same point from a different angle: the governance question and the value question are both answered by naming the problem first.

The job has to be written down, the information it needs has to exist somewhere, and somebody has to own reading what it does. Where any of the three is missing, that item is not ready.

This is what turns a list of ideas into an order of work. Two jobs can look equally valuable and be months apart in readiness, and the strategy is mostly about noticing that before anybody spends money.

The three that have to be true

• The job is written down.

  End to end, including what happens when something unusual turns up.

• The information exists somewhere.

  Where a step needs a fact nobody records, that fact has to start being recorded first.

• Somebody owns reading the output.

  Every automation needs one person who notices when it stops or when it says something wrong.

Where an item fails one of the three, the strategy says what would make it ready rather than dropping it. That is often a smaller piece of work than the build itself.

The data question, which is where most of these stall

Almost every AI consulting engagement that stalls, stalls on data. Not on the technology and not on the strategy: on the fact that the information a job needs is in somebody's head, or spread across a spreadsheet and an inbox, or recorded so inconsistently that nothing can read it. A data assessment is not a grand exercise. It is one question per item, asked honestly: where does this fact live today, and could a machine find it.

Security and access get settled in the same pass, because they decide what is possible rather than what is desirable. Which systems hold customer data, who is allowed to read it, and what may never leave the business. Those answers rule items in and out before any planning is worth doing, and settling them late is how a project gets to the build and then stops.

Roadmap, transformation, opportunity assessment

Other firms have names for this. A roadmap, a transformation programme, an opportunity assessment, a business case. They describe roughly the same work: look at what a business does, decide what technology could take over, and put the changes in an order. The difference worth asking about is not the vocabulary, it is what you are left holding at the end. A strategic planning document that nobody builds from is a cost. A page that names the first job and starts it is not.

The order matters and the calendar does not. What decides how long any of it takes is how quickly the business can write down how a job really happens, and that varies more than the building ever does.

A plan with months against each item reads as more professional and is worth less. The dates are guesses about the business's own availability, and they are the first thing to be wrong.

What actually sets the pace

• How fast the job gets written down.

  The slow half on every single item, and entirely inside the business rather than outside it.

• Who has to approve the wording.

  One person is fast. A committee is not, and that is worth knowing before starting.

• Whether the information already exists.

  Where it does not, recording it has to start before anything can use it.

• How long it runs watched.

  A fortnight, and it is not worth shortening. That fortnight is what stops a customer meeting a fault.

What a strategy can honestly say is the order, the dependencies and a rough size for each item. Anything more precise is a number invented to fill a column.

A week of the business gets watched, the repeated jobs go on a list with a cost beside each, the readiness of each one gets checked, and what comes back is an order rather than a plan for everything.

The looking is short. The value is in what does not make the list, and in the order the rest ends up in.

1. A week of the business gets watched

While people do the work for real. Not a survey, because what people say they do and what actually happens are different.

2. Every repeated job goes on a list with a cost

A rough number beside each one, in hours or in lost work. Anything that cannot carry a number comes off the list.

3. Each one gets checked for readiness

Written down, information existing, somebody owning it. That is what puts one of two equal-looking items first.

4. The dependencies get drawn

Which items wait on another item. This is what turns a ranked list into an order somebody can actually follow.

5. What to leave alone gets named

In writing, with the reason. You keep that page.

6. The first item starts

The strategy is finished when something is being built. A plan nobody acted on was not a strategy, it was a document.

The looking is short, days rather than weeks for most businesses. Acting on the list runs on its own timeline, and the free items are usually done before the first build starts.

The order it happens in

• The looking comes first.

  A week of the business, and nothing has been built at this stage.

• Then the page gets written.

  The ranked jobs, the readiness of each, the dependencies and what to leave alone.

• Then the first item starts.

  Because a strategy that nobody acted on was a document rather than a strategy.

What follows that is one job at a time, roughly a week to build and a week to watch each, with each one after the first shorter than the last because the connections already exist.

Ask what they look at before recommending anything, whether they sell the tools they recommend, what the output actually is, and what they would tell you not to build.

These are worth asking of anybody, including this one, so the answers given here sit under each question.

• What do you look at first?

  A week of the business. Anybody recommending something before looking is selling a product rather than answering a question.

• Do you sell what you recommend?

  No. Whoever supplies your software is not the right person to ask whether you need it.

• What is the output?

  A page the owner can read, with an order and a reason under each item. Not a slide deck and not a market survey.

• What would you tell me not to build?

  Anybody who cannot answer that has not looked hard enough, or is not going to tell you.

• Am I locked into a contract?

  Not here, it runs month to month. Any arrangement you cannot leave at the end of a month is worth a second look.

All of this can also be done in house, and plenty of businesses do it well. The six steps above are the same either way.