Software projects overrun by an average of 27% — and AI projects routinely do worse (McKinsey & Company, 2012, still the most cited large-scale study). The reason isn't that engineers are bad at their jobs. It's that AI work has a category of uncertainty that standard software estimation methods are not designed to handle: you don't know what the data looks like until you see it, and you don't know if the approach works until you've tried it.
The answer isn't to add bigger buffers or be vague with clients. It's to decompose AI projects into units that can actually be estimated, name the risks explicitly, and communicate estimates in a way that builds trust when things change — because they will.
This guide covers the estimation approach we use at Prodinit for AI development engagements, including the five traps that catch almost every team at least once.
how we structure AI consulting projects end-to-end
Key Takeaways
- AI projects overrun by an average of 27% (McKinsey, 2012) — with model iteration and data uncertainty adding variance not present in standard software
- Decomposing AI work into 5 task types — data, model, integration, evaluation, and deployment — gives you estimable units with known variance ranges
- Named uncertainty beats false precision: "2–4 weeks depending on data quality" is a better estimate than "3 weeks" that becomes 6
- Buffer should be earned by risk, not added arbitrarily — tie every buffer to a specific named risk
Why Is AI Timeline Estimation Harder Than Software Estimation?
Machine learning and AI tasks take two to four times longer than equivalent-complexity software engineering tasks because of a category of work that doesn't exist in regular software: the experimental loop (Sculley et al., "Hidden Technical Debt in Machine Learning Systems", NeurIPS 2015). In software, you write a function, it either works or it doesn't, and the fix is usually local. In AI, you train a model, evaluate it, discover it underperforms on a subset, retrace through data preprocessing, and iterate — often multiple times before the approach is validated.
This experimental loop is invisible in most timeline estimates because engineers estimate the happy path: data is clean, the model converges, integration goes smoothly. In practice, each of these assumptions fails with enough regularity to blow the timeline.
Three estimation errors account for the majority of AI overruns:
Estimating model training time as a fixed cost. Model training is iterative. The first training run surfaces problems that require data fixes, which require another run, which surfaces architecture problems, which require another run. A "train the model" task that appears to be 3 days of compute time routinely involves 3–6 full cycles.
Not estimating data work separately. Data cleaning, validation, schema normalisation, and pipeline building are estimated as a preamble to "real work." In practice, they're often 40–60% of total project time on data-heavy AI engagements.
Forgetting evaluation and iteration time. Getting a model to train is different from getting it to meet performance thresholds. Evaluation, failure analysis, hyperparameter tuning, and retraining cycles are frequently omitted from initial estimates.
How Do You Decompose AI Work Into Estimable Units?
Teams that use formal estimation techniques are significantly more likely to deliver within 10% of their deadline than teams using informal gut-feel estimates (Planview State of Project Delivery Report 2023, 2023). The key is decomposing AI work into task types with known variance — not individual tasks, which are too granular to estimate reliably at project outset.
The Five AI Task Types
| Task Type | Typical Duration | Variance Driver |
|---|---|---|
| Data audit & profiling | 2–5 days | Schema complexity, access issues |
| Data pipeline (cleaning, transforms) | 3–10 days | Data quality, volume, format diversity |
| Model development | 3–8 days per iteration | Approach novelty, dataset size |
| Evaluation & iteration | 2–4 days per cycle | Success criteria clarity |
| Integration & deployment | 3–7 days | Existing system complexity |
For each task type, estimate a range, not a point. "Data pipeline: 3–8 days" is more honest and more useful than "data pipeline: 5 days." The range communicates the variance directly and gives the client a realistic best/worst case.
Estimate by Phase, Not by Feature
Never estimate an entire AI project as a single number. Break it into phases:
Phase 0 (Discovery): Fixed. Discovery is scoped work with a defined deliverable (a delivery plan). It's always estimable because you're defining, not building.
Phase 1 (Data & Infrastructure): Estimate with range. The highest-variance phase. Estimate wide: "3–7 weeks depending on data quality confirmed in discovery."
Phase 2 (Model Development): Estimate with iteration budget. "2 model development iterations at 1 week each, with one additional iteration in reserve." This makes the iteration budget explicit.
Phase 3 (Integration & Deployment): Estimate tightly. Once the model exists, integration has standard software variance. This phase is estimable to within ±20%.
On our model distillation engagement — GPT-4.1 to fine-tuned GPT-4o-mini — the data pipeline phase was estimated at 3–5 weeks. It ran to 4.5 weeks because of deduplication work on near-identical training examples we hadn't anticipated. Because the range was communicated upfront, the client wasn't surprised. If we'd said "3 weeks" flat, we'd have had a difficult conversation.
our LLM model distillation case study
What Are the Five Most Common AI Timeline Traps?
Experienced AI teams hit the same estimation traps repeatedly. Naming them explicitly in your project planning process prevents them from appearing as surprises mid-delivery.
Trap 1: Assuming Data Exists in the Format You Need
Clients describe their data as "in a database" or "in our system." What they mean is: data lives somewhere accessible to them, in a format that makes sense to them, with quality that seems fine for their daily operations. What you'll find: nested JSON with inconsistent schema across years, missing labels, duplicates, and fields that were deprecated but not removed.
The fix: Require a data sample — real production data, not a sanitised demo — as part of contract signing, before any development begins. A 1,000-row sample reveals 80% of the data problems you'll encounter.
Trap 2: Counting Training Time as Wall-Clock Time
GPU training jobs are measured in hours. But model development time is measured in iteration cycles: train → evaluate → identify failure modes → fix data or architecture → retrain. A model that trains in 4 hours may require 6 full cycles before it meets performance thresholds. That's not 4 hours of work. It's 2–3 weeks of engineering time.
The fix: Estimate in iteration cycles, not training hours. Budget at least 3 cycles per model component. State this explicitly in your timeline: "3 training iterations (1 week each) to reach target accuracy."
Trap 3: Forgetting the Evaluation Framework
"We'll know when it works" is not an evaluation framework. It's a recipe for indefinite iteration. Without pre-agreed success criteria — accuracy thresholds, latency targets, failure mode budgets — every demo becomes a negotiation about whether the model is "good enough."
The fix: Define success criteria in discovery, in writing, before development begins. "Precision ≥ 0.85 on test set, p95 latency ≤ 200ms, hallucination rate ≤ 2% on evaluation set." When the model meets these, the phase is done.
Trap 4: Underestimating Integration Complexity
AI models don't exist in isolation. They connect to existing systems — APIs, databases, authentication layers, logging pipelines. Integration complexity is often dismissed as "just wiring it up." In practice, integration is where latent technical debt in the client's existing stack becomes your problem.
The fix: Map integration points explicitly in discovery. For each dependency on the client's existing system, note: who owns it, what the API contract is, and whether it's documented. Undocumented dependencies add 2–5 days each.
Trap 5: Not Accounting for Client Review Cycles
Every deliverable goes through a client review cycle. For AI systems, reviews are slower than for standard software because stakeholders who aren't technical need time to evaluate outputs and form opinions. A model demo that you expect will take 30 minutes to approve may sit in review for a week while the client runs it past their team.
The fix: Build client review time into your timeline explicitly. For each major deliverable, add 2–3 business days for client review before the next sprint begins. State this in your milestone plan so it's visible, not hidden.
Review delays are the only timeline risk that's entirely outside your control — and they're underestimated almost universally. In our delivery tracking across multiple engagements, client review cycles averaged 3.2 days per major deliverable. Over a 10-week project with four major deliverables, that's nearly two full weeks of calendar time that doesn't appear in most timelines.
How Do You Communicate Timeline Estimates to Clients?
Named uncertainty communicates more confidence than false precision (PMI Pulse of the Profession, 2024). A client who hears "3–5 weeks depending on data quality" and then receives delivery in 4.5 weeks experiences you as reliable. A client who hears "3 weeks" and receives delivery in 4.5 weeks experiences you as over budget — even if the actual work was identical.
The communication pattern that builds trust:
Lead with the phase range, not the total. "Phase 1 will take 2–4 weeks depending on what we find in the data audit" is more credible than "the project will take 10 weeks." Ranges per phase are earned by analysis. A total project estimate without phase-level detail is a guess dressed as a plan.
Name every assumption explicitly. "This estimate assumes: (1) client provides production data sample by day 3, (2) model performance threshold is ≤ 5% accuracy from baseline at end of Phase 1, (3) deployment environment is a standard AWS setup." Assumptions become the basis for timeline revision conversations when reality diverges.
Update estimates at the end of each phase, not only when things go wrong. A post-phase estimate update — "Phase 1 completed on the high end of range at 3.8 weeks; Phase 2 revised to 3–5 weeks based on data findings" — positions you as proactively managing the timeline, not reacting to overruns.
How Do You Build Buffer Without Inflating Proposals?
Arbitrary padding — "add 20% to every estimate" — doesn't work because it's uniform. Risks in AI projects are not uniform. Data pipeline risk is high; deployment risk is relatively low. Uniform buffer protects the wrong things and makes your proposals look inflated to experienced clients.
Risk-linked buffer is more defensible and more accurate:
For each phase, identify the top risk and size the buffer to that risk:
- Data dependency on client: +3 days. Reason: access or quality issues require client action.
- Model convergence uncertainty: +1 week per iteration cycle beyond the first.
- New technology or integration: +2–4 days. Reason: unknown unknowns in unfamiliar systems.
- Client review cycles: +2 days per major deliverable.
When presenting a timeline, you can show the base estimate and the buffer separately with their rationale. This is more credible than a single inflated number — and it tells the client exactly what risks you're managing.
Estimation Is a Skill, Not a Formula
There's no formula that produces reliable AI project estimates. There's a practice: decompose work by type, name the risks, communicate ranges not points, and update estimates at phase boundaries rather than only when things go wrong.
The goal isn't to predict the future. It's to build a client relationship where changes in timeline are collaborative conversations, not broken promises.
how we structure and manage AI consulting engagements
At Prodinit, every engagement starts with a fixed-price discovery phase that produces a timeline you can actually commit to. Book a 30-minute scoping call if you want a second opinion on an estimate you're not confident in.
Frequently Asked Questions
Buffer should be tied to specific risks, not applied uniformly. A practical rule: 15–20% buffer on data pipeline phases (high variance), 10% on model development phases (medium variance), and 5% on integration/deployment phases (lower variance). Total buffer across a project typically runs 15–20% of raw estimate for well-scoped engagements.
Price and scope a discovery phase first, and commit only to the discovery timeline. Discovery's output — a data audit, defined success criteria, a milestone plan — is what makes the delivery timeline estimable. Estimating delivery before discovery is guessing with client money.
Communicate early, not at the deadline. The moment you know an estimate will slip — even if it's a week out — send a written update with the revised timeline, the cause, and the mitigation. Early bad news is recoverable. Deadline-day bad news is a relationship problem.
For complex AI projects, yes — especially in the proposal stage. "Best case 8 weeks (data is clean, model converges in two iterations). Most likely 11 weeks. Worst case 14 weeks (data requires significant cleaning, additional model iteration)." This format is common in professional services and signals estimation maturity.
LLM-based projects (prompt engineering, RAG, fine-tuning) have different variance than custom model development. Fine-tuning is the most predictable (known training pipeline, known data format). RAG has high variance in retrieval quality. Prompt engineering has low timeline variance but high quality iteration variance — you'll finish on time but may not hit quality targets without more iteration budget.