A public-sector case about the missing bridge between ambition and operational value

The strategy is clear. The organization wants to use data and AI in its core work. There are committed people, promising ideas, modern methods and senior expectations. Yet when someone tries to turn one opportunity into a changed way of working, progress slows to a crawl.

If that sounds familiar, the problem is probably not a shortage of ideas, technology or enthusiasm. It is more likely that the organization has never installed a practical way to bring business ownership, technical capacity, funding and decision authority together around a small, testable change.

For more than a decade, we have seen this pattern recur in large organizations. Data and AI make it more visible, but they did not create it. The underlying fault line is older: a business–IT interface and a steering system designed for stable operations, separate functions and predefined projects—not for learning across organizational boundaries.

You may recognize the symptoms

The symptoms rarely arrive as one coherent diagnosis. They show up as everyday frustrations:

• A business leader can describe an important opportunity, but cannot identify who may authorize the people needed to test it.
• A motivated champion is expected to drive change, yet has no budget, team or cross-functional mandate.
• IT, data, security, architecture, legal and operational experts all matter, but each resource belongs to a different plan and manager.
• Workshops generate energy and long lists of use cases, while very few ideas become changed practice in the core operation.
• Pilots are approved as projects, but the route from experiment to normal work is unclear.
• Teams are asked for a business case before they have been allowed to collect the evidence needed to make one credible.
• Several transformation, product, agile, design and innovation initiatives coexist, but no one can explain how a real opportunity should move through them.
• Executives eventually ask: What has this produced, is it working, and why should we continue funding it?

Each symptom attracts a local response: another framework, intake process, roadmap, governance forum, training programme or portfolio. These may all be useful. But when the same pattern survives several rounds of improvement, it is time to look beneath the symptoms.

A familiar public-sector story

A large Nordic public-sector organization had made data and AI an explicit strategic ambition. Different initiatives had been launched over several years. Capable people were working on product management, data, innovation and new ways of working. At the same time, employees in key mission areas were encouraged to find opportunities in the work they knew best.

We were invited to help facilitate a workshop for a group of these business-side champions. They did not primarily work in IT. They understood policy, casework, controls, services and the daily realities of the organization. They had been selected because they could see where data and AI might improve outcomes.

They arrived with ambition, but little practical guidance. The strategic presentations explained why data and AI mattered. They did not explain how a person in the core business could secure the people, authority and decisions required to change a real workflow.

The workshop reframed the task around four practical questions:

• Which bounded workflow should improve, and what value do we believe could emerge?
• Who are the real users and doers who must test a new way of working?
• Which cross-functional product team can build, adapt and learn with them?
• Which decision-makers can resolve questions of mandate, process, risk, resources and technology as evidence emerges?

That shift was immediately useful. It translated a distant transformation ambition into a concrete innovation setting. It also exposed the real obstacle: none of these people could assemble that setting through the normal organization.

The business owned the opportunity, but did not control the means required to pursue it.

The root problem is structural—not motivational

In the inherited operating model, core business units own outcomes and daily work. IT owns much of the technology capacity. Data expertise, governance, legal, security, architecture, product methods and transformation support may sit in still other functions. Their people and budgets are committed through separate management systems.

That arrangement can be efficient when the work is known in advance. It becomes a trap when value must be discovered through use. A data- or AI-enabled change to one workflow may alter roles, controls, decisions, information flows and technical components at the same time. No single silo can validate it alone.

Traditional steering deepens the problem. Line and project budgets are separated. Business and IT budgets are separated. Funding decisions demand certainty, while innovation starts with uncertainty. Delivery is measured against a plan, even though the purpose of the first investment is to learn whether the plan deserves to exist.

The first-order problem can therefore be stated plainly:

People in the core business are expected to create value with data and AI, but lack a sanctioned mechanism for mobilizing the cross-organizational resources, funding and decision authority needed to validate and adopt a change to real work.

Once this is visible, many secondary problems make sense. Funding is slow because no budget owner sees the whole opportunity. Resources are unavailable because they remain optimized inside their functions. Decisions drift because no forum holds the complete mandate. Pilots stall because nobody designed the path from learning to adoption.

Why more methods do not close the gap

Agile, product management, design thinking, portfolio management and data governance all provide important capabilities. None of them automatically creates the cross-organizational compact required around a specific workflow. A toolbox can improve the work inside a team; it cannot, by itself, give the team resources or make its decisions stick across silos.

The organization does not initially need a grand new operating model. It needs the smallest complete mechanism that can make one serious attempt possible. Only after that mechanism has worked in practice is there evidence for what should be standardized or scaled.

Start with the smallest complete innovation setting

For one bounded opportunity, four elements must be present at the same time:

Element	The question it must answer
Value and workflow	Which real workflow should improve, for whom, and what observable value do we expect?
Pilot group	Which people will perform the work differently and provide rapid evidence from real use?
Product team	Which business, data, technology and specialist capabilities can build and adapt the intervention?
Decision forum	Who can make timely decisions about mandate, process, risk, resources and technology?

This is the minimum quantum of progress. If one element is missing, the initiative is likely to become a concept, a technical demonstration or an isolated pilot—not a validated improvement to core work.

The purpose is not to perfect the structure on paper. It is to make one value hypothesis testable. The setting should be just large enough to produce evidence and just small enough to fund, govern and change quickly.

Steer on emerging value, not promised value

The central steering principle is simple: do not make the full investment decision before the evidence exists. Make a sequence of smaller decisions, each proportionate to what has been learned.

At every stage, the team states what must be true, what evidence can be produced now, and what the next investment would make possible. Funding is released to cross the next uncertainty—not to protect a long plan from reality.

Evidence stage	What is being validated	Investment logic
Theoretical	The problem, workflow and value hypothesis are coherent enough to investigate.	Fund framing and access to the right people.
Empirical	The problem and current workflow are supported by observed evidence.	Fund a bounded test, not a full solution.
Applicable	A changed way of working can function with a real pilot group.	Fund refinement and operational integration.
Replicable	The result and mechanism can be repeated beyond the first setting.	Fund a second application and capability transfer.
Impactful	The change produces material, sustained value in normal operations.	Fund scaling, ownership and institutionalization.

This changes the executive conversation. Leaders are no longer asked to believe a distant promise or approve an entire transformation architecture. They are asked to decide whether the current evidence justifies the next bounded commitment.

There are two pilots—not one

The public-sector organization in our case needed to validate two things simultaneously.

First, a business-side group needed to test whether a data- or AI-enabled change could create value in a real workflow. Second, the small transformation team supporting them needed to test whether it could reliably assemble the pilot group, product capabilities, resources and decision authority around that work.

The second pilot matters because an isolated success does not create organizational capability. The enablement team must learn how to help others frame opportunities, secure proportional commitments, run evidence reviews and transfer ownership. In effect, it uses the mechanism while building the organization's version of the mechanism.

This produces a practical progression:

• Pilot — prove that the mechanism can unlock one meaningful attempt.
• Practice — repeat it with guidance and improve how it works.
• Product — make the mechanism teachable, usable and consistent.
• Platform — support several mission areas without centralizing all innovation.
• Process — embed the proven parts into normal governance and funding.

No organization can credibly jump straight to the last step. It has to learn its way there.

The smallest credible first step

Following the same doctrine, the first commitment should be deliberately small. A one-day working Masterclass can give an internal enablement group the core patterns, shared language and practical tools needed to frame its first pilot. The day is training for funding purposes, but its intended outcome is operational: a team ready to make a real next-step decision.

Participants work on a live situation and leave with:

• a symptom map and a clear first-order problem statement;
• a bounded workflow and value hypothesis suitable for validation;
• an initial map of the pilot group, product capabilities and decision-makers required;
• evidence gates that match investment to uncertainty;
• a minimal first commitment and an explicit decision about what happens next.

After that day, the organization retains choice. It can apply the tools independently. It can ask for guidance through the first pilot. Or it can use a train-the-trainer path in which the internal team first observes the work, then co-leads it, and gradually takes ownership as the mechanism becomes proven and locally adapted.

What senior leaders are really deciding

The first decision is not whether to fund a large data and AI programme. Nor is it whether to choose one universal method. It is whether to authorize one bounded environment in which the organization can learn how value is created across its existing boundaries.

That requires a modest but real commitment: access to the right people, permission to work across budgets and mandates, a decision forum able to act, and funding proportional to the next evidence threshold.

If the mechanism does not improve the organization's ability to mobilize, decide and learn, stop or redesign it. If the workflow does not produce credible value, stop or redirect that hypothesis. If both work, the evidence—not enthusiasm—supports the next investment.

Recognize the problem before naming the model

Organizations often describe this challenge in new language before people have recognized their own experience in it. That is backwards. Begin with the stalled initiative, the missing resource, the unresolved decision, the pilot that never became normal work and the business case demanded too early. Once the pattern is visible, the root issue and the remedy become much easier to understand.

The problem is known. It has survived more than a decade of digital transformation because it is embedded in the way large organizations divide accountability, capability and money. Data and AI will not remove it. They make solving it more urgent.

Bring your real case to the open Masterclass

The Dairdux one-day open Masterclass is designed for leaders and practitioners who recognize these symptoms but do not yet have a practical mechanism for moving from ambition to validated value. It is relevant to business-side change leaders, data and AI leaders, product and transformation teams, and sponsors responsible for turning strategic intent into changed core work.

You will not be asked to adopt a large transformation blueprint. You will learn how to diagnose the structural constraint, frame the smallest complete innovation setting, steer investment by emerging evidence and define the first decision your organization can responsibly make.

Do not start by scaling a solution. Start by making one valuable change possible—and make the way you did it reusable.