The Sprint Zero diagnostic

Why most AI pilots never make it to production.

In our experience the reasons rarely have much to do with the model. These are the four things we look for in Sprint Zero.

80%+of AI projects fail

Industry estimates cited by RAND, 2024

2×the failure rate of non-AI IT projects

RAND, 2024

For every 100 AI projects

Stalled Fewer than 20 succeed

The four traps

None of them start with the model.

Each one looks different from the inside. Here's what to watch for, and how we fix it.

01

The use-case trap

What it looks like

Endless use-case discussions with no convergence. AI treated as a solution looking for a problem, producing a fragmented list of pilots that never scale.

The fix

The AI Necessity Gate. We test every candidate for three things: whether it needs a model at all, whether its value can be measured, and whether the data is governed well enough to trust the output. Most lists shrink by about half, which is what you want.

02

The ROI fallacy

What it looks like

Pilots get justified on "hours saved per employee." But unless those hours go into work that earns money, saving time doesn't show up on the P&L. It just becomes spare capacity.

The fix

Measure ROI in value created, such as revenue from data products, operations that hold up better, or lower cost per unit of output. Then drop the use cases that only look productive.

03

The data trap

What it looks like

Often the model works fine and the data is the problem: no contracts, no lineage, PII sitting in clear text, and a warehouse that only has part of the picture. People won't use AI built on data they don't trust, and security will block anything that exposes untokenized PII.

The fix

Get the data trustworthy before trying to scale. That means governed, versioned data contracts, tokenization at the source, and a single ingestion layer you can actually observe. We build this foundation first because everything else depends on it.

04

The organizational trap

What it looks like

The technology moves faster than most organizations can adapt. A common pattern: the team is excited because it looked easy in a chat window, then hits a wall when the system gives plausible but wrong answers in production, and then quietly gives up.

The fix

Training tailored to each role, pairing our engineers with yours so the know-how stays in the building, and governance built as automated checks that let people experiment safely instead of waiting for approval.

How we break the use-case trap

In Sprint Zero, every idea goes through the AI Necessity Gate.

Three questions, asked before anyone writes a prompt. The ones that fail aren't always thrown away. Some get built as plain, deterministic software. Others wait until the data is ready, and a few get dropped.

Candidate use cases

Doc extractionForecastingRoutingMatchingChat assistantReporting
Test 1

The Simplicity Test

Does a deterministic pipeline do this?

Test 2

The Clarity Test

Is the outcome measurable in value, not hours?

Test 3

The Data Test

Is the data governed enough to trust the output?

Build with AI

Needs prediction or generation, and the data can be trusted.

Build without AI

Faster, cheaper, and easier to audit as a deterministic pipeline.

So far, every Sprint Zero has turned up at least one use case that didn't need AI.

The framework

What has to be in place before AI scales.

Four things. We build three of them with your engineers. The fourth is about people, so we advise on it and pass it on by working alongside your team.

Data you can trust

We buildBase layer

Data with clear owners, contracts, and access rules, so people trust what the AI is built on.

A delivery process built for AI

We buildDelivery layer

Spec-driven development, secure AI integration, refactoring legacy code with AI help, and the habit of reviewing AI-generated code more carefully than human-written code.

The AI systems themselves

We buildValue layer

The use cases, pipelines, and agentic systems that run on the foundation.

People ready to use it

We advise

Role-specific training, change management, and measuring value instead of hours saved.

Runs across every layer.

Want us to look at your program through this lens?

In a free 30-minute call, we'll tell you which of the four traps you're in and what it would take to get out.

Talk to an Architect