A technology portfolio promises more value than it can deliver when several business cases claim the same benefit and each is approved on its own. The CRM replacement claims a sales-productivity gain. The data platform claims the same gain, because it feeds the CRM. The automation program claims it a third time, because it removes the manual step the CRM created. Three sponsors, three approvals, one benefit. Nobody sums the promises, and at year end the CIO is asked why technology delivered a fraction of what was promised. The fix is a portfolio-level benefits register, owned above the technology leader, in which each benefit is counted once.

The Same Benefit, Claimed Three Times

The arithmetic of a double-counted portfolio is simple, and it is almost never done.

A mid-market company approves eleven technology initiatives in a planning cycle. Each arrives with a business case, a sponsor, and a benefits figure. The sales-productivity gain from the CRM replacement is written as four hundred hours a month returned to the sales team. The data platform's case, written by a different sponsor three weeks later, counts the same hours, because the platform is what makes the CRM's reports useful. The automation program's case, written by a third sponsor in a third meeting, counts them again, because the program removes the data-entry step the CRM would otherwise require.

Each case appears credible in isolation. The error becomes visible only when the portfolio's promises are combined. The portfolio now carries twelve hundred hours of promised benefit against a pool of four hundred, and no document anywhere shows the overlap.

Why Business Cases Are Approved One at a Time

Business cases are approved one at a time because approval is an initiative-level event, with an initiative-level sponsor, and no step in the funding process adds the promises together.

The funding meeting evaluates the case in front of it. The questions are the right ones for that case: is the benefit plausible, is the cost credible, does the sponsor have the standing to deliver it. The questions nobody asks are whether the benefit has already been claimed, and by whom. The case on the table has no field for that, the sponsor has no reason to know it, and the finance partner reviewing the case is reviewing this case.

The volume makes the overlap invisible. Research on IT portfolio management published in MIT Sloan Management Review, drawn from a survey of 130 Fortune 1000 chief information officers, describes IT budgets that "comprise hundreds or even thousands of projects running simultaneously across functions, business units and geographies," and argues for managing them as a portfolio for exactly that reason. A portfolio of that size cannot be checked for overlap by anyone reading cases one at a time.

Nobody is gaming the process. The distortion is emergent. It exists in the sum and in none of the individual decisions.

How a Portfolio Comes to Promise More Than Exists

A portfolio's promised benefits exceed what the company can realize through three mechanics, and all three are ordinary.

The first is the shared pool. A saving that can only be made once, such as a headcount reduction in accounts payable, is claimed by the invoice-automation case and again by the finance-platform case, because both touch the same team. The pool is one. The claims are two.

The second is the unstated dependency. A revenue lift in the e-commerce case assumes a product-data cleanup that lives in a different case, funded in a different quarter, with a different sponsor. If the second case slips, the first case's benefit was never available. The case does not say so, because the sponsor who wrote it was not thinking about the other one.

The third is sequence counted as simultaneity. Benefit B only exists after initiative A ships and is adopted. Both cases are approved in the same cycle, both benefits are booked for the same year, and the year is too short for either.

Add the three together across eleven initiatives and the portfolio's promised total can run well past the addressable base. The base rate for delivered value is already poor before any of this. McKinsey and Oxford research covering more than 5,400 IT projects found that large projects deliver, on average, 56 percent less value than predicted. Double-counting sits on top of that shortfall.

What the Technology Leader Answers For

At year end, the portfolio delivered a fraction of its promised total, and the CIO is the only executive attached to every case on the list.

The shortfall arrives as one number. The sales-productivity gain was realized once, as it could only ever be, and two of the three cases that claimed it show a miss. The accounts-payable saving was made, and one of the two cases that counted it is now reported as failing. The e-commerce revenue lift is absent because the product-data cleanup landed in the next fiscal year. None of these is a delivery failure. All of them are read as one, because the executive team sees a portfolio that promised twelve hundred hours and produced four hundred, and the technology leader is the name on the portfolio.

The second-order cost is worse than the first. The following year, every business case gets discounted, and the discount lands on the technology leader's budget credibility as well. The honest case and the overlapping case take the same haircut, because the executive team cannot tell them apart. The organization loses the ability to see which investments worked, which is the one thing a benefits figure is for.

The value-ownership problem, where a funded initiative has no one accountable for its outcome, compounds this. Here the outcome has an owner. It has three.

The Benefits Register: One Ledger, Counted Once

The remedy is a portfolio-level rule, and it belongs to the CFO or COO as part of capital allocation.

Every benefit in the technology portfolio is registered once, at the portfolio level, with a single owner. A business case that claims a benefit already on the register must declare the overlap and identify every initiative required to realize it. The benefit is counted once regardless of how many initiatives contribute to it.

One ledger, because the overlap is only visible from above the cases. A benefit that appears in three cases appears once on the register, and the register is the first place anyone would see that three cases are pointing at it.

One owner per benefit, because two owners of one saving is how it gets counted twice. The owner is the executive whose function realizes the benefit, which may be none of the three sponsors who claimed it.

Declared dependencies, because the declaration forces the sequencing conversation before funding. When the data platform's sponsor has to write that the benefit is the CRM's productivity gain and that realizing it requires the CRM to ship first, the dependency is on paper, the timing is on paper, and the funding meeting can decide with both in view.

The technology leader can propose the register and maintain the technology view of it. The CIO cannot own the business's benefits, and should not try. Ownership of the ledger sits with the executive who owns capital allocation.

What Changes When Benefits Are Counted Once

Counting benefits once moves the reckoning from year-end review to the funding meeting, which is the only place it is cheap.

Some cases lose their justification before funding. A case whose only benefit is already on the register, and which is not among the initiatives required to realize it, has to find a different benefit or make a different argument, and some cannot. That failure happens in the planning cycle, with no money spent.

Dependencies become visible as jointly enabled benefits. Two cases listed against one benefit are, by definition, related, and the register shows the relationship before anyone has to discover it in delivery. Sequencing becomes a funding decision made with the dependency in view.

The portfolio's promised total becomes a number that can exist. The technology leader is measured against a sum that the company could actually realize, and a miss against that sum means something.

What Technology Leaders Bring to the Executive Table

The benefits register is a capital-allocation design decision, and the executive team owns it. The CIO is positioned to propose it because the technology leader is the one executive who sees every case at once.

The move is one page. Down the left, every live initiative and its promised benefit. Across the top, the benefit pools those promises draw on. Where two or more cases draw on the same pool, the overlap is marked and the total claimed is written next to the size of the pool. The page makes the case for the register on its own. An executive team seeing the portfolio's promised total next to its addressable base usually does not need the argument explained.

Then the ask: adopt the register as part of how the portfolio is funded, with the CFO or COO as its owner and the technology leader maintaining the technology view. The subject throughout is the ledger. It is never any sponsor's honesty, and it is never how technology performance is measured.

Close: Count Before the Next Funding Cycle

The annual planning cycle is when overlap is cheapest to find, because the cases are all on the table at once and none of the money has moved. Year-end review is the most expensive time to find it, because by then the shortfall has a number and the number has a name.

The register takes one page to propose and one planning cycle to install. The conversation ends with the executive team owning the arithmetic of its own portfolio, which is where it belonged from the start.

A technology portfolio that promises more than it can deliver was never going to be judged fairly, and the technology leader is who gets judged. CIO Mastermind gives technology leaders a confidential peer forum for working through where a portfolio's promises overlap, how to bring the benefits register to the executive team, and how to be measured against a number that can actually exist. Explore the CIO Mastermind peer network.