Qatreh AI Logoقطره
Back to blog
AI Adoption and Management

How to Choose Your First AI Project

Four selection criteria in order of weight, three common candidates and which usually wins, the build-or-contract split, and what belongs in the contract.

تیم قطرهSeptember 6, 20266 min read
How to Choose Your First AI Project

When an organisation decides to adopt AI, the hardest decision is not technical — it is which project to do first. That choice determines whether there is a second one.

The short answer

A first project needs three properties: a result visible in under three months, a single number that proves it, and a failure that would not be expensive. The most exciting project is usually the worst first choice, because it is large, slow to show anything, and holds the credibility of the whole programme hostage.

Four selection criteria, in order of weight

1. A numeric measure defined in advance. If you cannot write a sentence of this shape — "this figure must move from x to y by this date" — the project is not ready. This is the one criterion with no exceptions.

2. An owner with authority. Someone must be accountable who can change the process itself, not only swap the tool. The reasoning is in redesign the process, do not add a tool.

3. Data that already exists. A project whose prerequisite is six months of new data collection is not a first project. If the data exists today — even in spreadsheets, even incomplete — work can start.

4. A low cost of being wrong. The first project should not sit where one incorrect answer to a customer, or one bad decision, creates direct loss. Organisational trust is built in the first project.

Three common candidates, and which usually wins

Answering repeat customer questions. The data exists already (six months of inbound messages), the measure is clear (share of questions answered without a human), and the error is containable if the system says plainly when it does not know.

Extracting numbers from images or documents. Anywhere someone reads a form or a photograph and types into a system. Measure: time and error rate of data entry.

Forecasting demand or consumption. Higher potential value but slower to prove, because a full cycle has to pass before forecast and outcome can be compared. It is usually the second project, not the first.

In our experience the first candidate wins most of the time, because it has the shortest measurement cycle.

Build in-house or contract out

Split this into three parts, because the answer differs for each:

  • Defining the problem and the measure — always internal. Nobody outside the organisation knows which stage really consumes time.
  • Building and deploying — usually external for a first project, because repeated experience matters more than general knowledge.
  • Operating and maintaining — should transfer inward. If nobody in the organisation can understand and change the system after handover, every small subsequent change becomes a new contract.

That is why we treat team training as part of delivery rather than a separate service for later. Permanent dependence on a contractor is itself a hidden long-term cost.

What belongs in the contract

  • A numeric acceptance criterion for each phase, not a general description of "system delivery"
  • Ownership of data and models after the work ends
  • A fallback path if an external service is unavailable
  • Knowledge transfer: how many of your people must independently do what, by the end
  • The right to stop at the end of phase one if the measure was not met

That last point serves both sides. A project that cannot be stopped is a project that is not being evaluated.

A realistic schedule

A workable sequence: two weeks measuring the current state, one to two weeks defining the problem and the measure, then a prototype in a narrow domain. Results are measured thirty to sixty days after deployment.

A decision taken this week therefore has a presentable number roughly a season later. That range is deliberately conservative; a programme that starts by promising results in two weeks usually loses its credibility in the third month.

For organisations in Karaj and Alborz province we run the project-selection session in person, at Alborz Science and Technology Park or on site. The numbers behind this advice are in why an AI budget does not turn into profit.

Frequently asked questions

What if we are not sure which process is suitable?

Start by counting, not analysing. List the three processes consuming the most staff hours, and for each ask whether it is measurable today. That pair of questions usually reduces the list to one.

What is the minimum data required?

It depends on the problem, but a practical test: if an experienced employee could do the task from the data you already have, a system has a chance. If they could not, the problem needs more data, not a better model.

How do we know we picked a good contractor?

Ask them to write the phase-one acceptance criterion before the contract. A contractor willing to tie the project to a number differs seriously from one who supplies a list of technologies.

Do we need an internal technical team?

Not to start, but yes to continue. At minimum one person who owns the measure and understands what the system does and where it struggles. Building that person is the purpose of enterprise training.

What if phase one does not reach its target?

With a small scope and a short period, the cost is bounded and the information is valuable. It usually shows the constraint was elsewhere. Reached early, that is itself a result.

How large should the first budget be?

There is no fixed figure and it depends on scope, but a working rule: small enough that losing it entirely would not halt the organisation's programme. The first consultation is free, and scope becomes clear in that session.

Related services from Qatreh