If you've worked inside any company larger than 80 people, you know the pattern. A "Head of AI" gets hired. An external consultancy gets engaged. Three workstreams kick off. Six months later, the workstreams have produced 140 slides and zero shipped systems.
This isn't laziness. It's structure. The structure that companies have for shipping software — committees, RFCs, vendor reviews, procurement, security sign-off, change management — is the right structure for ERP migrations. It is the exact wrong structure for AI projects, because AI work is irreducibly experimental.
The five places AI projects die
1. The committee phase
The first 6–10 weeks are spent in meetings. Stakeholders. Workshops. Discovery. Workshops about workshops. By the time the first prompt gets written, the original sponsor has rotated to a new role and the political weather has changed.
Fix: compress the entire stakeholder phase into a single 4-hour session. Names on a brief. Decisions made in the room. Anyone who can't show up doesn't get a veto later.
2. The vendor selection grand prix
"We need to evaluate OpenAI vs Anthropic vs Google vs Cohere vs..." Three months later, three POCs are running, none have shipped, and the team has learned that all major LLMs are similarly competent for 80% of tasks.
Fix: pick one model on day one based on cost and team familiarity. Switch if and only if you have a concrete eval failure that proves you need to.
3. The "AI strategy" deck
A 60-page deck about how AI will transform the company. It looks impressive. It commits to nothing measurable. It gets presented to the board. The board nods. Nothing happens.
Fix: the only AI strategy that survives contact with reality is a list of three specific workflows you're going to automate this quarter, ranked by ROI, with a baseline and a target.
Strategy that doesn't end in someone owning a deliverable on a specific date isn't strategy. It's a wishlist.
4. The "we need a platform first" trap
Someone — usually a well-meaning architect — points out that all these AI projects need a shared "AI platform" before any of them can ship. The platform team gets formed. The platform takes 9 months. The original use case is now stale.
Fix: ship the first three use cases without a platform. They'll be slightly redundant. That redundancy will teach you what the platform should actually be — instead of guessing.
5. The handoff that never happens
The most common death: the project actually ships, sort of, but it's owned by an external team. Nobody internal knows how the prompts work. When the model changes, the system breaks. Within a year, the AI feature is quietly turned off because nobody can maintain it.
Fix: "shipped" means an internal person owns it. If you can't say which internal person owns it after launch, you haven't shipped.
What the studio model looks like
We borrow the pattern from architecture firms and design studios: a small, senior, multi-disciplinary team is fully accountable for a specific deliverable, in a fixed window, with a fixed price.
This works because:
- One throat to choke. No vendor finger-pointing.
- Senior-only. No "we'll staff this with juniors" — the people pitching are the people shipping.
- Fixed scope. Scope creep is the enemy of shipping. We say no to expansion mid-sprint and bank it for sprint two.
- Fixed timeline. 30 days. Not "30 days plus discovery". Not "30 days plus contracting". 30 days.
It's not the only model. But it's the only one we've seen work reliably across 40+ AI projects. The committee model has, in our admittedly biased experience, never produced a single shipped system on the timeline its authors promised.
If your AI initiative is stuck in PowerPoint and you want a sanity check, book a 30-minute audit. We'll tell you where it's stuck and what we'd do if it were ours.