When a project finishes by saying “we ran out of budget,” what really happened is the engineer who knew how the estimating spreadsheet worked got pulled onto a deadline three weeks in and never came back. The money was fine. The person wasn’t there.
Most teams approve an AI pilot the way they approve a piece of equipment. They ask what it costs, they put a number against it, they get sign-off, and they assume the spend is the thing standing between them and a result. Then the pilot stalls, and everyone reaches for the budget conversation, because budget is the lever everyone knows how to pull. Need more? Ask for more. The trouble is that the budget was never the binding constraint.
The constraint is your people’s time and attention — specifically the people who actually understand the problem you’re trying to automate. The senior estimator. The QA lead who knows why the inspection process is the way it is. The project engineer who can tell you which of the four “official” workflows the team really follows. You cannot buy more of those people on short notice, and you cannot substitute a vendor’s headcount for them. A pilot lives or dies on how much of their calendar you can realistically protect, and almost nobody scopes for it honestly.
This is the failure mode I see most often, and it’s the one nobody puts in the post-mortem. So let’s put it in writing.
The hidden time costs nobody puts in the plan
Walk through what an AI pilot actually asks of your organization, and you’ll find that the model-building part — the part the vendor talks about — is rarely where the hours go. The hours go to four places, and all four of them draw on your internal people, not the vendor’s.
Subject-matter interviews. Whatever you’re automating, somebody in your building understands it in a way that lives in their head and nowhere else. Getting that knowledge out is slow. It’s not one meeting; it’s a first conversation that surfaces how little is written down, a second one to correct the wrong assumptions from the first, and a third when you discover the real rule has six exceptions. A senior person who is already the bottleneck for actual work now owes you several hours of their best thinking.
Data access. This is the quiet killer. The data you need lives in a system someone has to grant access to, in a format someone has to explain, with caveats only one person remembers. “We’ll pull the historical records” turns into a two-week wait because the person who can run that export is on a project, and the records turn out to live in three systems that disagree with each other. None of that is hard work. It’s just work that only specific people can do, and those people have day jobs.
Testing and validation. A pilot produces output, and that output is worthless until someone qualified looks at it and says whether it’s right. That someone is, again, your senior person — the only one who can tell a plausible-looking wrong answer from a correct one. Validation isn’t a rubber stamp. It’s careful, repeated attention from the exact person you can least afford to borrow.
Adoption. Even a working pilot changes how someone does their job, and that change costs hours: training, the awkward stretch where the new way is slower than the old way, the meetings where people air why they don’t trust it. Skip this and you get a technically successful pilot that nobody uses, which is the same as a failed one.
Add it up and the pattern is obvious. Nearly every hour the pilot consumes is an hour from a person you already rely on for something else. The vendor’s time is the cheap, abundant input. Yours is the scarce one.
Why under-resourced pilots stall instead of failing
Here’s the part that makes this hard to catch in time: a starved pilot rarely dies cleanly. It stalls. And a stall is much harder to act on than a failure.
A failed pilot gives you a clear answer — the approach didn’t work, move on. A stalled pilot gives you nothing. The vendor is still “making progress.” There’s always a next step. But the calendar keeps moving and the thing never reaches the point where someone with authority can look at it and decide. That limbo is almost always a time-and-attention problem wearing a technical costume.
Watch for the signatures:
- The same three questions for the SME have been “waiting on a response” for two weeks.
- Test results exist but nobody senior has actually reviewed them, so they don’t count.
- The kickoff had eight people; the working sessions have two, and neither owns the problem.
- Every status update describes vendor activity and almost none describes internal decisions made.
What’s happening underneath is that the pilot needs decisions and knowledge that only specific busy people can supply, and those people are rationing themselves across the pilot and their real job. The pilot loses every time, because it’s optional and the day job isn’t. More budget does nothing here. You can’t spend your way out of a senior engineer who has twenty minutes a week to give you.
This is why “let’s just extend the timeline” is usually a trap. Extending time without protecting attention just stretches the same starvation over a longer period. The pilot doesn’t get healthier. It gets quieter.
Scope around a fixed time box, not a fixed deliverable
The fix is to invert how you scope. Instead of starting with the deliverable (“build us a model that does X”) and letting the time float, start with the time you can genuinely protect and let the scope adjust to fit.
A time box forces the honest conversation up front. If the answer to “how many hours of your estimator’s attention can you commit over the next six weeks?” is “maybe four total,” that’s not a reason to give up — it’s the single most useful piece of planning information you’ll get, and it should reshape the pilot before anyone writes a line of code.
What a time box does for you
- It makes the real constraint visible. You’re now negotiating in the currency that actually matters — SME hours — instead of pretending dollars are the bottleneck.
- It forces a narrow problem. You can’t validate a sprawling pilot with four hours of attention, so you pick the one slice that’s worth those four hours. Narrow is a feature.
- It creates a real decision point. At the end of the box, you have a yes or no, not an open-ended “still going.” That’s worth more than the pilot’s output, because it lets you reallocate cleanly.
How to actually do it
Pick a window short enough that people can hold attention through it — six to eight weeks, not six months. Name the specific people whose time you need and get an explicit, calendared commitment, not a vague nod in a kickoff. Cut the problem down until it fits inside the attention you’ve actually secured. Then, before anything starts, write down what result at the end of the box would justify going further. If you can’t define that, you’re not ready to start — which brings us to the real question.
What “ready to start” actually requires
“Ready to start” has very little to do with whether you’ve picked a tool or signed a statement of work. A pilot is ready when the human inputs it depends on are lined up and committed. In practice that means a short, unglamorous readiness checklist:
- A named problem owner with real authority. One person who can make decisions and whose own work gets measurably better if this succeeds. Not a committee. Not someone delegating it down because it’s not really their priority.
- Identified SMEs with protected time. You know exactly whose knowledge you need, and their manager has agreed — in the calendar — to shield those hours from being eaten by something more urgent.
- A clear path to the data. Not the data cleaned and perfect, just a known route to it: who grants access, where it lives, who can explain its quirks, and a realistic estimate of how long that takes.
- A defined success criterion. A specific, checkable statement of what “this worked” looks like, agreed before you start, so the end-of-box decision is about evidence rather than vibes.
- A named validator. The qualified person who will judge the output, with the time to do it carefully.
Notice what’s not on the list: a polished data warehouse, a finalized model architecture, executive consensus on a multi-year AI strategy. Those are nice and mostly irrelevant to whether a focused pilot can run. The list is almost entirely about people and their availability, because that’s almost entirely what determines the outcome.
If you read that checklist and several items are soft — “we’ll figure out the SME thing,” “data’s probably accessible” — you’ve learned something valuable for free. You’re not ready, and starting anyway just means paying for the discovery in a slower, more expensive form later. The honest move is to fix the soft items first, even if that means waiting a month. A pilot that starts ready beats a pilot that starts early, every time.
What this means for how you plan
The reframe is simple and it changes everything downstream: stop asking “what will this pilot cost?” and start asking “whose attention will it require, and can we actually protect it?” The dollar figure is the easy question. The attention question is the one that predicts the result.
This is also why the most useful thing you can do before committing to anything is an honest scoping conversation — not a sales pitch, an actual look at whether the problem, the people, and the time line up. If they don’t, the right answer is sometimes “not yet,” and a good delivery partner will tell you that. We’d rather have that conversation in thirty minutes than watch a well-funded pilot quietly stall because nobody asked whose calendar it really needed.
If you’re weighing a pilot and want a clear-eyed read on whether you’re actually ready to start, that’s the kind of thing to book a 30-minute call about. Bring the problem and the names of the people who own it. We’ll tell you what we’d tell anyone: the budget is rarely the thing in your way. Your best people’s time is. Plan for that, and most of the ways a pilot fails simply stop being available to it.
