The AI project roadmap: discovery to production, phase by phase

Why phases and gates

AI projects have an unusual failure shape. Progress is fast at the start, because a model can produce something impressive in an afternoon. Then it slows, because turning that into a reliable system means confronting data quality, edge cases, security and adoption. Teams that treat the demo as most of the work are surprised; teams that know the shape plan for it.

Gates make the shape explicit. Each one asks a question that can be answered with evidence, not enthusiasm: Is the scope written down with a baseline? Does the evaluation set pass the target? Has security signed off? Are people using it? If the answer is no, the project does not move, and that is a feature.

The roadmap

Phase 1: discovery (2–3 weeks)

Discovery turns an idea into a scope with a number attached. It is short because its job is to decide, not to design everything.

Activities. Interviews with the people who do the work today. A look at the real data, not a description of it. A review of what already exists in the organisation. Identification of the regulations and security requirements that apply, including whether the use is high-risk under the EU AI Act.

Deliverables. A one-page scope: the user, the task, the data source, what is out of scope. A baseline: how the task is done now, how long it takes, how often it goes wrong. A first evaluation set of real cases with known good answers. A risk register and a cost estimate for the pilot.

Gate. The sponsor signs the scope and the baseline. If the baseline cannot be measured, the project is not ready, however good the idea.

Phase 2: pilot (4–8 weeks)

The pilot builds the thinnest system that can be evaluated against the set from discovery and used by a small group of real users. It is not a demo; it runs on real data with real inputs.

Activities. Data access and preparation, which usually takes longer than expected. Building the retrieval, prompting or model pipeline. Weekly evaluation runs, with the set growing as users find cases it missed. A simple interface for the pilot group.

Deliverables. A working system in a test environment. Evaluation results against the target agreed in discovery. A log of failure cases and how they were addressed. A short write-up of what production will need that the pilot did not have.

Gate. The evaluation target is met on the current set, and pilot users say they would use it. Our evaluation guide explains how to set that target so it means something.

Phase 3: hardening (4–6 weeks)

Hardening is the phase most often skipped, and its absence is the most common reason a pilot never becomes a product. It converts something that works into something that can be trusted and run.

Activities. Access control enforced at the data layer. Logging, monitoring, cost attribution and alerting. Evaluation turned into regression tests that run on every change. A security review against the LLM security checklist, with a red-team pass if the system takes actions. A runbook, a support path and a kill switch. Performance and cost tuning.

Deliverables. A production-ready deployment, a security sign-off, a runbook, and a monitoring dashboard somebody actually watches. The LLMOps and monitoring page describes what that looks like.

Gate. Security sign-off and an owner for operation. Not "we will add that later".

Phase 4: rollout (2–4 weeks)

Rollout is about people. The system is ready; the question is whether the organisation adopts it, and whether the baseline moves.

Activities. Staged release to user groups. Training that fits into the working day, not a course. Feedback channels that feed the evaluation set. Measurement against the discovery baseline.

Deliverables. Adoption and outcome metrics against the baseline. A first ROI figure with its assumptions written down. Handover of ownership to the team that will run it.

Gate. The adoption target agreed in discovery is met, and the result is reported to the sponsor in the same terms as the baseline.

Phase 5: operate

Production systems built on models drift. Providers update models, documents change, users find new ways to ask. Operation means someone owns the evaluation set, reviews a sample of outputs, watches cost and quality trends, and has a process for model upgrades that runs the regression tests first. Budget for this from the start; it is typically a fraction of the build cost per year, but it is not zero. Our fine-tuning and evals service often runs this layer for clients.

Phases, deliverables and gates at a glance

Two threads through every phase

Evaluation starts in discovery as fifty real cases and grows every week. It is the pilot's definition of done, hardening's regression suite and operation's early-warning system. Projects that build it late never catch up. See evals.

Security starts in discovery as a list of requirements, becomes controls in hardening and becomes monitoring in operation. Guardrails added at the end are always weaker than constraints designed in at the start, because the architecture has already decided what is possible.

Why pilots stall

Each of these is prevented by a gate in this roadmap. That is why the gates exist. How we run them with clients is described in how we work, and the AI CTO playbook shows where a first project sits in a wider 90-day plan.

Key takeaways

• AI projects are fast at the start and slow in the middle; plan for the shape.
• Five phases, four gates, each gate answered with evidence.
• Discovery must produce a written scope, a measured baseline and a first evaluation set.
• The pilot is done when the evaluation target is met, not when the demo impresses.
• Hardening is not polish; it is what makes the system runnable and trustworthy.
• Rollout is about adoption and the baseline moving; measure it.
• Budget for operation: models drift, documents change, someone must own the evaluation set.

Related services