Eighteen months after the kickoff meeting, the programme still has a name, a budget code and a steering committee that meets on the second Tuesday of every month. It does not have anything running in production. The slide deck has grown to sixty pages. Somewhere around month four the use case list went from three candidates to eleven, and nobody has trimmed it back since.
An AI implementation strategy is the answer to a smaller question than most programmes treat it as: what are we building first, on what data, built by whom, and how will we know if it worked. The maturity models, the governance charters, the twelve-month roadmaps are decoration on top of that answer, and decoration is exactly what is left standing when the four questions underneath were never actually settled.
We build data and AI systems at Shipshape Data, and the scene above is one of the more common ways we see a programme die: not from a bad idea, but from nobody being willing to narrow eleven ideas down to one. This guide covers how to pick a first use case worth betting on, the data foundation you cannot skip past, when to build versus buy, how to sequence and resource the work, and the failure modes that quietly end programmes before anything ships.
Why "AI strategy" usually turns out to be a strategy for nothing in particular
Ask a room of ten people what the AI strategy is meant to achieve and you will get ten different, reasonable answers. Cut costs. Free up the team from repetitive work. Keep up with a competitor who has already announced something. Stop losing good people to companies that look more current. None of these is wrong. The trouble starts when the strategy document tries to serve all ten at once, because a document that answers everything commits to nothing, and a committee reviewing it every month can go on meeting for years without ever being wrong about anything.
The document that never says no
A real strategy rules things out. It says we are doing this domain and not that one, this quarter and not next year, with this team and not a vendor we have not yet chosen. Most of the documents we get handed at the start of an engagement do the opposite. They list every function that might benefit from AI, attach a maturity score to each, and leave the actual choosing for a later meeting that keeps getting rescheduled. The document feels thorough. It is thorough at describing the landscape and silent on what happens Monday morning.
What the document should actually settle
Four things, no more. Which use case ships first. Whose data it runs on and whether that data is in a fit state to use. Who owns the build, internally or externally, and who owns it once it is live. And what "worked" means in a number somebody can check three months after launch. If your strategy document answers those four questions for one use case, you have a strategy. If it answers adjacent questions for eleven use cases, you have a very well-organised list of options, and options do not ship.
Picking a first use case without picking eleven
The workshop version of this exercise usually produces a long list scored against two axes: business value and feasibility. It looks rigorous. In practice almost everything scores medium-to-high on both, because the people scoring it want their own idea to survive, and vague criteria let every idea survive. The list gets shorter on paper and stays exactly as long in reality.
Score for data readiness, not ambition
The axis that actually separates a viable first project from a doomed one is rarely on the workshop slide: does the data this use case needs already exist, in a place you can reach, in a state that is not actively hostile. A use case that would transform the business but depends on five systems that have never been reconciled is not your first project, however good it sounds in the room. A narrower use case sitting on data that is already clean and already governed will ship in a fraction of the time and teach the organisation what running AI in production actually involves. That lesson is worth more than the ambitious version, because you learn it once and reuse it.
The domain expert test
A simpler filter than most scoring matrices: can you sit a domain expert down next to the output and have them tell you, within a minute, whether it is right. A model that drafts customer support replies passes this test easily, because a support agent reads the draft and knows immediately if it is nonsense. A model that predicts churn six months out fails it, because nobody can check the prediction for six months, by which point the model has been running unsupervised on real decisions for half a year. Pick the use case where someone can catch the mistake quickly, not the one where the mistake is theoretically bigger but invisible until it is expensive.
The data foundation you cannot skip past
Every programme we have watched stall has, somewhere in its post-mortem, a version of the same sentence: we assumed the data was in better shape than it was. Nobody sets out to build on sand. The data simply looked fine from a distance, because looking closely enough to see the cracks is unglamorous work that nobody had budgeted time for.
What "ready" actually means, concretely
Readiness is not a maturity score out of five. It is a short list of specific, checkable things. Does the field you need exist, and is it populated in more rows than not. Does more than one system claim to hold the truth about the same entity, and if so, which one wins when they disagree. Has anyone actually looked at a sample of a hundred real rows recently, rather than trusting the schema documentation written two systems ago. A data strategy done properly answers these questions before the AI conversation even starts, and skipping straight to model selection because the data question feels slower is how a promising pilot turns into eight months of quietly cleaning spreadsheets nobody budgeted for.
Bad data does not fail loudly
This is the part that catches technical teams out. A broken pipeline throws an error. Bad data does not. A model trained on duplicated customer records, or fields that were free text for years before anyone enforced a dropdown, will still train, still produce a score, still look plausible on a dashboard. It is wrong in a way that is expensive precisely because it is quiet, and data quality problems of this kind tend to surface only once a model is already making decisions people trust. Fixing the foundation after launch costs several times what fixing it before launch would have, and it costs credibility too, because someone senior already told the board the model works.
None of this means finishing a full data programme before touching AI. It means being honest, for the one use case you have chosen, about whether the specific data it depends on is actually usable, and treating that as a real prerequisite rather than a footnote you will get to later.
Build versus buy, and why the honest answer is usually both
The build-versus-buy question gets asked as if it were binary, and most vendor conversations are happy to keep it that way, because a vendor's answer is rarely neutral. The honest answer is that almost every implementation ends up as a mix: bought infrastructure underneath, built logic on top, wired together by a team that understands both.
When buying is obviously right
Do not build what is already commoditised. Vector search, model hosting, evaluation tooling, basic monitoring: these are solved problems with mature products behind them, and building your own version is a way of spending a year reproducing something you could have licensed in a week. We see this most often with teams that enjoy the engineering more than the outcome, and building infrastructure feels like progress even when it delays the thing that was actually meant to ship.
When building earns its keep
Build where the logic is genuinely specific to how your business works: the rules that decide which cases need a human, the way your particular product catalogue gets matched to a customer's history, the judgement calls a domain expert would make that no off-the-shelf tool has been trained to replicate. This is also where most of the actual differentiation lives, if there is going to be any. Buying the entire stack from a single vendor is fast and can be the right call for a first project, but it tends to leave you with limited ability to change behaviour later, at exactly the point you have learned enough to know what you would change.
A reasonable rule of thumb: buy the plumbing, build the judgement. If a vendor's pitch is mostly about the plumbing, that is a sign the harder, more valuable part is still yours to design. Getting the operational side right, from deployment through to ongoing monitoring, is its own discipline, and MLOps is the practice most teams underestimate until the first model has been live for a few months and nobody quite knows who is watching it.
Sequencing: what actually has to happen in what order
Programmes that stall often have all the right pieces, assembled in the wrong order. Governance gets written before there is anything to govern. A platform gets procured before anyone has confirmed the data it will run on exists in usable form. A team gets hired before the first use case has been chosen, so they spend their first quarter arguing about which use case they were hired for.
The order things happen in is not a scheduling detail, it is most of the strategy. Get the sequence wrong and every piece can be individually well built and the programme still fails to ship anything at all.
A sequence that tends to work
Pick the use case first, using the criteria above. Then check the data it actually depends on, not the data estate in general. Then choose the narrowest build-versus-buy split that gets that one use case live. Then ship something small enough to fail cheaply and learn from. Governance, platform standardisation and a wider roadmap come after that first thing is live, informed by what you actually learned rather than by what a framework predicted you would learn.
This runs backwards from how most programmes start, which is with the governance framework and the platform decision, on the theory that getting the foundations "right" first avoids rework later. It usually just delays discovering what the real requirements were, because you cannot know what your governance needs to cover until something is running that needs governing.
Resourcing: who actually has to do the work
The resourcing conversation tends to focus on data scientists, because that is the visible, glamorous role, and the job adverts write themselves. The uncomfortable truth is that a first AI use case is rarely blocked by a shortage of modelling talent. It is blocked by the absence of someone who can get access to the right data, someone who understands the business process well enough to say whether an output is correct, and someone whose job it is to keep the thing running after the person who built it has moved to the next project.
The role nobody budgets for
That last one is the gap we see most often. A model gets built, it works in the demo, it goes live, and then the person who built it is reassigned, because the org chart treated the build as the deliverable rather than the beginning of an ongoing responsibility. Six months later nobody is watching for drift, nobody owns the retraining schedule, and the model is quietly getting worse until a customer complains. Budget for the running of the thing with the same seriousness you budget for building it, or do not be surprised when it decays.
Small teams beat big committees
A first use case is better served by a small team with the authority to make decisions than a large one that has to report through several layers before anything ships. Two or three people who can access the data, build the thing, and put it in front of real users will move faster and learn more than a twelve-person working group that meets weekly to discuss progress it has not yet made. Scale the team once the first thing has shipped and you know what actually needs scaling.
The failure modes that kill programmes before they ship
Most failed AI programmes do not fail on the model. They fail on one of a small number of organisational patterns that repeat with almost boring reliability.
The scope that keeps growing
A use case that starts narrow accumulates requirements as more stakeholders hear about it and want their concern addressed before launch. Each addition is reasonable on its own. Together they turn a three-month build into a fifteen-month one, and fifteen months is long enough for the original sponsor to move roles, the budget to get questioned, and the project to lose the momentum it needed to survive its first difficult review.
The proof of concept that was never meant to become real
A pilot gets built quickly, on a laptop, on a sample of data somebody happened to have handy, with none of the access controls, monitoring or error handling that production requires. It works. Everyone is pleased. Then someone asks when it goes live, and the honest answer is that turning a demo into something reliable enough for real customers means rebuilding most of it, a fact that was true from day one and got left out of the pitch that sold the pilot.
No one senior enough to make the calls nobody wants to make
Somewhere in every implementation there is a decision that requires two departments to agree that one of them has been doing something wrong. Whose customer record is correct. Which team's process the AI should follow when the two disagree. Without someone with the authority to close that argument, it gets deferred, and a deferred decision has the same effect on a timeline as an unmade one.
Measuring the model instead of the outcome
A team can spend months improving an accuracy metric while the business question that justified the project in the first place goes unanswered. The model gets better by every technical measure and the programme still gets cancelled, because nobody can point to a number the business actually cares about that moved. Decide what "worked" means in business terms before the build starts, not after the model is already good at the wrong thing.
Where to start
Pick one use case, not three and not eleven. Choose it for fast feedback and usable data rather than for how well it will read in a board pack. Check the actual data it depends on before you check anything else, because that is where most delays are quietly hiding. Decide what you will build and what you will buy for that one thing, ship the smallest version that can go live safely, and only then start writing the governance and the roadmap, informed by what shipping the first one actually taught you.
None of this is exotic. It is mostly the discipline of doing one thing properly instead of planning eleven things in parallel, and resisting the pull toward a bigger, tidier strategy document when what the organisation actually needs is a single working example it can point to. If you are trying to get an AI programme past the steering committee stage and into something running, talk to us.