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.
