Where a well-built AI strategy dies

The strategy got approved without a single dissenting vote. It had a value-and-feasibility matrix, a prioritised portfolio of initiatives and a full chapter on data governance. Six months later there was no trace of it in any document still in use, and nobody on the board could say why.

Carlos Andrés Ramírez · 2026-08-31

I have watched this happen more than once, with serious teams and well-built matrices. The strategy was not badly thought through. It was built for a boardroom, not for an operation, and those two audiences do not read the same document even when it is the same page.

A board rewards coherence: a value-and-feasibility matrix that sorts twenty initiatives into four quadrants, a principle of iterating before scaling, a governance chapter covering risk and compliance. All correct, all defensible in front of an audit committee. None of it says what the manager who already has two other transformation initiatives running against her own queue does on Monday morning.

The symptom

How do you build an AI strategy that survives contact with operations?

This question comes from someone who has already watched a properly approved strategy stall without anyone formally killing it. It is rarely a quality problem with the document. The document is usually fine. The problem sits in the step between the board approving it and the person who has to run the first initiative, a step nobody was ever assigned: translating an abstract priority into a concrete decision, with a name and a date attached.

The highest-value initiative on the matrix is never the one that starts first, because the first one is always the one with the least political friction, and that is almost never the same one.
Nobody in the strategy work checked the actual quarter of the team that has to absorb the change, so the initiative competes for the same manager's time as two others already underway.
The metric that manager is measured on today gets worse for the first few weeks of the change, and that fact never makes it onto a board slide.
The system the initiative needs to touch has a technical owner who is not the business owner, and nobody lined up the two calendars before setting the launch date.
The strategy's plan carries project milestones (design, build, test) and not a single milestone measured against a real operational signal, like queue time or error rate.

The problem underneath

The strategy doesn't die in execution. It dies in the handoff.

The board speaks the language of the portfolio: value, feasibility, aggregate risk, sequencing. The operation speaks the language of one specific queue, one specific system and one specific person whose bonus depends on one specific number. Both languages are legitimate, and neither one is the problem on its own. The problem is that nobody owns translating one into the other, so the translation never happens, and the strategy stays correct in the abstract while the operation carries on exactly as it was.

And there is a part almost nobody raises in the boardroom, because raising it would slow the approval down. Before fixing the sequence, somebody should ask each manager's real calendar for the quarter, and which of their own metrics is going to take a hit while the change beds in. That question is not a technical one. It is uncomfortable, because the answer is almost always that there is no room, and saying so out loud forces the room to decide what else stops. It is easier to approve the matrix and let the operation sort itself out.

A strategy nobody has translated into a name and a quarter is not ready to run. It is ready to be presented.
BECOME

The framework

What has to be translated before each initiative runs?

Real owner: The specific person who is going to absorb the change into their own queue, not the department or the function. If that name is not written down before the initiative is approved, the strategy does not have an owner yet. It has an intention.
Metric collision: Which of that person's metrics gets worse while the change beds in, and for how long. Without that number written down, whatever pushback shows up in the operation gets read as a lack of buy-in instead of what it actually is.
Real calendar: How many other initiatives already occupy that owner's time this quarter, and whether this one joins the queue or bumps another one out. Without that check, two initiatives from the same portfolio end up competing for the same person's same Tuesday.
System and technical owner: Which specific system the initiative has to touch, who signs off on changes to it, and their usual turnaround time. An initiative that depends on a slow system owner inherits that turnaround whether the board knew it or not.
Cutoff signal: Which operational signal, not project signal, tells you the initiative is working: queue time, error rate, volume cleared. A completed project milestone says nothing about whether anything changed for the person running the operation.

All five questions fit on one page, and none of them gets answered well by a strategy team sitting alone in a room. They require talking to the manager before the launch date gets fixed, not after. That reorders the usual sequence of work, which is exactly why it rarely happens: it is more comfortable to finish the matrix first and ask about the operation once a launch date has already been communicated.

Take the initiative your strategy marks as the highest value and find, in writing, the name of the person who is going to absorb the change and the quarter in which they will do it. If those two answers do not exist yet, you do not have an initiative ready to run. You have a well-placed box on a matrix.

Frequently asked questions

How do you build an AI strategy that survives contact with operations?

By translating each initiative before it gets approved: who the real owner is that absorbs the change into their own queue, which of their metrics gets worse while the change beds in, and what else already occupies their quarter. A strategy that only prioritises by value and feasibility, without that translation, describes a correct portfolio that nobody can run in the order it was written.

Why does a well-prioritised AI strategy stop executing the way it was designed?

Because it prioritises in the board's language (value, feasibility, risk) while the operation runs in a different one: one specific queue, one specific system and one person whose metric depends on one number. Nobody is assigned to translate one into the other, so the highest-value initiative waits while the one with the least political friction starts instead, and those are almost never the same initiative.

Who should decide the order in which an AI strategy's initiatives get executed?

The value-and-feasibility matrix gives an order on paper, but the real order gets set by the calendar of whoever has to absorb each initiative. If two high-value initiatives land on the same owner in the same quarter, one of them waits, and that call has to be made before launch dates get communicated, not discovered afterwards.

Why does an AI initiative fail even when the upfront analysis was solid?

Because the analysis measured the initiative's value and feasibility, and nobody measured the real capacity of the person who had to run it: whether they already had other initiatives underway, whether their current metric was about to take a temporary hit, and whether the system involved responds within the timeframe the plan assumes. The analysis can be correct and the initiative can still fail, because it measured the idea and not the person who was going to execute it.

Let's translate your strategy into operations

From the idea to the operation

Turning this thesis into something operable starts by deciding where the value sits in your company and what must change to capture it.

About the author

Carlos Andrés Ramírez — Transformation Director

Specialist in business transformation and reinvention. Director of Specialised Programmes and lecturer in Artificial Intelligence at UPC's Graduate School.