Key takeaways

  • Almost none of the failure patterns are technical. The technology usually works. The problem is almost always upstream: wrong problem, unclear ownership, no adoption plan, or measurement that starts too late.
  • The single most expensive mistake is automating before understanding the process. Building a technically correct solution to the wrong problem costs the same as building the right one and delivers nothing.
  • Team enthusiasm at the launch of an AI project is not adoption. Real adoption is what happens six weeks later when the novelty has worn off and people are under deadline pressure.
  • AI owned by everyone is maintained by no one. Every automation needs a named person whose job it is to keep it working and improve it over time.
  • The pattern underlying almost every failure is the same: implementation started before the diagnostic was complete. Two to four weeks of structured thinking before any build begins prevents the majority of these problems.

The articles that show up when you search for why AI projects fail share a common feature: they quote a number and then explain almost nothing. "Seventy percent of AI projects fail" followed by a list of abstract causes like "lack of data quality" or "insufficient change management." True, probably, and not very useful if you are in the middle of a project that is not working.

This article takes a different approach. It describes the specific, concrete mistakes I have seen repeated across AI and automation projects of different sizes and sectors. Each one has a recognisable signature: you know it when you see it. And each one has a practical fix that does not require a major restructuring of the project.

Why this keeps happening

Before the individual mistakes, it is worth naming the structural reason they repeat so reliably. AI implementation projects have a specific pressure that most other technology projects do not: the expectation of visible, fast results. Leadership has approved a budget based on projected savings. A vendor has demonstrated impressive capabilities. The team is excited. There is enormous pressure to show something working quickly.

This pressure is the root cause of most failures. It pushes teams to skip the slow, unglamorous work of understanding the current process before they start changing it. It rewards visible activity (automations built, demos delivered) over actual outcomes (time saved, errors reduced). And it creates an environment where admitting the project is heading in the wrong direction feels like failure, so problems accumulate quietly until they are too large to fix incrementally.

Every mistake below is, in some way, a consequence of this pressure.

The five mistakes that appear in nearly every failed project

01

Automating before understanding the process

A founder I spoke with last year had spent four months and around 40,000 euros building an AI system to automate his operations team's reporting workflow. The system worked. It produced reports faster and with fewer manual steps. The problem was that the reporting workflow was not actually the bottleneck. The real bottleneck was the decision-making process that happened after the reports were produced, which the automation did not touch at all. The operations team was saving two hours a week on report generation and still spending twelve hours waiting for decisions to be made on the output.

This pattern repeats constantly. Teams automate the most visible manual process, not the most valuable one. The two are rarely the same. The most visible processes are usually those that feel laborious to the people doing them. The most valuable are those that are actually slowing the business down. Finding the second category requires a diagnostic phase before any tool is selected or any build begins.

Warning signal

The project started with a tool or a workflow in mind, not a business problem. If the first conversation was "let's automate our X process with Make" rather than "what is actually costing us the most time or money," the project is at risk of this mistake.

02

Confusing launch enthusiasm with adoption

Every automation project has a honeymoon period. The team uses the new system enthusiastically. Early metrics look promising. Leadership declares success. Then, six to eight weeks in, a high-pressure week arrives. There are deadlines, edge cases appear, and the automation requires a workaround or produces output that needs reviewing. Under pressure, people revert to what they know. The automation gets used selectively, then occasionally, then not at all by some team members.

Adoption is not enthusiasm. It is what happens after the novelty wears off and people have to choose between the new system and their old habits under real conditions. Projects that do not plan for this transition fail at adoption even when the technology is sound. Planning for it means identifying the specific conditions under which people will revert, training for those scenarios, and having a real owner who notices when usage drops and responds to it.

Warning signal

Usage data is not being tracked, or nobody is looking at it. If you cannot answer how many team members are using the automation regularly versus occasionally versus not at all, you do not know whether it is adopted.

03

Choosing the tool before defining the problem

This is the vendor-driven version of mistake one. A company attends a demo, is impressed, and signs up for a platform. The platform then shapes what problems get solved, because the team naturally looks for problems the tool can handle rather than asking what problems most need solving. You end up with a beautifully configured Make workspace automating processes that were not actually high priority, while the real bottlenecks remain untouched because they do not fit the tool's strengths.

The order of operations matters: define the problem first, identify the requirements second, then evaluate tools against those requirements. This sounds obvious and is almost universally ignored. Tool selection is exciting. Problem definition is slow and sometimes uncomfortable because it surfaces disagreements about what is actually important. Teams rush past it.

Warning signal

The project was initiated by a tool evaluation rather than a problem audit. If the first step was comparing Zapier to Make rather than mapping which processes are costing the most, the order is inverted.

04

No clear owner for the automation after launch

AI and automation projects are frequently treated as projects rather than products. They have a build phase and a launch, and then they are considered done. What they actually need is an owner: a specific person whose job it is to keep the system working, handle edge cases, update it when upstream processes change, and improve it over time based on what the usage data shows.

Without an owner, the automation degrades. Upstream data formats change and the automation starts producing errors. A process step gets modified and nobody updates the workflow. A new edge case becomes frequent and gets handled with a manual workaround that nobody documents. Six months after launch, the system is partially broken and partially worked around, and nobody is quite sure of the current state of what is automated and what is not. I have seen this in every organisation that treats automation as a project with an end date rather than a capability that requires ongoing stewardship.

Warning signal

The person who built the automation is no longer actively involved and no one has formally taken ownership. Ask who is responsible for the automation working correctly next month. If the answer is vague, ownership has not been established.

05

Expecting AI to replace judgment instead of support it

This mistake is specific to AI components rather than rule-based automation, and it is becoming more common as language models get integrated into business workflows. A team builds a system where the AI makes a decision or produces an output that goes directly into the process without human review. This works well until an edge case appears that the model handles badly. Because there is no review step, the bad output propagates downstream before anyone catches it, and the cost of the error is multiplied.

The better design is to treat AI outputs as inputs to human judgment rather than replacements for it, at least until the system has demonstrated consistent reliability on your specific data and use case. This means building in a lightweight review step, not for every output forever, but for long enough to understand where the model performs well and where it does not. The goal is not zero human involvement. It is appropriate human involvement at the points where the cost of an AI error is highest.

Warning signal

No review step exists for AI-generated outputs that enter downstream processes. If the AI output is used directly without any human checkpoint, ask what happens when it is wrong. If the answer is "it will propagate through the system before anyone notices," a review step needs to be added.

The pattern underneath all five mistakes

Each of these mistakes looks different on the surface. But they share a common root: implementation began before the diagnostic was complete.

A proper diagnostic, done before any tool is selected or any build begins, would surface most of these problems before they become expensive. It would identify which processes are actually the bottleneck, not just the most visible. It would surface disagreements about what the project is actually for. It would establish who owns what after launch. It would define what success looks like in measurable terms, so there is something to track against rather than an impression.

The diagnostic takes two to four weeks. It is not glamorous. It does not produce anything immediately visible. It is the part most organisations skip because the pressure to show progress is already high before the project has officially started.

The irony is that skipping it does not accelerate the project. It accelerates the arrival at a point where the project needs to be partially or fully restarted. The time lost to a bad build plus a restart is almost always longer than the time a diagnostic would have taken.

For a practical framework on measuring whether an AI project is working once it is running, see how to measure the ROI of an AI automation project. For guidance on which processes to automate first, see AI automation for startups and SMEs.

What to do if you recognise your project in this list

If you are reading this because a project is already in trouble, the first step is separating the technical problems from the strategic ones. Technical problems (the automation is unreliable, the output quality is poor, the system breaks on certain inputs) can often be fixed without restarting. Strategic problems (you are automating the wrong process, nobody owns the system, the team is not actually using it) require going back to the diagnostic before adding more technical work.

Adding features or complexity to a project with a strategic problem makes the strategic problem more expensive to address later, not less. The instinct when a project is not working is to do more. Usually the right move is to pause, diagnose, and decide whether what has been built is worth continuing or whether the resources are better spent starting from a better-defined problem.

This is an uncomfortable conversation to have internally, which is often why it does not happen until the problem is very large. An external perspective, whether from a consultant, an advisor, or even a peer who has been through a similar situation, can make it easier to see the project clearly enough to make a good decision about it.

Work with Ipernovation

Recognise one of these patterns in a project you are running?

A focused diagnostic session can identify which of these problems you are dealing with and what the practical next step is. No pitch, no proposal: a direct conversation about your specific situation.

Start a conversation