In 2013 everyone asked who would build the WordPress site. In 2016 who would implement CRM. In 2018 who would ship OCR and CV scoring. In 2019 who would build the cash-flow forecast model.
Each time the pattern was simple: pain, tool, vendor. Missing customer insight? CRM. Missing warehouse visibility? WMS. Missing cash forecasts? A model. Someone felt the pinch, picked a tool, someone shipped it.
Today one question dominates: who will deploy AI for us?
Not: what it should do. Not: whether it pays for itself. Not: where in the work it will change anything. Just: who ships it.
That is exactly where the missing 70% begins.
Where the project lands
Some firms answer instantly: IT, because they deploy. Others say R&D, because “innovation”. Or the COO, because the scope fits the title. In every case the decision lands before anyone has defined what should exist on the other side.
That is rarely a people problem. It is a sequence problem.
What “deploy” even means
Is buying licences deployment? Is standing up a GPT assistant with no ERP or CRM access deployment? Are employees who log in once a week “adoption”?
Tick what you have. You will see where you really stand.
What a deployment actually includes
In that journey, coding work is often 30–40% of the clock. The rest is picking technology, shaping solution architecture, understanding the business questions the model must answer, making sure it actually can, and hunting the edge cases nobody remembered to mention.
The cost line that never appears in the proposal
Leaders: the question is not where to deploy AI. It is what it should do and whether that is worth the ticket price.
Token spend
Model choice and volume matter. At the same query volume, list prices can differ by an **order of magnitude**.
Prompt upkeep
A refreshed model reacts differently to the same instructions. Someone has to babysit that. **Continuously.**
Systems integration
A model without data access is an assistant without a case file. Integration is a **programme**, not a checkbox in settings.
Operating model change
If the tool does not sit in the rhythm of work, it will not get used. That is not a UX nitpick — it is **change management**.
A workshop is no substitute for showing up
We hear it everywhere: map the process. Event storming, DDD, BPMN. All roads lead to a diagram — and diagrams are useful. They tell you whether a process is even worth an AI bet and what would shift operationally, not on a slide.
A workshop captures the story the organisation tells about itself. Gemba adds the layer underneath: what actually moves between teams, who really makes the call, and what a given tool does in a normal week.
The COO convenes a room. Sticky notes, whiteboard, the right people. A few hours later you have a diagram and alignment around the table. Weeks later the diagram lives in Confluence while execution still runs on the old rails. You did not remove the chaos — you documented it.
To see where the problem really lives, you have to go where the work is: interviews, observation, the moments when the system says “no” at the worst possible time.
A tool on a separate domain with another password is not a convenience. It is one more thing to remember. Habits are stubborn.
There are also problems the company does not know are solvable — vision on the line, defect detection against a golden sample, drafting a new machine controller. You will not spot those by mapping alone.
The board approves the budget. Excel stays.
The roadmap appears. IT delivers the system. Months later the report shows weak adoption, budget overruns, and the spreadsheet that was supposed to die.
The numbers have rhymed for years. Only a minority of large technology programmes land on time, on budget, and in scope. That is not an argument against tech. It is an argument for getting the order of operations right.
Three questions before anyone opens a pricing sheet. Where are we bleeding time and money, specifically? Is another module purchase the shortest path to moving a metric, or would a simpler organisational move do? How will you measure impact before you sign?
Sometimes plain old code still wins
Sometimes the problem is not a GenAI fit. Good.
Sometimes classic software and a tight algorithm — a few lines of code, a handful of integrations, no perpetual token bill — is the grown-up answer. Sometimes the change has to be slow and structural, and no language model will shortcut that.
People who understand that match the tool to the problem. People who do not buy licences and wait for magic.
Culture and people — not the shiny object
BCG surveyed more than 850 companies. Only about **30%** of large technology programmes hit time, budget, and scope together. The rest do not fail because “the tech did not work”. They fail because the organisation was not ready to absorb what it bought.
People crawl back to Excel not because they are change-averse. They crawl back because the new tool does not sit where their work lives. Because nobody looked for the real friction. Because the workshop diagram lives in Confluence while the chaos still lives at the desk.
That pattern has repeated for decades; AI only **turns up the tempo**. We hunt for excuses in trends, waves, hype cycles instead of hunting for **real value**.
Almost everyone feels it — innovators who ship first because they can, early adopters who see an opening, the early majority who move because competitors already did. They all ask the same question: who will deploy.
Only the stragglers ask a different one: **what is this actually for?**
Paradoxically, today that may be the best question on the table.
Part one of a thread — why ~70% of transformation efforts miss the mark and why workshops without gemba leave chaos described, not removed.
Consultation
Book a consultation
Send a short note on context — we will reply with a time slot and a suggested next step. You can also write to connect@atypical.pl.