Eighteen months after the initial meeting, the programme still has a name, a budget code, and a steering committee. The committee convenes on the second Tuesday of every month.
It doesn't have anything running in production.
The slide deck now contains sixty pages. In the fourth month, the list of use cases grew from three to eleven candidates. That number has not been reduced since.
An AI implementation strategy tackles four questions: which use case will be implemented first, what data will be used, who will be responsible for development and maintenance, and how success will be measured. All other elements, including maturity models, governance charters, and roadmaps, remain secondary until these four questions are answered for a single project rather than for a list of many projects.
An AI implementation strategy responds to a more specific set of questions than most programmes realise. It must specify what is being built first, which data will be used, who will build it, and how success will be measured. Maturity models, governance charters, and long-term roadmaps are secondary to these items. These frameworks often fail if the four underlying questions are not settled first.
Shipshape Data builds data and AI systems. The scenario described is a common cause of programme failure. The issue is typically not the quality of the ideas, but a reluctance to pick one specific project from many options. This guide explains how to choose a viable first use case and identifies the required data infrastructure. It also discusses the decision to build or buy software, the correct way to schedule and staff the work, and the specific errors that cause programmes to fail before launch.
Why AI strategy often fails to address specific business needs
If you ask ten people to define the goals of an AI strategy, you will get ten different but logical responses. Some will suggest reducing expenses. Others will focus on automating repetitive tasks to help employees. Some will prioritise matching the public announcements of competitors. Others will aim to improve employee retention by making the company appear modern.
None of these is wrong.
Problems arise when a strategy document tries to address all ten goals at once. A document that attempts to answer every question fails to make a specific commitment. A committee can review such a document each month for years without ever being proven wrong.
The document that always says yes
An effective strategy excludes specific options. It defines the current domain, the immediate timeline, and the specific team involved. Most documents given at the start of a project do not follow this approach. Instead, they list every department that could use AI and assign a maturity score to each. These documents delay the final decision for meetings that are often postponed. The result is a document that describes the general environment well but gives no instructions for immediate action.
What the document should resolve
You need to address four specific points. First, identify which use case will launch first. Second, determine whose data the system uses and confirm that the data is ready for use. Third, establish who is responsible for the initial build and who will manage it after it goes live. Fourth, define success with a specific metric that can be verified three months after launch. If your strategy document answers these four questions for a single use case, you have a functional strategy. If the document addresses related questions for many use cases, you have a list of options rather than a plan that will produce a finished product.
Choosing a single first use case instead of many
In the workshop version of this exercise, participants usually create a long list and score items based on business value and feasibility; this process appears thorough. In practice, most items receive medium or high scores for both categories. This occurs because participants want their specific ideas to stay on the list, and the vague criteria let all ideas persist. The list may look shorter on paper, but the actual number of projects stays the same.
Evaluate data readiness instead of ambition
The factor that determines whether a first project succeeds or fails is whether the necessary data is already available, accessible, and usable. A project that offers high business value but requires reconciling five separate systems is not a suitable first project, regardless of its potential. A smaller project that uses data that is already clean and already governed will be completed much faster. This approach lets the organisation understand the requirements of running AI in production. That experience is more valuable than a larger project because the knowledge can be applied to all future work.
The domain expert test
You can use a simpler filter than most scoring matrices. Determine if a domain expert can sit next to the output and tell you if it is correct within one minute. A model that drafts customer support replies passes this test. A support agent can read the draft and spot nonsense immediately. A model that predicts churn six months out fails this test. No one can verify that prediction for six months. By then, the model will have been running unsupervised on real decisions for half a year. You should choose a use case where someone can catch a mistake quickly. Do not choose the case where the mistake is theoretically larger but stays invisible until it becomes expensive.
The essential data foundation
Every programme we have seen fail includes a similar finding in its review. The teams involved assumed the data was of higher quality than it actually was. These teams did not intend to build on an unstable foundation. The data appeared correct during initial observations. No one had allocated the time or budget needed to perform the detailed inspection required to identify specific errors.
What "ready" means, concretely
Readiness consists of a list of specific items to check rather than a maturity score out of five. You must confirm whether the necessary fields exist and whether most rows contain data. You need to determine if multiple systems store the same information and which system is the primary source when data conflicts. You should examine a sample of one hundred actual rows instead of relying on outdated schema documentation. A data strategy addresses these issues before you begin discussing AI. If you skip to model selection because data preparation seems slow, a pilot project may result in eight months of unbudgeted spreadsheet cleaning.
Bad data doesn't fail loudly
Technical teams often overlook this specific issue. A broken pipeline generates an error message, but poor data quality does not. A model will still finish its training and produce plausible results even if it uses duplicated customer records or inconsistent text fields. These errors are costly because they are hard to detect. data quality problems usually become apparent only after a model is used to make decisions. Fixing these foundational issues after a launch is far more expensive than addressing them beforehand. This also damages professional credibility because leadership has likely already reported the model's success to the board.
You do not need to complete an entire data programme before you start using AI. You must instead determine if the specific data required for your chosen use case is usable. You should treat this data readiness as a mandatory requirement for that project.
Build versus buy, and why the honest answer is usually both
People often discuss the choice between building or buying software as a simple trade-off between two options. Vendors usually encourage this view because they have a specific interest in selling their products. In practice, most projects require a combination of both approaches. Organisations typically purchase the underlying infrastructure and then build custom logic on top of it. A team with knowledge of both areas must then integrate these components.
When purchasing is the correct choice
Don't build what is already commoditised.
Vector search, model hosting, evaluation tools, and basic monitoring are solved problems with mature products available. Building your own versions of these tools can take a year to reproduce what you could licence in a week. This occurs most frequently with teams that prefer engineering tasks over final outcomes. Building infrastructure can feel like progress, but it often delays the actual product release.
When building earns its keep
Build your own systems where the logic is specific to your business operations. This includes the rules for assigning cases to human staff, the methods for matching your product catalogue to customer history, and the specialised decisions that standard software cannot replicate. These areas are where your company distinguishes itself from competitors. Purchasing a complete software package from one vendor is a fast approach that may suit an initial project. However, this choice often restricts your ability to modify the system later, particularly after you have gained the experience necessary to identify which changes are needed.
A reasonable rule of thumb: buy the plumbing, build the judgement. If a vendor's pitch is mostly about the plumbing, that's 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: the required order of events
Programmes often stall because the steps are taken in the wrong sequence. Organisations sometimes establish governance structures before they have any assets to manage. They may purchase a platform before confirming that the necessary data is available in a usable format. In other cases, a team is hired before a specific use case is identified. This leads the team to spend their first few months debating which project they should be working on.
The order of events is a primary part of the strategy rather than a minor scheduling detail. If the sequence is incorrect, the programme may fail to deliver any results even if every individual component is constructed well.
A sequence that is usually effective
Select a use case based on the criteria provided. Review the specific data required for that use case instead of evaluating your entire data collection. Determine the simplest combination of custom development and existing tools needed to launch that single use case. Release a small version of the project so you can identify issues at a low cost and gain practical experience. Address governance, platform standards, and long-term planning only after the first project is operational. Use your actual results to guide these decisions rather than relying on theoretical frameworks.
This process is the reverse of how most programmes begin. Usually, organisations start with a governance framework and a platform choice because they believe establishing foundations early prevents future rework. This approach typically delays the discovery of actual requirements. You cannot determine what your governance must address until you have a functioning system that requires oversight.
Resourcing: who has to do the work
Discussions about resourcing usually focus on data scientists because that role is high-profile and easy to recruit for. However, a first AI project is rarely delayed by a lack of modelling expertise. Instead, projects are typically blocked by a lack of staff who can access the necessary data, staff who understand business processes well enough to validate outputs, and staff responsible for maintaining the system after the initial developer moves to a different project.
The role nobody budgets for
The final point describes the most common problem. Organisations often build a model that works during a demo and then reassign the developer after the launch. This happens because the organisation views the initial build as the final product rather than the start of a long-term responsibility. Six months later, no one monitors the model for drift or manages the retraining schedule. The model loses accuracy until a customer reports a problem. You must budget for ongoing operations with the same rigor you use for the initial development. If you do not fund the maintenance, the model will eventually fail.
Small teams beat big committees
A small team with decision-making authority handles a first use case more effectively than a large team that must report through multiple layers of management. Two or three people who can access data, build the product, and deliver it to users will work faster and gain more information than a twelve-person working group that meets weekly to discuss incomplete tasks. You should scale the team only after the first version has shipped and you understand which areas require more resources.
The failure modes that kill programmes before they ship
Most AI programmes do not fail because of the model. They fail because of a few organisational patterns that occur consistently.
Increasing project scope
A narrow use case often gains more requirements as stakeholders learn about it. These stakeholders want their specific concerns addressed before the project launches. Each individual addition may seem logical. However, these additions can extend a three-month build into a fifteen-month project. Fifteen months is enough time for the original sponsor to change roles or for the budget to be questioned. The project may then lose the momentum required to pass its first difficult review.
The prototype that was not intended for production use
A pilot is rapidly created on a laptop with a limited sample of the data that is available. It does not include the access controls, monitoring, or error handling required for a production environment.
It works. Everyone is pleased.
Eventually someone asks for the launch date. The truthful answer is that stabilising a demo for real customers means rebuilding most of the system. This fact was true from the start, yet it was not disclosed in the initial sales pitch for the pilot project.
No one senior enough to make the calls nobody wants to make
Each implementation reaches a stage where two departments must agree that one of them used an incorrect method. This situation arises when choosing the correct customer record or determining which team's process the AI should follow in a conflict. When no one has the authority to settle these disputes, the decision is postponed. A postponed decision affects a project timeline just as a decision that is never made would.
Measuring the model rather than the outcome
Teams frequently spend months enhancing accuracy metrics without addressing the original business question. A project may be cancelled even when the model improves on every technical measure. This occurs when nobody can demonstrate a change in the specific numbers that the business values. Success should be defined in business terms before building begins. Do not wait until the model performs well on the wrong metrics to decide what success means.
Where to start
Pick a single use case. Do not pick three or eleven. Select this case based on how fast you can obtain feedback and usable data, not on how it will look in a board report. Confirm the required data before undertaking other tasks, because data problems cause most delays. Determine which components to build and which to buy for this particular case. Deploy the smallest version that can operate safely. Create the governance documents and the roadmap only after this deployment, using the information gathered during the process.
These methods are standard. The process demands discipline to finish one task correctly instead of planning many tasks simultaneously. You should resist the urge to produce a large strategy document when the organisation actually needs a functional example. If you want to move an AI programme from the steering committee phase into active operation, talk to us.
When the reading becomes a roadmap question, our AI strategy consultants will honestly tell you what the work requires and what it depends on.
If you are ready to choose a provider, our buyer's checklist for choosing an AI consultancy includes twelve questions to ask before signing a contract.
If you are unsure whether the first use case is ready to start, score it against an honest AI readiness checklist before committing budget.
Once the first use case is chosen, the delivery work is covered in taking an AI system from pilot to daily use.
Frequently asked questions
What does a responsible AI strategy and implementation pathway look like?
The article describes this as a prioritisation process: first identify the use case, then review the data it needs. Next, choose the most limited build-versus-buy approach, and finally, launch a minimal product to enable low-cost failure. Governance and a broader plan should come after the initial release, using lessons learned from that first implementation, instead of being set up beforehand.
What does AI strategy implementation involve?
In practice, this means deciding four factors for a single use case: which will be released first, whether the required data is ready, who is responsible for building and later maintenance, and which specific metric will define success three months later. The article says that a document covering these questions for eleven different use cases is a list of options rather than a strategy.
How do you pick the first AI use case for an implementation strategy?
Pick a use case based on data readiness instead of ambition. A narrow project with clean data will finish faster and deliver more organisational learning than a large project that depends on five separate systems. You should also use a domain expert test. Select a use case where an expert can verify the output within one minute. Avoid projects where errors could stay hidden for several months.
Should you build or buy when implementing AI?
The practical approach is often to do both. You should purchase commodity services such as vector search, model hosting, and basic monitoring. Creating your own versions of these tools delays your product release. You should develop the logic that is specific to your business. This includes the rules for human intervention and the methods for matching product catalogues to customer history. These custom elements give you the real competitive advantage.
What are the most common failure modes in AI implementation?
The article lists several common project risks. Scope frequently expands as stakeholders add seemingly reasonable requirements, which can turn a three-month project into a fifteen-month project. Another problem is building a proof of concept without production-grade access controls or monitoring, which demands a full rebuild before the system can go live. Projects also struggle when no senior leader is present to settle disagreements between departments. Finally, the text cautions against focusing only on model accuracy while neglecting the specific business outcome the project was meant to achieve.