Most GenAI pilots do not fail because of the technology. They fail because they were built to prove that a tool works, not to change a specific person's work. A pilot that lasts tests one defined question, on work that happens every week, with an owner, a before-and-after measure, and a date when someone decides.
You know the script. Pick a team, pick a tool, run a POC, and present results that look great. The pilot worked.
Three months later nobody works that way. The team is back on its old processes, the licences are still being paid, and at the next leadership meeting someone asks why the investment did not move anything.
Why doesn't a successful pilot become a way of working?
Because it tests a different question. A typical pilot asks "can the tool do the job?", and the answer is almost always yes. Whether anything stays depends on something else: whether the organization can adopt a new way of working, and who is responsible for making that happen.
Four patterns keep coming back in the teams I meet:
- The pilot that did not know what it was testing. Without one sentence the pilot is meant to confirm or disprove, it ends with "there's something here, we should look deeper". That is a polite postponement, not a conclusion.
- The tool bought before the work was defined. Licences for the whole organization are a procurement move. Three months later usage is low and the conclusion is that the team resists, when in fact nobody told them which piece of work was supposed to look different.
- The training that created excitement, not a habit. Two weeks after a good session, the only people still using it are the two or three who would have used it anyway, because no existing workflow changed.
- The lone champion. Whoever picks it up fast becomes the go-to person, then the bottleneck. What they know sits in their chat history, and nobody else can use it.
In all four, the investment went into a tool or an event rather than a process. I break each one down, with what to do instead, in the guide From Idea to Implementation (in Hebrew).
What should a pilot test besides "does the tool work"?
Four questions, before you start: who owns the process, how much time and how many rounds of revisions the work takes today, who checks the output and against what, and who maintains it two months from now. If one of them has no clear answer, the pilot is not ready to start.
The process owner is not the VP who sponsors it or the person who had the idea. It is the person who has this work on their desk every week. Measuring the starting point is the step people skip most easily. Without one number from today, there is no way to know at the end whether anything changed.
Here are the two kinds of pilot side by side:
| A pilot that proves a tool | A pilot that builds a way of working | |
|---|---|---|
| The question | Can the tool do the job? | Will the team still work this way in a month? |
| Starting point | The tool | One piece of work that happens every week |
| Who takes part | Whoever volunteered | Three people who actually do the work |
| What gets measured | Output quality in a demo | Time, revision rounds, and who still works this way after 30 days |
| How it ends | A slide deck with results | A decision: expand, fix or stop |
| What is left afterwards | Licences | A written process others can open and continue |
How do you turn GenAI from an experiment into a routine work tool?
Start small and expand on what worked: one piece of work, three people, four weeks, then a decision. In the organizations I work with, expansion usually comes from one team that starts working differently, and from the teams that see it and come to ask how.
I watched this happen at a global cybersecurity company. It started with one workshop for the marketing department, on Gemini, because the company runs on Google. After the workshop, marketing invited me to accompany their offsite, then asked for a workshop for new employees. HR heard about it and booked their own, and after them sales and legal together. Nobody mandated it from the top. The full story.
It works with a sceptical team too. In a global sales team at a tech company, some people had never touched AI. We ran two workshops on their real material and built a complete sales process together: account research, meeting prep, follow-up. Today there is no step in their workflow that happens without AI, and the sceptics from the first workshop are the ones sending me new releases. The full story.
What happens the day after a successful pilot?
If nobody owns it and nobody measures it, the window closes within weeks. So a pilot ends with one of three decisions: expand, fix or stop. If you expand, there is a named owner and one measure you check. Real change is checked after 4 to 6 weeks, with one question: is the team still working this way, without anyone asking them to?
"Let's keep testing a bit longer" is not one of the options. That is how pilots die quietly.
And the day after never quite ends, because the tools keep moving. In a global marketing department I work with, it started with one manager who took my course twice, and grew into support for the whole department: a shared workshop, then one-on-one sessions where each person built her own processes. When Claude arrived we ran a workshop for the whole department, and each of them built her own skills. The work continues because the tools keep changing, and the point is that the gap does not open again. The full story.
When is it worth bringing in outside help?
When the question is no longer "does it work" but "how does it reach the rest of the organization and stay there". One team can run a good pilot on its own. An organizational program deals with what comes after: which processes to expand, who owns them in each team, how to measure, and what to do when the tools change.
That is how my organizational programs are built: strategy, operating model, team enablement and governance, usually over 8 to 16 weeks. And if you are still at the stage of one team and one process, a team workshop is a good place to start.
The goal is not to start with AI. The goal is to make it stay.