AI Project Mistakes to Avoid: 10 Decisions That Sink Projects

Avolis Research Group

·

·

23 min read

Most AI project mistakes are owner decisions made before launch. The ten that sink smaller businesses' projects, real cases, and what to do instead of each.

The AI project mistakes that do the most damage are decisions, and most of them are made by the owner or manager before anything is built. The ten most common are starting from a tool instead of a measured workflow, putting the first project in front of customers, making it too big, accepting a demo as proof, signing without owning what gets built, skipping a written bar and stop date, building without the people who do the work, letting AI output go out unchecked, never switching off the old way, and treating launch as the finish line. Each one has a simple counter-move, and none of them takes technical skill.

That last point matters because the usual story about failed AI projects is a technical one, with bad models, messy data, and missing engineers. The research says otherwise. When RAND interviewed 65 data scientists and engineers about why projects failed, 84% of them named one or more leadership-driven causes as the primary reason projects fail, and our guide to why AI projects fail walks through that and the other major studies. The mistakes below are the operational version of that finding, and they apply whether a 10-to-200-person business is about to start a project or is already a few months into one.

Key Takeaways

  • Most AI project mistakes are management decisions, not technical errors, and most are made before launch, while choosing the project, buying, and setting it up.
  • Start internal. New York City's business chatbot launched in October 2023 and was telling owners they could take workers' tips within five months; the city took it down in February 2026 after a new mayor called it "functionally unusable."
  • Start small. In a study of 1,471 IT projects, the average cost overrun was 27%, but one in six projects overran by 200% on average and ran almost 70% late.
  • Check everything that leaves the building. Deloitte Australia agreed to refund part of an AU$440,000 government report in 2025 after a researcher found up to 20 errors, including a fabricated quote from a court judgment.
  • Write the bar down before you start. McDonald's ended its IBM drive-thru voice-ordering test, run in about 100 restaurants, in 2024; it had been aiming for 95%-plus order accuracy before a broader rollout.
  • Pitch AI as taking paperwork off people's desks, not as a headcount cut. In a 2024 Pew survey of 5,273 U.S. workers, 52% said they were worried about how AI will be used at work, and 36% felt hopeful.

Table of Contents

What Are the Biggest AI Project Mistakes?

The biggest AI project mistake is choosing what to build before measuring the work it's supposed to improve, because every later decision inherits that guess. A project aimed at a workflow nobody has timed can't be sized, priced, tested, or judged, so it drifts until someone loses patience with it. The other nine mistakes are mostly ways that first guess goes unchecked.

Here's the idea in simple terms. An AI project in a smaller business is a change to how a specific piece of work gets done, like writing up quotes, building the weekly schedule, or turning inspection notes into a client report. It succeeds when that work gets faster, cheaper, or more accurate and stays that way after the vendor's attention moves on. Every mistake below breaks one link in that chain: the wrong work gets picked, the change is too large to control, nobody can tell whether it worked, or nobody keeps it working.

None of these mistakes are exotic. They show up in city governments, global consulting firms, and fast-food chains, which is useful, because it means you can learn from expensive public examples instead of paying for your own. A roundup of AI project failure statistics covers how often projects fail and what each famous number actually counts; and the decisions below are what put a project on that list.

Where the Mistakes Happen

Six of the ten mistakes are made before any AI is built: three while choosing the project and three while buying it. That's good news for an owner, because those are the stages where you hold the most control and spend the least money. By the time a tool is live and people are using it, fixing a bad early decision means unwinding work, renegotiating a contract, or rebuilding trust with staff who've already decided the tool doesn't help.

AI Project Mistakes to Avoid: 10 Decisions That Sink Projects - Avolis AI Where the ten mistakes are made Six of ten happen before anything is built Before anything is built After the build starts Choose Buy Build Launch Run 1Tool beforethe workflow 2Customer-facingfirst 3Too big tocontrol 4Demo takenas proof 5No ownershipterms 6No bar orstop date 7Built withoutthe crew 8Output goesout unchecked 9Old way neverswitched off 10No ownerafter launch Cost to fix rises left to right: a changed decision on paper, then a changed contract, then retraining people.
The ten mistakes covered on this page, grouped by the stage where each decision is usually made.

Mistakes Made While Choosing the Project

The choosing stage is where a project gets its target, its audience, and its size, and the three mistakes here decide how much damage everything after them can do. Get these right and a weak vendor or a rough first version is a recoverable problem. Get them wrong and even a good build ends up solving the wrong thing in front of the wrong people at a scale nobody can steer.

Mistake 1: Starting from the tool instead of a measured workflow

This mistake looks like a decision to "get an AI chatbot" or "try an AI scheduling tool" because a competitor has one, a vendor demoed it well, or the owner saw it at a trade show. The tool comes first, and the search for a problem to point it at comes second. Months later the tool works roughly as advertised, and the hours that were actually draining away, in estimating, in the paperwork that follows every job, in the office manager's Monday reconciliation, are untouched.

Do this instead: pick the workflow first and put a number on it before talking to any vendor. "Matching supplier invoices to purchase orders takes about 9 hours a week" is a target you can price a tool against. Once you know what a piece of work costs you today, you can tell whether any tool is worth its price, and you'll often find the best first project is one no vendor was pitching.

Mistake 2: Putting the first project in front of customers

The first AI project a lot of owners picture is a customer-facing one, usually a website chatbot, because it's visible and easy to demo. It's also the riskiest place to learn, because every wrong answer goes straight to someone you can't call back and correct, and the business is on the hook for whatever the tool said.

New York City learned this in public. In October 2023 the city launched an AI chatbot meant to help business owners with city rules. Five months later, testing by The Markup found it telling landlords they didn't have to accept tenants with housing vouchers, telling employers they could take workers' tips, and telling a restaurant it could go cash-free despite a 2020 law requiring businesses to accept cash. When ten Markup staffers asked the same housing question, all ten were told no (The Markup, "NYC's AI Chatbot Tells Businesses to Break the Law", March 2024). The city added disclaimers and kept it running. In January 2026 Mayor Zohran Mamdani called it "functionally unusable" and said it was costing "around half a million dollars," and the city took it down the following month (The Markup, "Mamdani to kill the NYC AI chatbot", January 2026, updated February 2026).

Do this instead: make the first project an internal one, where a staff member reads every output before it reaches anyone outside the business. A tool that drafts quotes for your estimator, or summarizes job notes for your office manager, gets the same learning with a person standing between every mistake and your customer. Move it closer to customers only once you have weeks of evidence about how often it's wrong and what kind of wrong it tends to be.

Mistake 3: Making the first project too big to control

Big first projects feel efficient. If the AI is going to handle intake, why not have it schedule the job and draft the invoice too? The trouble is that each added step multiplies the ways the project can go wrong, and large technology projects don't fail by a little.

The clearest evidence comes from Bent Flyvbjerg and Alexander Budzier at Oxford's Saïd Business School, who studied 1,471 IT projects. The average cost overrun was 27%, which sounds survivable. But "fully one in six of the projects in the sample was a Black Swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%" (Flyvbjerg and Budzier, "Why Your IT Project May Be Riskier than You Think," Harvard Business Review, September 2011). Their advice for avoiding those outliers was to break big projects down "into ones of limited size, complexity, and duration."

AI Project Mistakes to Avoid: 10 Decisions That Sink Projects - Avolis AI The average hides the projects that sink you Overruns in 1,471 IT projects (Flyvbjerg and Budzier, 2011) 0% 50% 100% 150% 200% All projects: cost overrun 27% 1 in 6 projects: cost overrun 200% 1 in 6 projects: schedule overrun ~70% Amber bars: the "black swan" projects, averaged across that group.
Source: Bent Flyvbjerg and Alexander Budzier, "Why Your IT Project May Be Riskier than You Think," Harvard Business Review, September 2011. The study covers IT change projects generally, not AI projects specifically.

That study predates generative AI, but the shape transfers. A smaller business doesn't have the cash buffer to absorb a tripled budget, so the outlier risk matters more, not less.

Do this instead: cut the first project down to one step of one workflow, with a defined input and a defined output, that can show a result within a quarter. If it works, the next step builds on something proven, and if it doesn't, you've lost a few months and a small budget instead of a year and your team's goodwill.

Mistakes Made While Buying

The buying stage is where a promising idea turns into a contract, and the three mistakes here are about what you agree to before you've seen the tool work on your own business. A smaller buyer has real bargaining power at this point, because no money has changed hands, and almost none once the contract is signed and the setup fee is paid.

Mistake 4: Taking the demo as proof

A vendor demo is built to succeed. It runs on clean sample data, on the cases the tool handles best, and usually with someone at the keyboard who knows exactly what to type. None of that tells you how the tool will handle your job records, with your abbreviations, your half-filled fields, and the customer who emails a photo of a handwritten note.

Do this instead: before signing, ask for a test on 20 to 30 of your own real, recent cases, including a few messy ones, and decide in advance what a passing result looks like. Write that test into the contract as the acceptance step, so the vendor's final payment depends on the tool doing your work and not their demo. Our page on why AI consulting projects fail to reach production lists the other scope terms worth writing in.

Mistake 5: Signing without owning what gets built

Many AI tools for smaller businesses run inside the vendor's account, with the instructions, templates, and connections that make the tool fit your business stored on their side. That's convenient until you want to switch vendors, the price goes up at renewal, or the vendor goes out of business, and you find that the part you paid to have built doesn't leave with you.

Do this instead: before signing, get written answers to four questions. Can you export your data and the tool's setup (its instructions, templates, and workflow configuration) in a usable format at any time? Is there written documentation of how it works that another provider could follow? What notice do you get before price or terms change? And how short is the commitment for a first project? Month-to-month or a short initial term costs a little more per month and is worth it until the tool has proven itself. Our guide to choosing an AI consulting company covers the wider set of questions to ask a partner before you hire one.

Mistake 6: No written bar and no stop date

A project with no written result to hit and no date to judge it by has no way to fail and no way to succeed. It just continues, and the monthly bill continues with it. The pattern is common enough to have a name, and our page on AI pilot purgatory covers how pilots get stuck there.

McDonald's offers a useful counterexample. It partnered with IBM in 2021 and tested AI voice ordering in about 100 drive-thrus. According to Nation's Restaurant News, it was aiming for a 95%-plus order accuracy rate before any broader rollout (Nation's Restaurant News, "McDonald's is ending its AI drive-thru test with IBM", June 2024). A 2022 BTIG report had put voice-ordering accuracy in the low 80% range, and two sources told CNBC the system had trouble with different accents and dialects. McDonald's declined to comment on accuracy and told franchisees the technology would be shut off "no later than July 26" (CNBC, "McDonald's to end IBM AI drive-thru test", June 2024). The target was public and specific, and the last outside estimate sat well short of it, so everyone involved could see the gap.

Do this instead: before work starts, put four things on one page: today's number, the target, a monthly cost ceiling, and a decision date. Our guide to AI project success metrics covers which numbers to track, and our page on AI pilot purgatory covers how to make the call when the date arrives.

Mistakes Made While Building

The building stage is when the tool meets the people who'll use it and the work it will touch, and the two mistakes here both come from treating the project as a technology installation instead of a change to how people work. They're the mistakes most likely to produce a tool that functions perfectly and gets quietly ignored.

Mistake 7: Building without the people who do the work, or pitching it as a headcount cut

The people who do a job every day know where it actually breaks: the exception that comes up twice a week, the customer who always needs a different format, the field nobody fills in because the old system made it optional. A tool designed around the manager's description of the work, instead of the workers' version of it, misses those details and earns a reputation for being "fine for easy ones."

The framing matters as much as the involvement. In an October 2024 Pew Research Center survey of 5,273 employed U.S. adults, 52% said they felt worried about how AI may be used in the workplace in the future, 36% felt hopeful, and 32% thought AI would lead to fewer job opportunities for them in the long run (Pew Research Center, "U.S. Workers Are More Worried Than Hopeful About Future AI Use in the Workplace", February 2025). An announcement that sounds like "the AI will do what you do" lands on that worry, and a worried team has every reason to find the tool's mistakes and none to help fix them.

Do this instead: put the person who does the work today on the project from the first week, and ask them which part of the job they'd most like to stop doing. Describe the project as taking the paperwork off their desk so they spend more time on the part of the job only they can do, and then make sure that's what it actually does. Our guide to why corporate AI implementations fail goes deeper on the adoption side.

Mistake 8: Letting finished-looking output go out unchecked

Generative AI produces drafts that look finished, with confident prose, tidy formatting, and citations in the right places. That polish is exactly what makes errors easy to miss, because a reviewer skimming a clean document has no visual cue that one sentence in it is invented.

Deloitte Australia's report shows what can reach a client when that review is thin. In 2025 it delivered an AU$440,000 report to Australia's Department of Employment and Workplace Relations. After publication, a University of Sydney researcher found up to 20 errors, including a fabricated quote from a federal court judgment and references to academic papers that don't exist. A revised version disclosed that a generative AI system, Azure OpenAI, had been used, and Deloitte agreed to repay the final instalment of its contract (Associated Press, "Deloitte to partially refund Australian government for report with apparent AI-generated errors", October 2025). The department said the substance and recommendations were unchanged, but the firm's name was on a government document with a made-up judicial quote in it.

Do this instead: for anything that leaves the business (a quote, a client report, a compliance document, an email to a customer), name the person who checks it and what they check against. A usable check names the record, as in "confirm every price matches the price list and every date matches the job record." Keep that review in place until you have weeks of records showing how often the tool is wrong, and loosen it only for the kinds of output that have earned it.

Mistakes Made at and After Launch

The last two mistakes happen after the project looks done, which is why they're easy to miss. Both come from treating launch as the end of the project, when for an AI tool it's closer to the start of its working life.

Mistake 9: Never switching off the old way

Running the old process alongside the new tool for a few weeks is sensible. Running it indefinitely means the business pays for both, staff learn that the new tool is optional, and nobody ever finds out whether the tool could carry the work on its own. The office manager who keeps a spreadsheet "just in case" is often right to, since nobody set a date for the tool to take over.

Do this instead: set the switch-off date before launch, tied to the bar from Mistake 6. When the tool has hit its target for an agreed stretch, say three or four weeks, the old method stops for the work the tool covers. Our page on AI pilot purgatory covers what "in production" should mean.

Mistake 10: Treating launch as the finish line

An AI tool keeps working only as long as the things it depends on stay the same, and in a working business they don't. Prices change, a new service line gets added, a supplier changes its invoice layout, the job system gets an update, and the tool that was accurate in March starts drifting in June. Unless checking is someone's job, a customer is usually the first to notice.

Do this instead: name one internal owner for the tool after launch, give them a short monthly check (pull a handful of recent outputs and compare them to the records they came from), and agree on who fixes it when the check fails. Our guide to why AI projects fail because of data quality covers the ways a working tool decays, and if a project is already slipping, our page on how to recover a failing AI project walks through the triage.

The Checklist: One Question per Mistake

Each of the ten mistakes can be caught with one question asked at the right moment. None of them needs technical knowledge to answer, only someone willing to ask before signing, building, or launching.

# Mistake When to ask The question that catches it
1 Tool before the workflow Before talking to vendors Which workflow is this for, and what does it cost us today in hours or errors?
2 Customer-facing first Choosing the project Does a staff member read every output before a customer sees it?
3 Too big to control Choosing the project Is this one step of one workflow, with a result inside a quarter?
4 Demo taken as proof Before signing Has it been tested on 20 to 30 of our own real cases, with a pass mark set in advance?
5 No ownership terms Before signing Can we export our data and the tool's setup, and is the first commitment short?
6 No bar or stop date Before work starts What's today's number, the target, the monthly cost ceiling, and the decision date?
7 Built without the crew First week of the build Is the person who does this work on the project, and is it described to them as removing their paperwork?
8 Output goes out unchecked Before first use Who checks each output that leaves the business, and against what record?
9 Old way never switched off Before launch On what date, and after what result, does the old method stop?
10 No owner after launch At launch Who checks the tool monthly, and who fixes it when the check fails?

If you can answer the first six questions with specifics before a contract is signed, you've removed most of the risk on this page. A structured readiness diagnostic answers them across several workflows at once, and our guide to AI readiness assessment services explains what a good one should produce.

A 55-Person Commercial Cleaning Company, Before and After

A 55-person commercial cleaning company (an illustrative composite) shows how the mistakes stack up, and how differently the same business can fare when it avoids them. The company cleans offices, medical suites, and light-industrial sites under monthly contracts, with three area supervisors who inspect each site and an operations manager who handles client reporting.

The first attempt. After a competitor added a chat window to its website, the owner signed a 12-month contract for an AI website assistant at $1,200 a month. It would answer prospective clients' questions, collect square footage, and give an instant estimate for nightly cleaning. That was three mistakes at once: a tool chosen before any workflow was measured (1), placed in front of prospects (2), and handling pricing, a judgment call the company's sales lead had always made herself (3). The setup lived in the vendor's account, with no way to export the pricing rules the sales lead spent two afternoons writing (5), and nobody had written down what success would mean (6).

Within six weeks, the assistant quoted a medical suite at the standard office rate, missing the disinfection work that roughly doubles the labor on that kind of contract, and the sales lead had to walk the number back with an annoyed practice manager. The pricing feature was switched off in month four. The chat window stayed up, answering questions about service areas, until the contract ran out, for about $14,400 in total.

The second attempt. This time the owner started from a measurement. The operations manager was spending about 26 hours a month turning supervisors' inspection notes and photos into monthly quality reports for 40 clients, and the reports went out around the 12th of each month, which two facility managers had complained about at renewal time. That became the target: one step (inspection notes in, draft report out), internal, with the operations manager reading every draft before it went to a client.

The bar was written down before any work began: reports out by the fifth business day, under ten minutes of editing per report, and no report sent with a score or photo that didn't match the inspection record. The decision would come after three monthly cycles. The setup ran in the company's own account on a month-to-month arrangement, and the supervisors were involved from the first week, which turned up the real obstacle. Each supervisor described problems in their own words, so the same scuffed floor appeared as "scuffing," "marks," and "needs buffing," and the drafts were inconsistent until the three of them agreed on a short shared list of deficiency terms.

In the first cycle, the operations manager's review caught two drafts that had pulled photos from the wrong building, which traced back to supervisors naming photo folders inconsistently in the inspection app. The naming was fixed before the second cycle. By the third cycle, reports were going out by the fourth business day, editing averaged about eight minutes per report, and the work took roughly nine hours a month instead of 26. The old manual process was retired after that cycle, and the operations manager now spends half an hour each month comparing five random reports against the inspection records, with the provider on call if a check fails.

First attempt Second attempt
Starting point A competitor's chat window A measured workflow (26 hours a month, reports out ~12th)
Audience Prospective clients Operations manager, then clients after review
Scope Answers, intake, and pricing One step: inspection notes to draft report
Contract 12 months, setup in vendor's account Month-to-month, setup in company's account
Bar and date None Fifth business day, under 10 minutes editing, decision after three cycles
Review None before quotes went out Every draft read before sending
Result Pricing switched off in month four; ~$14,400 spent Reports by the fourth business day; ~9 hours a month

Both attempts used similar technology, and the second differed in the decisions listed in the table.

Which Mistakes to Fix First If You're Already Underway

If a project is already running, fix the review gap first (Mistake 8), then the missing bar and date (Mistake 6), then the owner (Mistake 10). That order follows the risk: unchecked output can hurt you with a customer this week, while a missing bar costs money more slowly, and a missing owner costs you over months as the tool drifts.

Some of the other mistakes are cheaper to fix than they look. A project that started from a tool (Mistake 1) can often be re-aimed at a measured workflow without starting over, by narrowing it to the one task where it already helps. A customer-facing tool (Mistake 2) can be pulled back behind a staff review while you gather evidence. Contract terms (Mistake 5) are hardest to change mid-term, but renewal is a natural point to ask for export rights and a shorter commitment, and a vendor who wants to keep you will usually listen.

Sometimes the right fix is to stop, and our page on how to recover a failing AI project covers how to decide between recovering, narrowing, restarting, and ending.

Where Avolis Fits

Every engagement starts with our diagnostic, which is built to make the first six decisions on this page with evidence instead of instinct. We work through each candidate workflow with the people who run it, measure how it runs today (volumes, time per task, handoffs, error rates), and rank what's worth building, so the project you pick is aimed at work with a known cost and a realistic first step. You keep the ranked result whatever you decide to do next.

When we build, the rest of the list is part of how we work. Our first projects are internal by default and sized to show a result within a quarter. There's a written bar and decision date before the first draft goes out, the people who do the work are on the project from the start, and everything that leaves your business has a named reviewer until the records say it's safe to loosen that. What we build lives in your systems and is documented, and when we stay on after launch, the monthly checks and fixing what underperforms are our job. Our guide to AI readiness assessment services explains what the diagnostic produces, and our guide to which AI consulting company to choose covers how to compare us with the alternatives.

Frequently Asked Questions

What is the most common AI project mistake?

The most common mistake is choosing a tool or a use case before measuring the work it's supposed to improve. Without that starting number, nobody can size the project. Nobody can judge whether it worked, either, or justify its cost when the budget gets tight and someone asks what the monthly bill is buying. 84% of the 65 data scientists and engineers RAND interviewed named leadership-driven causes as the primary reason projects fail.

Should a small business start with a customer-facing AI chatbot?

Usually not. A customer-facing tool sends every error straight to someone outside the business, and the business is responsible for what it says. Five months after launch, New York City's business chatbot was telling owners they could break the law, and the city took it down in 2026. An internal project, where a staff member reviews every output, teaches the same lessons with far less risk.

How big should a first AI project be?

Small enough to show a measurable result within about a quarter: one step of one workflow, with a defined input and output. Large technology projects carry outsized risk. In a study of 1,471 IT projects, one in six overran its budget by 200% on average and ran almost 70% late, and the authors recommended breaking big projects into ones of limited size, complexity, and duration.

What should an AI vendor contract include?

At minimum, an acceptance test on your own real cases with a pass mark agreed in advance, the right to export your data and the tool's setup (instructions, templates, configuration) at any time, documentation another provider could follow, notice before price changes, and a short first commitment. These terms matter most for a smaller business, which has the least bargaining power after signing.

Which AI project mistakes are made before signing a contract?

Six of the ten common mistakes happen before signing: choosing a tool before measuring the workflow, making the first project customer-facing, making it too big, accepting a vendor demo as proof, signing without the right to export your data and setup, and starting without a written target and decision date. They're also the cheapest to fix, because nothing has been paid or built yet.

Continue Learning

Every mistake on this page is a decision someone could have made differently, and most of them come down to measuring the work, keeping the first project small and internal, writing the bar down, and naming who checks and who owns the result. None of those steps needs technical skill, only someone willing to ask before signing.

If you're about to start an AI project, take the ten questions in the checklist into your next vendor conversation and don't sign until you can answer the first six.

Why projects fail, in detail:

Starting the right way:


Sources

On the McDonald's figures. The 95%-plus accuracy goal is as reported by Nation's Restaurant News; McDonald's declined to comment on accuracy to CNBC, and the accent and dialect difficulties come from unnamed sources cited by CNBC. Both outlets describe the test as running in about or more than 100 restaurants.

On the Flyvbjerg and Budzier study. It covers 1,471 IT change projects and predates generative AI. The figures are used here to show how technology project overruns are distributed, not as a forecast for AI projects.

On the Pew survey. Fielded October 7 to 13, 2024, among 5,273 U.S. adults employed part or full time (one job, or a primary job). 63% of respondents said they don't use AI much or at all in their job.

On the commercial cleaning company. It's an illustrative composite, not a client. Its figures (55 people, three supervisors, 40 clients, $1,200 a month, 12 months, about $14,400, six weeks, month four, 26 and nine hours a month, the 12th, fifth and fourth business days, ten and eight minutes, three cycles, two drafts, five reports, half an hour) are representative examples, not measurements or benchmarks.


About Avolis Research Group

Avolis Research Group is Avolis's in-house research practice, focused on how operations-heavy small and mid-sized businesses actually adopt AI. It synthesizes primary economic research, government survey data, and results from real implementations into practical, vendor-neutral guidance.

More about Avolis and how we work · Get in touch

Ready to make AI work for you?

Book an AI readiness evaluation. If there’s nothing worth automating, we’ll tell you.