Why AI Programmes Fail, and What the Survivors Do Differently

of AI projects fail, per RAND's 2024 review, twice the rate of other IT projects

80%+

of companies in BCG's 2025 study achieve AI value at scale

5%

of McKinsey's 2025 respondents qualify as high performers on profit impact

6%

Failure in AI is so common that it has become a statistic people repeat without alarm. RAND put the failure rate of AI projects above 80 per cent, about twice that of information technology projects generally. BCG found 60 per cent of companies getting no material value and only 5 per cent creating value at scale. McKinsey's 2025 survey classed about 6 per cent of respondents as high performers, meaning that more than 5 per cent of operating profit was attributable to AI. A study from MIT's NANDA initiative, smaller and self-reported, put the share of organisations with nothing measurable to show for their generative AI spending at 95 per cent.

The studies use different definitions and should not be added together. But they agree on the reason, and that is the useful part. The causes of failure are almost entirely managerial. This is encouraging for a company in Nepal, which cannot outspend anyone on technology but can certainly manage a small number of projects well.

This article describes ten ways AI programmes fail, how each appears in a Nepali setting, and what the successful minority does. It is the fifth piece in our series on artificial intelligence for business in Nepal.

What the research says about causes

RAND interviewed 65 experienced data scientists and engineers and found five root causes, in rough order: stakeholders misunderstand or miscommunicate the problem that needs solving; the organisation lacks the data to train an effective model; the organisation focuses on using the latest technology instead of solving a real problem; it lacks the infrastructure to manage data and deploy models; and the technology is applied to problems too difficult for it.

McKinsey asked what high performers do that others do not. The clearest differences were that they redesign workflows around AI instead of adding it to existing ones, their senior leaders visibly own the effort, they aim at growth and innovation as well as cost, and they have defined when and how a human validates what the model produces.

BCG summarised its findings in a ratio: 10 per cent of the effort on algorithms, 20 per cent on technology and data, 70 per cent on people and processes. Companies that fail tend to invert it.

The MIT study added an observation about a learning gap: generic tools succeed with individuals because they are flexible, and fail in enterprise workflows because they do not retain context, adapt or fit the process. It also found budgets skewed toward sales and marketing while the clearer returns were in back-office operations.

Four independent sources, one message. The rest of this article turns it into something a management team can act on.

Ten ways to fail

1. Starting with the tool

The programme begins with a demonstration, a licence or a directive: "we need to be using AI." A team is then asked to find uses. They find the ones that are easy to show, not the ones that matter.

*In Nepal:* this is the commonest pattern, and it often begins with a promoter returning from a conference or a vendor visit. The test is simple. Ask the sponsor to state, in one sentence, the business problem and its annual rupee cost. If the sentence names a technology, the programme has started in the wrong place (where the value is).

2. A vague problem

"Improve customer service." "Use data better." "Automate finance." These cannot be measured, so they cannot succeed. RAND's first root cause is this one: the people who understand the business and the people building the solution never agree precisely what is to be solved.

A workable problem statement has a measure, a baseline, a target and a date: "Reduce receivable days from 62 to 55 by the end of Chaitra by calling customers in order of predicted delay."

3. Data that is not ready

The project is approved on the assumption that the data exists. Three months in, the team discovers duplicated items, missing dates and two systems that do not agree. The budget is spent cleaning, the sponsor loses patience, and the project is quietly reduced to a dashboard.

*In Nepal:* expect this unless the readiness test has been done first (data before algorithms). The remedy is to do the data work as its own project, with its own justification, before the AI project begins.

4. Automating the existing process

A tool is added to a process without changing the process. Invoices are still approved by four people, but now a machine reads them first. The time saved at step one is lost in the queue at step two.

The gain from AI comes from removing steps: exceptions handled by people, everything else flowing through. That requires changing approval limits, responsibilities and sometimes job descriptions. It is a management decision that no software makes for you. This is McKinsey's principal finding about high performers, and the one most often skipped.

5. Nobody owns the outcome

The technology team owns the tool. The vendor owns the model. The department owns the process. The result belongs to no one. When the pilot ends, each party reports success on its own terms.

*In Nepal:* this is aggravated where AI is handed to the IT manager, who typically has little authority over sales, stores or finance. The owner of a collections use case must be the person accountable for receivables.

6. No baseline, no measure

The pilot "went well". Staff liked it. Nobody recorded how long the task took before, or what the error rate was, so nobody can say what changed. At budget time the project has enthusiasm and no evidence, and it is cut, or worse, extended on faith.

7. Pilot purgatory

The company runs many pilots and scales none. Each is small enough to avoid hard decisions about process, people and money. MIT's figures, with around 5 per cent of custom tools reaching production, describe this state. Pilots are comfortable. Scaling means changing how a department works, and that needs authority.

A pilot should be designed from the first day as the first stage of a rollout, with the criteria for extending it and the criteria for stopping it written down.

8. People left out

Staff are told a tool is coming. They are not told why, what happens to their roles, or how to use it well. Some resist quietly: the tool is "tried" and found wanting. Others use it uncritically. The KPMG and University of Melbourne study found that two thirds of employees who use AI rely on its output without checking accuracy, and more than half conceal their use.

*In Nepal:* two cultural features sharpen this. Hierarchy makes it hard for a junior to tell a senior that the new system the senior championed is producing errors. And long-serving supervisors, whose authority rests on knowing how things are done, may see a tool that encodes that knowledge as a direct threat. Both are manageable if they are acknowledged. Involve the supervisors in designing the new process. Make reporting an error a sign of diligence, publicly.

9. No plan for the first error

Every AI system will produce an error. The question is who sees it first. If a customer, a bank or a tax officer sees it first, trust in the whole programme collapses, internally as well as outside. There are well-known public examples: an airline held liable by a Canadian tribunal in 2024 for a refund policy its chatbot invented, lawyers in New York sanctioned in 2023 for filing cases a chatbot had made up, and a Big Four firm refunding part of its fee in 2025 after apparent AI-generated errors in a report for the Australian government.

The survivors design the human check before launch: which outputs are reviewed, by whom, against what, and what happens when an error is found (who reviews the machine).

10. Too much, too thin

Fifteen initiatives, each with a part-time owner. Management attention, which is the scarce resource, is divided until none gets enough. BCG's leaders concentrate on a few high-value workflows and fund them properly.

For a mid-sized company the right number of serious AI initiatives at one time is two or three.

Four patterns particular to Nepal

Beyond the general ten, some failure patterns are distinctively local.

The inauguration. A system is launched with ceremony, a press note and a photograph. The launch is treated as the achievement. Six months later usage has faded and nobody is asked why. The discipline that prevents this is a scheduled review at three, six and twelve months, with numbers.

The departure. The programme depends on one capable young person who understands both the business and the tools. That person leaves for Australia, Canada or a job paying in dollars. With them goes the configuration, the prompts, the knowledge of where the data comes from. Nepal's outward migration of skilled people makes this a structural risk, not bad luck. Everything must be documented, and at least two people must understand each system.

The funded pilot. A project is paid for by a grant, a vendor's promotional offer or a development programme. It runs while the money lasts. No one made the internal business case, so no one funds the continuation. A pilot the company would not pay for itself is not a pilot. It is a demonstration.

The imported template. A system designed for another market is installed without adaptation: it expects Gregorian dates, another country's tax structure, clean address data, card payments. Staff build spreadsheets around it. The official system and the real system diverge.

What the survivors do

Seven habits recur among companies that get results. None requires scale.

1. They choose few problems, each tied to money. Two or three use cases, selected by rupee value and feasibility, each stated as a measurable problem.

2. They fix the foundations first, or alongside. Data and process work is funded as part of the programme, not treated as someone else's job.

3. They redesign the work. They ask what the process would look like if it were designed today with these tools, and they change roles and approval rules accordingly.

4. They put a business leader in charge. The owner has authority over the process and is measured on the result. Technology supports.

5. They measure against a baseline and report in cash. The finance function validates the gain.

6. They build the human check in. Review points are defined by risk: light where errors are cheap, firm where they are not.

7. They decide. Each stage ends with a decision to scale, change or stop. Stopping is treated as a result, not a failure.

An eighth could be added: they invest in their people's ability to use and question the tools. BCG and McKinsey both find that leaders train far more of their workforce, and train managers first.

The pre-mortem: a one-hour tool

Before approving an AI initiative, gather the sponsor, the owner, the finance head and two people who will use the tool. Ask one question: "It is one year from now and this project has failed. What happened?" Give everyone ten minutes to write, then read the answers aloud.

The answers will come from the list above. Someone will write that the data was worse than expected. Someone will write that the sales team never used it. Someone will write that the person who built it left. Each answer becomes a line in the plan: a data check before the start, a named sales sponsor, documentation and a second person trained.

The technique works because it gives people permission to voice doubts that hierarchy would otherwise suppress. In a Nepali meeting, where disagreeing with the chair is uncomfortable, that permission is worth a great deal.

Stage gates and stop rules

A simple structure prevents most of the ten failures.

Two details are worth stressing. The old process must be retired at stage 4. While it remains, people drift back. And the stop rules must be written at stage 0, when nobody is yet attached to the project. A stop rule invented after the money is spent is never applied.

Reading the warning signs

Signals that a programme is heading for failure, and the response.

A cautionary pattern from abroad

One widely reported case illustrates several failure modes in sequence. In 2024 a European payments company announced that its AI assistant was doing the work of several hundred customer service agents. The announcement was celebrated as proof of what was possible. By 2025 the company said publicly that it had gone too far, that quality had suffered, and that it was bringing human agents back for work where customers valued them.

The technology worked as designed. What was missing was a measure of quality alongside the measure of cost, and a view of which interactions customers wanted handled by a person. For a Nepali business, where the personal relationship is frequently the reason a customer stays, the lesson applies with more force. Automate the tasks customers do not value, and protect the ones they do.

From shop floor to policy

Failure has the same causes at every level, and it is instructive to see them repeated.

In a department, a tool fails because the supervisor was not consulted and the data entered by the team was never checked.

In a company, a programme fails because the board asked whether AI was being used and not what it had achieved.

In an industry, adoption fails where firms copy each other's showpieces. One bank launches a chatbot and five follow, while the harder and more valuable work on credit assessment and early warning proceeds slowly.

In government, digital systems have often failed in Nepal for familiar reasons: procurement focused on hardware, weak ownership after the launch, data not shared between agencies, and staff transferred before a system is embedded. The National AI Policy 2082 is ambitious about centres, councils and compute. Its success will depend on the unglamorous items, data standards, skills and continuity of ownership, exactly as a company's does. The Nepal Rastra Bank's AI Guidelines are notable for starting where the survivors start: with accountability, risk classification and human oversight, not with technology.

The role of consulting and advisory firms

It would be incomplete to discuss failure without discussing advisers, since they are present at many of them.

The research cited here comes largely from consulting firms, and it reflects well on them that they publish findings unflattering to a market they sell into. Their frameworks, the workflow redesign emphasis, the 10-20-70 ratio, the focus on a few high-value domains, are sound and free to use.

Advisers also contribute to failure in recognisable ways: strategies with no owner in the client, pilots sized to the consulting budget, technology recommendations shaped by alliances, and teams that leave before the process has changed. The MIT study's finding that external partnerships succeeded about twice as often as internal builds supports using outside help. It does not say all help is equal. And the firms themselves are not immune. The 2025 episode in which a report for a government client contained apparent AI-generated errors shows that review discipline slips under pressure everywhere.

How a mid-sized Nepali company should use an adviser on an AI programme:

And how it should not: as a substitute for an internal owner, or as a way to avoid a decision.

Our practice works on the finance and control side of these programmes: process automation in finance functions, reporting and analytics, internal audit of new processes and virtual CFO support to the person who owns the outcome. We are not a technology implementer, and for work that needs one we help the client choose and manage it.

The next 90 days

Days 1 to 30: audit what exists. List every AI initiative, pilot and subscription. For each, write the problem, the owner, the baseline and the result so far. Most companies find several with none of the four. Stop those, or restart them at stage 0.

Days 31 to 60: concentrate. Choose two or three initiatives to continue. Run a pre-mortem on each. Write stage gates and stop rules. Confirm the owner has the authority to change the process.

Days 61 to 90: run one pilot properly. Alongside the old process, in one unit, measured weekly, with an open error log. At the end, let finance confirm the result and let the board decide.

A company that does only this will have moved from the majority that experiments to the minority that learns. That is most of the distance.

Frequently asked questions

*This article is general guidance, not professional advice on any specific project. Research findings are quoted from the published sources listed. Company examples from abroad are summarised from press reports.*