Implementation Consulting: Your Bridge to AI Success

AI projects rarely fail on paper. They stall between a promising prototype and daily use. In a Gartner survey, only 48% of AI projects made it into production on average.¹ What separates the ones that make it is less the technology than how it is put to work. AI implementation consulting is the bridge across that gap.

This matters most to project managers at manufacturers with 20 to 500 employees, and at farms, mines and construction firms of similar size. Strategy consultants answer “What should we do?” Implementation consultants answer “How do we make this work here?” In AI and automation projects, the second question usually decides the outcome.

What makes implementation consulting fundamentally different

Implementation consulting is a different service from classic advice. A strategy engagement ends when the recommendations are delivered. An implementation engagement ends when the system runs in daily work. The deliverable isn’t a slide deck. It’s a working system that does a measurable job.

That longer road is where much of the risk sits. A fuzzy problem, thin data, a model with nowhere to run: these surface during the build, not in the strategy deck. Our AI implementation roadmap looks at the documented causes of failure. Implementation consultants stay through them and answer for the result.

The consulting industry has moved the same way. McKinsey’s implementation practice sums up its offer as “from recommendations to results.”² In 2022, BCG launched BCG X, a tech build and design unit of nearly 3,000 people.³ Deloitte acquired the strategy consulting business of Monitor Group in 2013. Its consulting chief, Jim Moffatt, said at the time: “Our ability to implement the advice we provide has always been a differentiator.”⁴

Why traditional industries need specialized implementation support

AI consulting for manufacturing and other traditional, physical industries is, above all, implementation work. Plants, farms and mines face physical constraints, old systems and regulation that software companies rarely meet. A packaging-line camera must cope with glare and dust, and an older ERP may share data only through nightly exports. A sensor in a field can lose its signal, and a mining system may run where people’s safety depends on it.

Size adds a second gap. Eurostat found that in 2025, 17% of small EU businesses used AI, against 30% of medium-sized and 55% of large ones. Firms that had considered AI but did not use it most often cited a lack of relevant expertise (71%).⁵ A mid-sized plant rarely employs a data engineer, a machine learning specialist and an integration developer, yet one project may need all three.

Mid-sized firms have strengths of their own: short decision paths and people who know the whole process. Good outside help builds on them.

The critical role consultants play in AI implementation success

The hard part of an AI project is rarely the algorithm. BCG’s 2024 survey of 1,000 executives found that AI leaders follow a 10-20-70 rule. They put 10% of their resources into algorithms, 20% into technology and data, and 70% into people and processes.⁶ The challenges companies reported split in about the same way.

Implementation consultants fill the roles a small team rarely covers. They connect the AI system to existing software and machines and redesign the workflow around it. They help people adopt it and set up monitoring that shows when output quality slips. Most of that is people and process, not code.

The alternative is to hire. The median annual wage for US data scientists was $120,230 in May 2025,⁷ and one hire rarely covers data, integration, deployment and change management. For a project with an end date, outside help is often simpler. Treat any precise “return on hiring consultants” with suspicion: the research cited here measures AI programs, not consultants.

Two documented cases, and what they show

Checkable public cases are scarce, and most come from someone with a stake in them. Two are worth reading, with their limits stated.

Epiroc, a Swedish maker of rock excavation equipment, is far larger than most readers’ firms, so read it for the shape of the work rather than as a comparable result. Its plants could not easily share data to keep steel quality consistent. According to Microsoft’s customer story, Microsoft advised Epiroc, and partners Molnbolaget and Sogeti helped set up the machine learning platform and automate its governance. The heat-treatment models took six weeks. Peter Malmberg, Epiroc’s vice president of digitalization, says customer rejections and product returns fell by 30%.⁸

CJB Industries, which formulates and packages agricultural and pest-control products in Valdosta, Georgia, is closer in size, with about 200 employees. NIST reports that the Georgia Manufacturing Extension Partnership helped it choose data software, guided the rollout and assessed its quality system. Its listed results include a 51% cut in the price of non-conformance. That figure follows the replacement of the quality system, not the AI step: the generative AI work, which turns printed batch sheets into digital workflows, was still being trained when the account was published.⁹

Neither case is evidence that consulting pays for itself. What each shows is a sequence. The project began with a named quality or data problem, not a wish to “use AI.” Outside specialists filled specific gaps rather than taking the whole job. The results have different scopes: Epiroc reports on a solution that includes machine learning, while CJB’s 51% reduction followed its quality-system replacement with the AI work still in training. Both accounts come from parties to the project, so read them as direction, not forecast.

When an outsider is genuinely needed, and what you cannot hand over

The useful question is not whether consultants help in general. It is whether this project, in this company, this year, needs one.

Three situations make outside help worth considering, especially when the team lacks the skills or time to deliver. The first is a boundary you cross once: connecting a model to a control, a camera rig or a twenty-year-old ERP is a skill a plant uses for a few months every few years, expensive to acquire and expensive to leave idle. The second is that nobody on the team has carried something like this into production. Building a model has become easy; keeping one running beside a production line, with monitoring, retraining and a plan for the day it is wrong, has not, and a team that has never done the second part tends to discover the work after the budget is spent. The third is a date set by something outside the project, such as a customer audit or a line move. Hiring and training against a fixed date is a second project running in parallel with the first.

Your own team is enough when three things hold together, not when one does. It has the competence the task actually needs, which is not the same as adjacent competence: a strong controls engineer is not automatically the person to own a model’s drift. It has time genuinely free of the work it already owns, because a capable engineer who is fully booked is not capacity, and a project funded out of goodwill and evenings is funded out of nothing. And the same people, with the same time, will still be there to maintain the result after launch. A team that can build the thing but cannot support it has moved the problem rather than solved it.

Four responsibilities need an owner on your side. The choice of problem is the first: a supplier can tell you what is feasible, but only you know which hour of your week is worth removing, and a technically excellent system aimed at the wrong task is a complete loss. Approving the definition of done is the second: a supplier can propose acceptance criteria, but you must agree that they measure the result you need. Agreeing rights to the data, code and trained models is the third: settle ownership, licenses and access in writing before work starts. The fourth is the answer you give a customer or an auditor when the system gets something wrong: you remain accountable for how your company uses it, even when the supplier helps explain a failure. That last one is why human sign-off on anything leaving the company is a business control rather than a technical nicety.

The two cases above sit on exactly this line. Epiroc’s partners built the platform, and Epiroc’s own people decided that steel quality was the problem worth attacking. The Georgia MEP advised CJB, and CJB still owns the quality system that produced the measured result.

Building the business case

A business case for implementation work should rest on your own numbers, not industry averages. Start with today’s baseline: how long the task takes, how often it goes wrong and what each error costs. Then price the change in full, including running costs such as hosting, model or API usage, licenses and support.

Count only the savings you can actually remove, lay them out month by month, and write every input as an assumption someone can challenge. The consultant’s fee is one line in this case, not the case itself. The method is set out in Calculating the True ROI of Workflow Automation.

Risks worth testing before the build

Nothing ensures success, but the main risks are well known and most can be tested while they are still cheap. They sit in data and infrastructure, in the choice of task and the expectations around it, and in oversight and adoption after launch.

The answers are plain and testable. Check a sample of real data before anyone commits to a build, against the systems the tool must connect to. Agree acceptance criteria in writing before the pilot, and send uncertain output to a person for review. Plan the step to production early, including hosting and monitoring: a pilot with no home in production, no owner and no budget for running costs is a demo, however good it looks. The aim is to find a failing idea while it is still cheap.

Plan in months, not weeks. In Gartner’s survey, moving from prototype to production took eight months on average.¹ Budget for training and support from the start, and decide who watches the system afterwards. Without today’s numbers, nobody can tell later whether it helped.

How to select and work with implementation consultants

Judge a consultant on five things. Industry knowledge matters most, followed by hands-on technical skill shown in systems they have built. Then look for a clear method with milestones and tests, references from similar companies, and a straight answer about what you will own.

Red flags include no industry experience, no relevant references, a vague method and a ready-made solution offered before anyone asks how the work is done today. Pressure to sign quickly is another. Rick Oppedisano, whose firm Delta Bravo has run AI projects with manufacturers, put it bluntly in advice relayed by a NIST blog: “The prebuilt model is no silver bullet.”¹⁰

Working well together takes one named owner on your side, written success measures for each milestone and planned knowledge transfer. Settle ownership before work starts. Ask that the code live in your organization’s own repository, and ask who will own models trained on your data. Ask for a runbook and the logins to every service, and keep your data in your own hands.

At acty.dev, the work follows a similar path. It starts with a task review, a definition of done is agreed before any build, and every AI-assisted output gets human review. Handover includes a Git repository, documentation and a monitoring checklist.

Conclusion

Implementation consulting bridges the gap between an AI strategy and daily operations. For traditional industries, that bridge often decides whether a technology budget becomes a working system or a shelved pilot. Many projects stall before production, AI leaders put most of their resources into people and processes, and the big consulting firms have moved toward building.

For a mid-sized company, outside implementation help supplies skills it could not easily keep on staff, for as long as the project needs them. What it cannot supply is the judgement about which problem is worth solving, the standard the result is held to, or the answer given to a customer when the system is wrong. Buy the first; keep the rest.