Most failed AI projects fail for the same handful of avoidable reasons. Here are the questions worth asking first, and why skipping them tends to cost far more later than answering them honestly upfront would.
Do We Actually Have the Data This Needs?
This is the single most common reason AI projects stall. Not "do we have data," but "do we have enough clean, relevant, accessible data for this specific use case" — a much higher bar than most teams initially assume. Data that's technically been collected for years can still be unusable if it's inconsistent, poorly labeled, or scattered across systems that don't talk to each other.
A quick, honest gut check: pull a genuine sample of the data you'd need and try to manually answer the question you want AI to eventually answer. If that's difficult or ambiguous even by hand, it will be difficult for a model too — AI doesn't fix messy data, it just makes decisions faster on whatever data it's given.
What Does Success Actually Look Like?
"Improve efficiency" isn't a success metric. A clear, measurable definition of success, agreed on before the project starts, is what separates AI initiatives that get evaluated fairly from ones that just quietly fade out because nobody could agree afterward on whether it actually worked.
Good success criteria are specific enough that two different people, looking at the same result, would reach the same conclusion about whether it succeeded. If your current definition would let two reasonable people disagree, it needs to be tightened before you start building anything.
Who Owns This After Launch?
AI systems need monitoring and occasional retraining — they're not "set and forget." If nobody's clearly responsible for that after launch, performance tends to degrade quietly until someone notices a problem downstream, often a customer or a bad business decision made on stale output.
This ownership question is worth answering with a specific name, not a department. "The data team" isn't ownership — a specific person whose job includes checking on this system regularly is.
Could a Simpler Solution Solve This?
Sometimes a well-built dashboard or a straightforward automation solves the actual problem better than a machine learning model. It's worth asking honestly before committing to the more complex path, since AI adds real ongoing complexity — monitoring, retraining, explainability — that a simpler rules-based tool doesn't carry.
A reasonable rule of thumb: if the logic behind a decision can be written down as a clear set of if-then rules that would handle the vast majority of cases correctly, you may not need AI for it at all.
What's the Real Cost of Being Wrong?
Understanding how much it costs when the model makes a mistake — and how you'll catch it — should shape both the project's design and how much human oversight it needs. A wrong product recommendation costs very little. A wrong decision about a loan application, a medical flag, or a safety-critical process costs a great deal, and needs correspondingly more human review built in.
A Practical Way to Use These Five Questions
Run through them as an explicit checklist before approving any AI project, not as an informal gut check. Writing down honest answers, even briefly, forces a level of clarity that a verbal "yeah, I think we're ready" conversation rarely produces. If more than one answer is genuinely uncertain, that's not necessarily a reason to stop — but it is a reason to address that specific gap before committing real budget.
Not sure where you stand on these? An honest readiness assessment can tell you. AI Readiness Assessment
What Happens When These Questions Get Skipped
The most common outcome isn't a dramatic, visible failure \u2014 it's a quiet one. A model gets built, technically works in a demo, and then either never gets deployed because nobody defined what "ready for production" meant, or gets deployed and slowly loses accuracy because nobody was watching for drift. Months later, the project gets described internally as "the AI thing that didn't really pan out," without anyone tracing the outcome back to a specific, avoidable gap in the original planning.
That quiet failure mode is part of why these questions matter so much upfront. A project that fails fast and visibly at least generates a clear lesson. A project that fails slowly and invisibly often just erodes internal confidence in AI generally, making the next genuinely good AI opportunity a harder sell than it should be.
How These Questions Apply Differently to Small vs. Large Projects
A small, contained AI project — automating one specific internal report, say — still benefits from running through these five questions, but the bar for "good enough" answers can reasonably be lower than for a large, customer-facing initiative. What matters is scaling the rigor of the answer to the scale of the risk, not applying the same exhaustive process regardless of project size.
A larger, higher-stakes project deserves written, specific answers reviewed by more than one stakeholder. A smaller internal experiment can reasonably be answered in a short conversation, as long as the conversation genuinely happens rather than being skipped entirely.
A Worked Example of Applying These Questions
Consider a team proposing an AI tool to automatically categorize incoming support tickets. Data readiness: do they have enough historically categorized tickets to train from, and are those categories still relevant today? Success criteria: what accuracy rate would actually be useful versus just interesting? Ownership: who reviews miscategorized tickets weekly to catch drift? Simpler alternative: could a well-designed set of keyword-based rules handle most cases without a model at all? Cost of being wrong: a miscategorized low-priority ticket costs little; a miscategorized urgent one could mean a slow response to a real emergency, which changes how much human review the system needs.
Revisiting These Questions Mid-Project
Conditions change as a project progresses — data quality issues emerge, success criteria that seemed clear turn out to be ambiguous in practice. Briefly revisiting these five questions at a project's midpoint, not just at kickoff, catches drift before it compounds into a larger problem by launch.
How These Questions Change for Regulated Industries
In regulated industries like healthcare or finance, the cost-of-being-wrong question carries additional weight, since a mistake can trigger compliance consequences beyond the immediate business impact. Teams in these industries benefit from explicitly involving compliance or legal review as part of answering that fifth question, not treating it purely as a technical risk assessment.
A Final Word on Balancing Rigor With Momentum
None of this is meant to slow every AI initiative down with excessive process. The goal is proportionate rigor — enough honest reflection to catch the mistakes that actually sink projects, without turning every small experiment into a lengthy committee review.
Key Takeaways
- Data readiness means more than having data — test it by trying to manually answer your question with a real sample first.
- Success criteria need to be specific enough that two reasonable people would reach the same conclusion from the same result.
- Post-launch ownership should be a named person, not a department, since AI systems degrade without active monitoring.
- If the decision logic can be written as clear if-then rules, a simpler tool may outperform AI on cost and reliability.
- The acceptable level of human oversight should scale directly with how costly a wrong decision would actually be.
Frequently Asked Questions
What if we're not sure how to answer some of these questions?
That's common and not a disqualifier — a structured readiness assessment is specifically designed to help answer these honestly before committing to a full project.
Do small businesses need to go through this same process?
Yes, arguably more so — smaller teams have less slack to absorb a failed AI project, which makes honest upfront readiness checking even more valuable.
How long does answering these questions properly take?
A focused internal discussion can cover the basics in a few hours; a more thorough assessment involving real data review typically takes one to two weeks.
Should we revisit these questions during the project, not just before?
Yes — conditions change as a project progresses, and revisiting success criteria and ownership periodically helps catch drift before it becomes a real problem.
Do small internal AI projects need the same rigor as customer-facing ones?
The five questions still apply, but the bar for how exhaustively they need to be answered should scale with the actual risk and visibility of the project.
Can you walk through how these questions apply to a real example?
Yes — for something like automated ticket categorization, each question maps to a concrete consideration: data history, a meaningful accuracy threshold, a named reviewer, whether simple rules could work instead, and how costly a miscategorization actually is.
Should we revisit these questions after the project has already started?
Yes, briefly revisiting them at the project's midpoint catches drift in data quality or success criteria before it compounds into a larger problem by launch.
Do these questions change for regulated industries like healthcare or finance?
The cost-of-being-wrong question carries added weight, and involving compliance or legal review directly in that assessment is worth doing explicitly, not just as a technical exercise.
Won't going through all five questions slow down every project too much?
The goal is proportionate rigor, not a lengthy review for every initiative — small experiments need a lighter touch than large, high-stakes projects.
