Nearly everything written about failed technology projects is written by technology people. I spent my career on the other side of the table, the side that approves the money. I spent 14 years in the CEO's chair, most of them running a medical-services company with more than 100 employees. Before that I sat on the executive board of a national medical-services company, and later I ran a surgical medical center. I approved the budgets, sat through the implementations, and quietly buried a few projects that were supposed to "change the organization".
The numbers say I had plenty of company. The 2025 MIT NANDA study found that 95% of enterprise GenAI pilots produced no impact on the bottom line. The State Comptroller's June 2026 report found that only 32% of AI projects in Israeli organizations ever reached production; the other 68% are still parked in pilot. In my own experience, almost none of those failures were caused by technology that didn't work.
The money runs out exactly when the real work begins
Budgets get approved on the price of the pilot. But the working rule of thumb in the global market is that going from pilot to production costs 2.5 to 4 times what the pilot cost. So you sign off on a NIS 300,000 pilot convinced you have approved most of the project. What you have approved is the deposit.
Then comes the dangerous moment. The pilot works, and turning it into a system now costs three times as much. That request goes back to the budget committee, competes from scratch against every other need in the organization, and dies there. Not because it is a bad project. Because nobody told the executive team at the start what the finished thing would cost.
What I learned: don't approve a pilot. Approve the whole route, with defined exit points along the way, or don't start.
The demo always works. The system is another matter
In all my years as a buyer I never once saw a demo fail. Demos run on clean data, with no permissions model, no legacy systems and none of the edge cases that make up an ordinary Tuesday in a real organization. International surveys of technology buyers found that 78% struggle to verify the claims AI vendors make, and 69% say every vendor sounds the same.
The questions worth money are not "what can the system do". They are: what happens with our real, dirty data? Who fixes it when it gets something wrong, and how fast? What happens in month three, when the excitement is gone and the system has to stand on its own? A vendor who can't answer those three in the first meeting is selling a demo, not a system.
Now that I sit on the side that builds systems rather than only approving them, I see the gap even more clearly. The demo is 20% of the work. The other 80% is the edge cases, the permissions, the backups, and what happens when something breaks at two in the morning. A serious vendor talks to you about the 80% from the first meeting. A demo vendor talks only about the 20%.
Organizational politics kills more projects than bugs do
This is the part technology people never see and every CEO knows by heart. Every new system moves power around. The manager whose weekly report becomes automatic loses a standing slot in the management meeting. The team lead whose knowledge now lives inside the system stops being indispensable. Neither of them will ever say that out loud. What you hear instead is "the system isn't accurate", "the data isn't being entered properly", "our situation is different".
As a CEO I learned to run one exercise before every project: write down on a single page who gains and who loses from the new system - in power, in visibility, in convenience. Then deal with the losers before the project starts, not after it stalls. A new role, a new responsibility, public credit for the rollout. A project that skips that step dies quietly, and nobody ever works out why.
One warning sign is worth memorizing. When everyone in the management meeting supports the project and nobody asks a hard question, that isn't consensus. It's indifference. The projects that succeeded for me were the ones somebody fought for while somebody else argued back, out loud.
The decision that actually matters: one metric, signed up front
Before the first shekel, I want a written answer to four questions. Which line in the P&L does this system move? By how much? By when? And who is the one person accountable for making it happen? Not "efficiency", not "employee experience". A line, a number, a date, a name.
If there is no answer, the project isn't ready, and that's fine. Far better to find out before the money goes out. If there is an answer, it becomes the project's internal contract: every later discussion comes back to it, and every proposed expansion gets measured against it. That is the difference between the 68% stuck in pilot and the minority that reach a working system.
One more rule I learned the expensive way: start narrow. Not "roll out AI across the organization" but fix one painful process, end to end, until it runs by itself and somebody can point to the saving. A narrow, measurable win buys you the organizational trust you will need for the next project. A broad announcement buys you a steering committee and a third round of slide decks.
The technology has never been better than it is now. The organization that has to absorb it hasn't changed at all. Whoever manages that gap wins.
Do you have a project stuck between pilot and system? Tell me which metric you signed up front. And if there never was one, let's define one together, and I'll show you a demo of what it looks like when it actually works.
