A finance platform goes live in November, on schedule and slightly under budget. The steering committee closes the program and thanks the team. Eighteen months later the monthly close takes about as long as it did before, two of the four business units still run the spreadsheet workaround the platform was meant to retire, and the working-capital improvement that justified the investment appears in no report the CFO reads. Nobody can say when the outcome stopped being tracked, because nobody was ever assigned to track it. Delivery finished on schedule. The outcome that justified the spend never arrived. When the next funding request comes up, the CIO is asked to defend it line by line.

What Funding Actually Authorizes

Funding authorizes delivery. It does not establish ownership of value.

Most initiatives of any real size do have an executive sponsor. Sponsorship secures the money, clears political obstacles, and puts weight behind the schedule. Accountability for the outcome after the system is live is a separate assignment, and the funding decision rarely makes it. Approval sets a budget, fixes a scope, names a delivery date, and points at the technology organization to build the thing. It closes without naming who is answerable when the intended business result arrives or fails to. The approval record is complete by its own standards and silent on the only question that determines whether the money worked.

That silence is a design choice, made by default rather than on purpose. Every organization has a process for authorizing spend. Very few have a process for authorizing outcome accountability at the same moment, with the same rigor, in the same document.

Where The Value Gap Opens: The Handoff Nobody Owns

The gap opens at the handoff. A business unit defines what it needs, the technology organization builds it, and the business receives it at launch. Between those two points the initiative belongs to IT, and at go-live it returns to a business that has been largely absent from it for months.

The intended value almost never lives in the software. It lives in operational change that follows the software: redesigning the process the system was built to support, retraining the people who run it, retiring the workaround that competes with it, and holding the new practice in place long enough for it to become how work is done. None of that can be owned by the delivery team alone. The organization treats go-live as the finish line because go-live is the last event anyone scheduled.

Delivery metrics conceal this completely. On time, on budget, and on spec can all be satisfied while the business result never arrives, and a program can close green on every measure the steering committee reviews. McKinsey's transformation research puts a number on what follows: an average of 20 percent of a transformation's value is lost after its initiatives have been fully executed. That loss lands in the window after delivery ends, which is the window nobody was assigned to watch. An analysis of project practice describes the same structural problem in plainer terms: delivering a project on budget and on time does not guarantee that its benefits are realized.

The Three Owners Every Funded Initiative Needs

Every funded technology initiative requires three distinct owners, named before work begins.

The delivery owner is the technology leader accountable for technical delivery. The system works, integrates with what surrounds it, meets security and reliability standards, and can be supported after launch. This role is almost always assigned, usually well.

The value owner is the business executive accountable for adoption and the intended business outcome. Adoption and outcome belong to the same person. Splitting them across two executives produces an adoption number that nobody connects to a business number. The value owner runs the process change, retires the competing workaround, and reports the outcome against the target that justified the spend.

The governance owner is the CEO or CFO accountable for ensuring that delivery ownership and value ownership stay connected. This role owns the connection between the other two and does not own either one directly. It exists because the two owners report through different structures, answer to different incentives, and have no standing mechanism that binds them to each other. The governance owner holds the funding decision, which makes that office the only one positioned to bind them at the moment the money is approved.

What It Costs To Leave Value Unowned

The cost shows up as slow leakage across a portfolio, and it compounds quietly enough that no single review catches it.

The same McKinsey research identified clear roles and responsibilities for monitoring progress as one of the factors separating transformations that hold their gains from those that give them back. Value that is nobody's job tends to drift toward the losing side of that line.

The second cost lands on the technology leader. Renewals get funded on the assumption that the original case held, because no one measured whether it did. Over several cycles the organization accumulates a portfolio of investments with no evidenced results, and the absence of evidence becomes the operating memory. A CFO reviewing the next request has no track record to reason from, so technology spend gets read as discretionary and reviewed one line at a time. The scrutiny is a reasonable response to missing information. It rarely gets recognized as a consequence of ownership that was never assigned.

Name The Value Owner At The Funding Decision

The first fix is specific, testable, and takes one sentence in an approval meeting: a named business executive, recorded in the approval, accountable for adoption and the outcome, identified before the money moves.

The test is whether the name appears in the funding record rather than in a conversation. Sponsors are frequently named. Value owners are frequently assumed, and an assumed owner produces the same result as no owner once the delivery team disbands and moves to the next program.

The technology leader is well positioned to raise this and poorly positioned to assign it. The framing that works is a question asked before approval closes: who owns the outcome once this is live, and can their name go on the approval alongside the budget. Timing determines how it lands. At the funding decision the question reads as rigor. After launch, with a result missing and an explanation being sought, it acquires a defensive tone the technology leader rarely intends.

Define The Value Measure And Measurement Date Before Work Begins

A measurement date with no agreed measure and target is a calendar entry. Three elements have to be fixed together at approval.

The measure names what will be tracked, in a number the business already reports. The target names what result counts as value realized, with a figure attached rather than a direction. The date names when it gets checked, far enough past go-live that adoption has had time to take hold. The value owner and the funder agree all three before work begins, and both sign the same definition.

Measures chosen after launch get chosen, consciously or not, to fit whatever results are already available. A metric picked in hindsight will almost always show something defensible. Fixing the measure in advance is what makes the later review capable of returning an uncomfortable answer. An assessment of project practice framed this as a sequence of questions asked at initiation rather than at closeout: how success will be measured, who signs off on the intended business outcomes before work starts, and who confirms at the end that they were delivered.

What Executive Leadership Owns In The Connection

The connection between delivery and value belongs to the executive leadership responsible for approving the investment. The technology organization cannot hold it, because adoption sits outside its control. A single business unit cannot hold it, because no unit has standing to hold another accountable. It sits with the office that approves the money, and it gets established at approval or it gets established late.

For the CIO, the useful move is to stop treating this as an IT problem to solve and start treating it as a governance gap to name. Technology leaders who raise it early, in the language of decision quality rather than the language of project management, tend to find the conversation lands with executive peers rather than bouncing back as an IT concern.

Take one question into the next funding approval, before it closes.

Who owns the outcome, what number proves it, and on what date do we check?