AI delivery methodology
Four phases, a concrete output at the end of each, and a clear split of decisions. Including the part most sites leave out: the conditions under which we will tell you not to start.
The four phases
Each phase ends in a document and a decision about whether to continue. That is not a formality — a project can end after the first or second phase, and that is an anticipated outcome rather than a broken engagement. The structure applies to an AI implementation whether the work is automating a process, building an assistant for a team, or integrating with a system you already run.
The above describes how we work. If you are after the steps on your own side — from picking the first process through to deciding whether you need a supplier at all — those are set out separately in our guide to implementing AI in your company.
| Phase | What it produces |
|---|---|
| 1–2 wksAudit and process selection | A list of processes worth considering, with time and cost estimates, one process chosen to go first with the reasoning for it, and measurable success criteria agreed before anything is built. |
| 2–4 wksPilot | A working solution on your real data rather than sample data, measured against the criteria from phase one. This is where the decision is taken: put the solution into day-to-day use, or stop the project. |
| 4–12 wksGoing live in day-to-day work | Connection to your systems, handling of unusual cases and failures, logs of system activity and errors (including who did what, and when) and ongoing checks on the quality of the system's output, technical documentation, and an agreed way to report problems. |
| ongoingHandover and growth | Practice with the system on real tasks, handover of code and documentation, agreement on who watches for failure and how they would notice, and a plan for the next processes based on data from this one. |
The durations are indicative, and what usually stretches them is not engineering but data access and client-side decisions. What actually drives the cost is broken down in our piece on what an AI implementation costs.
Who decides what
Most projects that stall do not stall on technology. They stall because nobody has the authority to settle an argument about what the process should look like once it changes. So the split is agreed at the start:
- The process owner (on your side) — decides how the process should work, what counts as an error and what counts as an acceptable exception, and signs off the pilot. One named person, not a committee.
- Us — we design the solution and recommend which AI model (the engine behind tools such as ChatGPT) to use, how to build the whole thing and how the system should handle errors. You approve the choice of AI model provider, because that is also the choice of a sub-processor: a company we pass the processing of data on to (sub-processing). We are answerable for the system doing what we agreed and for it being maintainable after our work ends.
- Jointly — the success criteria, the scope of the pilot, the decision to go live in day-to-day work, and the decision to stop. We take none of those four alone.
When we will say it is not worth it
The fastest route to a wasted budget is applying AI where the problem is not an AI problem. We check the following in phase one, and if any of them holds we say so immediately — before invoicing for a build.
- The process is not stable. If five people do it five different ways and none of those ways is written down, there is nothing to automate yet. The process has to be agreed first, and that is organisational work, not software work.
- The data does not exist or cannot be reached. We check whether the data the process needs can be obtained — from an API (the interface other software uses to work with a system and its data), a file import, or documents such as email attachments. We also check whether the required actions can be carried out and whether the total cost is justified. If the decision history exists only in somebody’s head, it has to be written down first — we then say how much work that is and whether it pays off. If the data cannot be obtained, or the actions cannot be carried out, at a justified cost, we do not take the project on.
- The saving does not cover the running cost. Every AI system has a standing cost: using the AI model, ongoing checks that the system works, making fixes. If the process takes two hours a month, it is almost certainly not worth it — and that is better heard at the start.
- There is no process owner. Without someone to settle disputes, the project stops at the first disagreement about what counts as an error.
- Regulation rules the scenario out. The AI Act, the EU regulation on artificial intelligence, prohibits some uses of AI outright, and others require preparation whose cost changes the case for the project. That assessment belongs to your lawyer, before the build starts, not after; the AI Act technical compliance sprint then implements the duties they identify.
In each of those cases you get the reasoning in writing and, where one exists, a cheaper route to the same goal. Advising against a project costs both sides less than delivering one nobody uses.
What we need from you
- One person who knows the process and can authorise changes to it.
- Access to the data the process actually runs on — not a demonstration sample.
- A contact in IT for access, integration, and the security rules that apply in your organisation.
- Agreement that the pilot may end with “not worth it”. A pilot tests whether the implementation makes sense, so that answer must stay possible — otherwise it becomes a formality.
What we do not do
- We do not build models from scratch. For the overwhelming majority of business uses that is far more expensive and slower than an existing AI model with good software, rules and tests built around it.
- We do not run projects without a measurement phase. An implementation whose effect nobody measures cannot be defended at the next budget round.
- We do not give legal advice. We prepare the technical material a compliance assessment rests on; classification and interpretation stay with your lawyer. How data is shared and what we decide about it during a project is set out under security and GDPR.
Frequently asked questions
How long does an implementation take?
From the first conversation to a process running day to day, usually two to four months — and the time goes not into building but into data access and decisions on the client side. A pilot alone is typically two to four weeks. Anyone promising the whole thing in a fortnight is describing a demo, not an implementation.
Can we start with one process rather than an AI strategy?
Yes, and that is normally where we start. A strategy written before the first implementation rests on assumptions nobody has tested. Putting one process into day-to-day use produces hard numbers about what it actually costs and where your organisation’s bottleneck really sits — and that is what a plan for the rest should be built on.
What happens if the pilot does not work?
We stop at the pilot and you get a written account of what we learnt: where the AI model made mistakes, what condition the data was in, and whether the problem was the technology or the process itself. That is an anticipated outcome rather than a failed project — which is exactly why the pilot is a separate phase with its own decision, not a deposit against the build.
Who do we need to involve on our side?
One person who knows the process from the inside and has the authority to change it, plus someone from IT for access and integration. Without the first of those the project will not succeed — not for want of hands, but because there is nobody to settle what the process should look like once it changes.
Do we get the code and documentation, or are we locked in?
The code, the configuration and the documentation are yours, and we hand them over at the end of the implementation. We treat that as a condition of working honestly: if a support contract only makes sense because nobody else understands the system, that is not support, it is a lock.
How is this different from an ordinary IT project?
In two ways. First, an AI model may give different answers to the same question and sometimes gets things wrong, so from the start we plan what should happen when it does, instead of assuming it will not. Second, quality depends more on the data than on the code, so checking the data is a phase in its own right, not one item on a pre-project checklist.
Let’s start with one process
A free 20–30-minute call that ends with knowing which process makes sense to go first — or whether it is worth starting at all. Write or call, and we’ll reply with two time slots.
Last updated: