Sanjay K Mohindroo
Technology value is not the CIO's job alone. A practical framework for making business leaders accountable for technology outcomes and ROI.
Making the Business Own Technology Outcomes
After nearly three decades around enterprise technology, I have seen the same sentence end too many difficult meetings:
“IT needs to fix this.”
Sometimes the problem was a delayed platform. Sometimes adoption was poor. Sometimes the investment had delivered the system everyone asked for, but not the business result everyone had promised.
The conventional wisdom is that when a technology programme succeeds or fails, the CIO should be accountable.
I disagree.
The CIO should be accountable for technology delivery, resilience, architecture, security and technology economics. But if the intended outcome is higher revenue, lower operating cost, faster fulfilment, improved customer retention or reduced business risk, then the business must own that outcome.
Otherwise, we create one of the most expensive governance failures in modern enterprises: business leaders approve technology investments, IT delivers them, and nobody outside IT is truly accountable for extracting the value.
That model has to change.
Technology Accountability Is Not the Same as Business Accountability
Most large technology programmes begin with a business case.
The language is rarely technical.
Increase conversion. Reduce processing time. Improve forecast accuracy. Lower inventory. Accelerate product launches. Reduce regulatory exposure. Improve customer retention.
Yet something strange often happens after the investment is approved.
The business objective remains in the presentation, while operational accountability migrates toward IT.
The programme gets a technology steering committee. Progress becomes milestones, integrations, releases and budgets. The CIO is asked why adoption is slow, why productivity has not improved or why the return on investment has not appeared.
But a CIO cannot force a sales organisation to change its selling process.
A technology team cannot redesign decision rights inside a supply chain.
A platform cannot eliminate redundant approval steps if the business insists on preserving them.
And no software can produce a return on investment if management treats implementation as the end of the transformation.
This is where many boards confuse technology accountability with business accountability.
They are not the same thing.
The Conventional Wisdom Is Wrong: The CIO Cannot Own the Entire Outcome
There is a comfortable management assumption that technology transformation belongs to the CIO because technology is involved.
That logic would sound absurd in almost any other area of business.
We do not tell the CFO to own revenue because pricing sits in the financial model.
We do not tell HR to own sales performance because salespeople require recruitment and incentives.
We do not tell the general counsel to own market expansion because contracts are required.
Technology should be treated the same way.
When the objective is a business outcome, the accountable executive must come from the part of the organisation that can change the process, behaviour, incentives and operating model required to achieve it.
The CIO remains a critical co-owner.
But co-ownership is different from becoming the organisational shock absorber for every missed transformation target.
#DigitalTransformation
Why Technology Value Disappears After Approval
The business case for a major technology investment usually receives more scrutiny before approval than after implementation.
That is backwards.
Before approval, executives debate benefits, payback periods, risks, and strategic necessity.
Once capital is committed, attention shifts toward delivery.
The question changes from:
“What business result are we buying?”
to:
“Are we on schedule?”
Schedule matters. Cost matters. Technical quality matters.
But none of those prove that the investment created value.
A programme can be on time, within budget and technically sound, while still being a poor business investment.
That is the distinction boards need to enforce.
Technology delivery is an output.
Business value is an outcome.
The two are connected, but they are not interchangeable.
Shared Accountability Does Not Mean Nobody Is Accountable
There is another danger here.
Whenever organisations hear “shared accountability,” responsibility can become blurred across committees, functions and steering groups.
That is not what I am proposing.
Shared accountability should not mean collective ambiguity.
It should mean two clearly named executives accepting responsibility for different sides of the same investment.
One executive owns the technology capability.
One executive owns the business result.
The relationship should be explicit enough that the board knows who must answer which question.
That distinction becomes especially important when results disappoint.
If the platform is unstable, the technology leader should answer for it.
If the platform works but the business has not changed the process, incentives or behaviours required to capture value, the business leader should answer for that.
If both have failed, both should be accountable.
That is far healthier than asking the CIO to explain every number on the benefits case.
The Shared Outcome Accountability Framework
For any material technology investment, I would encourage boards and CEOs to insist on five things before approving capital.
1. Name a Business Outcome Owner
Every significant technology programme should have one senior business executive whose name sits beside the promised business result.
Not a committee.
Not “the business.”
A person.
If the investment promises to reduce cost-to-serve, improve customer conversion or shorten the order-to-cash cycle, someone with authority over that operating outcome must own it.
The test is simple:
If the technology works exactly as designed but the expected business benefit does not appear, who is called into the CEO's office?
If the answer is automatically “the CIO,” the governance model is incomplete.
2. Name a Technology Outcome Owner
The CIO, CTO, or relevant technology executive should own the technology conditions necessary to produce the business result.
That includes delivery quality, scalability, security, resilience, interoperability, and total technology economics.
This is not diluted accountability.
It is sharper accountability.
The technology leader is no longer expected to own matters outside their control, while becoming far more clearly responsible for the technology commitments that are within it.
3. Translate the Business Case Into Operating Metrics
Many transformation programmes fail because their benefits remain trapped in the original investment paper.
A promise such as “improve productivity” is too vague.
What changes?
Processing time from what to what?
Conversion from what baseline?
Inventory by how much?
How many manual interventions should disappear?
How much working capital should be released?
By when?
If management cannot answer those questions, the programme does not yet have a measurable outcome.
One metric I like boards to ask for is a simple value bridge:
Baseline performance → technology-enabled change → business behaviour change → financial outcome
This forces executives to explain how the investment actually creates value.
It also exposes assumptions hidden inside large return-on-investment numbers.
4. Make Business Change Part of the Investment
This is where many business cases become unrealistic.
The capital request funds the platform but understates the cost of changing the organisation around it.
Training is budgeted.
Transformation is not.
There is a difference.
Real business change may require redesigning processes, removing controls, changing incentives, consolidating roles, rewriting policies or abandoning practices that senior leaders themselves created.
Those decisions cannot be delegated to the technology function.
Boards should therefore ask a harder question before approving transformation capital:
What must the business stop, start or change for this investment to generate the promised return?
If there is no uncomfortable answer, the transformation may not be transformative enough.
5. Review Value After Go-Live, Not Just Delivery
For many programmes, governance intensity peaks before implementation and falls immediately afterwards.
It should continue until the promised outcome is either achieved, revised with evidence or formally written off.
A board does not stop reviewing an acquisition the moment the transaction closes.
Technology investments deserve similar discipline.
At 90 days, six months and twelve months after implementation, management should be able to answer:
What value has been realised?
What has not?
Which assumptions were wrong?
Which business changes have not happened?
What additional capital is required?
Should we continue, change direction or stop?
This turns technology governance into capital governance.
That is where it belongs.
A Useful Boardroom Distinction: Adoption Is Not Value
Another mistake is using adoption as proof of success.
Adoption can be encouraging, but it is an intermediate measure.
A thousand employees logging into a new platform does not demonstrate value.
The important question is what changed because they used it.
Did decisions become faster?
Did error rates fall?
Did customers behave differently?
Did the organisation require fewer manual interventions?
Did revenue improve?
Did risk decrease?
I have seen organisations celebrate usage statistics while the original economics of the investment quietly disappeared from discussion.
That is dangerous.
Management should track adoption because poor adoption can prevent value.
But adoption itself is not the destination.
#CIO
What Happens When the Business Really Owns the Outcome
The quality of decision-making changes.
Business executives begin asking different questions before approving technology expenditure because they know their own performance will ultimately be measured against the result.
Requirements become more disciplined.
“Nice to have” functionality receives more scrutiny.
Process redesign happens earlier.
Adoption stops being somebody else's problem.
And benefits are less likely to become theoretical numbers added to a presentation simply to pass an investment threshold.
There is another benefit.
The relationship between the CIO and business leadership becomes healthier.
Instead of IT acting as supplier and the business acting as customer, both sides become investors in a common result.
That is a far more mature operating model.
The Counter-Argument: The Business Does Not Understand Technology
I often hear a version of this objection:
“The business cannot own something it does not understand.”
I think that confuses understanding the technology with owning the outcome.
A CEO does not need to understand every engineering detail of a factory to hold the operations leader accountable for manufacturing performance.
A board does not need to understand every quantitative model used by treasury to hold the CFO accountable for financial risk.
Business leaders do not need deep technical expertise to own the result a technology investment is supposed to produce.
They need to understand what they are buying, what assumptions underpin the value case, and what their organisation must change to realise it.
If they cannot do that, the answer is not to transfer accountability to IT.
The answer is to improve the quality of executive decision-making.
Technology Governance Should Follow the Money
At board level, technology is increasingly one of the largest pools of discretionary and strategic investment.
That means technology governance cannot remain a specialist conversation.
It is a capital allocation conversation.
For every major programme, directors should know:
What business outcome are we purchasing?
Who owns that outcome?
What assumptions connect the investment to financial value?
Which business changes are required?
What happens if the value does not materialise?
These are not CIO questions.
They are management questions.
And once boards begin asking them consistently, something useful happens: technology stops being viewed as an expensive department that periodically requests capital.
It becomes what it should have been all along, an instrument for changing business performance.
The Real Accountability Test
There is one question I would put to any executive team approving a major technology programme:
If this system works perfectly and the business case still fails, who owns the failure?
If the answer is unclear, the programme is not ready for approval.
If the answer is “IT,” despite the promised benefits sitting in sales, operations, finance or customer experience, the accountability model is wrong.
The best technology organisations I have seen do not ask the business to “support” transformation.
They make the business own the transformation with them.
That is the shift boards should demand.
Not more steering committees.
Not another alignment workshop.
Clear ownership of business outcomes, paired with clear ownership of technology performance.
Because when everybody benefits from technology, but only the CIO is accountable for the result, accountability is not shared.
It is outsourced.
How does your organisation handle this today? When a technology investment delivers the system but misses the business result, who actually owns the outcome?
If this resonates, subscribe to TechnologyTrends or add your perspective in the comments.