How Long AI Implementation Actually Takes

The ranges, by project type

Timelines cluster by complexity far more tightly than by anything else. Broadly:

• Simple automations — 4 to 8 weeks. Document handling, support triage, internal search, scheduled report generation.
• Medium complexity — 2 to 4 months. Lead scoring, sales forecasting, recommendation logic, multi-step workflow automation.
• Complex ML systems — 12 to 18 months. Custom models, anything requiring training on proprietary data at scale.
• Enterprise-wide programmes — 6 to 12 months on average, though this is an average across very different things.

Project type predicts duration better than company size

This is the most useful and least intuitive finding. People assume a bigger company means a longer project. It is a weak predictor. So is budget, and so is industry.

What predicts duration is what you are building. A simple automation at a 2,000-person company and at a 10-person company land in roughly the same range, because the technical work is the same and the extra organisational overhead is smaller than people expect. Conversely, a small business attempting a custom model will not get it done in six weeks because it has fewer approval layers.

The practical use of this: when someone quotes you a timeline, the question that tests it is what category the work falls into, not how big your business is.

Sequencing for early proof is a scoping decision, and it is one of the outputs of an AI consultation — the roadmap comes ordered, not just listed.

Data preparation is 40 to 60% of the schedule

This single factor is the largest driver of the total, and it is the one most often left out of optimistic estimates. Between 40 and 60% of a typical project is consumed by getting data into a usable state — extracting it, reconciling formats, deduplicating, deciding which system is authoritative when two disagree.

It is also the least visible phase. Weeks two through five can produce nothing a stakeholder can look at, which is exactly when a project feels like it is failing. Naming this at kickoff — that there is a stretch with no demo and it is normal — prevents most of the mid-project panic.

It follows that anything you do to improve data quality before the engagement starts comes directly off the timeline. That is the practical payoff of a readiness assessment.

What actually makes timelines slip

Slippage is rarely the build. It is almost always one of a short list of predictable things.

• Access delays — waiting on credentials or an IT ticket to reach a system. Often weeks, and entirely avoidable.
• Scope drift — the demo prompts three good ideas, all of which get added without extending the timeline.
• Undocumented exceptions — the process turns out to have edge cases nobody mentioned because they are handled by habit.
• Approval gaps — one decision-maker on holiday stalls a phase.
• Integration surprises — an API that is rate-limited, deprecated, or does not expose the field the design assumed.

What can realistically be live in 30 days

More than people expect, if the target is chosen for speed rather than impact. A single well-defined automation on a process with clean data and API access can be running inside a month. So can a voice agent handling a narrow call type, or automated routing and follow-up on inbound leads.

What cannot: anything requiring a custom model, anything touching a system without an API, and anything where the process rules still need to be agreed. If a proposal promises those in 30 days, the estimate has not been thought through.

Sequence for early proof

Given that data preparation dominates and that sponsorship fades, the sequencing conclusion is clear: build the smallest genuinely useful thing first, even if it is not the biggest opportunity.

An automation live in week five that saves six hours a week does something a larger roadmap cannot — it converts the project from a cost into a demonstrated return while there is still budget and attention. The bigger builds get funded by the credibility of the small one. Reversing that order is how a technically sound programme dies in month four with nothing shipped.