AI projects rarely fail only because the model is not good enough.
More often, they fail because the work around the model is not ready. The team starts with the tool, the demo, or the promise of productivity before checking whether the use case has the conditions it needs to become useful.
Before asking which model, platform, agent, or workflow to build, a sponsor should ask a simpler question.
Is this the right AI work to build?
I help teams avoid vague AI ambition by checking whether a use case is frequent enough, feasible enough, and valuable enough to deserve a build.
The right AI work has three signals.
1. Frequent work
A real task repeats often.
The best candidates are recurring decisions, service moments, or process steps where people spend time applying context.
This matters because repetition creates enough evidence to learn from. It also makes improvement worth the effort. If the task only happens once, or happens differently every time, it may still matter, but it is less likely to be the best first AI project.
Self-assessment:
- What work is repeated often enough to be worth improving?
- Where do people spend time applying judgement, context, or rules?
- Which service moments or process steps create delay, rework, inconsistency, or frustration?
- Is the work specific enough to observe from start to finish?
If the work is not frequent enough, the project may not have enough value or learning volume to justify a build.
2. Accessible context
The data and rules can be reached.
The workflow needs enough information, examples, constraints, and escalation paths for AI support to be reliable.
That context might be structured data, documents, examples, policies, previous cases, customer feedback, operational notes, or expert knowledge. The important question is not simply whether data exists. It is whether the right information is available, current, usable, and safe for the workflow.
Self-assessment:
- What information does the workflow need to do the work well?
- Can the team or system reach that information?
- Are the relevant rules, examples, constraints, and edge cases visible?
- Are privacy, permission, security, and access boundaries understood?
- What should happen when the workflow is uncertain, risky, or wrong?
If the context is not accessible, the pilot may still be possible, but the first phase should be about learning what is missing rather than pretending the project is ready to scale.
3. Measured value
A sponsor can define success.
Before build starts, the team needs a value driver, evidence plan, and clear decision to proceed, pause, or scale.
This is where sponsorship matters. An AI project needs someone who can explain why the work matters, make decisions, unblock issues, and own the value conversation. Without that, the project can become a demo looking for a business case.
Self-assessment:
- Who owns the outcome?
- What value driver are we trying to improve?
- What baseline do we have for time, quality, cost, risk, experience, or capacity?
- What evidence would show that the AI support is helping?
- Who can decide whether to proceed, pause, redesign, or scale?
If value cannot be defined, the project may still create activity, but it will be hard to prove whether the work mattered.
A simple sponsor test
Before approving an AI project, ask the team to answer these three questions in plain language:
- Is the work frequent enough to matter?
- Is the context accessible enough to support the workflow?
- Is the value measurable enough to make a proceed, pause, redesign, or scale decision?
If the answers are clear, the project may be ready for a pilot.
If the answers are vague, that is not a failure. It is useful evidence. It means the next step is not to build faster. The next step is to clarify the work, the context, the value, and the decision the sponsor needs to make.
Successful AI projects do not start with certainty.
They start with work that is frequent enough, context that is accessible enough, and value that can be measured well enough to learn safely.