I have watched companies spend six months and €400,000 on an "AI transformation initiative" that, when you strip away the vendor workshops, the capability assessments, the pilot programmes, and the governance frameworks, was trying to do one thing: summarise a PDF and extract five fields from it. I wrote that prompt in thirty minutes. It worked on the first try.
This is not a failure of intelligence. It is a failure of organisational honesty. The elaborate transformation programme was not a technical plan — it was a political manoeuvre disguised as one. The complexity was the point. Complexity creates budget, headcount, committees, and timelines. Simplicity creates accountability.
The Pattern I Keep Seeing
The engagement always starts the same way. A leadership team has decided that the company needs to "do AI." This is often triggered by a competitor announcement, a board question, or a consultant's market map. The instinct is correct — there is genuine value to be captured. The execution goes sideways almost immediately.
The first move is to hire a strategic advisory firm or bring in a platform vendor. They run a series of workshops. There is a use case taxonomy. There is a capability maturity assessment. There is a heat map of opportunity. After eight to twelve weeks, there is a 60-page strategy document and a recommendation to stand up a Centre of Excellence.
Nobody has built anything yet.
The next move is to commission a pilot. The pilot has a steering committee, a workstream structure, and a 16-week timeline. There is a data readiness assessment, a security review of the vendor platform, and a change management plan. At week 12, the pilot produces a demo. The demo works. There is applause. The steering committee commissions phase two.
Six months in, the organisation has spent significantly on consultants, platform licences, and internal coordination time. They have a demo, a strategy document, and a phase-two plan. No user has touched the product in production.
Meanwhile, a competitor with four engineers and a clear-headed product manager deployed a working tool to 200 internal users in three weeks, iterated it for six weeks based on real feedback, and is now measuring productivity gains.
Why Organisations Do This
Calling this dysfunction is accurate but not useful unless you understand the mechanism.
The transformation frame expands scope by design. When you call something a "transformation," you implicitly commit to changing multiple systems, processes, and people simultaneously. The scope expansion is not irrational — transformations do require those things eventually. But it is premature. You have not yet established that the core use case works at all. Proving it first, at minimal cost, makes every subsequent investment decision faster and less risky. Starting with the transformation frame is betting the whole thesis before running the experiment.
Complexity is how organisations manage political risk. If an initiative is simple and fails, accountability is clear. If it is complex — multi-vendor, multi-team, multi-phase — failure is distributed and ambiguous. Nobody is held responsible for a 16-week pilot that "produced learnings." A two-week prototype that does not work is a career event. The structural incentive pushes toward complexity, even when simplicity would produce better outcomes faster.
Vendors and consultants have no incentive to recommend simplicity. A prompt engineering session that solves your problem in three days is not billable at transformation rates. A twelve-month capability-building programme is. I am not impugning anyone's integrity — the incentives are structural. But you need to be clear-eyed about whose interests are being served by the scope of the recommendation you received.
Strategy documents are not proof of anything
A 60-page AI strategy document is evidence that someone spent time thinking about AI. It is not evidence that the proposed solutions work, that users want them, or that the organisation can execute them. The only proof that something works is a working thing used by real people.
The Diagnostic: What Are You Actually Trying to Do?
When I join an organisation mid-transformation and find it stalled, I start with a simple exercise. I ask the steering committee to describe the outcome they want — not the initiative, not the programme, not the platform — the outcome. What would be different for which person doing which task?
Answers typically fall into three categories:
| What They Say | What It Usually Is | Time to Working Prototype |
|---|---|---|
| "We want to leverage AI across the business" | No specific use case yet | Not applicable — define a use case first |
| "We want to automate our document processing" | Extraction + classification task | 1–3 days with a frontier model API |
| "We want an intelligent assistant for our team" | RAG over internal documents | 5–10 days with a vector store and standard retrieval pipeline |
| "We want to reduce call centre handle time" | Summarisation + suggested response | 3–7 days to a working demo |
| "We want to personalise customer communications" | Structured generation with customer data | 1–2 weeks including data integration |
| "We need an AI platform strategy for the enterprise" | Actually complex — proceed carefully | 6–12 weeks for a real architecture assessment |
The last row is the only one where a long timeline is justified. Everything above it should have a working proof of concept in your hands within two weeks, before any further investment is committed.
If someone is telling you it will take six months to validate whether a document summarisation use case is viable, they are either solving a genuinely different and harder problem than the one described — or they are not moving with appropriate urgency.
What "Start Simple" Actually Means in Practice
Starting simple is not the same as being naive. It means sequencing correctly: validate the use case before investing in the platform.
The sequence I run for clients — and the point at which production investment becomes justified:
Week 1: Define and prototype. Write the clearest possible description of the task — input, expected output, edge cases, quality criteria. Build the simplest possible implementation using a frontier model API and a few sample inputs. Do not build infrastructure yet. Use the API directly. The goal is to answer one question: does the model produce acceptable outputs for this task, given well-prepared inputs?
Week 2: Test against real data. Take 50–100 real examples from your actual data. Run the prototype. Measure quality manually or with a lightweight eval. Identify the failure modes. Determine whether they are fixable with prompt engineering, retrieval improvements, or data cleaning — or whether they indicate a fundamental problem with the use case.
Weeks 3–4: Ship something to real users. Not a demo to a steering committee. Something that a real user can interact with to do a real task. The feedback from 20 users using a real tool for two weeks is worth more than 12 weeks of requirements documentation.
Only after that validation should you invest in production infrastructure, security hardening, vendor selection, and organisational change.
The prototype is not a throwaway — it is the requirements document
A working prototype answers questions that no amount of upfront analysis can answer: Does the model handle the edge cases in your actual data? What does a good output look like when users see it? Where does the integration with existing systems create friction? Ship the prototype fast, learn from real use, and let that inform the architecture.
The Legitimate Complexity Cases
I want to be precise here, because "start simple" can be used to under-invest in things that genuinely require investment.
Legitimate complexity in AI programmes arises from four sources:
Data readiness. If your core use case requires structured data that currently lives in disconnected systems with poor quality, fixing that is real work. It is not AI work — it is data engineering work — but it must be done. The mistake is letting data readiness become a reason to delay the prototype. Prototype with the data you have, even if it is messy. The prototype will tell you which data quality problems actually matter.
Security and compliance. Regulated industries — financial services, healthcare, insurance — have genuine requirements around data residency, model access, auditability, and model risk governance. These are real constraints. They take time to satisfy. But they should be scoped to the specific use case, not used as a reason to delay all experimentation.
Enterprise integration. Connecting a new AI capability to legacy systems — ERPs, core banking platforms, policy administration systems — is often genuinely hard. Integration complexity is real. The mistake is leading with integration architecture before validating that the AI output is worth integrating.
Organisational change. Deploying AI in ways that change workflows, job descriptions, or headcount creates change management requirements. This is real and should not be minimised. It should also not be the reason nothing gets built.
None of these legitimate complexities justify a six-month timeline before users see anything. They justify careful sequencing — validate the AI first, then solve the integration, compliance, and change management problems for a thing you have already proven works.
What a Good Outcome Looks Like
The best AI programmes I have seen share a structure: small teams, short cycles, real users, early.
A team of three to five people — one engineer, one product/domain expert, one person who owns the data access — can validate most enterprise AI use cases in two to four weeks. The output is not a strategy document. It is a working prototype, a measured quality baseline, a list of known failure modes, and a clear go/no-go recommendation for production investment.
That prototype, used by 20 real users for two weeks, produces more useful strategic information than any capability assessment. It tells you whether users want to use the tool, what they actually do with it, where the quality falls short in practice, and what the real integration requirements are.
The organisations that move fast on AI are not the ones with the biggest budgets or the most sophisticated vendor relationships. They are the ones with the discipline to start with a falsifiable hypothesis — "this use case works with current AI capabilities" — and test it before committing to a programme.
The ones that move slowly are the ones that turn a hypothesis into a transformation before they know if the hypothesis is true.
Start with the prompt. Then build the platform.
If your organisation is mid-transformation and unsure whether you are building the right thing, or if you want to run a rapid validation of an AI use case before committing further budget, let's talk — book a 30-minute discovery call and we will cut through the noise.