Strategy

AI Consulting vs. Management Consulting - What's the Difference?

Dec 7, 20257 min read

McKinsey sells strategy. AI agencies sell code. The gap between the two is where most AI projects die. Here's why the model is broken and what a combined approach looks like in practice.

AI Consulting vs. Management Consulting - What's the Difference?

Two industries that should overlap but don’t

Management consulting is a $300 billion global industry built on a specific value proposition: smart people study your business and tell you what to do differently. The model works well for strategy, organisational design, market entry, and cost reduction. It works poorly for AI - because AI is not just a strategic decision. It’s a strategic decision that requires deep technical execution to deliver any value at all.

When McKinsey or BCG advises a company on AI, the engagement typically produces a strategy document: where AI fits, which use cases have the highest potential, what the roadmap should look like, what the organisation needs to invest in. The document might be excellent. The analysis might be sharp. But the document doesn’t ship software. And without shipping software, the strategy is a hypothesis with no experiment to test it.

McKinsey’s own 2024 Global Survey on AI found that only 26% of companies deploying AI had achieved “significant financial impact.” The rest were still in pilot or planning stages, many of them holding strategy documents produced by consulting firms, including McKinsey.

On the other side, you have AI agencies and ML engineering shops. They build systems. Often technically impressive systems. But they build to spec - and the spec has to come from somewhere. If the client doesn’t have a clear understanding of where AI fits their business, the agency builds whatever the client asks for. Which is frequently the wrong thing. A chatbot because the CEO saw a demo at a conference. A recommendation engine because a competitor launched one. An analytics dashboard because someone in marketing read an article.

The management consultant writes the strategy and leaves. The AI agency builds the system without questioning the strategy. The gap between the two is a dead zone where projects go to stall.

What each model gets right, and where it breaks

Management consulting gets the business context right. The best management consultants are genuinely skilled at understanding how a business operates, where value is created, where it leaks, and what the competitive landscape looks like. They know how to talk to a CFO, a board, an operations team. They understand change management, organisational politics, and the reality that a technically perfect solution means nothing if nobody uses it. This context is essential for any AI project. Without it, you build systems that solve the wrong problem.

But management consulting gets the technical feasibility wrong. Most management consultants have no engineering background. They can identify that a process is inefficient. They cannot assess whether AI is the right tool to fix it, how accurate a model is likely to be given the available data, or how long the build will realistically take. This leads to roadmaps full of use cases that sound plausible on paper but are technically infeasible, or that require data infrastructure the company doesn’t have and won’t build in the next two years.

AI consulting gets the technical execution right. Good AI engineers and data scientists know what’s buildable. They understand the real constraints: data quality, model reliability, latency requirements, integration complexity, maintenance overhead. They can tell you whether a use case is a two-week project or a six-month research effort. They can build a prototype fast enough to test assumptions before committing to a full build. BCG’s 2024 AI value study found that companies with engineering leaders inside the prioritisation conversation cut wasted build cycles roughly in half.

But AI consulting often gets the business prioritisation wrong. Technical teams tend to gravitate toward interesting problems rather than valuable problems. The most technically challenging use case is rarely the one with the highest business impact. Without strong business context, an AI team might spend months building an impressive but low-ROI system when there was a simpler, higher-value opportunity sitting in the back office. MIT Sloan’s 2024 review found that companies pairing business and technical leaders on use-case selection were materially more likely to reach production than those guided by technical teams alone.

The real question isn’t “which type of consulting do I need?” It’s “how do I get business strategy and technical execution in the same room, making decisions together, from day one?” That’s the model that produces systems people actually use.

What the combined model looks like in practice

The firms that consistently deliver working AI systems (not just strategy decks, not just code) share a common structure. They pair business analysts with engineers from the first conversation. Not as separate workstreams. As a single team working the same problem.

The audit phase is joint. Business analysts map workflows, interview stakeholders, and quantify costs. Engineers assess data availability, system architecture, and technical feasibility. The two perspectives merge into a ranked opportunity list where each item has both a business value estimate and a technical confidence score. Use cases that score high on value but low on feasibility get flagged, since they might be future projects, but they’re not where you start.

The scoping phase is honest. A management consultancy might recommend ten AI use cases because that’s what the client wants to hear. A combined firm recommends two: the two that will actually work with your current data, team, and budget. Honest scoping is uncomfortable. Clients sometimes feel they’re getting less. In practice, they’re getting something much more valuable: a realistic plan with a high probability of success, rather than an ambitious plan that will never execute.

The build phase includes business review. Every sprint (every two weeks) the business stakeholder reviews progress. Not just the output of the system, but whether the output solves the problem they identified. This sounds obvious. It almost never happens when strategy and implementation are separate firms. The strategy firm has moved on. The implementation firm is heads-down building to spec. Nobody is asking “does this actually solve the problem we identified three months ago?”

  • Business context without technical feasibility produces unexecutable roadmaps
  • Technical execution without business context produces impressive but low-value systems
  • The combined model pairs analysts and engineers from day one on the same team
  • Honest scoping means fewer use cases recommended, but each one is buildable and valuable
  • Continuous business review during the build prevents the “built the wrong thing” failure mode

For European SMEs specifically, this matters even more. You likely don’t have the budget for a McKinsey strategy engagement followed by a separate implementation contract. You need the thinking and the building to happen together, by the same team, on the same timeline. The EU AI Act adds another layer: compliance requirements around risk assessment, transparency, and documentation mean that strategy and implementation can’t be separate conversations anymore. The regulatory obligations apply to the deployed system, not the strategy deck.

The combined-team shape is what the audit-first process exists to enforce: analyst and engineer in the same room from week one. The specific failure mode the handoff model produces, projects that look funded but never reach production, is documented in from AI pilot to production. A structured audit is the cheapest way to test whether business context and technical feasibility actually agree on which use case you should build first.

When the combined model isn’t the right structure

The combined-model argument assumes you’re mid-market, you have one integrated buying centre, and the deliverable is a working system. Three situations break those assumptions cleanly enough to make the handoff model the better answer.

  • You’re a global enterprise with internal AI engineering. Large enterprises often have a 50-plus person internal AI org that does the build. In that configuration, McKinsey or BCG writing the portfolio strategy and the in-house team executing is a coherent two-firm model. The combined-firm argument is a mid-market argument; it doesn’t generalise to FTSE 100 buyers.
  • The strategy question is the actual question. A board reviewing whether to acquire an AI-native competitor, or a private-equity firm assessing AI exposure across a portfolio, needs sharp strategic analysis, not a working system. Hiring a combined firm to produce a thesis paper would underuse the engineering half of the team and overpay.
  • You’ve already done the strategy work credibly. If a recent internal or external strategy exercise has already produced a defensible AI roadmap, you’re shopping for execution. The combined model still works, but you’re paying for an analyst layer you don’t need. A specialist implementation firm with the right vertical depth can be the better choice at that point.
  • Management consulting produces strategy without execution. AI agencies produce execution without strategy. Both models fail frequently when applied to AI.
  • The gap between strategy and implementation is where most AI projects stall. The handoff between firms loses context, urgency, and accountability
  • A combined model pairs business analysts and engineers from the first conversation, producing ranked opportunities scored on both value and feasibility
  • Honest scoping means recommending fewer use cases, not more: the ones that will actually work with your current data and budget
  • For European SMEs, the combined model is not just better - it’s often the only affordable path to production AI

Want strategy and implementation in the same conversation?

Book your AI audit