Plan the build
AI implementation roadmap: the first build and what comes next
An AI implementation roadmap connects a business goal to the work needed to reach it. It should show what you will build first, how people will use it and what a later project could reuse. For service firms and large teams, that means planning beyond launch while keeping the first commitment clear.
Keep the wider ambition visible. Deliver one useful workflow, then use its results to decide the next investment.
Give the first build a place in the wider plan
Imagine a service firm that wants to offer ongoing planning help to more clients. Its first build turns one type of request into a plan an expert approves. Later, it may add progress reviews using those plans.
A large business might begin with one region, then bring the same expert support to others. The next region may share the methods but need different access rules or local checks.
These are possible routes, not promised results. Write down what the first build must achieve on its own and what later work it could support.
A six-stage AI implementation roadmap
This invented example covers one agreed workflow over 90 days. The dates show a possible order, not a schedule for every organisation. Access delays or a different scope change the plan.
| Stage | Work and responsible people | What must be true before moving on |
|---|---|---|
| 1. Understand the work — days 1–15 | Delivery team and builder map requests, decisions and delays. Agree the future process. | The first workflow, success measures and human decisions are clear. |
| 2. Prepare the information — days 10–30 | Record owners and technical teams connect approved sources and set access rules. | Current records can be used, client separation is checked and updates have an owner. |
| 3. Build the workflow — days 25–50 | Builder joins the request, planning, review and approval steps. Experts check examples. | The whole job works for agreed cases, including asking for help. |
| 4. Test beside current work — days 45–65 | Users and experts compare results, effort and difficult requests. | The agreed quality and access checks pass; failures have a safe way to stop. |
| 5. Start limited use — days 60–80 | Service owner introduces it to the first users with training and support. | People can complete the work, get help and return to the old process if needed. |
| 6. Hand over and review — days 75–90 | Builder and service owner agree support, ownership and the review routine. | The agreed workflow is working; the next investment has a clear evidence requirement. |
Some stages overlap. A date alone does not approve a release. If a permission check fails, resolve it before the affected work goes live.
Build your implementation roadmap
Build the connections the work actually needs
Follow a request from arrival to a result someone uses. List the records, rules and people involved. This shows which systems need to talk to each other.
For our example, that might include client agreements, current goals and approved plans. Document what each field means and who can change it. A later project can then use the same records without guessing.
In a large business, ask early which systems and approval processes the build must fit. Agree how to handle local differences. You do not need to connect every system before delivering the first workflow.
Make the decision to go live explicit
The owner of the service must see the test results and know how to pause the system. Include the people responsible for access and support in that decision.
Worked example
A decision to hold the release
Invented example. No actual test has been run.
Workflow: draft client plans for expert approval.
Proposed release: a limited group of named users.
Decision: HOLD.
Reason: the test can retrieve an old agreement without warning.
Action
The records owner marks the current agreement.
The builder changes retrieval and adds an old-version test.
The expert reviewer checks the new results before release is reconsidered.
Required before release
Correct client access, current sources and approval before sharing.
Users trained, support contact named and manual process available.
Later expansion
Add another type of plan only after reviewing real use and support effort.
Existing records may help; new rules and tests still need to be agreed.
Make room for people to change how they work
Give users time to practise real tasks. Show them how to check an answer, report a problem and handle a request the system cannot finish.
Keep the existing process available during the agreed transition. Track why people avoid the new one. The cause may be a missing source, a slow approval step or a task it does not yet support.
Agree who updates records, supports users and pays ongoing costs. Those jobs continue after the first build is delivered.
How our workshop and implementation fit together
Our AI Strategy Workshop helps you compare ideas and choose the first workflow. We map the work in detail, plan the new process and prepare the data as part of the build project.
Our delivery promise covers one agreed workflow, built and working in 90 days or less from the start of the build project. It includes studying the work and teaching your team how to use the system. Changing the wider business takes more projects and choices.
Clients own the code we write for their business and can run it with another host. We keep ownership of the shared tools we use across projects. Clients can keep using those tools within their system without an ongoing licence fee.
We also offer support, changes and advice through a separate agreement. We agree what is needed for the system you will run.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.