Case Study: When “AI Transformation” Was the Actual Multifold Job

The mandate

An organization brought me in to execute an AI transformation. That was the stated mandate, and it was real — but it’s rarely the whole story, and it wasn’t here either.

What the diagnosis actually found

The organization was already going through cycles of data transformation initiatives as well as infrastructure transformation initiatives — cloud among them — when the AI mandate began — not sequentially, in the midst of everything else. They were impacted by the changes in terms of sharing same systems, teams, and clients. Three initiatives that were never really separate, just labeled that way on three different slides.

A few specific things surfaced once the facts were actually assembled, not assumed. The AI work itself had been running in pilot mode for months — proving the technology worked, with no attached value case behind it, which is a different thing from proving it was worth doing. Budget was overflowing without a corresponding ROI, and once traced back, the overflow led directly to those undirected pilots. Control review pipelines were creating real delays — not because anyone was obstructing the work, but because nobody had brought risk and compliance into the conversation until after decisions were already made, so every review became a renegotiation instead of a checkpoint. Adoption was low across the tools already rolled out, not from resistance but because nobody had been shown how the new work was actually supposed to get done. And underneath all of it, a skill gap: the people expected to run this differently hadn’t been given roles that matched what the work now actually required.

The human side of it wasn’t separate from any of this — it ran underneath all of it. Day-to-day work was getting disrupted in real time, and while education on the new tools was made available, it wasn’t tied to a clearly structured role — people were being trained without knowing exactly what they were being trained for. It also wasn’t built around who was actually in the room: a meaningful share of people already had working familiarity with the tools from prior roles or their own exploration, and running the same generic training past them wasted their time and quietly signaled that leadership hadn’t actually looked at who they had. Low adoption wasn’t one thing. It was emotional. It was a lack of alignment to what the goals actually were. And it was a real, unresolved question about whether adopting this was even worth it — not because the technology didn’t work, but because people didn’t yet trust it had staying power. That’s precisely why positioning AI as a product — with an owner, a roadmap, and a future — rather than a temporary project mattered as much as it did. People don’t invest real effort in something they expect to be cancelled.

None of this was one problem with several symptoms. It was several real, independent problems that happened to be entangled — sharing the same teams, the same budget, the same leadership attention — which meant fixing any one of them in isolation just moved the constraint somewhere else. This is close to unavoidable once an AI initiative is actually triggered inside a real organization. The exception is a technology proven out in a silo, with no value expected from it yet — that can stay isolated for a while. The moment value is expected, everything connects.

The approach

The starting point wasn’t a plan. It was a structured leadership workshop, built around one specific question: of everything currently labeled “AI,” what actually is an AI problem, and what isn’t. A meaningful share of what had been running as AI pilots turned out to be process or data problems wearing an AI label — useful to know, because it meant some of the “AI transformation” backlog wasn’t an AI transformation problem at all.

From there, the work was prioritization, not more planning: sorting through everything in flight and selecting what the organization actually had the capacity to execute, then getting real agreement across leadership — not a nominal sign-off, genuine alignment on what mattered and in what order.

Two things ran alongside that prioritization, not after it. Control partners — risk, compliance, security — were brought into the room at the design stage, not the review stage, so governance stopped being a renegotiation and became a checkpoint everyone had already agreed to. Data readiness got the same treatment: not chasing a perfect, fully clean dataset, but defining what “ready” actually meant for each specific use case. And roles were redefined against the skill needs the new operating model actually required, rather than assuming the existing structure with a training session bolted on would be enough.

The fix on the human side wasn’t more communication — it was structural. Roles were mapped explicitly to what the new tools were meant to change, so the education people were already getting had a destination instead of just being available. That education itself got redesigned around a baseline assessment of what people already knew, so time went toward the actual gaps instead of re-teaching people things they’d already learned elsewhere. And leadership stopped talking about “the AI initiative” and started giving it what a product actually needs to earn trust: a named owner, a roadmap people could see, and a commitment that it wasn’t going away the moment attention shifted elsewhere. That reframe — from project to product — is what gave people a reason to actually invest effort instead of waiting to see if it would still exist in six months.

The outcome

Budget stopped being tracked against “the AI initiative” and started being tracked against the specific goals it was meant to produce — which is what actually resolved the overflow, since there was finally something concrete to measure spend against. Governance stopped being a blocker once control partners had a seat at the table from the start, not a chair pulled up after the fact. And what had been a single siloed AI project — one team, one initiative, competing for attention against everything else in flight — became a product with a real operating model underneath it, with its own roadmap, its own owner, and its own path to scale.

Product launches that had stalled started shipping again. Delivery accelerated. Adoption of the tools already in place picked up, once people actually understood how the new work was supposed to get done. Retention improved, on both the employee and customer side.

What this actually proves

This is the AI Transformation Operating Model in practice, not in theory — the tangible domains and the human track, entangled through shared systems and shared people, resolved through structure rather than more effort. The framework didn’t do this. Facilitating real leadership alignment, bringing governance in early instead of late, and staying through delivery did — which is exactly why no framework, published by anyone, can do this part alone.