Boards approve technology projects for two bad reasons: because the presentation was good, and because nobody in the room felt licensed to expose their own lack of technical familiarity. The questions below solve the second problem. None of them requires technical knowledge to ask, and all of them require real knowledge to answer.
Use them in order. The first four eliminate most bad projects before you spend time on the other eight.
Value
- Which number in our operation changes, and by how much? The answer has to be a P&L line or an operational indicator with an owner, a current value and an expected value. "Efficiency gains" and "better experience" are not answers. If nobody can name the number, the project has no thesis, it has enthusiasm.
- How will we know in 90 days whether we are on the right track? Every project should carry an early-read milestone. Without one, the first sign of failure arrives with the final invoice.
- What is the cheapest alternative that would solve 70% of this? Ask even though the answer may be unwelcome. In mid-market operations, a process change or an integration usually captures most of the value an AI project promises, at a fraction of the cost. If nobody assessed the cheap alternative, the comparison you were shown is rhetorical.
- What happens if we do nothing for 12 months? If the honest answer is "not much", you have just discovered this is not the most important project in the queue.
Data
- Does the data this model needs exist today, with audited quality? The control question is always the same: has anyone measured completeness, duplication and error rates in that dataset? "We have the data" rarely survives the second question.
- Who owns the data, and have they agreed to this use? Data with no declared owner is data nobody corrects. And a use not agreed with the team that generates the data is the single most common cause of a project that works in pilot and dies at scale.
- If the model is wrong, who notices, and how long does it take? Models degrade quietly. An AI project with no monitoring plan and nobody accountable for reviewing outputs is not an asset, it is a liability that looks like automation.
Risk
- Which personal, sensitive or third-party data enters this process, and under which legal basis? If the answer takes a while, stop the approval. Images of people, data about minors, customer information and supplier data under confidentiality agreements are the four most frequent sources of unmapped exposure.
- Does this project make us dependent on a single vendor? Ask specifically: if we change vendor in 24 months, what do we lose, what does the exit cost, and who owns the models, the training data and the documentation. The answer belongs in a contract, not in a relationship of trust.
- Which human decision is being replaced, and who answers for it afterwards? Automating a decision does not transfer accountability for it. If the answer does not name a person or a committee, the project is creating an accountability vacuum.
Execution
- Who on our team has to dedicate time to this, and how many hours a week? The most underestimated cost of any technology project is the attention of the people running the operation. If the plan does not state those hours, it is already late on the day it is approved.
- Does the person advocating this project have a financial incentive in its approval? This is not an accusation, it is governance hygiene. A vendor reselling licences, an integrator billing by the hour and an internal team measured on project delivery all have legitimate interests, but not neutral ones. If the only technical assessment available comes from the party selling, you do not have a second opinion, you have a sales proposal wearing the clothes of an assessment.
How to use this in practice
Send the twelve questions to whoever is presenting, before the meeting. The point is not to embarrass anyone in public, it is to raise the quality of the work before it consumes board time. A good proposer thanks you for the list. A proposer who complains about it has just answered question 12.
An AI project that answers these twelve well rarely fails for technical reasons. And a project that cannot answer them rarely fails for technical reasons either: it fails because it was never a project, it was an intention.
If three or more answers require someone to go and find out, that does not mean the project is bad. It means the decision is being taken too early, and what is missing is diagnosis, not courage.
This document is free to circulate
Forward it, print it, adapt it to your committee, use it without crediting the source. If you would like, we will run this conversation alongside your executive team in a 90-minute session, at no cost and with no company deck.
Book the 90-minute session