The Four Conditions You Can Test Before You Spend Another Dollar on AI

If you read the last post in this series, you know the pattern: pilots succeed because someone quietly built a set of ideal conditions around them, and they die the moment they're asked to run without that support. The obvious next question is what those conditions actually are, specifically enough that you could go check for them this week — not after a six-month scaling initiative.

After three decades of watching technology efforts succeed or stall inside large organizations, I've narrowed it down to four. You can test every one of them cheaply, before you write a business case for anything.

1. Does one person actually own the outcome?

Not a steering committee. Not a "cross-functional working group." One person whose job gets harder if this doesn't work and easier if it does. Pilots almost always have this by accident — someone was assigned to make the demo work. Production initiatives lose it almost as often, because ownership gets diffused the moment more departments have a stake in the outcome.

The test: ask who is accountable for this AI initiative's outcome, by name, and see how many people it takes the room to answer. If it takes more than one name, you don't have ownership yet — you have a hope.

2. Is the scope small enough that dependencies don't multiply?

Every dependency you add to a project doesn't add risk in a straight line — it multiplies it, because now you need every one of those teams' priorities to line up in the same quarter. A pilot has one team and zero dependencies. Most production rollouts I've seen have six to ten by the time they touch every system they need to touch.

The test: count the number of other teams whose cooperation this project needs to work, and the number of existing systems it needs to integrate with. If that number is high, the fix usually isn't more coordination meetings — it's shrinking the scope until the number comes back down.

3. Is the data actually trustworthy, not just available?

Pilots almost always run on a hand-picked, cleaned-up dataset someone built specifically to make the demo look good. Production runs on whatever the organization actually has, which is usually a decade of inconsistent entry, siloed systems, and fields nobody has looked at critically in years.

The test: pull a genuinely random sample of the real production data this initiative would use — not the sample someone selected for you — and have a person manually check it for accuracy. If what you find would embarrass you in front of the initiative's sponsor, you don't have a data problem you can automate your way past. You have a data problem you have to fix first.

4. Is the accountable owner close enough to the work to catch drift?

This is the condition people skip most often, because it sounds like a soft skill instead of a hard requirement. In a pilot, the person accountable for the outcome is usually in the room, watching the work happen, day to day. In production, that person is often three organizational layers away, reading a status report written by someone else.

The test: ask the accountable owner to describe, specifically, what the AI actually did last week — not what the dashboard says, what it actually did. If they can't answer without pulling up a report someone else wrote, they're not close enough to the work to catch it when it starts drifting, and it will drift.

Run this before you scope the next initiative

None of these four tests requires a consultant, a platform, or a quarter of runway. They require an honest afternoon and a willingness to hear an uncomfortable answer. Most organizations skip this step because it's slower than starting, and starting feels like progress. It isn't, if you're about to build the same conditions the last twenty pilots didn't have.

Next in this series: how to actually map where your organization's real dependencies and decision rights sit — and how AI itself can help you build that map faster than any consultant ever could.

Christopher Daily is a Certified AI Master Trainer and Managing Director of InnoPower LLC, and the author of Disrupt or Be Disrupted. He writes about human-centered AI — using AI to amplify human potential rather than replace it.