Most companies get their first AI project right and their second one wrong. The first one runs on novelty, senior attention and one volunteer who cares enough to fix things by hand. The second one competes with real work. That is where you find out whether the company actually changed, or simply borrowed enthusiasm for a quarter. If you want to know whether an AI project worked, don't reread the pilot report — look at what happened next.
Why does the first AI project almost always look like a success?
In most first projects nearly everything is stacked in your favour, and almost none of it is repeatable. The scope was chosen because it could be proven, not because it was the most painful thing in the business. Someone senior asked about it every week. There was one person — usually not in IT — who wanted it to work badly enough to paste data by hand on a Thursday evening rather than let a demo fail.
None of that is cheating. It is how new things start in every company and every industry, and I would take an enthusiastic first project over a perfectly governed one that nobody cares about. But it does mean the first project measures something other than what people think it measures. It measures whether the technology can work here. It does not measure whether this organisation can run it.
By "second AI project" I mean the next distinct process a company automates or augments after its first one is live — not phase two of the same build. Phase two inherits the goodwill of phase one. A genuinely new process does not, and that is precisely why it is diagnostic.
I have written before that AI adoption fails in the organisation, not in the code. This essay is the next question along: not why a first project stalls, but what a second AI project tells you that a first one structurally cannot. The second project is the first honest measurement you get, because by then all the temporary help has gone home.
What actually changes between project one and project two?
Five things, in my experience — and not one of them is technical.
The volunteer is no longer free. The person who carried project one now owns project one. Every question about it lands on their desk. Whatever capacity they had for something new was spent, and nobody replaced it, because on paper the first project "finished".
The novelty budget is empty. A management team will clear its calendar for one experiment. It will not do that twice for the same category of thing. The second project has to survive on ordinary attention, which is a much harsher test and a much more realistic one.
Project one now costs something every month. Prompts drift, an upstream form changes, a supplier renames a field, someone asks for one more exception. None of that is dramatic, and all of it takes hours that were never budgeted. If maintenance was not named and staffed, project two is competing against a tax nobody wrote down.
The easy process is gone. By definition, you already automated the one with clean data and few exceptions. The next candidate has more edge cases, more people with opinions, and usually at least one person whose job description quietly changes if it works.
The comparison flips. Project one was allowed to be rough because it was new. Project two is measured against the polished version of project one that exists in everyone's memory — not the messy one that actually shipped. That is an unfair benchmark, and it is the one you will be held to.
Why do AI projects fail after the pilot? Dutch healthcare named this before AI did
There is a word for organisations that keep running promising pilots that never become normal work: pilotitis. It did not come from AI. It came from digital health, and Dutch researchers have been using it in print. A 2025 study in the journal DIGITAL HEALTH — Addressing pilotitis: A qualitative study on the implementation of eCoaches in hospital-based chronic care — opens with exactly the observation I am making here: despite promising results from pilot initiatives, the step to wider adoption and scaling remains difficult.
I find that useful for two reasons. First, it is proof this is not an AI problem. Dutch hospitals were failing to scale good digital pilots years before anyone in a boardroom said "large language model", which means the cause sits in how organisations fund, staff and hand over new work — not in the technology of the moment. Second, it is a warning about how pilots are designed. A pilot built to be evaluated is not the same artefact as a pilot built to be continued. The first needs a report. The second needs an owner, a budget line and a plan for the Tuesday after the enthusiasm ends.
That distinction is the whole essay, really. Most first AI projects in the Dutch mkb are, structurally, evaluation pilots wearing the clothes of production systems.
What do the numbers say, and what do they leave out?
Gartner's June 2025 forecast is the one most often quoted at me: more than 40% of agentic AI projects will be cancelled by the end of 2027, driven by escalating costs, unclear business value and inadequate risk controls. You will also see an MIT figure quoted everywhere — that around 95% of enterprise pilots produce no measurable profit-and-loss impact. I mention it because you will meet it, and I would not build an argument on it: the methodology has been publicly disputed, and a number that contested belongs in a footnote, not in a business case.
The Dutch picture is quieter and, for a smaller company, more useful. In the CBS AI-monitor covering 2024, 22.7% of Dutch firms with ten or more employees used at least one AI technology — up from around 14% a year earlier, with the smallest band (10 to 19 staff) at 17.8% and firms of 500-plus at 59.2%.
Now notice what every one of those statistics has in common. They count whether a company has started. Adoption surveys, cancellation forecasts, pilot counts — all of them are measurements of first contact. Nobody publishes the number I actually want, which is how many companies that finished one AI project went on to finish a second one without outside help. That is the number that would tell you whether AI took root in the Dutch economy or just visited it.
There is a second thing missing from the statistics: nothing in them distinguishes a company that bought an AI feature inside software it already owned from a company that changed how a process runs. Turning on the assistant in your accounting package counts as adoption in a survey. It teaches your organisation almost nothing about running a system it is responsible for, which is the capability the second project actually draws on.
How to choose the next AI project: the four questions I ask
These are not clever. They are the ones that predict the outcome, and I ask them in a first conversation, before scope or price ever comes up.
Who is still holding project one?
If the answer is a name, and that name is also the proposed owner of project two, the honest advice is to wait. One person cannot be the operations team for a growing portfolio of automations and also the champion of the next one. If the answer is "nobody, it just runs" — good, but I want to see what happens the first week it doesn't.
What broke in project one that we never fixed?
Every project has one. A manual step that was supposed to be temporary. An export somebody still does on Friday. If nobody can name it, either the project is genuinely clean or nobody is close enough to it to know — and I have seen the second far more often than the first.
I ask it in that form on purpose. "Is everything working?" gets you a yes from a room that wants the meeting to end. "What broke that we never fixed?" assumes something did, which is true in every project I have ever been part of, and it gives people permission to be specific in front of their boss.
Is this process chosen for pain, or for ease?
Project one is allowed to be chosen for ease; you are buying evidence. Project two chosen for ease is a warning sign, because it usually means the organisation is repeating the comfortable part of the exercise rather than pointing it at something that costs real money. I have written separately about which process to automate first, and the logic for the second one is stricter, not looser.
Who decides when it goes wrong at eleven at night?
Not "who gets the alert" — who is allowed to switch it off, override it, or tell a customer it was wrong. If that person has not been named out loud, you do not have a production system, you have a pilot with better uptime.
What does a good second AI project look like?
Boring. Deliberately, structurally boring.
The best second projects I see reuse almost everything except the process itself: the same authentication, the same logging, the same review step, the same human-in-the-loop pattern, the same rules about what the model is never allowed to decide alone. The novelty budget goes into the business problem, not into the architecture. If your second project needs a new stack, a new vendor and a new integration pattern, then the first one built you a demo rather than a foundation — which is a finding worth having early, and cheaper to fix at project two than at project five.
Effort per unit of value should fall. If it doesn't, that is the real signal, and it is more useful than any ROI slide. It usually means the reusable parts were never separated from the specific ones, and that is fixable — but it is fixable as an explicit piece of work, not as a hope.
For companies under fifty people, I also argue for sequence over parallelism, and I lose that argument regularly. Two automations landing on the same team in the same quarter do not cost twice as much attention; they cost far more, because the team is now debugging two unfamiliar behaviours while doing their actual jobs. One at a time, until the first one pays its own maintenance, is slower on the roadmap and faster in reality.
When the honest answer is: not yet
Sometimes the right recommendation after a successful first project is to do nothing new for two quarters, and spend that time making the first one properly owned, documented and dull. That is a bad quote to win consultancy work with. It is also, more often than people expect, the advice that makes the second project possible at all.
If you are somewhere between project one and project two right now, the two things worth reading next are what to measure once something is live — I set that out in what to measure in an AI pilot — and the difference between a pilot, a proof of concept and an MVP, because naming the thing correctly is half of what stops project two being evaluated against the wrong standard. If you would rather talk it through against your own situation, that is what our AI consultancy for SMEs is for, and if the question underneath yours is really about budget, the honest numbers live on what an AI proof of concept costs.
Written in August 2026, from the pattern I keep seeing in first conversations. The technology in this essay will date quickly. The part about who is still holding project one will not.
