How to Define an AI Project Before Choosing the Technology

The first step in an AI project is to define the business change. That definition needs an owner, a baseline, an observable target and a boundary around the harm the project must avoid.

It should come before a model, an agent, a software platform or a demo.

This sounds like ordinary project discipline. Yet AI discussions often begin somewhere else:

Where can we use AI?

That question produces a list of possibilities. It does not tell the organisation which problem is worth solving, how the work needs to change or how success will be judged.

Why tool-first AI projects lose their shape

A tool-first project can generate activity quickly. Teams can build a chatbot, connect a model to documents or show an agent completing a task.

The difficulty appears when the demonstration has to become an operating service.

Who owns the result? What volume must it handle? Which exceptions need human judgement? What error rate is acceptable? Does a faster output create more review work elsewhere?

Without those answers, a good demonstration can become a poor investment.

The problem is not prototyping. Short tests can expose weak assumptions and help a team understand unfamiliar technology. The problem is treating the prototype as proof of a business case that was never defined.

Start with five questions

An initial project definition should answer five questions:

1. Who experiences the problem? Name the customer, employee, team or supplier affected.
2. What triggers the work? Define the event that creates one unit of demand.
3. What outcome needs to improve? Choose something observable, such as elapsed time, error rate, cost, capacity or customer effort.
4. What is the baseline? Record current performance before estimating a benefit.
5. What must not get worse? Set boundaries for safety, control, quality, privacy, commercial risk and human workload.

The fifth question prevents a narrow measure from hiding a poor result.

A customer response might become faster while becoming less accurate. An automated quote might save an estimator 30 minutes but create an hour of checking for a commercial manager. A support agent might close more cases while customers make more repeat contact.

Speed is not the outcome if the work has merely moved.

Turn the idea into a measurable statement

“Automate proposal writing” is a technology instruction. It does not define the business change.

A measurable version could read:

Reduce the median time from a qualified enquiry to a customer-ready proposal from three working days to four hours, without increasing pricing errors, unauthorised commitments or senior review time.

This example is illustrative. Its value is in the structure:

• A defined unit of work
• A starting point
• A target
• A named quality boundary
• An implied group of people who own the measures

The statement does not assume AI is the answer. It creates a problem that different interventions can be tested against.

Map the current work before redesigning it

A label such as “proposal writing”, “invoice processing” or “customer onboarding” hides the steps inside the work.

Map the flow from beginning to end:

Trigger → inputs → decisions → actions → hand-offs → output → feedback

Then collect evidence for each stage:

• Demand volume and patterns
• Elapsed time and active working time
• Waiting and queue time
• Rework and repeat contact
• Common exceptions
• Systems and documents used
• Decision owners and approvers
• Consequences of errors
• Feedback available after the outcome

This map often changes the proposed project.

The delay may sit in an approval queue rather than the drafting work. Rework may come from poor source data. A manual check may exist because two systems disagree. Removing those causes may produce more value than adding a model to the visible task.

Check the intervention ladder

Once the business change and current work are understood, compare the available interventions:

1. Stop work that has no useful customer, control or operational purpose.
2. Simplify the process and remove avoidable hand-offs.
3. Standardise inputs, decisions and outputs where the work allows it.
4. Use fixed rules, integrations or conventional software for predictable cases.
5. Use AI to assist people where language, judgement or variable inputs matter.
6. Permit bounded agentic action where controls, feedback and recovery are strong enough.

The right answer may combine several levels. Poor source data may need fixing before an AI assistant can help. A rules engine may handle normal cases while a person deals with exceptions. An agent may draft an action but require approval before it changes a customer record or creates a commitment.

AI remains an implementation choice. The measurable business change remains the objective.

Use a one-page opportunity brief

The first project document can be short. A one-page opportunity brief should record:

• Outcome: What changes, for whom and why it matters
• Owner: The person accountable for the operational result
• Unit of work: One enquiry, quote, claim, case or other measurable item
• Baseline: Current volume, time, cost, quality and exception measures
• Boundary: Where the process starts and ends
• Inputs: Data, documents, systems and people required
• Failure consequence: What a wrong answer or action would cause
• Oversight: Who reviews, approves, corrects and stops the system
• Success measure: The evidence required to continue
• Stop condition: The evidence that should end or redesign the project

No vendor or model is needed at this stage.

The UK Government AI Playbook advises teams to lead use-case selection with business and user needs rather than technical possibility. It also recommends checking existing techniques and conventional alternatives before choosing AI.

The NIST AI Risk Management Framework Core follows a related sequence. Its Map function establishes purpose, context, business value, risk tolerance, affected people, benefits, costs and oversight. That information supports the first decision on whether the work should proceed.

A test for any AI proposal

Take the current proposal and remove every product, vendor and model name.

Can the remaining document explain:

• The operational change
• The people affected
• The present level of performance
• The intended result
• The unacceptable outcomes
• The evidence needed for a go or no-go decision

If it cannot, choosing a model will not fix the gap.

The project is not ready for a technology decision because the business decision has not been made.

The next part of this series examines suitability. Repetitive work may look attractive, but variability, judgement, exceptions, data quality and the cost of error determine whether AI belongs in the process.