Solution Scoping and Ownership

The example I keep coming back to is a corporate governance specialist.

Somebody spots an opportunity to automate part of the governance process. Maybe it's drafting committee packs, tracking actions, reviewing submissions against standing orders or answering routine governance questions.

The first instinct is often to think about the technology. What agent should we build? What tool should we use? Who can develop it?

But we've increasingly found those are the wrong questions to start with. The more important question is whether the person asking for the solution can explain exactly how the work is done. Because no central team can do that for them.

A governance specialist knows why one submission is acceptable and another isn't. They know which exceptions matter. They know where judgement is required and where process can be followed mechanically. They know which mistakes are annoying and which mistakes create risk.

The agent builder doesn't, and why would they? If they understood governance well enough to define the process, the rules, the risks and the exceptions, they'd probably be working within that function.

That's why subject matter experts need to be involved from the very start.

Not as consultees or people who only provide a requirements document, but as part of the solution build itself. This is obvious and understood by (nearly) everyone. What often gets missed is that this doesn't stop once the solution is deployed. The same person who helped define the process needs to be prepared to own it afterwards.

If the outputs drift, somebody has to notice. If an instruction stops producing the right results, somebody has to fix it. If the solution starts giving people incorrect information about a service, somebody has to take accountability for that too.

In practice, it's easier to think about this in human terms.

Imagine hiring a new member of staff. You wouldn't ask a central AI team to write the job description, recruit them, train them, supervise them and manage their performance on your behalf forever. You would own that because they're operating within your function. An agent is no different really.

You're creating a digital employee that becomes part of the process. It may be software rather than a person, but it still needs direction, oversight, testing and management by the people who understand the work, in the same way your existing team would.

That's the lesson that has emerged most clearly from our programme. A solution without a subject matter expert who owns it is not a solution. It's just a product. A product that doesn't quite solve the problem.

Our ideas won't fail because the solution isn't good enough. It'll more likely be because nobody in the receiving area can properly own them. The technology works, but the ownership doesn't. And when ownership doesn't exist, responsibility gradually falls back to the central team and what looked like a scalable solution becomes a permanent dependency.

That's why one question increasingly sits at the front of our scoping conversations. Before we ask whether something can be built, we ask who will own it. If the answer is unclear, in most cases, we probably shouldn't build it.

There is some nuance to that. In the early stages of establishing a build function, greater reliance on a central team is almost inevitable because that's where the build expertise sits. That's fine. The problem emerges when there isn't a plan to move from heavy central involvement towards local ownership.

Without that plan, you're effectively making a bet that the initial pilot solutions will continue to deliver benefits that justify all AI investment forever. Because the people who built the solution also become the people who run it, maintain it and support it. Eventually their focus shifts from building tomorrow's solutions to owning yesterday's ones. And clearly, that's not going to work for very long.

There's also some nuance in the decision to build or not build. Sometimes the answer isn't no. It's not yet. Or more accurately, not that version. A team may not be ready to own the most sophisticated version of a solution today, but there may be a version that delivers value now, can be sustained by the receiving function, and forms part of a bigger solution later.

Done well, that creates value today whilst giving people a reason to grow their confidence, capability and ambition over time. Rather than shutting the door with a flat no.

So the main lesson? Ideas are cheap and digital maturity really matters.

There are hundreds of things most organisations could build. The question isn't simply whether a solution can be built. It's whether it can be built and then safely sustained by the people expected to own it, in a way where the benefits outweigh the cost of creating and supporting it.