Here is an uncomfortable truth about AI projects. The ones that fail rarely fail because the technology could not do the job. They fail because the wrong project got funded, for the wrong reasons, after a convincing demo and an optimistic business case. The build was fine. The decision to build was the mistake.
That is actually good news, because it means the cheapest place to prevent an expensive failure is the funding conversation itself. Before you commit the budget, you can ask a handful of blunt questions that a weak project cannot survive. None of them are technical. All of them are the kind of thing the person writing the cheque should be asking, and often is not.
Here are the eight we would want answered before putting money behind anything.
Short answer: To evaluate an AI project before you fund it, pressure-test it with eight questions that cut past the pitch: what actually breaks without it, who stops doing a task because of it, whether it survives the model having a bad day, who checks the output and whether they have time, what it really costs at full volume, who has used the tool on a real case, what the people doing the job today think, and what it unlocks next. A strong project answers most of these cleanly. A weak one falls apart on the second or third.
1. What breaks today if this project never happens?
This looks like a question about the problem. It is really a question about ownership. If the honest answer is “nothing breaks, but we would fall behind,” then you are about to fund something nobody is actually in pain over, and pain is what gives a project an owner who fights for it when things get hard. The AI projects that succeed solve a problem someone feels every week: the complaints that keep coming, the task that eats every Friday afternoon, the delay that customers notice. If you cannot point to the specific thing that gets worse by not doing this, you are buying a trend, not solving a problem.
If nothing breaks without it, no one will fight for it when it gets hard.
2. Who stops doing something because of this?
Almost every AI project is sold on time saved. Far fewer are honest about where that time actually goes. “Saves the team ten hours a week” sounds great and means nothing until you can name the person and the exact task those hours come from.
If no one actually drops a specific activity, the saving stays on the slide and never reaches the business. Real savings are concrete: this person stops doing this task, and here is what they do instead. Vague savings are a sign the project was costed by someone who has never done the work.
Time saved that no one can point to is time that was never saved.
3. Would this still work if the model got worse?
Call this the fragility test, and it is the one most people skip. Models change. They behave differently on a bad day than they did in the demo, and they stumble on the odd cases your real work is full of. If your process only works when the model performs perfectly, you have not designed a process. You have staged a demonstration.
Robust projects assume imperfection and plan for it: a human check at the right moment, a confidence threshold, a safe default when the system is unsure. The question is not whether the model is good. It is whether your project still stands up when the model is merely okay.
If it only works when the model is perfect, it does not work.
4. Who checks the output, and do they have time?
This is the most ignored line in almost every AI business case. A lot of deployments do not remove work. They move it, because every result the system produces now needs a person to verify it before it can be trusted. If checking the output takes nearly as long as doing the task used to, you have bought a more expensive version of the same job. Decide this upfront: who checks, how much they can realistically review in the time they have, and what happens to everything they cannot get to. The answer often reshapes the whole project, which is exactly why it is worth asking early.
If verifying the output costs as much as the work it replaced, you have moved the work, not removed it.
5. What does this cost to run a thousand times?
Pilots are nearly free, which is precisely why they mislead. The real question is what the thing costs at the volume you would actually use it: every day, across the whole team, for a year. There is a twist in 2026. The cost of running these models has been moving quickly, so an answer that was true a month ago may be wrong today, in either direction. That makes it more important, not less, to get a current number at real volume before you commit, rather than reasoning from a pilot-sized guess. Ask for the cost at the scale you will actually run it, dated to this week.
The pilot tells you whether it works. Only the running cost tells you whether it is worth it.
6. Who in the company has actually used the thing you're buying?
A surprising number of AI decisions rest entirely on a polished sales demo. The trouble is that demos are built to work. They use clean inputs, familiar cases, and a path the vendor has walked a hundred times. Your real world is messier than that on its calmest day.
If no one on your team has spent a week using the actual tool on one of your actual cases, you are not buying a capability. You are buying a promise, and hoping it survives contact with your data and your exceptions. A week of real use tells you more than any number of demos.
A demo proves it can work once. A week of real use proves it works for you.
7. What does the person doing this job today think about it?
This is the question almost nobody asks, and often the most valuable one on the list. The people who do the work every day know exactly where the exceptions live, and exceptions are where AI implementations quietly come apart. They know the edge cases, the unwritten rules, the “except on Tuesdays” that no specification ever captures. They also decide, in practice, whether the thing gets used or quietly worked around. If they first hear about the project after it has been approved, you have probably already lost both their knowledge and their goodwill. Bringing them in early is not a courtesy. It is how you find the problems while they are still cheap to fix.
The people doing the job know where it breaks. Ask them before you fund it, not after.
8. If this works, what's the next thing you'd build on top of it?
This is the test for whether you have a project or a purchase. A good project tends to open the door to the next one: it leaves you with cleaner data, a capability you can reuse, or a team that now knows how to do this kind of work. An isolated one solves a single problem and stops there.
Neither is wrong. Sometimes you just want the one problem solved. But the two are worth very different amounts, and knowing which you have changes how much you should sensibly spend. A project that unlocks the next three is worth investing in properly. A dead end is worth exactly what it saves, and no more.
A good project makes the next one easier. A dead end just solves one thing and stops.
Reading the answers together
You do not need a perfect score. Few worthwhile projects answer all eight cleanly on the first pass. The point is not to find reasons to say no. It is to see clearly what you are funding before the money is gone. If a project answers most of these well, fund it with confidence.
If it stumbles on two or three, you have not found a reason to kill it. You have found your to-do list: the gaps to close before the budget goes out the door. Either way, you will have replaced a hopeful decision with an informed one, which over time is the single biggest difference between the companies that get value from AI and the ones that keep paying for lessons.
- Key takeaways
AI projects usually fail at the funding decision, not in the build. The cheapest place to prevent an expensive failure is before you commit the money. - The strongest filter is a set of blunt, non-technical questions about the problem, the people, the hidden checking work, the real running cost, and what it unlocks next.
- Watch especially for savings nobody can point to, processes that only work when the model is perfect, and output that quietly creates a new checking job.
- Talk to the people who do the work today. They know where it breaks, and they decide whether it gets used.
- A weak set of answers is not a reason to stop. It is a list of what to fix before you fund.
Frequently asked questions
How do you evaluate an AI project before funding it?
Pressure-test it with questions that cut past the pitch: what breaks if it never happens, who stops doing a specific task because of it, whether it survives the model performing imperfectly, who checks the output and whether they have time, what it costs at full volume, who has actually used the tool on a real case, what the people doing the job think, and what it unlocks next. A strong project answers most of these cleanly.
Why do AI projects fail?
Most fail at the decision to build, not the build itself. They are funded on a convincing demo and an optimistic business case, without a clearly owned problem, a plan for who checks the output, a realistic running cost, or input from the people who do the work and know where the exceptions are.
What is the biggest hidden cost of an AI project?
Verification. Many deployments do not remove work, they move it, because every result now needs a person to check it. If checking takes nearly as long as the original task, the project has relocated the cost rather than removing it. The second hidden cost is running at real volume, which is far higher than a nearly free pilot suggests.
Should I trust an AI vendor demo?
Treat a demo as proof the tool can work once, under ideal conditions, not proof it will work for you. Demos use clean inputs and rehearsed cases. Before committing, have someone on your team use the actual tool for a week on one of your real cases, with your real data and exceptions.
How do I know if an AI project is worth the investment?
Separate whether it works from whether it is worth it. A pilot shows the first. Only the cost to run it at full volume, for a year, across everyone who would use it, shows the second. Because model running costs have been changing quickly, get a current number at real volume before deciding.
What is the difference between an AI project and an AI purchase?
A project opens the door to the next one, leaving you with reusable data, capability, or know-how. A purchase solves a single problem and stops there. Both can be valid, but they are worth very different amounts, and knowing which you have should change how much you invest.
Working through these questions on a project of your own and want a second pair of eyes? That is one of the more useful conversations we have with companies, and it tends to save a lot more than it costs. We are happy to talk it through and give you a straight read, whether or not we turn out to be the right fit.
