Seven questions we ask before we say yes to an AI or GeoAI project

Every week, organisations arrive with a version of the same request: we have a lot of data, we want to use AI, can you help? It is a sensible question and an exciting one. It is also, on its own, nearly impossible to answer well. The projects that succeed are rarely the ones with the cleverest idea. They are the ones where a few basic questions were asked, and honestly answered, before anyone wrote any code.

This article shares the seven questions we ask at the start of any AI, GeoAI or immersive 3D project. Use them to test your own project idea, whether you work with us or not.

1. What decision will this change?

Every useful AI system changes something that someone does. A map of crop stress is useful if it changes where an officer drives this week. A document assistant is useful if it changes how long a team takes to answer a question. If we cannot name the decision, we are about to build a dashboard that nobody opens.

• Good answer: “We decide which districts get field visits each month, and today we guess.”
• Weak answer: “We want insights from our data.”
• Follow-up: how is that decision made today, and what would a better answer be worth?

2. Who will use it, and have we asked them?

The person who commissions a project is often not the person who will use it. A manager may want a tool that a field officer finds slow and awkward. We ask to speak to at least two real users in the first week, and we ask them to describe their day, not to approve our plan.

• What do they use today, and what do they dislike about it?
• On what device, with what internet, in what setting?
• What would make them trust the result, or ignore it?

3. What data exists, and can we actually use it?

“We have a lot of data” can mean anything from a clean, documented database to a shared folder of spreadsheets that three people understand. We ask to see the data in the first week, not the last, and we check four things.

1. 01Access: can we legally and technically use it for this purpose, and who must approve?
2. 02Quality: how complete, current and consistent is it?
3. 03Labels: for supervised models, are there examples of the right answer, and who created them?
4. 04Continuity: will it keep arriving after the project ends, and who is responsible for that?

4. How will we know it worked?

We agree on a measure of success, and a baseline, before building. Without a baseline, every improvement is an opinion.

• Time: minutes per task, before and after.
• Quality: error rates, or accuracy on a test set that was agreed in advance.
• Money or reach: cost saved, enquiries handled, area covered.
• Adoption: how many people use it each week, and what they say.

We also agree a minimum result below which the idea needs to change, and a date to decide. A pilot with no decision date is a hobby.

5. What happens when it is wrong?

Every AI system makes mistakes, so the question is what they cost and who catches them. We list the likely errors and sort them by harm.

• Low harm, easy to catch: a poor first draft that a person edits.
• Medium harm: a missed item that a later check will find.
• High harm: a wrong decision that affects people, money or safety, which needs human review and careful limits.

This conversation shapes the design. High-harm uses get a person in the loop. Low-harm uses can be automated further.

6. Who owns it after launch?

Software is not finished when it is delivered. Models need monitoring, data needs refreshing, documents change and users change jobs. We ask who will own the system in a year, and what time and budget they have. If the honest answer is “nobody”, we plan a simpler system that can survive without constant care, or we plan the handover and training as part of the project.

7. What is the smallest version that proves the idea?

Most ideas start too big. The cure is to ask what we could build in six to eight weeks that would answer the biggest uncertainty. That might be one district instead of the whole province, one document collection instead of every file or one task instead of a whole workflow. A small, real result teaches more than a large, theoretical plan.

What a good answer looks like

We ask clients to answer all seven in a single page. A strong page might read: “Field officers choose which villages to visit each month. They need a ranked list by Friday. We have three years of survey data and free satellite imagery, owned by the planning unit. Success is cutting wasted visits by a third, measured against last year. Wrong rankings cost a trip, so officers will review the top ten. The planning unit will own it. We will start with one district.” That is a project we can begin.

Warning signs

• The goal is a technology, such as “we need a chatbot” or “we want machine learning”.
• There is no named owner who has time for the project.
• The data cannot be shown until after the contract.
• Success is described only as “innovation” or “modernisation”.
• Nobody has talked to the people who will use the result.

When we say “not yet”

Sometimes the right answer is to wait. If the data does not exist, we propose a short project to collect it. If the decision is unclear, we propose a workshop. If the budget is too small for the ambition, we suggest a smaller scope. We would rather tell a client this in the first week than deliver a disappointing system in the sixth month.

A checklist to take away

• Can we state the decision this will change in one sentence?
• Have we spoken to two real users?
• Have we seen the data, and confirmed access and quality?
• Do we have a baseline and a success measure?
• Do we know the cost of a wrong answer and who reviews it?
• Is there an owner for after launch?
• Is the first version small enough to finish in two months?

Frequently asked questions

What if we do not have good answers to some of these?

That is normal. The questions are a map of what to do first. A project can start with the unanswered ones, such as a data audit or a user workshop.

How long does this take?

Often a few days to two weeks, including looking at the data and talking to users. It is the cheapest part of the project and has the highest return.

Do we need a technical person to answer these?

No. They are business questions. A technical partner helps with data access and feasibility.

What if our idea does not pass?

Then you have saved money, and learned what to change. Many of the best projects began as an idea that failed the first review and came back smaller and sharper.

Good projects are chosen as much as they are built. Seven honest questions will not guarantee success, but they remove most of the reasons that projects fail, and they make the work that follows far more likely to matter.