Every organization has more AI ideas than it can fund, and the loudest idea is rarely the best one. The usual response is a scoring spreadsheet for the things worth doing. A more useful exercise is the opposite: an explicit list of the things not to do, with reasons. Saying no early is the cheapest form of risk management a strategy has.
Six tests a project must pass
- The problem is real and measured — someone can state today's cost, error rate or delay as a number. 'It would be nice to have' fails here.
- A named owner will change how they work — not a sponsor who approves it, but a person whose day looks different if it succeeds.
- The data exists and is accessible — it is not locked in systems nobody can connect to, or in a quality nobody has examined. Discovering this after kickoff is the most common surprise.
- A wrong answer is survivable — the action is reversible, or a human checks it before it matters. High-stakes, irreversible, unreviewed actions need a much longer path.
- A simpler tool wouldn't do — a rule, a template, a spreadsheet or an existing product solves enough of it. Many problems don't need a model at all.
- It pays for itself on the measured number — with realistic run costs and review time included, not just build cost.
A project that fails two or more tests is not a pilot waiting to happen. It's an expensive way to learn something you could have learned in a one-hour review.
Keep the list visible
Write down each rejected idea with the test it failed and what would change the answer: a data source being connected, a metric being measured, a product reaching a certain maturity. Review the list every quarter. Some items graduate; others stay rejected with a clear record of why.
Why it builds trust
Stakeholders accept a 'not yet' more easily when it comes with a reason and a condition for revisiting. Funding then concentrates on the few projects that pass every test, which is how an organization ends up with a short list of working systems instead of a long list of experiments.