You do not need to assess the technology
Approving a machine learning budget feels like it requires judging technology you do not understand. Mostly it does not. The projects that fail usually fail for reasons visible in how the proposal answers ordinary business questions.
The five below can be asked by anyone and are hard to answer well without having thought the project through.
One: what decision changes, and who makes it?
If the answer describes an insight or a dashboard rather than a decision that will be made differently, the project has no route to value.
Push for specifics: which person, how often, what they do now, and what they would do instead. 'Better visibility of demand' is not an answer; 'the buyer's weekly order quantity' is.
Two: what does the current method achieve?
If nobody can say how well the existing process performs, nobody will be able to prove the project worked. This is the single most common gap, and it is fixable before the project starts.
It also occasionally ends the project usefully. Measuring the current method sometimes shows it is already good, and the money is better spent elsewhere.
Three, four and five
- Who uses the output, and have they been involved? A model the intended users first hear about at training will not be adopted. If they have not been consulted, that is a risk on the face of it.
- What happens after launch, and what does it cost? Monitoring, retraining and support are recurring. A business case without them is understated, and the shortfall appears in year two.
- What would make us stop? Ask for the specific finding that would mean not proceeding, and at which point it would be visible. A project with no stopping condition has no decision point, only momentum.
Answers that should concern you
| Answer | Concern |
|---|---|
| We will know more once we start | No feasibility stage; risk sits with you |
| The accuracy will be around 90% | Nobody can know that before seeing the data |
| The business will benefit from insights | No decision identified |
| It runs itself once built | Post-launch cost not understood |
| We have not spoken to the team yet | Adoption risk, and possibly the wrong problem |
Structure the approval in stages
The most effective control is not asking better technical questions but structuring the spend. Approve a small feasibility stage with a defined deliverable and a decision point, then approve the build on evidence.
That converts one large uncertain commitment into a small one followed by an informed one. It also gives the project team permission to report bad news, which is worth more than any amount of oversight.
A project with no stopping condition does not have a decision point. It has momentum.