Sanjay K Mohindroo
IT value gets lost when CIOs speak technology instead of economics. Use five CFO-ready lenses to connect IT investment to business outcomes.
Your CFO Does Not Care About IT Value. Translate It.
The budget request was technically flawless. The CFO still said no.
Not because the technology was weak, but because the value case was written in a language finance did not use.
I have seen versions of this conversation repeatedly over the years. Technology leaders arrive with architecture diagrams, transformation roadmaps, uptime improvements, cybersecurity scores, cloud migration percentages, technical debt measures, and increasingly, AI use cases.
Finance asks a different set of questions.
What happens to cash?
What cost disappears?
What risk are we buying down?
What business capacity are we creating?
When will we know whether the investment worked?
If those questions are not answered clearly, the problem is rarely that the CFO "doesn't understand technology."
The problem is that IT has not translated its value.
And that leads to a view I suspect some technology leaders will dislike:
The CIO's job is not to make the CFO understand IT. The CIO's job is to make IT understandable in financial and business terms.
That distinction matters.
The Conventional Wisdom That Needs Challenging
The conventional wisdom says IT needs to "prove its ROI."
That sounds sensible. It is also too simplistic.
Not every technology investment should be justified through a neat project-level return on investment calculation.
A cybersecurity control may prevent an event that never happens.
A platform modernization may remove constraints from five future initiatives rather than create revenue by itself.
A data program may improve decisions across multiple functions without appearing as an isolated line of incremental profit.
A resilient infrastructure investment may look expensive until the day a competitor experiences a major outage and you do not.
Trying to force every technology decision into the same ROI formula can create false precision. Worse, it can bias capital toward initiatives with easily measurable short-term benefits while starving investments that protect resilience, strategic capacity, and future options.
The better question is not:
"What is the ROI of IT?"
It is:
"What financial or strategic outcome does this investment change, by how much, over what period, with what confidence?"
That is the CFO's language.
Why IT Value Gets Lost in Translation
Technology leaders and finance leaders often look at the same investment through fundamentally different lenses.
IT might describe a cloud modernization program in terms of:
- application rationalization,
- infrastructure modernization,
- automation,
- improved scalability,
- lower technical debt,
- faster deployment.
All legitimate.
But the CFO hears a request for capital.
The CFO is comparing that request with a factory expansion, an acquisition, a new market entry, debt reduction, additional sales capacity, or simply keeping the cash.
That changes the conversation.
Technology is not competing only against other technology projects. It is competing for enterprise capital.
That means every major IT investment should survive the same questions applied to other capital decisions.
What economic outcome changes?
What is the timing?
What assumptions drive the case?
What could go wrong?
What other choices are we giving up by funding this?
Who owns realization of the benefit?
This is where many IT business cases weaken.
They explain what will be built.
They do not explain what will become economically different.
Stop Reporting Technology Activity as Business Value
One of the most persistent mistakes in executive reporting is confusing activity with value.
Consider these statements:
"We migrated 70 percent of workloads."
"We reduced critical vulnerabilities."
"We automated 40 processes."
"We deployed an enterprise AI platform."
"We improved system availability."
Each may represent meaningful progress.
None, by itself, tells the board whether the company is better off.
A CFO needs the second sentence.
"We migrated 70 percent of workloads, which allows us to retire two legacy environments and removes a defined annual operating cost."
"We reduced critical vulnerabilities, lowering exposure in the systems responsible for our highest-value revenue processes."
"We automated 40 processes, eliminating a specific amount of manual processing effort and increasing transaction capacity without proportional headcount growth."
"We deployed an enterprise AI platform, reducing the marginal cost and cycle time of selected knowledge-intensive processes."
"We improved system availability, reducing expected interruption to revenue-generating operations."
The technology metric establishes that something happened.
The financial translation explains why the enterprise should care.
A Five-Part Framework for Translating IT Value
For major technology investments, I use a simple boardroom test.
Every investment should be translated across five dimensions:
1. Cash
2. Cost
3. Capacity
4. Control
5. Competitive Options
Not every investment will score highly in all five areas. It does not need to.
But if a significant technology program cannot produce a credible answer in any of them, the value proposition probably needs more work.
1. Cash: What Changes in Economic Terms?
Start with the most obvious question.
What happens to cash flow, revenue, working capital, or capital expenditure?
Technology leaders often jump too quickly to cost savings because they appear easiest to quantify. But technology can change cash economics in several ways.
A platform might reduce the time required to launch a product.
An analytics capability might improve pricing decisions.
A supply-chain system might reduce inventory.
A digital channel might improve conversion.
A billing modernization program might shorten the cash collection cycle.
The strongest cases make the causal chain visible.
Not:
"Implement analytics to improve decision-making."
But:
"Improve demand forecasting, reduce excess inventory, and release working capital."
The closer the technology investment is connected to an economic mechanism, the easier it becomes for finance to evaluate it.
2. Cost: What Expense Disappears or Stops Growing?
Cost reduction is familiar territory, but it is frequently overstated.
Technology teams sometimes present "productivity improvement" as though it automatically becomes savings.
It does not.
Saving employees ten minutes per day does not reduce expenditure unless the organization does something economically useful with those ten minutes.
The benefit may still be real. Employees might handle more transactions, improve service, accelerate sales, or avoid additional hiring.
But call it what it is.
There is an important distinction between:
- hard cost removal,
- cost avoidance,
- productivity improvement,
- capacity creation.
Finance will treat them differently, and it should.
A credible IT business case does the same.
3. Capacity: What Can the Business Do That It Could Not Do Before?
This is one of the most undervalued dimensions of technology investment.
Many technology initiatives do not immediately produce revenue or remove expense. They expand the company's capacity to operate.
That might mean supporting twice the transaction volume without doubling operating cost.
It might mean reducing the time required to integrate an acquisition.
It might mean entering a new geography without building an entirely new technology stack.
It might mean launching products in weeks rather than quarters.
Capacity matters because growth often exposes the weaknesses of yesterday's architecture.
A platform that supports today's business may still be economically inadequate if tomorrow's growth requires adding cost at the same rate as revenue.
A CFO understands operating leverage.
Translate technology scalability into that language.
4. Control: What Risk Are We Reducing?
Risk discussions between CIOs and CFOs often fail because IT presents technical exposure while finance thinks in economic exposure.
"Critical vulnerabilities" are important.
So are unsupported systems, concentration risk, weak recovery capability, data quality problems, regulatory exposure, and dependency on scarce technical skills.
But risk becomes much more actionable when framed as:
Probability × impact × exposure period.
The numbers will rarely be perfect. They do not need to be.
The purpose is not to manufacture mathematical certainty. It is to make assumptions visible.
Instead of saying:
"We must replace this legacy platform because it is high risk."
Say:
"This platform supports a business process responsible for a material proportion of daily transactions. Vendor support ends next year. Recovery depends on skills held by a very small number of employees. Our proposed investment reduces both operational concentration risk and recovery exposure."
Now the board can discuss risk appetite rather than debate technology terminology.
That is a much better conversation.
5. Competitive Options: What Future Choice Are We Buying?
This is where traditional ROI thinking often becomes weakest.
Some investments create options.
A clean data architecture may make future AI initiatives cheaper and faster.
A modular platform may allow acquisitions to be integrated faster.
API capabilities may make new distribution partnerships possible.
Modern infrastructure may allow the company to enter a geography without rebuilding its technology environment.
These benefits are difficult to value precisely because the future action may not yet be committed.
But boards allocate capital to strategic options all the time.
A company may purchase land before expansion is approved.
It may acquire intellectual property before the full commercial opportunity is known.
It may enter a market partly to establish future strategic positioning.
Technology should not receive a free pass from financial discipline. But neither should strategic technology capability be dismissed simply because it cannot be reduced to a twelve-month payback calculation.
The correct question is:
What future action becomes faster, cheaper, safer, or possible because we make this investment now?
That is option value.
The Missing Question: Who Owns the Benefit?
There is another uncomfortable truth about IT business cases.
Technology teams are often held accountable for delivering systems whose financial benefits depend on someone else changing the business.
Imagine a program designed to automate a finance process.
IT delivers the platform successfully.
The business continues operating with the same staffing model, approval layers, and manual workarounds.
The technology project is complete.
The savings never appear.
Was the technology unsuccessful?
Not necessarily.
The benefit case failed because implementation and value realization were treated as the same thing.
They are not.
For every major IT investment, I would ask two separate questions:
Who owns delivery?
And:
Who owns benefit realization?
The CIO may own the first.
The CFO, COO, business-unit leader, or functional executive may need to own the second.
Once this accountability is explicit, the quality of technology investment decisions improves dramatically.
A Better One-Page IT Investment Case
Before a significant technology request reaches an executive committee or board, it should be possible to summarize it on one page.
Not the entire program.
The decision.
That page should answer seven questions:
1. What business problem or opportunity are we addressing?
2. What happens financially if we do nothing?
3. Which of the five value dimensions will change: cash, cost, capacity, control, or competitive options?
4. What measurable business outcome will change?
5. What assumptions must be true for the value to materialize?
6. Who owns realizing the benefit?
7. When will management review whether the expected value actually appeared?
Notice what is missing.
Server counts.
Architecture diagrams.
Vendor feature comparisons.
Migration percentages.
They may matter to the teams executing the program.
They rarely belong at the center of the capital allocation decision.
The CFO Is Not the Last Stop in the Business Case
Another common mistake is bringing finance into the process after the technology solution has effectively been chosen.
At that point, the conversation becomes negotiation.
IT wants funding.
Finance wants justification.
Both sides defend positions.
A better approach is to involve finance earlier.
Ask the CFO's team to challenge the economic assumptions before the preferred solution becomes emotionally or politically committed.
Which benefits are credible?
Which are merely potential?
What should count as cost avoidance?
How should risk reduction be treated?
Which assumptions should be sensitivity-tested?
What benefit should appear in the operating plan?
That conversation does more than strengthen the spreadsheet.
It creates shared ownership of the logic behind the investment.
Technology Leaders Should Learn Capital Allocation
The next generation of CIO credibility will not come from being more technically articulate.
It will come from becoming more economically articulate.
Senior technology leaders need to understand the language of:
- operating leverage,
- cash flow,
- working capital,
- margin,
- cost of capital,
- risk,
- scenario analysis,
- opportunity cost,
- capital allocation.
Not because CIOs should become accountants.
Because technology has become capital.
In many enterprises, decisions about AI, cybersecurity, cloud, data, digital platforms, automation, and resilience now shape some of the company's largest strategic commitments.
If technology wants a permanent seat in those conversations, it cannot ask finance to translate on its behalf.
Measure Value After Approval, Not Just Before It
Most organizations put enormous effort into proving value before an investment is approved.
Far fewer return twelve or eighteen months later and ask whether the value actually appeared.
That is backwards.
A business case should be treated as a hypothesis.
We believe this investment will produce these outcomes because these assumptions are true.
Then measure them.
Did the legacy cost disappear?
Did capacity increase?
Did cycle time fall?
Was additional hiring avoided?
Did risk exposure decline?
Did the business use the capability that was created?
If not, why not?
That feedback improves the next capital decision.
Without it, organizations develop a strange ritual where every project has an impressive business case, and nobody can say, several years later, whether the portfolio produced what was promised.
That is not technology governance.
It is approval governance.
The board should demand the former.
The Translation Is the Leadership Work
Technology value does not become strategic because the CIO says it is strategic.
It becomes strategic when its relationship to enterprise outcomes is clear.
The best technology leaders I have seen do not overwhelm the board with technical sophistication.
They simplify.
They connect technology choices to economic consequences.
They distinguish savings from capacity.
They distinguish technical risk from enterprise exposure.
They make assumptions visible.
They assign ownership for benefits.
And they return later to determine whether the value actually materialized.
That is how IT stops being perceived as a cost center asking for money and starts being treated as a disciplined allocator of enterprise capital.
The next time a technology proposal goes to the CFO, do not begin by asking, "How do we explain the technology?"
Ask:
What changes economically if we make this decision, and what changes if we do not?
That is the conversation that matters.
Where does your organization still struggle most when translating technology investment into financial value: cost, risk, growth, or accountability?
If this is a conversation your leadership team is wrestling with, subscribe to TechnologyTrends or add your perspective in the comments.