How long an AI implementation takes, and what really decides it

The phases, and where the time actually goes

An implementation has six phases and only one of them is engineering. Naming them separately is the first useful thing you can do, because a single number covering all six hides the phase that will slip. These are the phases inside the work itself, whoever does it, and not the same thing as the commercial stages a supplier bills against, which for Wobble are set out in how we work.

Ask any supplier to put dates against those six rather than against the project as a whole. The phase that slips is usually the second one, and the second one is mostly yours.

• Discovery. Walking the process end to end and listing every system it touches. Short if the process is documented, long if it lives in somebody's head.
• Access. Credentials, permissions and any platform approvals. Purely administrative, and frequently the longest phase in the entire project.
• Build. Connecting the systems, writing the logic, handling the exceptions. The part everybody pictures when they imagine the work.
• Testing against real cases. Running the awkward examples out of actual traffic rather than the tidy ones somebody invented for a demonstration.
• Pilot. A limited live run with a person watching, before anything gets trusted on its own.
• Handover. Documentation, training and agreeing who owns it. Skipped often, and the reason perfectly good systems get abandoned.

What you control that shortens it

Almost every lever sits on the buyer's side. That is uncomfortable and also useful, because it means the timeline is partly a decision you make rather than a fact you receive.

A business that arrives holding those finishes noticeably sooner than one assembling them while the work is under way, and the difference has nothing to do with which supplier was chosen.

• One decision maker, available, who can say yes without convening anybody else
• Credentials gathered before the build starts rather than requested during it
• The process written down, even roughly, by the person who actually does it
• Twenty or thirty real examples out of live traffic, including the messy ones
• A named owner on your side from the first week, not from the handover
• An agreed definition of done, written before the build, in one paragraph

What lengthens it, usually without warning

Delays rarely announce themselves in advance. Each of these has ended up on somebody's project plan in week four rather than week zero.

The last one deserves a rule of its own. Write down what the first release does and what it deliberately does not do. Additions then get scheduled rather than absorbed, and the first release actually ships.

• A system with no interface for software, discovered during the build rather than before it
• Platform approvals with their own queues. WhatsApp Business API messaging runs on templates approved in advance, so every message the system might send has to exist before it is needed.
• Procurement, legal or a security review that nobody mentioned at the start
• The one person who understands the process being on leave, or simply never free
• A peak season during which nobody will allow changes, which is entirely reasonable and should be planned around rather than argued with
• Scope that grows quietly, one small addition at a time, each of which genuinely was small

Estimate your own timeline before anyone quotes one

You can produce a usable estimate in an hour, and it will tell you more than a supplier's number, because you know things about your own business that they cannot.

Every no on that list is time, and it is time that exists whether or not anyone mentions it in a proposal. Fixing them before the project starts is the cheapest schedule improvement available to you, and the only one that costs nothing.

• Count the systems the process touches, then count how many you could get credentials for this week
• Ask whether the process is written down anywhere a stranger could read it
• Name the person who decides what a correct outcome looks like, and check they will be available
• Check whether any platform involved requires approvals that have their own waiting time
• Check your calendar for a freeze period nobody will move

Why the second workflow is faster than the first

The first build pays for things the second one inherits: the connections, the credentials, the conventions for logging and error handling, and the arguments about what correct means. The second workflow reuses all of it and starts halfway along.

There is a less obvious inheritance. Your own team learns what these projects need from them, which is mostly clear examples and a fast answer to a question about the process. No supplier can provide that, and it is often the whole difference between a project that felt slow and one that felt quick.

So the honest way to plan a programme is to treat the first workflow as its own decision with its own result, and to schedule everything after it using the number that first one produced rather than the number somebody estimated.

Timelines that should make you walk away, in both directions

A supplier promising a date before seeing your systems is guessing, and the guess will be optimistic, because optimism wins work. The date moves later, after you have committed and after walking away became awkward.

A supplier proposing many months for a single workflow is usually selling a programme rather than a build, or has not decided what the first release contains. Ask what ships first and what it deliberately leaves out. If nobody can answer that in a sentence, the scope is not agreed, and unagreed scope is what long projects are made of.

There is a third case, and it is not the supplier's fault. If your own answer to who decides and where are the credentials is a shrug, no timeline anybody gives you is real. Fix that first. It is free, and it is the largest single lever you have.

A published shape, and the phase nobody puts on the plan

One supplier's actual pattern, offered so the six phases above have something to sit against. Wobble publishes its stages rather than quoting a date: the audit takes the first week, one named system is live inside a fortnight, the second and third land across month two, and by around month six the pieces are connected and the reporting arrives without anyone assembling it. That pattern sits behind engagements published with their figures, including Quillon's delivery line rebuilt as a single audited automation with 94 units delivered in the first two months. The company works from Karachi, bills month to month and is answerable for what it runs across 25 engagements in six countries.

A published shape is only worth more than an estimate if somebody is accountable for it. Moiz Khan owns automation architecture and decides what gets built and how it runs, which includes saying during the audit that a build will take longer than the pattern rather than saying it in month three. Ibrahim owns build and workflows and trains your team as each piece lands, and that training is itself a phase most plans leave out of the schedule and then absorb into somebody's evenings.

There is a seventh phase that never appears on a plan and never ends. Every workflow needs a stop, and somebody on your side has to stand behind it. Anything published in your name, any change to spend, any pricing decision and any serious complaint wait for human approval, and a workflow that meets a case it was not built for hands it to a person with the record attached. Staffing that from week one is what turns a live system into an operating one. Skipping it is why a project that finished on time can still fail in month four.

The uncomfortable half of the article above is the accurate half. The levers are mostly yours: access granted in the first week rather than the third, a decision maker who is actually in the room, a process somebody is willing to write down. Where all three hold, the pattern holds. Where one does not, no supplier's schedule survives it, and it is better to hear that before a contract than to discover it in week four.

Common questions

How long does an AI implementation take?

It depends far less on the AI than on your systems and your decisions. A single workflow with documented steps, available credentials and one decision maker moves quickly. The same workflow in a business where the process is undocumented and access has to be requested from three people takes considerably longer, and the difference is administrative rather than technical.

What takes the longest in an AI project?

Access, usually. Credentials, permissions and any platform approvals have their own queues and their own gatekeepers, and none of that work is visible in a proposal. Discovery comes second when the process has never been written down, because mapping it is a phase of its own.

Can we speed it up?

Yes, and most of the levers are yours. Gather credentials before the build starts, get the process written down by the person who does it, name one decision maker who is actually available, and supply real examples from live traffic including the messy ones. Businesses that arrive with those finish sooner regardless of supplier.

Why do suppliers give such different timelines for the same thing?

Usually because they assumed different scopes. One has spotted a system with no usable interface and priced the time for it; another has not looked yet. Ask both what ships in the first release and what it deliberately excludes, and the timelines usually become comparable or one of them becomes indefensible.

Should we do everything at once or one workflow at a time?

One at a time, because the first build produces a real number for what the next one costs and how long it takes in your business specifically. It also teaches your team what these projects need from them. Committing to a full programme beforehand means scheduling against an estimate rather than against evidence.

How long before we see a result?

Sooner than the project finishes, if the first workflow was chosen well. A candidate with a readable measure, such as time to first response, moves within days of going live. If nothing observable has changed after a month of real use, the choice of task is the more likely problem rather than the build.