Why do estimates vary so widely?
Because "AI implementation" covers very different projects. A business-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 with confidence once it has been scoped.
Where does the time actually go?
Whatever the length of the project, the time goes into the same stages, and the size of each one is what sets the calendar.
- Scoping. 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 supplier or customer who wants things differently. The more variations a process has, the longer this takes, and the timing for the rest of the project is set here.
- Build. Build the new process on the business's own systems and documents, in the tools the team already uses. Every extra system it has to read from or write to adds work, as does every template or exception it has to handle.
- Parallel run. Run the new system alongside the current process on live work, so the team can compare the two and real cases expose any gaps. A process that runs often produces evidence quickly; one that runs monthly needs longer to prove itself.
- Go-live. The new way becomes how the job is done once your team signs it off, rather than an option alongside the old way. How quickly that sign-off comes depends on who has to give it.
- Support. Support continues under the subscription, fixing the small problems that only appear with daily use and helping 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 the build starts.
- 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 person in the team, decisions queue up behind other deadlines.
- Undecided standards. When managers disagree on what the finished output 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 management approval that happens at the end rather than the start can add weeks. Raise it at scoping.
What does the business need to have ready?
A short list, and most businesses already have it.
- A named owner for the process, with a little time each week.
- Access to the people who do the job during scoping.
- 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 out.
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 tightly scoped project 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 work, without being reminded. Only the second counts. When you compare timelines, ask each provider which of the two their date refers to, what the estimate is based on, 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 business, run the audit. It takes about three minutes.