How to Estimate an AI Project
To estimate an AI project, classify it first as either model development or LLM integration, break the resulting scope into a phase-based work breakdown, estimate each piece of work as a three-point range rather than a single number, adjust that range for AI-specific complexity, add the cost layers beyond labor — infrastructure, licensing, and, for LLM-integration work, token cost — and present the total as a confidence range instead of one figure. We walk through that process below in six steps. The order matters as much as the arithmetic: skip the classification step, or collapse the range into a single number at the end, and the rest of the process produces a confident-looking guess rather than a defensible estimate.
Why a Single Number Isn't an Estimate
A single figure with a flat percentage tacked on answers "what do you think this will cost," not the question a steering committee actually needs answered — how confident is that number, and what happens if one of the assumptions behind it is wrong. Most AI project estimates fail for a structural reason, not an arithmetic one: they start from a point figure and bolt a buffer onto it, which hides exactly the information a sponsor needs to see. The six steps below are the basic version of the process that avoids that — a sequence we recommend following in order, every time, rather than reinventing it per project. For the deeper cost-structure breakdown underneath each layer — how model-development costs differ from LLM-integration costs, role-level rate tables, and token-pricing mechanics — see How to Estimate an AI Project Cost: Model Development vs LLM Integration.
Step 1: Classify the Project Before Estimating Anything Else
Before a single line item gets built, decide whether the project trains or fine-tunes a model from data, or builds application logic around an existing model consumed through an API. This one decision determines which effort drivers apply later, and which complexity adjustment belongs where — a non-linear complexity multiplier belongs on model-development effort; it does not belong on LLM-integration effort, which scales closer to linearly with scope. Skipping this step is the most common reason an AI estimate turns out wrong in structure, not just in size.
Step 2: Break the Scope into a Work Breakdown Structure
Once the project type is set, break the scope into phases and the discrete activities inside each one — discovery, data engineering, the model or integration build itself, testing, and deployment, at minimum. A phase-based breakdown does two things a single blended number cannot: it lets a reviewer see where the effort is actually going, and it gives every later adjustment — a complexity multiplier, a contingency reserve — a specific place to attach, instead of being guessed at the whole-project level.
Step 3: Estimate Each Work Package as a Range
For every activity in the breakdown, estimate an optimistic, a most-likely, and a pessimistic figure rather than one guess — the three-point input a PERT-based estimate runs on. This is the step most teams skip under deadline pressure, and it is the one that makes everything downstream possible: without three points per work package, there is no defensible way to produce a confidence range at the total-project level later, only a single number with an arbitrary buffer stacked on top.
Step 4: Adjust for AI-Specific Complexity
A model-development estimate built the way a standard software estimate would be — effort scaling roughly in proportion to scope — understates real delivery effort, because data quality problems, architecture complexity, and training-iteration cycles compound rather than simply add. At the basic level, this step is: don't skip it. Apply a complexity adjustment to the model-development phases specifically, not uniformly across the whole project, and treat it as a property of the work rather than a generic contingency line. What drives that adjustment in detail is its own subject; the point here is that leaving it out entirely is what turns a plausible-looking estimate into one that diverges from actuals within the first few months.
Step 5: Add the Cost Layers Beyond Labor
Labor is the largest cost category on most AI projects, but it is rarely the only one. Before the estimate is complete, add infrastructure and licensing costs — compute, MLOps tooling, software — and, for LLM-integration projects specifically, the ongoing cost of API token consumption at production volume, which behaves differently from a one-time build cost and needs its own line rather than living inside a general infrastructure figure. Close with a contingency reserve sized to whatever residual uncertainty the rest of the process hasn't already captured. None of these layers needs to be modeled in full depth to produce a usable basic estimate — each one needs a number against it, rather than being silently absent.
Step 6: Present the Total as a Range, Not a Single Figure
Roll the work-package ranges, the complexity adjustment, and the added cost layers up into P50, P80, and P90 figures — the most-likely case plus the two more conservative figures a sponsor uses for contingency planning and sign-off — instead of one blended total. Split the result between capital and operational expenditure as well, since a steering committee and a finance reviewer are answering two different questions with the same number: what does this cost, and which budget absorbs it.
A Worked Illustration
Picture a mid-sized organization scoping an internal document-search tool built on an existing LLM through an API. Classifying the project correctly as LLM integration, not model development, is what tells the team the complexity adjustment that would apply to a from-scratch model does not apply here — effort scales closer to linearly with the number of document types and query patterns in scope. The team breaks the work into phases, ranges each activity instead of guessing a single figure, and adds a token-cost line sized to expected query volume rather than treating it as a rounding error. The resulting estimate goes to the steering committee as a range, not a point figure, with the token-cost assumption called out explicitly instead of buried inside a generic infrastructure line. None of that requires deep expertise in any single layer. It requires following the six steps above in order, and not skipping the ones that feel optional under deadline pressure.
Keep the Estimate Honest After Approval
An estimate that is accurate the day it is approved and never revisited stops being accurate the first time scope, model choice, or usage volume shifts. We recommend logging every assumption behind the number — which project type was selected, which complexity adjustment was applied and why, which token-volume figure the LLM-integration line used — in a form that can be checked against reality as the project proceeds, not reconstructed from memory after a budget review goes badly. The six steps above produce a defensible number at the start. Revisiting the assumptions behind it is what keeps that number defensible six months in.
Where to Go Deeper
The six steps above are the basic process, and they are enough to produce a defensible estimate for most AI projects. Three pieces sit underneath them that this piece does not try to cover in full. The detailed cost-structure differences between model-development and LLM-integration work, role-level rate tables, infrastructure budget categories, and the token-cost mechanics behind Step 5's LLM-integration line are covered in the cost-estimation post linked above. The five-factor mechanics behind the AI-specific complexity adjustment in Step 4, including the composite multiplier formula and why it applies unevenly across project phases, are their own subject entirely. Each is worth reading on its own terms. The point of this piece is the sequence that ties them together into one process, not a shortcut around reading any of them.
The AI Project Estimation Model provides a confidence-ranged P50/P80/P90 cost and effort estimate across an 11-tab Excel workbook, built on a PERT-based three-point input method with a non-linearity multiplier for model-development complexity, a dedicated LLM token cost tab, and an automatic CAPEX/OPEX split — the six-step process above, built out in full.
→ Available at www.viksya.com