How to Recover a Failing AI Project

To recover a failing AI project, stop adding to it, spend two weeks measuring what it actually does on real work, find the first link in the chain that's broken, and then make one of four calls: recover it, narrow it to the part that pays, restart it on a better footing, or stop it. Most rescues go wrong at the first step, because the instinct when a project is slipping is to add features, extend the contract, and promise that next month will be different. That instinct is well documented, and it's the main reason troubled projects run as long and as expensively as they do.

Trouble is common. Gartner's survey of 782 infrastructure and operations leaders, fielded in late 2025, found that only 28% of their AI use cases fully succeed and meet ROI expectations, while 20% fail outright, and Gartner attributes most of those failures to initiatives that were "overly ambitious or poorly scoped" (Gartner, "Gartner Says AI Projects in I&O Stall Ahead of Meaningful ROI Returns", April 2026). Unlike a weak model or missing records, scope is something an owner can cut back midstream, which is why a struggling project deserves a triage before it gets a cancellation.

Key Takeaways

• Recovering a failing AI project starts with a freeze: no new features, no contract extensions, and two weeks of measuring how the tool performs on real work.
• Gartner's 2026 survey of 782 infrastructure and operations leaders found only 28% of their AI use cases fully succeed and meet ROI expectations, with failures driven mostly by projects that were overly ambitious or poorly scoped.
• Keil, Mann and Rai found that between 30% and 40% of information systems projects show some degree of escalation, where a team keeps committing resources to a course that isn't working.
• Every triage ends in one of four calls: recover the project, narrow it to one workflow, restart it, or stop it. The measured value of the work behind it decides most of that.
• In Keil and Robey's interviews with 42 IS auditors, most troubled projects changed course, either turned around or sensibly abandoned, after senior managers, internal auditors, or outside consultants stepped in.
• Before replacing an AI vendor, secure your accounts, data, and configuration. In a 2026 Zapier survey, 58% of executives whose companies had tried to switch AI platforms said the move failed or took far more effort than expected.

Table of Contents

• How do you recover a failing AI project?
• Signs your AI project is failing, not just slow
• Why failing projects are so hard to stop
• Run a two-week triage
• Recover, narrow, restart, or stop
• Keep your current consultant or bring in someone new?
• A 90-day recovery plan
• A maintenance-request assistant, recovered
• How to tell the recovery is working
• Where Avolis fits
• Frequently Asked Questions
• Continue Learning

How Do You Recover a Failing AI Project?

You recover a failing AI project by treating it as a diagnosis problem before you treat it as a build problem. Freeze the scope, measure what the tool does on the last two weeks of real work, trace the first place where the chain from problem to payoff breaks, and decide whether the work behind the project is worth fixing at all. Only then do you change the build, the plan, or the people.

That order matters because the symptoms of a failing project point in the wrong direction. Low usage looks like a training problem, wrong answers look like a model problem, and a slipping timeline looks like a staffing problem, so each one invites more spending on the thing that looks broken. Underneath, the cause is usually earlier in the chain. Our guide to why AI projects fail sets out five links (the right problem, a place in the workflow, the data the task needs, a defined cost and value, and an owner after launch), and in a failing project the first broken link tends to explain most of what's wrong further down.

The rest of this page follows the sequence an owner or operations lead can actually run: recognize the signs, get past the pull to keep going, run the triage, make the call, sort out the vendor question, and give the recovery 90 days with a stop date attached.

Signs Your AI Project Is Failing, Not Just Slow

A slow project is still moving toward a result someone can name, while a failing project has lost track of the result and keeps moving anyway. The difference shows up in a handful of plain signals you can check without any technical help, and two or more of them together usually mean it's time to stop and triage rather than wait another month.

The last two rows deserve the most attention. A growing feature list is how a struggling project buys time, since every new feature resets the clock on judging it. A missing owner is how a struggling project stays invisible, since nobody inside the business is close enough to the work to say it isn't helping. If the project is a consulting pilot that never made it live, our page on why AI consulting projects fail to reach production covers that specific case in more depth.

Why Failing Projects Are So Hard to Stop

Failing projects are hard to stop because the people closest to them have the most invested in believing they'll work. Researchers call this escalation of commitment: continuing to put money and time into a course of action after the evidence says it isn't working. It isn't rare. A survey of IS audit and control professionals, with 579 responses, led Mark Keil, Joan Mann, and Arun Rai to conclude that between 30% and 40% of all information systems projects exhibit some degree of escalation, and that the escalated projects were rated significantly worse on implementation, budget, and schedule (Keil, Mann and Rai, "Why Software Projects Escalate," MIS Quarterly, December 2000, p. 631).

Isabelle Royer, a management researcher who studied failed innovation projects and reported her findings in Harvard Business Review, found the cause wasn't incompetence or inertia. It was what she called a collective belief, "a strong conviction based on feeling rather than evidence that the project will eventually succeed," shared by most of the people deciding (Kathleen Melymuka, "Blind Faith," Computerworld, February 2003). Her opening example, RCA's SelectaVision videodisc player, ran for 14 years and cost $580 million before it was killed, even though experts called the technology obsolete at the prototype stage (Royer, "Why Bad Projects Are So Hard to Kill," Harvard Business Review, February 2003).

A 40-person company won't lose $580 million, but the mechanism scales down neatly. The owner who championed the AI project is the person everyone reports to, the office manager who quietly stopped using it doesn't want to be the one who says so, and the provider writing the status reports is the one paid to keep the engagement going. Royer's remedy was an "exit champion": a credible person who argues for stopping with evidence rather than opinion and pushes for a rigorous review. In a smaller business, that role often falls to a skeptical partner, a controller, or an outsider with no stake in the original decision.

Keil's research points to a simpler guard as well. He and his co-authors recommend defining "de-escalation trigger points" at the outset, so that when cost and schedule approach them, managers act before the overrun compounds (p. 656). If your project never had those trigger points, the triage below is where you set them.

Run a Two-Week Triage

A two-week triage is a short, structured review that replaces opinions about the project with measurements of it. It doesn't need technical skill, and it works the same way whether the tool was built by a consultant, bought as software off the shelf, or put together by someone in-house who has since moved on to other work. One rule holds for the full two weeks. Nothing new gets added: no features, no contract extensions, no new use cases.

1. Freeze the scope. Tell the provider and the team that the plan is paused for two weeks while you measure. Work in progress can finish, but nothing new starts.
2. Write down what it was supposed to change. One sentence, with a number if one ever existed: "Cut the hours our coordinators spend logging maintenance requests." If nobody agrees on the sentence, the project never had a target, and that's the first thing the triage has found.
3. Measure the work without the tool. Time the workflow the way it runs today, including the workarounds. You need a before number to judge anything else against, and our guide to measuring AI ROI covers how to get one quickly.
4. Test it on what actually came in. Feed the tool every request, invoice, or record from the last two weeks, exactly as it arrived, rather than the cleaned-up sample it was built on. Sort each output into usable as is, usable with edits, or wrong.
5. Talk to the three people closest to it. Ask what they do with the output, where they stopped trusting it, and what they'd keep if they could keep only one thing.
6. Find the first broken link. Walk the five links in order (problem, workflow fit, data, cost and value, owner) and mark the first one that fails. That's where the recovery starts, because the later failures usually follow from it.

Step four is usually the most revealing. Projects drift from the work they were meant to serve, and a test on two weeks of live, unedited records shows how far in a single afternoon. If the tool handles most of that work well and the trouble is elsewhere, you have a recoverable project. If it struggles on the work as it actually arrives, the problem is closer to the foundation, and data quality is the usual suspect.

Recover, Narrow, Restart, or Stop

Every triage should end with one of four calls, and three questions decide which: is the work behind the project worth fixing, is the scope small enough to finish, and can what's already built be repaired within about a quarter? Answer them in that order, since a project that targets low-value work isn't worth rescuing however fixable it is.

Narrowing is the call that fits Gartner's numbers best. Gartner's 2026 survey found that the leaders who delivered at least one successful AI use case credited it mainly to integrating AI into existing workflows and systems, and to securing full support from business executives, while many of the leaders reporting a failure said they had expected too much, too fast. A project that set out to automate intake, scheduling, and reporting at once can often be saved by keeping only the piece with the clearest payoff and finishing it properly.

Stopping is a legitimate result, too. If the before number shows the workflow is a minor cost, or step four shows the tool can't work because the records it depends on were never kept, ending the project is the cheapest thing it can still do for you. The point of the triage is that the decision rests on a number rather than on how much has already been spent, which is exactly the trap Keil and Royer describe.

Keep Your Current Consultant or Bring In Someone New?

Keep your current provider if the triage shows the gap came from the scope you agreed together, and replace them if it shows they can't deliver against a clear scope. Many failing projects were set up to fail by both sides: a contract that never defined going live, a buyer who kept adding requests without saying which mattered most, and a provider who measured the project by its demos. Swapping providers doesn't fix any of that, and a new firm inherits the same unwritten scope.

Fresh eyes still help, even when you keep the provider. Keil and Daniel Robey interviewed 42 IS auditors about troubled software projects that were turned around or sensibly abandoned. In the majority of cases, they found, the change of course was triggered by senior managers, internal auditors, or external consultants; the change itself came both from managing existing resources better and from changing how much was committed (Keil and Robey, "Turning Around Troubled Software Projects," Journal of Management Information Systems, 1999). Royer reached a similar conclusion from the other direction, recommending that companies replace some of the decision-makers partway through a long project, because newcomers look at it without the original belief.

Use the triage findings to decide:

• Renegotiate when the provider built on your real data, will agree to a written go-live test and a fixed scope for the fix, and was held back by delays on your side, such as slow approvals, no one to answer questions, or a target that kept moving.
• Replace when the tool fails on your live records for reasons the provider can't explain, when status reports still describe activity after you've asked for outcomes, or when they push for a larger scope before the original one works.
• Bring in an independent review when you can't tell which of those applies, especially if the person who championed the project is the one deciding.

If you do switch, plan the handover before you give notice. In a 2026 survey of 542 U.S. executives at companies paying for AI vendors, two-thirds had tried to migrate between AI platforms, and of those, 58% said the move failed outright or took significantly more effort than expected (Zapier, "Nearly 3 in 4 enterprises say losing AI vendors would disrupt core business operations", April 2026). Those are larger companies than most of our readers, but the cause Zapier describes, undocumented dependencies and workarounds that were meant to be temporary, is the same in a 40-person business.

If you're choosing a new firm, our guide to which AI consulting company to choose sets out what to ask a replacement firm before you sign, including who owns the build if you part ways.

A 90-Day Recovery Plan

A recovery should be time-boxed, because an open-ended rescue is just escalation with a new name. Ninety days is long enough to fix one broken link and prove the result on live work, and short enough that the stop date is still close when you set it.

Days 1 to 14: triage. Freeze the scope, measure the workflow, test the tool on two weeks of real records, and make the recover, narrow, restart, or stop call. Write down the before number, the target, the monthly cost ceiling, and the date you'll decide whether to continue. Those are your trigger points.

Days 15 to 45: fix the first broken link. Do one thing at a time. If the output lands outside the system your team uses, connect it. If the tool can't handle a common type of record, fix that type. If it has no way to flag uncertain answers, build the review path so the cases it gets wrong go to a named person rather than back to everyone. Name one internal owner with protected hours each week, and hold the scope where the triage left it.

Days 46 to 90: run it on live work and measure. Put the tool in front of the people who do the work, inside their normal day, and compare the time it takes against the before number every two weeks. On day 90, the result is either a working system with a number attached, a clear reason to narrow further, or a clean stop. Any of those beats another quarter of drift.

The plan only works if the trigger points are written down on day 14 and nobody moves them later, including the owner who championed the project and the provider who would like another quarter to get it right. A target missed at day 45 is information. It isn't a reason to extend the deadline. For deciding which numbers to track along the way, see our guide to AI project success metrics.

A Maintenance-Request Assistant, Recovered

Picture a 60-person property management company running about 1,900 residential units (an illustrative composite). Its three maintenance coordinators spend most of their week turning tenant requests into work orders. Seven months ago the company hired an automation agency to build an AI assistant that reads incoming requests, sorts them by urgency, and drafts work orders. The project has cost more than planned, and the agency is now proposing to add lease-renewal reminders and monthly owner reports.

The warning signs are all there. Two of the three coordinators have gone back to logging requests by hand, because the assistant sends its drafts to a shared inbox the agency set up, and someone still has to open the property management software and create each work order from scratch. Status reports describe "requests processed," not hours saved. The go-live date has moved three times, and nobody inside the company owns the project beyond the operations director who signed the contract.

The two-week triage gives the director something firmer than frustration. Timing the work shows the coordinators spend about 32 hours a week on request intake. Running the assistant on the last two weeks of real requests shows it handles requests from the tenant portal well, since those arrive in a consistent format, but struggles with emailed requests and voicemail transcripts. Portal requests turn out to be about two-thirds of the volume. The first broken link is workflow fit: the output never reaches the system the coordinators actually work in.

The call is to narrow, and the hardest part is saying no to the agency's expansion plan. The lease-renewal reminders and owner reports come off the table, and so do emailed and voicemail requests for now. The director renegotiates rather than replaces, because the triage shows the agency's assistant handles portal requests well and the real gap, a connection to the property management software, was never in the original contract. The new terms are a fixed fee for writing drafts straight into that software as work orders, a go-live test the agency signs (half the portal intake time, measured against the 32-hour baseline), and a monthly cost ceiling. One coordinator takes ownership of the review queue for uncertain requests, and the director writes a day-60 checkpoint into the contract so the stop date can't drift the way the go-live date did.

How to Tell the Recovery Is Working

A recovery is working when the number you wrote down in the triage moves, and when people use the tool without being asked to. Usage by the people who do the work, time against the before number, and the share of outputs that need no correction are the three signals to watch, roughly in that order of importance.

Watch for the old signs coming back, too. If the feature list starts growing again before the narrowed scope is finished, or status reports drift back to activity counts, the project is sliding toward the same place it was. And don't read a quiet month as a good one. Gartner's Melanie Freeze told CIO that when "expectations are not realistically set and the results don't appear quickly, confidence drops and projects stall" (Paul Barker, "AI often doesn't deliver ROI for IT departments either," CIO, April 2026). A recovery plan with a modest target and a real date gives confidence something to rest on.

Recovered projects also tend to carry a lesson worth keeping for the next one. Nearly every rescue comes back to something that should have been settled before the build started: a measured baseline, a defined place in the workflow, and a named owner. Our page on why AI projects are failing looks at why so many projects launch without them, and AI pilot purgatory covers the related case of a pilot that never ends.

Where Avolis Fits

Every engagement we run starts with the diagnostic, and for a project already in trouble it works as the triage. We work through the affected workflow with the people who run it, measure volumes, time per task, and handoffs, test what's been built against real records, and rank what's worth keeping. The result is a clear recover, narrow, restart, or stop call on the project, plus a ranked map of where AI pays off elsewhere in the operation, and you keep both whatever you decide next.

If you bring us in for the fix, we build it inside the systems your team already uses and stay embedded while it settles in, so the trigger points and the owner don't disappear after launch. For what a good assessment should cover, start with our guide to AI readiness assessment services.

Frequently Asked Questions

How do you recover a failing AI project?

Freeze the scope, then spend two weeks measuring how the tool performs on real, unedited work against a baseline of how the workflow runs without it. Find the first broken link (problem, workflow fit, data, cost and value, or owner), decide whether to recover, narrow, restart, or stop, and give any recovery a 90-day stop date.

When should you stop an AI project?

Stop an AI project when the work it targets is too small to justify the running cost, when the information the task depends on was never recorded, or when it has missed a written trigger point without a fixable cause. Research by Keil and colleagues recommends setting those de-escalation trigger points at the start, before commitment builds.

Should I replace my AI vendor or consultant?

Replace them if the tool fails on your live records for reasons they can't explain, or if they keep pushing for more scope before the original works. Renegotiate if the gap came from an unclear scope on both sides. Either way, secure admin access, your data, and the configuration before you give notice.

How long does it take to recover a failing AI project?

Plan on about 90 days: two weeks of triage, a month fixing the first broken link, and six weeks running the tool on live work against the baseline. Time-boxing matters, since an open-ended rescue tends to become another round of the same escalation that put the project in trouble.

Why is it so hard to cancel a failing AI project?

People who championed a project tend to read bad news as a temporary setback. Keil, Mann and Rai found 30% to 40% of information systems projects show some escalation, and Royer traced it to a collective belief in eventual success. An exit champion with evidence, and trigger points agreed in advance, both help.

Continue Learning

A failing AI project is usually a scoping problem that grew while everyone waited for it to improve. Measure the work, find the first broken link, and make one clear call with a date attached, and most projects end up either working or cleanly stopped within a quarter.

Why projects fail, in detail:

• Why do AI projects fail? Common reasons and what the statistics count
• Why are AI projects failing?
• Why AI projects fail due to data quality

When a project is already stuck:

• Why is my AI consulting project failing to reach production?
• AI pilot purgatory
• How to measure AI ROI
• AI project success metrics

Starting the next one right:

• AI readiness assessment services
• Which AI consulting company should I choose?

---

Sources

All sources retrieved 2026-10-08.

• Gartner, "Gartner Says AI Projects in I&O Stall Ahead of Meaningful ROI Returns," press release, 7 April 2026 (survey of 782 infrastructure and operations leaders, November to December 2025), retrieved 2026-10-08: https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns
• Paul Barker, "AI often doesn't deliver ROI for IT departments either," CIO, 7 April 2026 (interview with Gartner's Melanie Freeze), retrieved 2026-10-08: https://www.cio.com/article/4155396/ai-often-doesnt-deliver-roi-for-it-departments-either.html
• Mark Keil, Joan Mann, and Arun Rai, "Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models," MIS Quarterly 24(4), December 2000, pp. 631 to 664 (mail survey of ISACA members; 579 surveys returned; pages 631 and 656 cited), retrieved 2026-10-08: https://scholarworks.gsu.edu/cis_facpub/43
• Mark Keil and Daniel Robey, "Turning Around Troubled Software Projects: An Exploratory Study of the Deescalation of Commitment to Failing Courses of Action," Journal of Management Information Systems 15(4), 1999, pp. 63 to 87 (interviews with 42 IS auditors), retrieved 2026-10-08: https://jmis-web.org/articles/531
• Isabelle Royer, "Why Bad Projects Are So Hard to Kill," Harvard Business Review, February 2003 (product summary), retrieved 2026-10-08: https://store.hbr.org/product/why-bad-projects-are-so-hard-to-kill/R0302C
• Kathleen Melymuka, "Blind Faith," Computerworld, 10 February 2003 (interview with Isabelle Royer), retrieved 2026-10-08: https://www.computerworld.com/article/1345763/blind-faith.html
• Zapier, "Nearly 3 in 4 enterprises say losing AI vendors would disrupt core business operations," 1 April 2026 (survey conducted via Centiment, 30 January to 6 February 2026, of 542 U.S. C-level executives and decision-makers at organizations paying for AI vendors), retrieved 2026-10-08: https://zapier.com/blog/ai-vendor-lock-in-survey/

On the escalation figure. Keil, Mann and Rai's 30% to 40% is based on IS audit and control professionals reporting on projects they knew, not on an audit of projects themselves, and it predates generative AI. It describes how common escalation is in information systems projects generally.

On the Zapier survey. Zapier sells workflow automation software and commissioned the survey. Its introduction refers to 500 executives; the methodology note gives 542 respondents, which is the figure used here.

On the property management company. It's an illustrative composite, not a client. Its figures (60 people, 1,900 units, 32 hours a week, two-thirds of volume) 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