The Realistic Timeline for an Enterprise AI Project

5 min read · updated August 3, 2026

Published timelines for enterprise AI projects are useless to you, because the durations that dominate them are properties of the organisation rather than of the work. The transferable thing is not a number of weeks; it is a method for deriving your own from queues you can measure this afternoon.

Why the estimate is wrong in one direction

Ask an engineering team how long the build takes and you will get a reasonable answer about building. Then the project takes three times that, and the difference is not underestimation of the work. It is that the estimate covered the only part the estimator controls.

Two structural reasons this is worse for AI projects than for ordinary software. First, they cross more organisational boundaries per unit of functionality: a small feature can require a vendor contract, a security review, a data processing agreement, a budget approval and a data access grant, each owned by a different function with its own queue. Second, several of the phases produce information rather than software — an evaluation result, a measured cost, a decision — and information phases cannot be compressed by adding engineers.

The failure is therefore predictable and one-directional, which is useful: it means the correction is a systematic addition rather than a contingency percentage.

There is a second-order effect worth planning for. Because the slippage lands on the phases that produce information rather than software, the usual response to a late project — cut scope — makes the schedule worse rather than better. Dropping the evaluation, shortening the baseline or skipping a rollout stage removes the evidence the project was supposed to generate, and a project that arrives on time with no evidence has to be redone. The things that genuinely compress are the build and the feature set. The things that look compressible and are not are the measurement window and the queues.

Work time and queue time

Split every phase into two quantities that behave completely differently.

elapsed = SUM(work_i)  +  SUM(queue_j)

work    days of effort by people you can talk to. Shrinks
        with more people, up to a point. This is what the
        estimate covered.

queue   calendar time waiting for a decision, an approval,
        a signature, a meeting slot, a budget window or
        another team's sprint. Does not shrink with more
        people. Frequently the larger term.

The important property of queue time is that it is measurable in your own organisation and nobody measures it. Pull the last five vendor security reviews and record the elapsed days from submission to decision. Do the same for the last five DPA negotiations, the last five data access requests, and the last five purchase orders above whatever threshold triggers extra approval. That is an afternoon of work and it produces the only numbers in this whole exercise that are actually about you.

Expect the distribution to be wide and skewed. Plan with something like the 75th percentile rather than the median: the median tells you what usually happens, and a project schedule is a promise about a specific instance, most of the risk of which lives in the tail.

The phases, and the question that ends each

Phases are worth defining by the question they answer, because a phase with no exit question runs until someone gets impatient.

Phase	Description
select	Ends when: one use case is chosen and scored, with a named owner on the receiving side. Mostly work time, and short — a scoring rubric applied to a list is days, not weeks, unless it is being used to avoid a decision.
assess data	Ends when: you know whether a competent person could do the task from the data the system would retrieve. A week of work, plus queue time waiting on access to the systems involved — which is usually the longer half.
procure and review	Ends when: the vendor is contracted, the DPA is signed, and the security review has a decision. Almost entirely queue time, largely outside your control, and the phase most often started far too late.
build and evaluate	Ends when: the evaluation on a frozen set clears the pre-registered threshold. Mostly work time. This is the phase everyone estimated and it is usually the estimate that was closest to right.
measure	Ends when: the measurement window closes. A fixed calendar duration by construction — a four-week baseline plus a measured period is eight weeks whatever the team size, and no amount of urgency shortens it.
roll out	Ends when: the last stage's exit criteria are met. Duration is set by the stage gates rather than by the work, plus queue time for training sessions and change windows.
fund production	Ends when: the money exists in a line somebody owns. Pure queue time, and the queue is an annual cycle rather than a review board, so missing it costs months rather than weeks.

The worksheet

One table, filled with your own measured queue times. The numbers below are placeholders, deliberately — the exercise is to replace every one of them.

phase              work   queue  queue owner        start early?
select              5d      0    us                  -
assess data         5d     ?d    system owners       yes
procure + review   10d     ?d    legal, security     YES - day 1
build + evaluate   25d      0    us                  after access
measure             0d     40d   the calendar        after build
roll out           10d     ?d    the teams           staged
fund production     2d     ?d    finance cycle       YES - day 1

elapsed  =  critical path through this table,
            NOT the sum of the work column

The two rows marked YES are the ones that decide the date.

Fill the question marks from your own history and the shape of the project appears immediately: for most organisations the procurement and review row is the single largest term, and it is also the row that can begin on the first day of the project, because everything it needs — a data-flow page, a use-case description, a candidate vendor — exists before any code does. Starting it in week one rather than after a successful pilot is typically worth more calendar time than every engineering decision in the project combined.

The funding row deserves the same treatment for a different reason. It is not a duration but a date: the budget window opens when it opens. Work backwards from it, and if the project cannot produce its decision before that date, either change the scope so it can or accept explicitly that production is a year away — which is the sixth field of the pilot charter and the reason it is in there.

Three things you cannot parallelise

Access before evaluation. A meaningful evaluation needs real examples, which need access to real data, which needs the review. You can build against synthetic data in the meantime, and you cannot conclude anything from it — the frozen set has to be real, or it is measuring your imagination.
Baseline before treatment. The measurement window is calendar time that cannot be bought. If nobody was measuring the metric before, the baseline starts when you start collecting it, and starting collection is therefore something to do in week one even though it produces nothing visible for a month.
Stages before stages. A staged rollout is serial by design: each stage answers a question the previous one could not, so compressing it removes the information rather than the time. The one legitimate accelerant is to shorten a stage whose exit criteria are already met, which is why the criteria are numeric.

Everything else is parallelisable and most of it should be. Run the security review, the data access request and the build at the same time. Start the baseline collection during selection. Shortlist vendors before the evaluation finishes, because the contract queue is longer than the decision. The realistic timeline for an enterprise AI project is not a number somebody else can give you — it is the critical path through your own queues, and the only way to shorten it is to enter them earlier.