Guides

How long does AI implementation take?

Rebuilding one well-chosen process can go from kickoff to live in 30 days: a week to map it, two weeks to build and test it on live work, and a week to train the team and switch over. Firm-wide programmes take far longer. Duration depends mostly on scope, access and how quickly decisions get made.

Why do estimates vary so widely?

Because "AI implementation" covers very different projects. A firm-wide programme that assesses every department, selects a platform, writes policy and trains everyone runs for many months, and often ends with a roadmap rather than a working change. Rebuilding one process, end to end, is a much smaller piece of work with a clear finish line: the job is done the new way, by the people who do it, on live work.

So the first question is not how long, but how much. The narrower the scope, the shorter and more predictable the timeline. A single process with a defined output, a known set of inputs and a named owner can be planned to the week.

Where does the time actually go?

Across a 30-day rebuild, the weeks break down like this.

Week 1, map it. Sit with the people who do the job. Record every input, template, handoff and check, and find where the hours go. This is where hidden steps come to light: the spreadsheet someone keeps on the side, the check a senior person always does, the client who wants things differently.
Weeks 2 and 3, build it. Build the new process on the firm's own documents, templates and language, in the tools the team already uses. Test it on live work, not a demonstration, and adjust it as real cases expose gaps.
Week 4, go live. Train the team on the new way and make it how the job is done, rather than an option alongside the old way.
Then 30 days of support. Fix the small problems that only appear with daily use, and help the new way bed in.

The full sequence, including what happens at each handover, is set out in how we work.

What slows an implementation down?

Very little of the delay in these projects is technical. The common causes are organisational, and most can be dealt with before kickoff.

Waiting for access. Accounts, permissions and sample documents that take a fortnight to arrive can consume half the calendar. Sort them out in the first days.
The owner has no time. If the person responsible for the process is also the busiest fee earner, decisions queue up behind client deadlines.
Undecided standards. When partners disagree on what the finished document should contain, the build stalls until someone decides.
Scope that grows. "While you are at it" requests turn one process into three. Keep a list of the next candidates instead and deal with them later.
Sign-off loops. Security, data protection or partner approval that happens at the end rather than the start can add weeks. Raise it in week one.

What does the firm need to have ready?

A short list, and most firms already have it.

A named owner for the process, with a little time each week.
Access to the people who do the job during the first week.
A set of recent real examples of the output, good and bad.
The templates, precedents and guidance the team currently uses.
Someone who can grant access to the systems the process draws on.
A decision on who reviews and signs off the output before it goes to a client.

Preparing for your call covers the details, and documenting a process helps if you want to get ahead on mapping.

Why is longer not safer?

It is tempting to think a longer project is a more careful one. In practice, long timelines tend to hurt adoption. The people who took part in mapping have moved on to other matters by the time anything is built. The examples used for testing are months old. Enthusiasm fades, and the eventual launch meets a team that has stopped expecting it. A short, fixed window keeps attention on one job and forces decisions to be made while they still matter. The ways drawn-out projects tend to stall are covered in why AI rollouts fail.

How does "live" differ from "delivered"?

A project is delivered when the provider hands something over. It is live when the team uses it as the normal way to do the job, on real client work, without being reminded. Only the second counts. When you compare timelines, ask each provider which of the two their date refers to, and what happens if the first live use slips. Doing it with your own staff instead brings a different set of timing trade-offs, set out in consultant or in-house.

To see which process would be the right first rebuild for your firm, take the audit. It takes about three minutes.

Questions people ask

Can it be done faster than 30 days?

Sometimes a simple process could be built faster, but the calendar is rarely set by the build. The team has to be available for mapping, the process has to be tested on real work, and people need time to switch. Compressing those steps is how rollouts end up unused.

What happens if it overruns?

With a fixed fee, the risk of an overrun sits with the provider rather than the firm. Under our terms, if the process is not live in 30 days, the firm does not pay. Ask any provider in writing who carries the cost of delay.

How much of our team's time does it need?

Most in the first week, when the people who do the job walk through how it really works. After that, a few short sessions to test drafts on live work, then training in the final week. The owner of the process needs a little time every week throughout.

When does the firm see the benefit?

From the first live use, which is the point of testing on real work rather than demonstrations. The time saved per job shows up straight away. The full effect across the team builds over the support period as the new way becomes routine.

More in guides

All guides

Which job is costing your firm the most?

Ten questions, about three minutes. You see the hours and the cost before you speak to anyone.

Find out which job is costing you most