The 5 Phases of an AI Consulting Engagement (Timeline Walkthrough)

A modern AI consulting engagement runs through five phases with predictable shape. Per industry analysis from firms like WhiteHat SEO and Wednesday Solutions, "leading AI consulting firms follow a structured four to five-phase engagement model, with discovery spanning 1-3 weeks." Skip any of them and the engagement either misses the target or ships a system the customer can't operate. This article is the week-by-week walkthrough — what each phase produces, what it actually feels like, and the failure modes when one gets shortchanged.

Phase 1: Discovery (Week 1, sometimes 2)

What happens: Stakeholder interviews, data inventory, existing AI inventory, constraint mapping. Workshops with the people who'll use, supervise, or maintain whatever gets built.

Output: A written scope document that names exactly what gets built and what success looks like.

Common pitfall: Stopping at "comprehensive analysis" without naming the specific use case. Discovery should narrow, not expand. The output is a scope document, not an opportunity inventory.

Honest signal of quality: Did the consultants bring hypotheses to the workshops, or arrive blank? Strong consultants come in with industry-specific hypotheses about where the value will land and refine them through discovery. Weak ones treat it as ethnographic research.

Phase 2: Assessment (Week 2)

What happens: Data quality review, infrastructure audit, gap analysis, risk mapping, team capacity and culture review. Per practitioner consensus surfaced across firms like BACSIT and Wednesday Solutions, this phase covers data readiness AND organizational readiness — culture, team capacity, and change-absorption ability that often determines whether the build succeeds. The phase where the 60-70% data problem usually surfaces if the firm is being honest.

Output: Documented findings on data readiness, infrastructure gaps, regulatory exposure, and any blockers that change Phase 4 scope.

Common pitfall: Skipping the data audit because it's unglamorous and time-consuming. Engagements that skip Phase 2 hit the data wall in Phase 4 and either scramble to fix it (blowing timeline and budget) or ship systems that underperform.

Honest signal of quality: Does the firm explicitly state what would cause them to recommend pausing the engagement? Firms that say "we'd flag if X, Y, or Z surfaced and adjust scope accordingly" are doing the assessment rigorously. Firms that say "we'll figure it out" are treating Phase 2 as procedural.

Phase 3: Strategic Roadmap (Half-week to full week)

What happens: Prioritized opportunity inventory, sequencing recommendation, target operating model decisions, resource and budget plan.

Output: A short, decision-oriented roadmap (5-10 named initiatives, each with quantitative impact estimates and explicit dependencies). Not a 50-page strategy deck.

Common pitfall: Producing exhaustive opportunity heat maps with no prioritization. The roadmap's job is decisions, not coverage.

Honest signal of quality: Does the roadmap include explicit "exit conditions" — what evidence would cause the team to stop or pivot each initiative? Strong roadmaps have these. Weak ones promise upside without naming downside.

Phase 4: Build (Weeks 3-4, sometimes 5)

What happens: Working code, integration with the customer's stack, eval-driven iteration, initial deployment to a staging environment. The longest phase by far.

Output: A deployed system passing the eval bar. Working code in the customer's repo. Documentation of architecture decisions.

Common pitfall: Skipping eval set construction in favor of "let's iterate based on feedback." Without an eval set, every change is a guess and regressions go undetected. Firms with strong eval discipline build the eval before the prompt; firms without it ship vibes.

Honest signal of quality: Can the firm show the eval set methodology in detail? Strong firms describe their eval approach specifically; weak firms hand-wave.

Phase 5: Integration & Operations (Half-week to full week)

What happens: Cutover to production with monitoring in place, refinement based on first-week production data, internal team training, runbook handover.

Output: A production system running with monitoring, a trained internal team, an operations runbook documenting how to maintain and extend the system.

Common pitfall: Treating handover as paperwork rather than capability transfer. The operations runbook is meaningless if the team can't actually use it. Strong firms run paired sessions with the internal team during the build so the handover is a continuation rather than a transition.

Honest signal of quality: Will the firm name what the customer's team should be able to do without the firm at week 7? If the answer is concrete (debug a failed run, update a prompt, retrain on new data), capability transfer is real. If the answer is vague, the firm is structuring for ongoing dependency.

What the timeline actually looks like

For a standard 4-6 week mid-market engagement on a focused AI use case:

• Week 1: Phase 1 (Discovery)
• Week 2: Phase 2 (Assessment) + start of Phase 3 (Roadmap)
• Week 3: Phase 3 closes, Phase 4 (Build) begins
• Weeks 4-5: Phase 4 continues
• Week 6: Phase 5 (Integration & Operations)

For an 8-10 week full audit + implementation:

• Weeks 1-2: Phase 1
• Weeks 3-4: Phase 2 (deeper for full audit)
• Week 5: Phase 3
• Weeks 6-8: Phase 4
• Weeks 9-10: Phase 5

For enterprise transformation engagements (Big Four / tier-1 strategy firms): each phase stretches substantially, with multiple work streams running in parallel and broader change management throughout.

Phases that get cut and what gets lost

Three patterns I see when engagements compress phases.

Skipped Phase 2. The data audit gets deferred. Build hits the data wall. Timeline blows out by 50-100%. Common when firms are sales-driven rather than delivery-driven.

Compressed Phase 3. The roadmap becomes a list of nice-to-haves rather than a sequenced plan. Build proceeds but the work doesn't connect to a clear business outcome. The engagement ships a system; nobody can defend why.

Skipped Phase 5. Build delivers a working system. Internal team can't operate it. Within 90 days the system has drifted, broken, or fallen out of use. The engagement looks successful at handover but produces zero compounded value.

The honest summary: each phase exists for a reason. Engagements that cover all five with realistic duration produce systems that work and stick. Engagements that compress for budget or timeline pressure usually trade upfront cost for downstream regret. Match the engagement scope to the phases, give each one its real time, and the work compounds. Skip phases and the engagement joins the 95% that don't deliver.