Most AI Projects Should Never Start
The bravest AI decision a leader can make is to kill the project before the budget is spent. Most initiatives fail a basic test no one bothers to run.

We get hired to build AI systems, so this is against our own interest to say: most AI projects should never start. Not because AI doesn't work, but because most of the projects we're asked to scope are solving the wrong problem, for the wrong reason, with no way to tell if they succeeded.
The pressure to "do something with AI" has produced a wave of initiatives that exist to be seen doing AI, not to deliver an outcome. Those projects burn budget, exhaust teams, and quietly get shelved. The strongest thing a leader can do is refuse to start them.
Why the conventional wisdom is wrong
The conventional wisdom is that you must move fast on AI or get left behind, so any project is better than no project. That's backwards. A badly chosen AI project is worse than no project, because it consumes the time, credibility, and political capital you'll need for the right one later.
Many projects start because a competitor announced one, not because a real problem exists.
Most have no defined success metric, so they can never be declared a win or a loss.
A large share of corporate AI pilots never reach production, which the McKinsey research has documented repeatedly.
What is actually true
A project worth starting passes a simple test: there is a specific, painful, measurable problem; AI is genuinely the right tool for it; you have the data to support it; and you've defined what success looks like before you write a line of code. Most proposals fail at least one of those, usually the first and the last.
If you can't state the problem in one sentence and the metric in one number, you don't have a project. You have an aspiration with a budget attached. And aspirations with budgets attached are how organizations end up six months in, money spent, with a demo nobody uses and no honest way to say whether it worked.
There's also a quieter test that catches a lot of bad projects: would you fund this if you couldn't call it AI? If the only reason it exists is the label, it's a vanity project. The good projects are the ones you'd want solved even if the solution turned out to be a spreadsheet, and AI just happens to be the best tool for the job.
What we learned at TTGC
During our own AI transition, the most valuable meetings were the ones where we decided not to build something. We killed more internal AI ideas than we shipped, and the discipline of saying no is exactly why the ones we kept actually worked. When clients come to us now, our first job is often to talk them out of the project they walked in wanting, and into the one that will actually move their numbers. Saying no early has saved our clients more money than any system we've deployed.
What surprised us was how relieved leaders were to hear it. Most of them already suspected their pet AI project was thin; they just hadn't been given permission to say so, because the pressure to be seen doing AI was so loud. A clear no, backed by reasons, freed them to redirect that budget toward the one or two initiatives that genuinely deserved it.
The honest take
Before you greenlight an AI project, try to kill it. Stress-test the problem, demand a metric, and check whether AI is even the right answer. If it survives that scrutiny, build it with confidence. If it doesn't, you just saved a fortune. The goal was never to do AI. The goal was the outcome, and most projects can't prove they'll deliver one.
Sources
McKinsey & Company, The State of AI (2024) — on the gap between AI pilots and production value. mckinsey.com
TTGC — lessons from our own AI transition and client implementation work.


