Posted on

Those Who Carry Out the Plans Should Make the Plans

A flowchart depicting an iterative cycle with stages: Define, Design, Improve, Deploy, emphasizing team collaboration and continuous improvement.

Why project success needs people readiness, not just data readiness

In what feels like another life, I studied Business and Finance. I was young, curious, and absorbing everything I could about how organisations worked and why some of them worked better than others. It was during that time I came across Peter Drucker and Tom Peters. Drucker shaped how I thought about organisations and the people inside them. From Peters, one line lodged itself somewhere permanent.

“Those who carry out the plans should make the plans.”

I’ve thought about that line in boardrooms, on project reviews, at customer events, and in conversations where someone is explaining, with complete confidence, why the new system is going to transform the business. I think about it every time I see an AI deployment that looks impressive on a slide and doesn’t survive contact with the people it was built for.

It’s not a line about technology. It’s a line about respect — for the expertise, the context, and the judgement of the people who actually do the work. And it is, in my experience, the most frequently ignored principle in the management of change.

This Failure Mode Is Not New

Let’s be honest about something. The failure mode we’re describing when we talk about AI projects ending up in the PoC graveyard is not new. It is not a product of machine learning complexity, data pipeline debt, or foundation model hype. It is a pattern that has been repeating itself across every major wave of enterprise technology for the last thirty years.

ERP systems that were technically correct and operationally ignored. CRM platforms that the sales team logged into once and then routed around via spreadsheets. Lean manufacturing programmes that consultants designed, managers approved, and shop floor workers gently buried. The technology changed. The failure mode didn’t.

In each case, the pattern was the same. A solution was designed by people who understood the technology and approved by people who controlled the budget. The people who were going to use it every day — the ones who knew where the edge cases lived, where the workarounds had evolved, and why the process worked the way it did rather than the way the manual said it should — were consulted late, informed later, and left to figure it out for themselves once the project team had moved on.

IT projects have been going live or dying for decades. What has changed is the amplification. AI deployments carry bigger expectations, bigger investment, and bigger visibility than a CRM rollout ever did. The failure, when it comes, is correspondingly louder — and the case study about what went wrong gets written faster.

The Quiet Failure

There is a specific kind of AI failure that deserves its own name. Not the dramatic kind — the model that produces obviously wrong results, the bias scandal, the infrastructure collapse. The quiet kind. The proof of concept that worked beautifully in the demo, received senior sign-off, and then never made it to production.

The PoC graveyard is full of technically impressive work. Models that performed well on the test set. Dashboards that visualised the right things. Business cases that stacked up on a spreadsheet. None of it survived — not because the technology failed, but because the organisation wasn’t ready to receive it.

Nobody had been asked whether the process the model was designed to improve was actually the process people ran. Nobody had involved the support team who would have to explain the system’s recommendations to confused customers. Nobody had thought about what happened when the model got it wrong and someone needed to know why.

The people who would carry out the plan had not been asked to make it. And so, quietly and without drama, they didn’t carry it out either.

The Half of Readiness Nobody Talks About

There is a conversation I have frequently about data readiness — about EDA¹, about the gap between data storage and data strategy, about the things that have to be true before a model can do useful work. That conversation is important and underserved, and it is a prerequisite for AI that’ll deliver value.

But data readiness is only one side of the coin. The other side is people readiness. And in my experience it receives a fraction of the attention.

People readiness asks different questions to the ones we usually focus on. Do the people who will use this system understand what it is doing and why? Do they trust it enough to act on its recommendations — or will they systematically override it, quietly and without logging the fact that they’ve done so? Do they have a genuine channel to raise concerns, flag errors, and feed back what they’re seeing on the ground — and do they feel ownership over the system, or merely obligation toward it? These are not soft questions. They are the questions that determine whether the technical work translates into business value or sits on a server being politely ignored.

There is also the black box problem. People do not trust what they cannot see into. If a system produces a recommendation and nobody can explain why — not in general terms, not in the language of the person being asked to act on it — then the most rational response is to ignore it. Not because the person is resistant to change, but because professional judgement requires understanding. A clinician, an underwriter, a logistics manager, a credit analyst — none of them can be expected to stake their reputation on an output they cannot interrogate. Explainability is not a technical nice-to-have. It is a precondition for trust, and trust is a precondition for adoption. Drucker’s observation that culture eats strategy for breakfast was not a warning about bad strategies. It was a warning about what happens when the human layer is treated as a variable rather than a foundation — and it applies here with full force.

An AI system without people readiness is like a well-engineered road built in the wrong direction. The construction is sound. Nobody uses it. The route everyone actually takes is the muddy path that existed before the contractors arrived.

Inclusion Is Not a Ceremony

When organisations talk about involving users in an AI deployment, they often mean something narrower than they should. A workshop near the start. A sign-off meeting near the end. A training session the week before go-live. Boxes ticked. Change management complete.

That is not inclusion. That is notification with a collaborative wrapper around it.

Genuine inclusion means the people closest to the process are in the room when the use case is defined. It means their knowledge of how the work actually happens — not how it is documented, but how it is actually done, with all its workarounds, exceptions, and institutional memory — shapes the design. It means their concerns about what happens when the model is wrong are taken seriously as design constraints, not managed as resistance to be overcome.

The winemaker who walked in with a printout challenging Clare’s model — a story I wrote about in an earlier post on data readiness — was not being obstructive. He was being exactly what a domain expert is supposed to be — the person who knows things the model doesn’t, and who will not pretend otherwise just because the accuracy metric looked good. That challenge made the system better. It surfaced a failure mode in Premium recall that would have cost the winery real money. It earned the model a place in the operation rather than a quiet demotion to the corner of a server room.

That dynamic — expert challenge leading to system improvement — is only possible when the people who carry out the plans feel authorised to question them.

A Trophy Is Not a Deployment

An AI system that goes live and then stays static is not a deployment. It is a trophy.

Real-world conditions change. The distribution of incoming data shifts. The business process the model was trained on evolves. Edge cases accumulate. The model that was fit for purpose in January is carrying assumptions from January into December, and nobody has checked whether those assumptions still hold.

The feedback loop is not a nice-to-have that gets added in a later phase. It is the mechanism by which the system earns continued trust, adapts to reality, and improves over time. And it only functions if the people using the system have a genuine channel to report what they are seeing — the errors, the gaps, the cases where the recommendation didn’t match the operational reality — and confidence that those reports will be acted on.

This is continuous improvement applied to AI. It is not a new idea. It is Toyota’s production system, Deming’s quality cycle, ITIL’s Continual Improvement practice — the basic principle that the people closest to the process are its best source of intelligence about where it is failing. ITIL frames this as a structured loop: identify opportunities, take action, measure outcomes, and feed the learning back in. The same logic applies here, with one important addition. What is new is the requirement to apply it to a system that learns — which means that the feedback the frontline provides does not just inform the next process review. It shapes what the model learns next.

Those who carry out the plans should not just make them. They should improve them. Continuously. With a mechanism that makes their input count.

When Change Has Actually Taken Hold

Throughout my career I have always taken pleasure in watching technology, when done right, change a business for the better. Seeing people work in a different, more productive way after a deployment — there is a quiet pride in that moment. A successful AI deployment in a business process does not look like a technology project that has gone live. It looks like a change that has taken hold. It becomes just the way things are done now. Over time, this new way becomes part of the fabric of the organisation — and then it disappears. It stops being the AI project. It is simply how work gets done. Quiet AI. Boring AI. That is what success looks like.

The people using the system understand what it is doing well enough to work with it intelligently — to know when to trust it, when to question it, and when to escalate. They have been part of the design process in a meaningful enough way that the system reflects how they actually work, not how someone assumed they worked. They have a channel to feed back what they are seeing, and evidence that the channel is listened to.

To achieve this, the leaders overseeing the deployment cannot simply hand it over to a technology team and declare it done. They have to accept that adoption is a longer and less linear process than implementation, and that their job after go-live is to create the conditions for it — removing blockers, taking concerns seriously, celebrating the early wins that build confidence in the wider team, and building a feedback loop worth listening to.

And somewhere in the governance structure, someone owns the agent — or the model, or the system — not as infrastructure to be maintained but as a product to be evolved. Someone who can answer, six months after go-live, whether the system is doing what it was supposed to do, what it has learned, and what the next iteration looks like.

None of this is complicated. Most of it has been known for decades. Tom Peters was writing about it before the internet existed. The reason it keeps being rediscovered is that the technology changes faster than the organisations adopting it do — and in the rush to demonstrate capability, the human layer gets treated as an afterthought rather than a foundation.

Closing Thought

AI is not different from any other technology introduction in the most important way: it succeeds or fails on adoption, and adoption is a human problem before it is a technical one.

Data readiness matters. Model selection matters. Infrastructure matters. But none of it delivers value if the people who are supposed to use the system don’t trust it, weren’t involved in building it, and have no way to improve it once it’s live.

The PoC graveyard will keep filling up as long as organisations treat change management as the last item on the project plan rather than the first.

Those who carry out the plans should make the plans. It was true when Tom Peters wrote it. It is still true now.

Create the future with all your stakeholders. No black boxes. No PoC graveyards.

Change management has to be built in, not bolted on. And it starts and ends with your people.

¹ EDA — Exploratory Data Analysis: The process of examining a dataset before building a model — profiling its structure, spotting missing values, identifying outliers, and understanding distributions. Think of it as the due diligence phase: the work that tells you whether your data is actually fit for the purpose you have in mind, before you commit to building anything on top of it. Finding the signal in the noise.

Posted on

Cool Story: Why Business Acumen and Domain Knowledge Are the Missing Ingredients in AI Strategy

Illustration of a presenter at a podium with an analysis chart, and seated audience members appearing distracted and disengaged, indicating lost communication signals.

I’ve seen many customer presentations. You know the ones: the pitch is well rehearsed, the content is polished and the delivery is flawless. At that point I watch the room. I’m checking the attention span. I see disengagement. Phones being scrolled, emails that could wait being sent, faces just saying “This isn’t relevant.”

However, the presenter goes home thinking he’s done a good job. In fact, so good he thinks — no one asked any questions.

When my boys were troublesome teenagers they’d say in a rebellious way, with more than a hint of sarcasm, “Cool story dad.” This was teenager speak for — what you’re saying is just not important to me.

I believe customers need more than that Cool Story. This is why business acumen and domain knowledge matters.

The Comfort Zone Problem

Here’s what I observe in the technology channel every day. Vendors and partners are deeply comfortable talking about servers, storage, networking, and cloud. They know the architecture. They know the benchmarks. They know the competitive positioning. Ask them about IOPS, latency, or core counts and they’ll talk for an hour.

But walk into a room with a CFO, an Operations Director, or a Head of Supply Chain — and ask them to have a conversation about how AI can genuinely help their business — and the comfort zone disappears fast.

Because that’s not a technology conversation. That’s a business conversation. And most of the technology channel hasn’t been trained to have it.

The result? Another Cool Story. Well rehearsed. Polished. Flawless.

And completely irrelevant to the person sitting across the table.

What Business Acumen Actually Looks Like

I’ll be honest — I take this for granted. I probably shouldn’t.

My first degree was in Business and Finance. Before I spent thirty years in enterprise technology I worked in the motor industry, retail, and pharma. I’ve sat on both sides of the table — as someone trying to run a business and as someone trying to help businesses use technology better.

That background gives me a lens that I’ve come to realise isn’t as common as it should be.

When I walk into a customer conversation I’m not thinking about products, features, feeds and speeds. I’m thinking about how the business actually makes its money, and where value is quietly being left on the table. I’m thinking about which decisions are being made badly, or not being made at all, and which processes are broken, slow, or dependent on people doing work they shouldn’t need to do by hand. Above all, I’m thinking about what good would actually look like, in terms a board would recognise — not in terms a vendor slide deck would recognise.

These aren’t AI questions. They’re business questions. And they’re the questions that determine whether an AI conversation goes somewhere real or becomes another Cool Story.

The Discovery Conversation

The most important AI conversation isn’t about models or infrastructure. It’s the discovery conversation — the one where you sit with a business leader and genuinely explore where AI and data analytics can make a difference.

Not future promises. Not theoretical possibilities. Real, practical impact. Here and now.

That conversation requires two things that most technology partners simply don’t have enough of. Business acumen — understanding how organisations work, how value is created, how decisions get made, and how to quantify the cost of a problem worth solving. And domain knowledge — understanding the specific industry, its language, its constraints, its regulation, and what good looks like in that context.

You cannot have a credible AI conversation in pharma if you don’t understand what a clinical trial looks like. You cannot have a credible AI conversation in retail if you don’t understand margin pressure, shrinkage, and the brutal reality of demand forecasting. You cannot have a credible AI conversation in manufacturing if you don’t understand what unplanned downtime actually costs.

Generic AI knowledge is becoming table stakes. Contextual judgment is the differentiator.

AI Is Not a Catalogue Item

Some can be forgiven for thinking AI is a catalogue of use cases. Scroll through any vendor presentation and you’ll find them — neatly packaged, impressively labelled, complete with ROI estimates and customer logos.

If only it was that simple.

Use cases can be interesting. They can be positive pointers to possible business solutions. They can spark a conversation, open a door, or help a business leader see what’s possible in their industry. I’m not dismissing them.

But here’s the problem. A catalogue of use cases is someone else’s answer to someone else’s question. And the moment you lead with it, you’ve already made a fundamental mistake — you’ve started with the solution before you’ve understood the problem.

The real work starts somewhere else entirely.

It starts by understanding the business. Its processes. Its people. And understanding the data — not just the data that exists, but the data that’s missing and hasn’t even been acquired yet. It means following the processes and the way decisions actually get made, not how the org chart says they should be made, but how they really get made. The friction that everyone knows about but nobody has fixed. The data that exists but nobody trusts. The process that runs on spreadsheets and institutional memory because nobody ever got around to doing it properly.

That understanding cannot come from a use case catalogue. It can only come from a conversation — a genuine discovery conversation, grounded in business acumen and domain knowledge, where the right questions get asked and the answers actually get heard.

A use case tells you what AI has done for someone else.

Business acumen tells you what AI can do for this business, right now, with the data and processes and people that actually exist.

That’s the difference. And it’s everything.

The Golden Process

In my AI Reality framework I talk about finding the Golden Process — the business process that is ready for AI right now. The one where the data exists, the problem is real, the ROI is quantifiable, and the organisation has the appetite to act.

You cannot find the Golden Process from a slide deck.

You find it by asking the right business questions, listening carefully to the answers, and having enough domain knowledge to recognise the opportunity when it appears.

A partner who only knows technology will walk past the Golden Process every time. Not because they’re not intelligent. But because they’re looking at the wrong map.

The right map isn’t a product catalogue. It’s an understanding of how the business works and where it hurts.

What the Room Looks Like When You Get It Right

I presented at a Partner event recently. I talked about AI Reality — practical AI, data readiness, real use cases, honest outcomes. No hype. No future promises. Just what’s working now and why.

Not one person was on their phone.

Afterwards they asked for my slides. I pointed them to my blog site. “It’s all here,” I said. “And I wrote it.”

The LinkedIn connection requests came in before I’d left the building.

That’s what happens when a room full of people hear a business conversation instead of a technology pitch. They lean in. They engage. They want more.

Because it’s relevant. Because it’s real. Because it respects their intelligence and their time.

No Cool Story. Just signal.

The Evolution of the Technology Partner

Let me take you back thirty years.

A technology partner’s job was straightforward. Understand the product. Know the speeds and feeds. Build the relationship. Win the deal. Rack the kit. Repeat.

And for thirty years — that was enough. Customers needed servers. Partners sold servers. Customers needed storage. Partners sold storage. Networking. Cloud. Virtualisation. Each wave brought new products to learn, new certifications to collect, and broadly the same conversation to have.

“Here’s what it does. Here’s what it costs. Here’s why ours is better than theirs.”

It worked. For a long time it worked very well.

But something has shifted. And the Partners who haven’t noticed yet are about to find out the hard way.

The World Changed. The Conversation Didn’t.

AI didn’t just bring a new product category. It brought a fundamentally different kind of customer conversation.

Because the customer isn’t asking “what does it do?” anymore.

They’re asking “what problem does it solve — for my business, in my industry, with my data, right now?”

That’s a different question. And it requires a different kind of partner to answer it.

The technology partner who built their career on product knowledge, competitive positioning, and relationship selling isn’t suddenly irrelevant. But they are incomplete. Because the customer has moved on — and the conversation they want to have requires something that thirty years of selling servers simply doesn’t build.

Business acumen. Business domain knowledge. The ability to walk into a room and talk about outcomes before products.

What Good Looks Like Today

The most relevant technology partner in 2026 isn’t the one with the most certifications. It isn’t the one with the biggest product portfolio or the most competitive pricing.

It’s the one who walks into a customer conversation and demonstrates — before a single slide is shown — that they understand their business, and that they’re genuinely interested in making it run better.

That partner leads with the problem, not the product. The first question isn’t “let me tell you about our AI portfolio.” It’s “tell me about the process that’s costing you the most time, money, or risk right now.”

That partner speaks the language of the business, not IOPS and latency. The CFO cares about margin. The Operations Director cares about throughput and efficiency. The Risk Director cares about compliance. Speak their language, not yours — because the conversation that lands in a board meeting sounds nothing like the conversation that lands in a data centre.

That partner understands the industry, not generically but specifically — the regulatory environment, the competitive pressures, the operational realities, the difference between what the industry says it does and what it actually does.

And that partner connects AI to outcomes. Not “here’s a large language model,” but “here’s how three organisations in your sector reduced their claims processing time by 40 percent — and here’s what had to be true about their data before that was possible.”

That last point is the real test, because earning the follow-up meeting is what separates the partner who gets invited back from the one who gets a polite thank you and a door that doesn’t open again. Not by being impressive. By being relevant.

How to Be the Most Relevant Partner on the RFP

Here’s the uncomfortable truth about most RFP responses: they look identical.

Same structure. Same claims. Same case studies. Same promises about partnership and innovation and transformation. The customer reads three responses and struggles to remember which was which.

The partner who stands out on an RFP isn’t the one with the longest list of capabilities. It’s the one who demonstrates — clearly, specifically, and credibly — that they understand the customer’s business well enough to solve their actual problem.

That starts with showing you’ve done the homework. Reference their industry. Reference their specific challenges. Show that you understand the context, not just the requirement — because anyone can respond to what the RFP says, but the best partners respond to what it means.

It means leading with outcomes, not outputs. Don’t describe what you’ll deliver. Describe what will be different when you’re done, in terms the business cares about — time saved, risk reduced, revenue protected, decisions improved.

It means being honest about the prerequisites. The partners who win long-term trust are the ones who tell the truth about what has to be true before AI delivers value — data readiness, process clarity, governance, stakeholder alignment. Customers have been burned by partners who promised transformation and delivered complexity. Honesty is a differentiator.

And it means demonstrating domain credibility. Reference real outcomes in their sector. Use their language. Show that you’ve been in rooms like theirs before, and that you know what good looks like from the inside.

The best RFP responses don’t just answer the question. They reframe it. They show the customer something about their own problem that they hadn’t fully articulated. That’s the moment a partner stops being a vendor and starts being an advisor.

The most relevant partner on the RFP isn’t the one who answered the question best.

It’s the one who made the customer think: “These people actually understand us.”

The Gap — And What To Do About It

The gap between what AI can deliver and what most organisations are actually getting from it isn’t a technology gap. The technology is good enough. In many cases it’s extraordinary.

The gap is a translation gap. Between AI capability and business outcome. Between what the technology can do and what the business actually needs.

Closing that gap requires people who can have the business conversation first and the technology conversation second. Who understand the industry they’re working in deeply enough to know where the problems are. Who can sit with a business leader and ask the questions that matter — and understand the answers.

That’s not a certification. That’s not a product training. That’s thirty years of paying attention.

But it can be developed. It starts with curiosity — genuine curiosity about how businesses work, how industries operate, and what keeps leaders awake at night. It continues with discipline — doing the reading, asking the questions, building the domain knowledge that makes the conversation credible.

And it shows up in the room. Every time.

The Bottom Line

It’s no longer a conversation about products, features, feeds and speeds.

Business wants to know how Data and AI can help their business. Reality, not future promises.

The technology partners who will thrive in the AI era aren’t necessarily the ones with the deepest technical knowledge. They’re the ones who combine enough technical literacy to be credible with enough business acumen and domain knowledge to be useful.

The ones who walk into a room and have the conversation that matters.

The ones who earn the follow up meeting.

The ones whose audience isn’t on their phones.

Because when you get it right — when the conversation is real, relevant, and grounded in genuine understanding of the business — nobody needs to check their emails.

They’re too busy thinking about what you just said.

That’s not a Cool Story.

That’s AI Reality.

Posted on

AI Winter is Coming – Again

Infographic depicting the evolution of artificial intelligence from the 1980s to the present, highlighting key eras such as AI Winter, Quiet AI/Edge AI, and Frontier AI. Includes illustrations of mainframe computers, decentralized architecture, and hyperscale data centers, along with notes on investment, data availability, and technology challenges.

AI Winter is nothing new. We’ve been there before. The last AI winter was 1987 – 1993. Businesses over-invested in “expert systems” — expensive, specialised computers designed to mimic corporate decision-making. When these systems proved too difficult to maintain and update, the commercial market for AI collapsed. This time winter may come because Frontier AI is hitting a scaling ceiling it can’t engineer its way past. This post suggests the answer isn’t bigger. It’s smaller. And the proof of concept has been running quietly for twenty years.

If you want an overview of how AI actually developed — from 1950s foundations through to today — I’ve covered that in AI Didn’t Come From Nowhere. The short version: AI has been building for seventy years. ChatGPT didn’t start it. It just made it visible.

The Clock Got Reset

When ChatGPT launched in late 2022 it did something remarkable and something damaging simultaneously.

Remarkable — it made AI legible to everyone. For the first time, a non-technical person could sit down, ask a question, and feel the capability directly. That democratisation matters. It changed the conversation permanently.

Damaging — it reset the public clock to zero. Suddenly AI had a birthday. And a generation of business leaders started building AI strategies as if nothing had existed before that date.

I meet smart, senior people regularly who genuinely believe AI started with ChatGPT. That 2023 was year one.

It wasn’t. Not even close.

This is what I’ve called the Magpie Effect — organisations distracted by the latest glittering capability, dropping whatever was already working to chase the new thing. The frontier AI conversation feeds it perfectly. New model. New benchmark. New promise. The magpie pivots. The roadmap restarts. The quiet AI that was already delivering sits ignored in the corner.

But before we get to what came before, we need to talk about where frontier AI is heading. Because the ceiling that’s approaching makes the Magpie Effect not just wasteful — but genuinely risky.

The Scaling Wall

The Frontier AI story has been built on a single premise: scale it out and it gets better. Bigger models. More parameters. Larger data centres. More powerful GPUs. The scaling hypothesis held, the results were real, and the industry committed.

But scaling isn’t a strategy. Scaling by laws of physics and economics always has limits. It’s a phase. And this phase is approaching a physical wall that no amount of engineering enthusiasm will move.

A single large-scale AI training run consumes energy comparable to a small town. Inference at scale runs continuously — millions of queries, every day, globally, without pause. The major cloud providers are signing nuclear power agreements not because nuclear is cheap or fast, but because conventional grid capacity cannot keep pace with demand. Microsoft has already reactivated Three Mile Island. Amazon is investing in small modular reactors. They have run out of other options.

Data centre construction can’t keep up. From planning decision to operational facility takes four to seven years in most developed jurisdictions. Grid connection queues in the UK, the US, and across the EU are already measured in years. Water rights for cooling are becoming a site selection constraint. Liquid cooling manages the thermal symptom. It does not touch the energy consumption problem.

The ceiling is lower than the industry’s public projections suggest. The people closest to the infrastructure already know it. The investment cycle is still running hot enough that saying so publicly is commercially inconvenient.

Efficiency gains — model distillation, inference optimisation, new chip architectures — will buy time. They won’t move the ceiling. The physics and the economics don’t negotiate.

As I write this, I use Claude daily. Claude for many of us has become a genuine thinking partner — including in writing this post. I’m not dismissing Frontier AI. I’m being honest about its infrastructure cost and scalability limits. Even Claude will hit this ceiling. That’s not a criticism. It’s physics, it’s economics. It’s a practical viewpoint.

The Transistor Parallel

We’ve been here before.

In the 1940s the valve computer proved the concept. ENIAC, Colossus — genuinely capable machines. But enormous, power hungry, heat generating, and impossible to scale to meet the demand that was already visible. The resource constraint was real. The engineering community knew it.

The answer wasn’t a bigger valve. It was the transistor.

The transistor didn’t just miniaturise the valve. It changed the trajectory entirely. Compute escaped the specialist room. It went into consumer products, industrial equipment, vehicles, eventually into every pocket on the planet. Nobody called it a compromise. The smartphone was always a better destination than a room full of valves — we just couldn’t see it from inside the valve paradigm.

Frontier AI is the valve computer. Capable. Proven. Impressive. And running into the same kind of physical ceiling that made the transistor not just desirable but inevitable.

The transistor moment for AI is smaller, distributed, efficient models — running where the work actually happens, without depending on infrastructure the planet cannot sustainably provide at the rate being demanded.

And here is the thing that gets lost in the Frontier AI conversation.

That transistor moment isn’t coming. It’s already here. It’s been here for twenty years. We just haven’t been paying attention to it.

The AI That Never Made the Headlines

While the world was discovering chatbots, a different AI had already been running quietly for years. Doing real work. Solving defined problems. Delivering measurable outcomes with ROI.

Netflix’s recommendation engine has been shaping what you watch since 2006. Gmail’s spam filter has used machine learning since 2004. Amazon’s demand forecasting and warehouse optimisation runs on ML models that have been refining themselves for over a decade. Google Maps learns from billions of journeys in real time.

Credit card fraud detection catches billions of fraudulent transactions annually using models that make decisions in milliseconds, invisibly, at the edge.

Aircraft engines predict their own failures. Factory production lines inspect their own output. Rail networks scan their own infrastructure at track speed.

None of this started in 2023. None of it needed a press release. None of it requires a nuclear power agreement or a seven year planning queue.

In my post on Machine Learning: The Backbone of Enterprise AI I looked at what this looks like in practice. DHL’s parcel inspection system uses computer vision models running at the edge — cameras over conveyor belts, ML models trained on millions of images, making pass/fail decisions on every parcel at line speed. Duos Technologies scans every railcar at track speed using AI-enabled imaging, catching defects before they become safety incidents. Factory quality control systems watch production lines continuously, catching defects too subtle for the human eye.

None of these run on hyperscale infrastructure. None send data to a cloud API and wait for a response. They run locally, efficiently, on hardware sized to the task — because the task is defined, bounded, and understood.

This is the transistor analogy for AI. Already in production. Already sustainable. Already delivering ROI.

The Right Tool for the Right Problem

The AI decisions that make genuine business sense share a common structure.

A defined problem — not “use AI” but “reduce defect escape rate on line 4” or “inspect every railcar at track speed without taking it out of service” or “predict supply chain disruption before it hits.”

A defined process — the AI is embedded in a workflow with a measurable before and after. It replaces or augments a specific activity with a specific outcome.

A defined return — because the problem is specific and the process is clear, the ROI calculation is straightforward. Not “we have AI” but “our cost per inspection dropped, our throughput increased, our safety incidents reduced.”

When AI is aligned to business process optimisation this way, the technology choices become obvious. Computer vision for inspection. Predictive models for maintenance. Anomaly detection for risk. Small, focused, efficient. Running on hardware sized to the job, not to the ambition.

The organisations getting genuine return from AI are overwhelmingly doing this. They’re not in the headlines. They’re on the production floor. They’ve been there for years.

I’ve written about what that structured approach looks like in practice in Getting AI Right First Time. The organisations that get AI right treat it as process optimisation first, technology second. Start small. Prove value. Escape the pilot graveyard. Make AI boring. That five step discipline is what separates durable capability from expensive experimentation.

The starting point is finding your critical process — the one business process that, if it stopped tomorrow, the business would stop with it. Name it. Find the friction within it. That friction is your AI use case shortlist. Not a vendor briefing. Not a capability demo. The process the business already depends on, and the specific points where better prediction, classification, or inspection removes a real constraint.

The Obvious Outcome

The Frontier AI scaling ceiling isn’t a maybe. It’s a when. Efficiency gains will buy time. The laws of physics and economics won’t be moved.

When it arrives, the organisations that built deep dependencies on hyperscale infrastructure for processes that didn’t require it will be most exposed. The expertise put to waste won’t be quickly rebuilt. The processes restructured around availability assumptions that stop being true won’t easily revert. That’s what winter looks like.

But for the organisations that chose the right tool for the right business problem — summer is already here.

Distributed. Local. Efficient. Sustainable. Aligned to real business processes. Delivering real ROI.

Not because they anticipated the ceiling. Because they were asking the right question from the start — not “how do we use AI” but “where does better prediction, classification, or inspection create measurable value, and what is the smallest, most reliable tool that delivers it.”

Electronics couldn’t scale with valves. It scaled with the transistor. And everything that followed — the PC, the phone, the computer in your car — emerged from that single shift in direction.

AI will follow the same arc. Not because anyone planned it. Because the ceiling makes it inevitable.

The quiet AI already running on the production floor isn’t the consolation prize.

It’s the destination.

Posted on

From 22 Binders to a Box on the Workbench

Blueprint illustration of a distributed AI architecture, highlighting challenges such as slow distribution and high space usage, and benefits including localized inference and enhanced security.

How AI is following the same arc as every technology before it — and why that’s the most important thing happening in enterprise AI right now.

The 22 Binders Problem

In the 1990s I worked for Volvo Trucks, responsible for technical documentation. Every authorised dealership workshop had 22 steel binders crammed with service manuals, torque specifications, fault code references, and replacement procedures. Covering every model, every variant, every engine configuration.

Getting those binders to the right workshop, in the right language, at the right time was a logistical nightmare. Print runs. Translation cycles. Physical distribution across multiple countries. And the moment a binder left the building, you started losing control of it.

Because trucks don’t stand still. Specifications change. Procedures get revised. Safety-critical updates happen. So we’d issue interim service bulletins — printed updates mailed out to dealerships, hoping they’d find their way into the right binder, in the right place, before a technician needed them.

The knowledge was good. The people who wrote those manuals understood those trucks deeply. The content was authoritative, structured, procedural. But the distribution model was broken by design. The moment you printed something, the clock started on it becoming out of date.

I spent years managing that problem. I never solved it. The technology didn’t exist to solve it.

It does now.

The Sledgehammer Era

When generative AI arrived at scale it came in like a sledgehammer. Vast data centres. Enormous compute. Hundreds of billions of parameters. Everything centralised, everything cloud-dependent, everything expensive.

That was necessary. You needed that scale to prove the capability existed. GPT-4, Gemini, Claude — these required hyperscale infrastructure to demonstrate what large language models could actually do. The sledgehammer era wasn’t wrong. It was the only way to get here.

But it’s not the end state.

There’s a pattern in technology that repeats so reliably it’s almost boring once you’ve seen it enough times. A new capability emerges at scale, centralised, specialist, expensive. Then the algorithms get smarter. The hardware gets smaller. The economics shift. And compute escapes the specialist environment and goes where the work actually happens.

We’ve seen this cycle before. Several times.

The Transistor Moment

In the 1940s the valve computer proved the concept. ENIAC, Colossus — genuinely capable machines doing real computation. Enormous, power hungry, heat generating, fragile, requiring specialist environments and specialist people just to keep running.

Then the transistor arrived. It didn’t just miniaturise the valve. It changed what was possible. Compute escaped the air-conditioned room. It went into consumer products, industrial equipment, vehicles. Eventually into the Volvo workshop — diagnostic computers, engine management systems, electronic service tools.

Nobody staring at a room full of valves in 1955 predicted the smartphone. But it was inevitable once the transistor existed. The use cases emerged from the distribution.

We are at that moment with AI.

The evidence is already here. Models like Mistral 7B, Microsoft’s Phi-3, and Meta’s Llama 3.1 8B perform remarkably well on focused tasks. Quantisation techniques mean a model that needed 80GB of GPU memory two years ago runs comfortably in 8GB today with minimal quality loss. NVIDIA has put one petaflop of AI compute into a desktop machine — the GB10 Grace Blackwell — that sits on a workbench. Apple put a capable language model in a phone.

The sledgehammer is giving way to the scalpel. Smarter algorithms. Smaller models. Distributed inference. The transistor moment.

The Architecture That Changes Everything

So let me describe what I’d build for Volvo Trucks today.

A GB10 desktop in every dealership workshop. On it: a small language model, a local MCP server, and a local cache of the workshop knowledge base. No internet connection required. No cloud dependency. No data leaving the building.

The knowledge base lives centrally — one authoritative source, maintained by a team of technical authors with a proper authoring and approval workflow. Single version of the truth. When a torque specification changes, it changes once, in one place, approved by the right person. Overnight, a delta sync pushes only the changed content to every workshop box in every country. By morning every technician in Europe has the current procedure.

The technician doesn’t type freeform queries. They select from predefined prompt templates — fault code lookup, torque specification, replacement procedure, service interval. Each template fires a carefully engineered retrieval query behind the scenes, pulling the right content from the local knowledge base, passing it to the local model, generating a precise, grounded answer.

The model never wanders off domain. There’s no internet to reach out to. No risk of the model hallucinating — confabulating a procedure it half-remembers from training. The answer comes from the authoritative knowledge base, retrieved precisely, generated locally, watermarked with the sync timestamp so you know exactly which version of the truth informed it.

This isn’t a chatbot. It’s a precision workshop tool that happens to use an AI model internally. The AI is an implementation detail. The value proposition is the right answer, instantly, for a truck that needs to move.

And crucially — this couldn’t be done with a naive RAG implementation bolted onto an ungoverned file store. The intelligence isn’t in the retrieval mechanism. It’s in the governance that happened before retrieval was ever involved. The single version of truth. The approval workflow. The deprecation process that ensures superseded procedures stop being retrieved. The content discipline that technical authors like my 1990s self spent years trying to maintain manually.

The AI amplifies good knowledge management. It doesn’t replace it.

The Pendulum

I’ve watched enough technology cycles to see the pattern clearly.

The PC era distributed compute out of the data centre and into the hands of individuals. The internet centralised it again — everything running on servers you didn’t own. Mobile distributed it once more, putting capable compute in every pocket. Cloud AI is centralising again — everything phoning home to a hyperscale data centre to answer a query.

Each time, the dominant narrative says this is how it will always be now. Each time, the pendulum swings back. Not because the technology fails, but because the same forces reassert themselves: latency becomes unacceptable, data sovereignty pressure builds, cost economics shift, and capability catches up to the point where distribution becomes viable again.

We are at peak centralisation with AI right now. The distribution forces are already building. Sovereignty regulation is tightening globally. Edge hardware is catching up fast. Algorithmic efficiency is compressing capable models into deployable sizes. Enterprises are growing uncomfortable with sensitive data leaving their premises to answer a query.

The pendulum will swing. It always does.

The Control Plane

But there’s something different this time that could break the historical pattern — and it’s the idea I find most interesting in enterprise AI right now.

Every previous distribution wave eventually lost coherence. The PC era fragmented into version chaos, security nightmares, and unmanageable sprawl. Mobile created a device estate that IT departments are still trying to govern. Distribution without discipline becomes a different kind of problem — one that often ends up being worse than the centralisation it replaced.

The question is whether AI distribution can be done differently. Whether you can have local inference without local chaos.

I think you can. The architecture looks like this: local inference running in your server room, your data never leaving your premises, your domain knowledge locked in a governed local knowledge base. But the model’s values, safety alignment, and capability updates maintained centrally by the people who built it. The enterprise controls the execution environment. The model provider maintains the model itself.

Distribution without fragmentation. Sovereignty without chaos.

It’s the Volvo KB architecture applied to the model itself. Central truth. Distributed execution. The same principle that would have solved my 22-binder problem in 1993 — one authoritative source, pushed to the edge, with discipline about what changes and who approves it.

This isn’t a theoretical position. The infrastructure to do it exists today. What’s missing, in most organisations, is the governance thinking that makes it safe. And governance thinking, it turns out, is not a technology problem. It’s a knowledge management problem. Which is a very old problem indeed.

What This Means

The use cases for distributed, domain-locked AI are not going to come from hyperscale thinking. They’re going to emerge from people who understand specific domains deeply — who know where the knowledge lives, what governance it needs, and what questions actually matter in that environment.

The Volvo workshop is one example. But the same architecture applies anywhere that has a bounded domain, authoritative knowledge, and real decisions being made by people who need the right answer quickly.

Consider a hospital ward. A clinician needs the current drug interaction protocol for a specific combination — not a general answer from a model trained on the internet, but the approved formulary for this trust, this version, signed off by the chief pharmacist last Tuesday. The architecture is identical to the workshop: local inference, governed knowledge base, delta sync, no data leaving the building. The AI is an implementation detail. The value is the right answer, for this patient, right now.

Or a field engineer on an offshore platform, no reliable connectivity, needing the current maintenance procedure for a specific valve configuration. Or a legal team needing to retrieve the approved contract clause library — not a hallucinated approximation, but the version that compliance signed off.

In each case the AI isn’t the interesting part. The interesting part is the governed knowledge layer underneath it — built by people who understand the domain, maintained with discipline, versioned and approved and auditable.

The sledgehammer era gave us the capability. The transistor moment gives us the distribution. What makes it useful is the same thing that always made the difference — knowing your domain, respecting your data, and being honest about what the technology actually does.

I learned that managing 22 steel binders for Volvo Trucks in the 1990s.

Some lessons don’t change.

Posted on

Do AI Projects Fail — Or Do We Fail AI?

Blueprint illustration featuring a bird labeled 'DIStraction VECTOR,' and a tower structure with three layered sections labeled 'PROCESS ALIGNMENT,' 'SKILLS & PEOPLE,' and 'DATA FOUNDATIONS.'

If you look back over the last 30 years, our technology history is riddled with failed projects, projects that never got off the ground, and projects that went massively over budget. And then there are the scandals.

The UK Post Office Horizon scandal stands as one of the most serious technology failures in modern British history. Between 1999 and 2015, around 1,000 sub-postmasters were wrongfully prosecuted after the Fujitsu-supplied Horizon accounting software recorded losses that did not exist. The total cost of redress now stands at around £2 billion. More than 13 people took their own lives. The technology did not just fail — it was trusted when it should have been questioned, and the consequences were devastating.

AI is just another technology. That is worth saying plainly. Although many of the possibilities being talked about are genuinely achievable, reality always kicks in. Every project — AI or otherwise — is a complicated combination of people, software, hardware, and process. That has been true for 30 years. It remains true now.

But we can always learn from the past. The question is whether we choose to.

AI is no different. And right now, the data on AI project failure should give everyone pause. The numbers are in. And they are not improving.

RAND Corporation, in one of the most rigorous independent analyses of AI project failure to date, interviewed 65 experienced data scientists and engineers across industries and company sizes. Their finding: more than 80% of AI projects fail to reach meaningful production deployment. That is twice the failure rate of IT projects without an AI component.

S&P Global’s 2025 survey of over 1,000 organisations across North America and Europe found that 42% of companies abandoned most of their AI initiatives that year. In 2024, that figure was 17%. The abandonment rate more than doubled in a single year. MIT’s Project NANDA, published in July 2025, found that 95% of organisations deploying generative AI saw zero measurable return. Not low return. Zero.

With global AI spending projected to reach $630 billion by 2028, these failure rates are not a statistic. They represent hundreds of billions of dollars in wasted investment, stalled initiatives, and businesses no closer to the outcomes they were promised.

What makes this harder to ignore is that the failure rate is moving in the wrong direction. The technology is more capable than it has ever been. The investment is larger than it has ever been. And yet more organisations are abandoning AI initiatives today than they were twelve months ago.

So what is actually going wrong?

The Research Points to Three Things

Across RAND, McKinsey, Gartner, MIT, and Informatica’s CDO Insights survey, the diagnosis is remarkably consistent. AI projects fail for three reasons, and they repeat themselves across industries, geographies, and organisation sizes.

The wrong use case. The process targeted for AI is not the right one, the problem definition is vague, or the initiative is chasing a technology rather than solving a business problem.

Data that is not ready. The data that would be needed to make AI work in production does not exist in the form required — it is fragmented, inconsistent, ungoverned, or simply not there.

A skills gap. The people needed to build, deploy, and sustain AI in a business context are not in place — and the organisation has not yet found a way to close that gap.

None of these are surprises. But the uncomfortable truth is that most organisations are still walking into all three of them, often simultaneously.

The Wrong Use Case: The Magpie Effect at Work

The first failure mode — choosing the wrong process to target — is something I have written about in depth. The Magpie Effect describes what happens when AI strategy is driven by possibility rather than process: the endless pivot towards the latest model, the newest capability, the most impressive vendor demo. Every pivot consumes time, burns budget, and erodes the momentum that comes from doing one thing properly and scaling it.

The RAND report is direct on this point. Stakeholders often misunderstand or miscommunicate what problem needs to be solved. Models get built and deployed optimised for the wrong metrics, or ones that simply do not fit into the real business workflow.

The antidote is starting with the Golden Process — the one business process that everything else hinges on — and asking what AI can do to remove the constraints within it. That conversation has to happen before any vendor is in the room, before any use case is evaluated, and certainly before any infrastructure is selected.

If you have not read the Magpie Effect post, the practical AI test at the end of it is a useful filter for any use case that lands on your desk.

Data That Is Not Ready: The Silent Failure

The second failure mode is the one that catches organisations by surprise — because it tends not to surface until a project is already in trouble.

The pattern is familiar. A proof of concept is built on a carefully selected, cleaned-up sample dataset. The demo runs well. Leadership approves production. And then everything stalls.

Production data is fragmented across systems that were never designed to talk to each other. Basic business terms — “customer”, “order”, “revenue” — are defined differently across departments. Historical records have gaps. Formatting is inconsistent. The clean sample that powered the demo bears almost no resemblance to the messy reality of how the business actually runs.

Informatica’s 2025 CDO Insights survey found that data quality and readiness was the top obstacle to AI success, cited by 43% of organisations. McKinsey found that organisations reporting significant AI returns are twice as likely to have invested in data infrastructure before selecting modelling techniques. Gartner predicts that 60% of AI projects lacking AI-ready data will be abandoned entirely.

This is not a new problem. It is the same problem that has existed since organisations first tried to build anything useful on top of their data. The difference is that AI amplifies it. A flawed report can be corrected. A model trained on broken foundations will confidently produce broken outputs at scale — and the damage compounds before anyone notices.

I have covered the data readiness problem in detail in Garbage In, Expensive Garbage Out and A Million Rows of Nothing. The short version: AI does not fix bad data. It scales it.

The Skills Gap: The Barrier Nobody Budgets For

The third failure mode is the one that receives the least attention — and may be the hardest to solve quickly.

The last 30 years of enterprise IT have built deep, hard-won expertise in infrastructure. Server architecture. Storage design. Networking and virtualisation. Security and compliance. That expertise is not obsolete — it remains essential. The physical and virtual foundations that AI runs on still need people who understand them properly.

But AI demands a different and additional skill set that most organisations are still building.

Traditional IT Skills (Still Relevant)New Skills Now Required
Server architecture and managementData engineering
Storage design and optimisationAI/ML engineering
Networking and virtualisationData science
Security and complianceBusiness domain knowledge

McKinsey’s 2024 State of AI survey found that 58% of businesses are hampered by internal AI skill shortages. Informatica’s CDO Insights survey placed skills and data literacy third in the list of top AI obstacles. PwC found that almost 65% of executives acknowledge their AI initiatives are not succeeding because of a lack of executive sponsorship — a leadership gap that is itself a symptom of not having people in the room who can translate between business outcomes and AI capability.

The skills gap is not a technology problem. It is a people and partnership problem. And it is the reason most AI pilots never leave the room they were born in.

Picture a typical scenario. An organisation identifies a strong AI use case, aligned to a real business process. The data is in reasonable shape. Leadership is supportive. A vendor is engaged. And then the questions start: who is going to build the data pipeline? Who owns the model in production? Who bridges the gap between what the model does and what the business actually needs it to do? The room goes quiet. Not because the will isn’t there — but because the people aren’t.

The honest message is that organisations do not need to replace their existing IT teams — they need to extend them. The people who understand the infrastructure are still essential. But they need colleagues who understand data pipelines, model behaviour, and the business processes those models need to serve. That combination is rare. It takes time to build. And in its absence, even the right use case with clean data will stall.

This is why Partner selection matters as much as use case selection. The right Partner does not just bring technical capability — they bring the scars of what does not work. An AI and data practice built over years has already made the mistakes most organisations have not made yet. That is not a credential. That is insurance.

AI is not a product, it’s an eco-system built on partnership

Three Causes. One Pattern.

What the research is describing — even when it does not use these words — is organisations that jumped to the model before they had solved the three problems that sit upstream of it.

They chased the possibility rather than the process. They skipped the data foundations. And they underestimated how different the skills requirement would be.

McKinsey’s summary of what separates the 6% of genuine AI high performers from everyone else is as sharp as it gets: AI is 20% algorithms, 80% organisational rewiring.

The organisations building durable AI capability are not necessarily the ones with the most sophisticated models. They are the ones that got the process right, made the data ready, and put the right people in place — before they wrote a single line of model code.

The failure statistics look alarming until you understand the causes. Then they look entirely predictable.

The good news: all three are solvable. None of them require waiting for the next frontier model. They just require doing the less glamorous work first.

I have written about what that looks like in practice. Getting AI Right First Time sets out a five-step path from honest awareness through to durable, enterprise-wide capability — the journey from AI as a science project to AI as part of how the business actually runs. And In Praise of Boring, Everyday AI makes the case for what success actually looks like in production: not the demo, not the headline, but the quiet system that runs on a Tuesday afternoon without anyone noticing — because it has simply become part of how the business works.

That is the goal. Not AI that impresses. AI that endures.

AI success has to be built on the right foundations — not retrofitted onto broken ones.

Posted on

The Magpie Effect: AI Possibilities vs Practical AI Solutions

An infographic titled 'The Magpie Effect' illustrating a magpie flying alongside various concepts related to AI strategies, constraints, and distractions. Includes labeled arrows pointing to elements like 'Distraction Vector', 'Shiny Object Response', and 'Golden Process - Critical Path'. Features a flowchart at the bottom indicating practical AI strategy.

Yesterday, I was sitting in a room listening to colleagues talk about the latest AI developments. New models. New capabilities. New promises about what AI will be able to do. It was energetic, enthusiastic, and genuinely well-informed.

And somewhere in the middle of it, a quiet thought surfaced: does any of this actually matter right here and right now?

It took me back to a book I read years ago when studying Business and Finance. The Goal by Eliyahu Goldratt. If you haven’t read it, it’s a business novel — a plant manager called Alex Rogo, a factory on the verge of closure, and a series of deceptively simple questions from an old professor that eventually save the business. The central insight is the Theory of Constraints: every system has a bottleneck. Find it, fix it, and the whole system improves. Ignore it, and no amount of optimisation elsewhere will save you.

Sitting in that room, I realised the AI industry has a Goldratt problem. It is endlessly fascinated by what is possible at the frontier, and not nearly interested enough in the bottlenecks that are quietly strangling real businesses today.

That is when the idea of the Magpie Effect crystallised for me.

There is a bird famously distracted by shiny things. It spots something glittering, drops whatever it was doing, and goes to investigate. Every few weeks, a new AI headline lands. A new model. A new capability. A new promise that this is the breakthrough that changes everything. Autonomous agents. Artificial General Intelligence. AI that writes code, runs your supply chain, manages your workforce. The glittering object rotates. The industry pivots. And somewhere in a conference room, a leadership team starts asking whether they should be doing that instead.

The Magpie Effect is quietly one of the biggest obstacles to real AI progress in business today. And Goldratt, I think, would have had little patience for it.

Goldratt was writing about factory floors. Machines, production lines, throughput, inventory. But swap the factory for a financial services firm, a retailer, or a healthcare provider, and the principle holds perfectly. The production lines just look different now. They are the workflows, the approval chains, the data pipelines, the customer journeys that run your business every single day. Constraints in those processes cost just as much as a jammed machine on a shop floor. They are just harder to see.

The Cost of the Chase

Chasing possibilities isn’t free. It has a price, and businesses are paying it in three currencies.

Time. Every pivot towards the next shiny object means restarting conversations, rewriting roadmaps, and pulling teams off work that was already delivering. The opportunity cost is real even when it’s invisible.

Money. Proof of concepts that never graduate. Vendor relationships built on promises. Platforms bought for futures that haven’t arrived. Science projects with no measurable return dressed up as innovation investment.

Momentum. Perhaps most damaging of all. Teams that are perpetually chasing the new never build the deep competency that comes from doing one thing properly, learning from it, and scaling it. They become generalists in hype rather than specialists in value.

The AI industry is not entirely to blame. Vendors need differentiation. Analysts need narratives. Media needs clicks. But the businesses that get swept up in it are making a choice — and there is a different choice available.

Practical AI Is Already Here. It’s Just Less Exciting.

Here is the uncomfortable truth: the AI that will genuinely move the needle for most organisations is not frontier. It is not exotic. And it is definitely not on the cover of a technology magazine.

It is the model that reduces manual data entry by 70%. The system that flags anomalies in financial transactions before a human would spot them. The tool that summarises a week of customer feedback into ten actionable themes in minutes. The scheduler that optimises field service routes and saves 15% on fuel costs.

None of those are science fiction. All of them are in production somewhere today. All of them have a measurable ROI. And none of them required waiting for the next frontier model to drop.

Practical AI solves a real business problem with available technology, accessible data, and a return you can put on a spreadsheet. That is not a consolation prize. That is the goal.

Start With Your Golden Process

Before you evaluate a single AI use case, ask one question: what is the one business process that, if it stopped tomorrow, the business would stop with it?

Not the most complex process. Not the most talked-about. The one that everything else depends on. The process that runs quietly in the background, holding the whole operation together. That is your Golden Process.

It might be order management. It might be claims processing. It might be production scheduling, customer onboarding, or logistics coordination. Every business has one. Most businesses have never explicitly named it.

Name it. Then look at it seriously.

Where does it slow down? Where does it depend on human heroics to keep running? Where does data get re-entered, reformatted, or chased across systems? Where do errors creep in? Those friction points are not just operational annoyances — they are your AI use case shortlist.

This is the starting point of a genuinely business-aligned AI strategy. Not a vendor briefing. Not a technology roadmap. Not a list of capabilities from the latest model release. The Golden Process and the friction within it.

The achievable business outcome — faster, cheaper, more reliable execution of the thing the business depends on most — is worth more than any amount of AI possibility. And it is almost always more achievable than it looks, because the process is already understood, the data already exists, and the ROI is not hypothetical.

Start there. Everything else follows.

How to Tell the Difference: The Practical AI Test

When an AI use case lands on your desk — from a vendor, from a consultant, from an enthusiastic team member who just watched a keynote — run it through these five questions.

1. What specific business problem does this solve? If the answer starts with “it could potentially…” or “imagine if we…” that is a possibility, not a solution. A practical use case has a named problem with a named owner.

2. Do we have the data to support it? AI without good data is not AI. It is noise with a marketing budget. Before you evaluate any use case, ask whether the relevant data exists, whether it is clean, and whether it is accessible. If the answer to any of those is no, the use case is not ready — regardless of how impressive the demo looked.

3. Do we have the skilled resources to support it? Good intentions and good data are not enough. Someone has to build it, maintain it, and own it when something goes wrong. That might be internal talent, a partner, or a combination — but the answer needs to be honest. An AI use case with no clear resource plan is not a use case. It is a wish list item.

4. Can we measure success? Define the KPI before you build anything. Handling time. Error rate. Cost per transaction. Customer satisfaction score. If you cannot articulate what winning looks like in a number, you are not running a business initiative. You are running an experiment with an open-ended budget.

5. Can this be in production within 90 days? Not perfect. Not scaled. But in the hands of real users, generating real outputs, against real data. If the answer is no, the scope is wrong or the foundations are not ready. Either problem needs solving before you proceed.

6. Would this still matter if nobody wrote about it? Strip away the hype. Imagine the use case is completely unglamorous — no AI branding, no press release, just a quiet improvement to a business process. Does it still make the list? If yes, it is probably worth doing. If the answer depends on how it sounds in a strategy presentation, be careful.

Make AI Boring. That Is the Win.

The organisations that are getting the most from AI right now are not the ones chasing the frontier. They are the ones that picked three or four use cases, proved the value, scaled what worked, and moved on to the next problem on the list. Quietly. Methodically. Without waiting for permission from the hype cycle.

They have made AI boring. And boring, in this context, is the highest compliment.

Boring means repeatable. Boring means trusted. Boring means it runs on a Tuesday afternoon without anyone noticing, because it has just become part of how the business works.

The magpies are still circling. The glittering objects will keep appearing. The organisations building durable capability are the ones that have learned to look away — and get back to the work that actually pays.

One Final Thought on Foundations

None of this works without getting data right. Practical AI is only as good as the data that feeds it. The organisations that move fastest are not necessarily the ones with the most advanced models — they are the ones whose data is clean, governed, and ready to use.

That is a less exciting conversation than whatever was announced at the last major AI conference. But it is the conversation that separates progress from theatre.

Data first. Practical use cases second. Everything else can wait.

At the end of The Goal, Alex Rogo doesn’t walk away with a new machine or a bigger budget. He walks away with a better question. Not “how do I optimise everything?” but “what is the goal — and what is stopping us from reaching it?” That shift in thinking is what saved the factory. It is the same shift that separates businesses building real AI capability from those still circling the next shiny object. Find your Golden Process. Name the constraints within it. Ask the right questions about where AI can remove them. The rest follows.

If you found this useful, the Getting AI Right First Time post covers the five steps to moving from AI experiments to durable enterprise capability.