A Minimum Viable AI Project Structure for a Small Team

19 Oct 2026 01:43 PM Comment(s) By GR Consulting Services

An AI project can become difficult to assess before it becomes technically complicated.

The first scope may include several tasks, several sources and several people checking different outputs. When something goes wrong, the team cannot easily tell whether the problem came from the source information, the instruction, the tool, the review process or the way the task was defined.

A smaller project gives the team a clearer question: can we make this one piece of work useful, controlled and maintainable?

This guide turns that question into five operating records. It builds on our earlier practical AI starter framework by showing what a small team should write down and test before connecting more work around the project.

Define one bounded piece of work

Start with a repeated task or a small project that has a visible beginning and end.

Write a short project definition covering:

the business problem;
the task the AI will support;
the people who will use or review the result;
what a finished output looks like;
what remains outside the scope; and
the conditions that should stop the process.

Avoid a scope such as "help the team with customer service". It is too broad to test or own.

A narrower scope might be: "prepare a draft weekly summary of late orders for an operations manager to check before the team meeting".

The AI is supporting one draft. It is not deciding customer compensation, changing delivery promises or sending messages without review.

The UK Government's AI Playbook recommends choosing use cases from business and user needs rather than from what the technology can do. Although the playbook addresses government organisations, that starting discipline is useful for a small business too.

Name the sources and information boundaries

The project needs a source list, not simply access to whatever information happens to be available.

For each source, record:

its name and location;
whether it is the current approved record;
who keeps it accurate;
what should trigger an update; and
whether the project may use it.

Keep business-wide, client-specific and project-specific information separate. Access to a file does not automatically make it suitable for the task.

In the late-order example, the approved weekly order export and the current service policy may be in scope. Informal notes, unrelated customer records and old spreadsheet copies should remain outside it.

This boundary helps the team correct the right source. It also limits the temptation to solve an unclear output by adding more information.

Define review criteria and authority

"A person will check it" is not yet a review process.

The reviewer needs to know:

what to compare with the source;
which errors matter;
what they may correct;
what requires escalation;
when they must reject the output; and
whether they have enough time and authority to intervene.

For the weekly late-order summary, the operations manager might check order number, status, promised date, exception reason and any wording that could be read as a commitment. If the source data is incomplete, the summary should be held rather than guessed.

The ICO's human-review guidance recommends standard review procedures. The level of review should reflect the risk and effect of the work. A low-risk internal draft and a decision affecting a person's rights do not require the same control route.

Test the normal case, an exception and a stop case

A demonstration using one tidy example does not tell the team how the project behaves when ordinary work becomes messy.

Test at least three conditions:

Normal case: the expected source is complete and the output follows the agreed structure.
Exception case: a record is missing, contradictory or outside the usual pattern.
Stop case: the output would create an unacceptable commitment, use information outside the boundary or proceed without the required reviewer.

Record what happened and how the person responsible responded. A useful test includes the manual fallback, because the team still needs to complete the work when the AI route cannot.

NIST's AI Risk Management Framework links testing and measurement to the actual deployment context. It also treats monitoring and review as continuing activities. The framework is voluntary US guidance and is being updated, but the principle is practical: test the project under the conditions in which people will use it.

Measure the outcome and the maintenance work

Choose a small number of measures before the trial begins.

Useful measures may include:

time from source availability to approved output;
number and type of corrections;
work returned for missing information;
delays caused by exceptions;
reviewer time; and
time spent updating sources, instructions or tests.

Record a starting point where possible. Otherwise, the team may notice that the draft is faster while missing the extra time spent correcting it or maintaining the process.

Do not combine every measure into a single success score. A project can produce faster drafts and still be unsuitable because it creates too much review work or relies on information the team cannot maintain.

A minimum project record

The complete structure can fit on one page:

Record	Minimum content
Scope	One task, intended output, people affected, exclusions and stop conditions
Sources	Approved records, owners, update triggers and information boundaries
Review	Acceptance criteria, reviewer, authority, escalation and rejection route
Tests	Normal case, exception case, stop case and manual fallback
Measures	Baseline, outcome, corrections, delay, review time and maintenance effort

The point is not to create documentation for its own sake. It is to make the trial understandable enough that another person can see what is being tested, what evidence controls the result and who can stop it.

Decide whether to improve, stop or expand

Set a review point before the trial begins.

At that point, compare the observed result with the original problem and the maintenance effort. Then make one of three decisions:

Improve: keep the same boundary and correct one known weakness.
Stop: retire the route because the value, control or maintenance case is not strong enough.
Expand: change one boundary only after the current project remains useful and controlled.

Expansion may mean adding one source, one type of output or one adjacent task. Changing several things together makes it difficult to know what produced the next result.

The smallest useful AI project is not the one with the fewest files. It is the one the team can explain, review, maintain and judge.

If you need help choosing a suitable first project, defining its operating boundary or deciding what to remove, apply for a Business Clarity Diagnostic.

Sources and limitations

Artificial Intelligence Playbook for the UK Government, checked 1 October 2026. Government guidance adapted here as practical operating principles for small businesses.
ICO human review guidance, checked 1 October 2026. Detailed requirements depend on the processing and its effects. The ICO states that this guidance is under review following legislative changes.
NIST AI RMF Core, checked 1 October 2026. Voluntary US framework; AI RMF 1.0 is being updated.

This article provides general operational guidance. Businesses should separately check applicable law, contracts, data-protection duties, information-security requirements, provider terms and sector rules.

Choose one next action

Take a workflow your team already uses. Identify its current record, owner and next review trigger. If those are unclear, resolve them before adding another helper or integration.

If you need help deciding what to maintain, simplify or stop, apply for a Business Clarity Diagnostic. This paid first step starts from GBP 495 and helps clarify the main issue and the next sensible route.