GaneevEcoThe questions worth asking first
Most of the AI rollout failures we see in retrospect trace back to a small, predictable set of questions that simply never got asked before the budget was approved and the project kicked off with enthusiasm. None of these questions are technically difficult to answer — they're just easy to skip in the excitement of getting started quickly.
- Which specific manual tasks are we targeting, and how much time do they actually cost today, measured rather than estimated from memory or gut feel?
- Who owns the tool and its knowledge base once the pilot ends — not just who champions it during launch, but who's still responsible six months later?
- What data can this tool actually access, and has anyone reviewed whether it should have that access in the first place, rather than assuming default settings are fine?
- What does "success" look like in a number we can measure in 90 days, not a general feeling that things seem to be going better?
Why these get skipped anyway
Launch energy rewards moving fast, and these questions feel like friction in the moment — the kind of due diligence that slows down an initiative everyone's excited to get started on. They're genuinely cheap to answer upfront, taking perhaps a single meeting, and expensive to discover the hard way three months into a rollout that's quietly stalled without anyone quite being able to explain why.
The teams that build a habit of asking these questions before every new AI initiative — not just the first one — tend to have a meaningfully better track record over time than teams that treat each rollout as a fresh start with no accumulated institutional memory from what happened, well or badly, on the last one.
Making this a standing habit, not a one-time checklist
The organizations that get the most value from this checklist don't treat it as a one-time gate for the first project — they build it into how any new AI initiative gets approved going forward, the same way a capital expenditure request goes through a standard review regardless of how many times the organization has done something similar before.
A short, standard template that any team proposing a new use case fills out — covering these same four questions — costs almost nothing to maintain and catches the majority of the problems that would otherwise only surface well after the project's already underway and harder to redirect without real cost.
It's worth keeping this list visible and referenced at the actual kickoff meeting for any new initiative, not filed away in a policy document nobody revisits under launch-day time pressure. A physical or shared-screen checklist reviewed out loud in the room, however brief, tends to actually get used in a way that a policy buried in a wiki generally doesn't.
Beyond the kickoff meeting itself, it's worth having someone specifically responsible for circling back on these four questions partway through any new initiative, not just at the very start. Circumstances can shift meaningfully between initial approval and actual implementation, and a mid-project check against the same questions — is the ownership still clear, does the success metric still make sense — catches drift before it compounds into a genuine problem discovered too late to easily correct.