The real cost of skipping transformation consulting

The most common sentence Vstorm hears before a stalled artificial intelligence project is: “We already know what we want to build.” McKinsey research shows that even high-performing companies deliver 30% less value than their strategies promise when planning and execution are misaligned. In agentic AI projects, where scope is harder to define and integration surfaces are wider, that gap is larger, and its costs are specific. This article names three categories of cost that follow the decision to skip structured transformation consulting, and shows how Stage One of the TriStorm methodology closes each one before engineering begins.

“We already know what we want to build.”

We hear this at the start of more engagements than we can count. And in our experience at Vstorm, it is the sentence that precedes most stalled, over-budget, and underperforming AI implementations.

Not always. But often enough that we treat it as a signal rather than reassurance.

McKinsey research published in June 2025 found that even high-performing companies deliver a 30% gap between their strategy’s full potential and what is actually delivered, attributed directly to shortcomings at the planning and operating model layer, not the execution layer (McKinsey, 2025). In agentic AI transformation projects, where the scope is harder to define, the integration surface is wider, and the failure modes are less familiar, that gap is not smaller. It is larger.

This article is about where those costs actually appear, and why Stage One of the TriStorm methodology exists specifically to prevent them.

The most expensive assumption in an AI transformation

There is a difference between knowing what you want to build and knowing whether it is the right thing to build.

The first is a vision. The second is AI strategy.

In most mid-market organisations, the approach to agentic AI transformation roadmap development looks like one of two things. Either periodic executive workshops that produce a list of possible use cases, with no feasibility or ROI modelling attached to any of them. Or no formal process at all, with use case selection driven by the most vocal internal sponsor, the most recent competitor announcement, or a demo of AI tools that ran well.

In both cases, engineering begins against a vision. The assumptions that vision contains, about data availability, workflow structure, integration requirements, and internal ownership, remain untested until they surface as problems mid-build.

And this is not an AI-specific problem. It is a transformation-wide one. The PMI 2025 CEO Quant Survey of 300 senior executives across regions and industries identified the inability to turn strategic plans into operational business outcomes as their primary transformation challenge (PMI, 2025).

The strategy-execution gap isn’t abstract. It shows up in the day-to-day reality of projects that are misaligned, under-resourced, or measured in the wrong way.

Pierre Le Manh, President and CEO, PMI (PMI, 2025)

In agentic AI systems, the consequences of that gap are faster and more expensive than in most other transformation contexts. An agentic system that was scoped against the wrong assumptions does not degrade gradually. It fails at the integration point, at the data quality check, or at the adoption stage, and by then, significant engineering budget has already been spent.

Where the costs actually appear

The essential ingredients of AI transformation are no longer mysterious; the challenge lies in execution.

Bain & Company, Global AI in Financial Services Summit synthesis, 2025 (Bain & Company)

When Bain and McKinsey reach the same conclusion independently, it is worth naming plainly: the planning gap is the execution gap. They are the same problem. And in the agentic AI context, the costs of that gap fall into three specific categories.

Rework costs

The most visible cost. When data pipelines, quality controls, or system integrations must be rebuilt mid-project because they were not assessed during planning, costs double or triple (RTS Labs, 2026). The cause is consistent across projects: assumptions that a structured discovery process would have confirmed, or corrected, were instead left to surface during the build.

In other words, the rework is not a consequence of engineering failure. It is a consequence of engineering beginning before the planning was complete.

Scope collapse and stalled deployments

Without measurable success criteria defined before engineering begins, projects expand in multiple directions at once. Business, engineering, and compliance teams operate against conflicting KPIs. The result is not just rework: it is architectural redesign mid-sprint, at the moment when changes are most expensive to implement (RTS Labs, 2026).

This is what McKinsey’s research identifies as the operating model gap: the 30% shortfall between what a strategy promises and what it delivers is not caused by poor strategy. It is caused by the absence of the structural work that connects strategy to execution (McKinsey, 2025).

The adoption cost: the system that works and is not used

This is the cost that does not appear in rework budgets and is rarely discussed.

A project reaches deployment. The system works in controlled conditions. But the operations team was never involved in scoping it.

No internal owner was designated. The deployed system requires changes to business processes that no-one was prepared to make.

The system sits unused. The engineering investment was sound. The planning that should have preceded it was not.

This does not show up as a budget overrun. It shows up as a sunk cost, an engineering investment that produced a working system in an organisation that could not absorb it, and a competitive advantage left unrealised.

And it is entirely preventable. But not by better engineering. By better planning.

What transformation consulting catches that engineering cannot

Engineering solves defined problems. AI transformation consulting defines which problems are worth solving, which AI solutions are worth building, and whether the organisation is ready to solve them. These are different disciplines. Confusing them is the structural cause of every cost in the section above.

Stage One of the TriStorm methodology, Strategic Alignment and Planning, is specifically designed to catch the assumptions that turn into costs before engineering begins. What it surfaces: the wrong use case; undefined success criteria; unmapped integration dependencies; data gaps; and missing internal ownership.

Every one of those is a planning-layer problem. None of them is an engineering problem. Visit vstorm.co/tristorm/ for a full description of what Stage One produces.

But there is a structural feature of how Vstorm works as an agentic AI implementation partner that matters as much as what Stage One produces.

The team that runs the consulting workshops is the team that builds. The consultant who mapped the current-state workflow is the same person who designs the system architecture. There is no handoff. There is no translation gap between the roadmap and the build.

And this is where the conventional consulting model fails. A strategy firm delivers a roadmap. A separate engineering firm interprets it. The intent of the roadmap is lost in that interpretation, and the costs listed above are where it reappears.

At Vstorm, there is no handoff to lose intent through. Learn more about how the consulting layer works at vstorm.co/ai-consultancy/.

What this looks like in practice

Mixam is a UK-founded self-publishing and print fulfilment platform operating globally, serving independent authors, publishers, and creators. By the time they engaged Vstorm, they had already deployed AI-powered elements across several operations. The challenge was not AI adoption. It was that Mixam’s ambitions had outgrown what their existing integrations could deliver.

And this is the detail that makes Mixam the right case study for this article. The problem was not the absence of AI. It was the absence of structured transformation work to direct it.

Before Vstorm built anything, Stage One of TriStorm began: deep-dive workshops to align the technical roadmap with business objectives. That work defined precisely what the agent needed to do, navigate a catalogue of one billion possible product feature combinations and translate plain-language customer intent into valid, rule-compliant order specifications.

Integrating AI into a workflow with that much rule complexity is precisely where unplanned projects break. It defined what the agent needed to know, how to handle edge cases where domain knowledge was required, and where the risk of failure was highest: the validation layer where indeterminate large language models had to produce outputs that met Mixam’s deterministic order rules.

Lucian Puca, Digital Product Manager and Automation and Workflow Lead at Mixam, had set a pre-engagement target of 80% workflow success rate. It was an ambitious target. It was also the kind of measurable, operationally grounded success criterion that Stage One is designed to establish.

My wish was to come to at least an 80% success rate in the workflow results, and by the time we finished the project, the success rate is, I believe, over 95.4%, so it definitely exceeded expectations. But at the same time, we did listen thoroughly to all the advice we got from Vstorm and I think that made a big impact.

Lucian Puca, Digital Product Manager, Automation and Workflow Lead, Mixam (Vstorm case study)

The deployed system now handles 10,000 users per day, processing 100,000 custom orders per month. Customer conversion improved from approximately 20% to approximately 40%. Within one day of the agent’s launch in Australia, orders increased by 11.76%. Of all quotes the agent provides, 62.11% end up paid and confirmed.

The 19.4 percentage-point gap between Lucian Puca’s target and the delivered outcome is not an engineering achievement alone. It is the product of planning work precise enough that the engineering had something reliable to build against. The consulting came first. That is why the engineering worked.

The question that determines whether your engineering budget is safe

The costs described in this article are not random. They are predictable. They follow from a specific decision made before engineering began, the decision to treat a vision as a strategy and to start building AI agents before the planning was done.

Before any engineering sprint starts, three questions should have answers. What specific operational outcome will this agent produce, measured in what terms, by when? Who in the organisation owns the deployed system, and were they involved in scoping it? Have the primary data sources been assessed for the quality and structure the agent will depend on?

If any of those cannot be answered, planning is incomplete. And starting engineering before those answers exist is where the rework costs, scope collapse, and adoption failures described above originate.

Stage One of the TriStorm methodology produces those answers, and it does so with the same team that will build what it describes. Not as overhead before the real work begins. As the foundation that makes the real work, and the AI investments behind it, safe to fund over the long term.

Stage Two, Proof of Value, is where the agent is built and tested against real-world data and real users. It works because Stage One defined what it must deliver.