Too many owners usually means nobody owns the outcome

An initiative has everything it needs. A business sponsor who wants new customers onboarded in days instead of weeks. A CIO who puts it on the roadmap. Architects for the integration, procurement for the selection, a vendor for the implementation. A security team for every interface, a data team for the migration, a project manager for the plan, operations for the training, and a consultancy for the change.

The platform goes live eighteen months later. Every workstream has closed green. And a new customer still waits almost as long as before. The three approvals that caused the delay moved from email into the new system, where they wait for the same three people.

Nobody failed at their part. The problem the whole effort was created to solve is still there, with a new platform around it.

Responsibility is not ownership of the outcome

Responsibility attaches to a deliverable. What you hand over defines it, and it ends when the other side accepts the handover. Ownership of an outcome answers to a different question, asked much later. Did it work?

A responsible specialist asks whether their part is done well. An owner asks whether the problem is solved, and if not, which part has to change. Only the second question puts scope, money and sequence back on the table, and only someone holding the whole can ask it with authority.

You can divide responsibility. That is what makes it useful. You can also break an outcome into measures. What you cannot divide is accountability for the result, because the result only exists as a whole. An initiative can have a dozen accountable people and still have nobody who answers for the outcome.

More specialists, more definitions of done

Adding expertise to a struggling initiative is the natural response, and often a correct one. Each specialist also brings a definition of success. The architect’s is a clean design. The vendor’s is scope delivered and signed off. Security’s is risk reduced. The project manager’s is the plan held.

Every one of these is legitimate. None of them is the outcome. A program can meet all of them on the same day the business problem goes unsolved. Each specialist can also say, accurately and in good faith, that a given problem is not theirs. The more specialists in the room, the more often that sentence is true.

Governance frameworks do not close this gap on their own, and not because they are badly designed. A RACI chart assigns an accountable name to every activity. It can be filled in completely, with a different name on every row, and still describe an initiative that nobody owns. It distributes accountability by activity. The outcome is not an activity. Adding a row for it helps only if the name on that row has authority over the other rows.

In 2024, PMI surveyed more than 5,700 projects and found that the project manager was the role most often seen as accountable for realizing a project’s benefits. Only 24 percent of respondents saw it that way, against 11 percent for other key stakeholders. The role closest to the whole is still, in most eyes, responsible for a part.

Specialists own parts. Someone still has to own the whole.

Intent leaks at the handoffs

The business case states the problem clearly, exactly once. Then the translating starts. Into requirements, into an architecture, into a statement of work, into a backlog. A competent person makes each translation for the audience that comes next, and each one loses a little of the why.

By the fourth translation the vendor is configuring an approval workflow, because that is what the backlog says. The requirement never said “remove the wait”, because the person who wrote it was describing the system rather than the problem. The original intent dropped out of the documents somewhere around the third one, and from then on it lived in the memory of whoever was still around from the start.

A stage gate checks that the deliverable is complete. It rarely checks that the deliverable still serves the problem.

The job between the parts

This is the job that distributed responsibility leaves unfilled in practice, even when a sponsor’s name sits at the top of the chart. The person who fills it does not need to be the deepest expert in any discipline. Their value is carrying the original business problem across the strategy, the process, the people whose work changes, the technology, the data, the vendors and the execution itself. At every step, they check that the decision in front of them still points at that problem.

Most of that work is noticing consequences that cross a boundary. Security adds a control and reintroduces the approval the program was meant to remove. The vendor’s scope cut, agreed sensibly in a cost review, drops the one feature that made adoption worth the training. Inside each discipline, the choice was reasonable. Seen across the whole, it trades the outcome away in installments.

The structure that makes delivery reliable is necessary and still not enough. Boundaries tell you where one responsibility ends. They say nothing about who is watching what crosses them. And the watching has to be continuous, because these connections break between steering meetings and look like progress from where they were made.

Four questions that show whether the whole has an owner

The test is simple to run and uncomfortable to answer.

1. Is it one name? Ask who answers for the result, not for the program. If the answer is a committee, or a sponsor who appears quarterly, the whole has no owner.
2. Is the original problem still intact? Can that person state it in the words it had at the start and point to where it lives in the current plan? If the plan now reads “deliver the platform”, scope has replaced intent.
3. Can they trade across parts? Ownership without the authority to move work and budget between workstreams and vendors is visibility with a better title.
4. Does it outlast go-live? The system arrives on launch day. The outcome arrives months later, in the year when the real load shows up. If accountability ends at launch, it ends before the result exists.

Who fills the role matters less than that one person does, with the mandate to match. It can be a business leader who learns enough of the technology to hold their own, or a CIO whose authority covers the business side as well as the systems. It can be an executive who signs for the result, with an outside advisor carrying the context across the parts. In product organizations it is meant to be the product owner, and the four questions apply just the same. What does not work is hoping the role assembles itself from the parts.

The question nobody is left to ask

In October 2024, Gartner published a survey of more than 3,000 CIOs and technology executives. On average, only 48 percent of their digital initiatives meet or exceed their business outcome targets. Organizations on the wrong side of that number rarely lack expertise. What they lack is context, the reason the work exists, carried by one person from the business case through the second year of operation, and handed over on purpose when that person moves on.

At closure, every function asks its own question. The project office asks whether the deliverables arrived. The vendor asks whether the client signed off. Both answers can be yes while onboarding still takes weeks. The question that matters is the one none of those roles is responsible for asking.

Did we actually solve the problem we started with?

Ask it before the work begins, and write down the name of the owner who will answer it at the end. If no name comes easily, the initiative already has its first risk, and it is not technical.