Why IT-Business Partnership Keeps Failing

Previous
Why the "IT-business partnership" cliché keeps failing

Sanjay K Mohindroo

The IT-business partnership model is failing. The real issue is split accountability for outcomes, capital, trade-offs, and technology value.

Why the IT-Business Partnership Cliché Keeps Failing

The phrase I distrust most in a transformation meeting is: “IT needs to partner more closely with the business.”

After nearly three decades around enterprise technology, I have learned that this sentence often reveals the real problem. The organisation has already separated technology from business accountability, and is now trying to repair the gap with better relationships.

That rarely works.

The conventional wisdom says IT must become a “trusted business partner.” CIOs are encouraged to speak the language of business, sit closer to business leaders, understand commercial priorities, and become more collaborative.

All sensible advice.

But the premise is increasingly outdated.

If IT still needs to “partner with the business,” we are implicitly saying IT is not part of the business.

And in a company where customer experience, pricing, supply chains, risk, productivity, distribution, and increasingly the product itself depend on technology, that distinction is no longer harmless.

It creates an accountability problem.

The Problem Is Not Alignment. It Is Split Accountability.

I have seen versions of the same situation repeatedly.

A business leader owns an ambitious growth target. Technology is asked to build the capabilities required to support it. Finance approves the investment. Operations must change processes. Frontline teams must adopt new ways of working.

Then the initiative starts slipping.

The business says IT is moving too slowly.

IT says requirements keep changing.

Finance asks why the benefits have not appeared.

Operations says the solution does not fit reality.

Everyone was involved.

Nobody owned the whole outcome.

That is not a partnership failure in the interpersonal sense. The executives may have excellent relationships.

It is an operating model failure.

The organisation has assigned responsibility for the business outcome to one group, responsibility for the technology to another, responsibility for the money to a third, and responsibility for adoption somewhere else.

Then it holds meetings to create “alignment.”

No number of steering committees can compensate for badly designed accountability.

Why the IT-Business Divide Is Becoming More Expensive

Twenty years ago, it was at least possible to think of many technology decisions as support decisions.

Today, technology increasingly determines how the enterprise competes.

A decision about data may affect pricing.

A decision about architecture may determine how quickly the company can launch in a new market.

A decision about automation may alter the economics of an operating model.

A decision about cybersecurity may affect the organisation's risk exposure and even its licence to operate.

A decision about artificial intelligence may change workforce requirements, customer experience, intellectual property risk, and capital allocation simultaneously.

These are not merely IT decisions.

They are business decisions expressed through technology.

Yet many organisations still govern them using a structure inherited from an era when IT primarily kept systems running.

That is why the language of partnership has become misleading.

The CEO does not normally ask finance to “partner with the business” before deciding where capital should go. Finance is part of how the business makes that decision.

Technology increasingly needs to be treated the same way.

What a Fake IT-Business Partnership Looks Like

The warning signs are surprisingly consistent.

The business writes the requirements, then IT estimates the delivery date.

The business case contains revenue or productivity benefits, but technology is measured mainly on cost and delivery.

Projects are approved individually without examining what must be delayed or stopped to create capacity.

Business sponsors disappear once funding is approved and return when implementation problems appear.

IT is expected to say yes to strategic priorities that collectively exceed available capital, talent, or organisational capacity.

And when results disappoint, each function can produce evidence showing that it completed its part.

That last point matters.

A company can have excellent functional performance and poor enterprise performance at the same time.

The technology team can deliver the system.

The business team can conduct training.

Finance can keep spending within the approved envelope.

The programme can still destroy value.

The board should care about the last outcome, not whether each department can defend its own scorecard.

The Four Tests of a Real Technology Partnership

Rather than asking whether IT and the business are “aligned,” I would ask four harder questions.

A real partnership requires shared outcomes, shared capital, shared trade-offs, and shared accountability.

If one of those is missing, collaboration may be strong, but the partnership is largely ceremonial.

1. Do We Share the Outcome?

Every major technology investment should have a business outcome that both the business executive and technology executive are accountable for.

Not “implement the platform.”

Not “migrate the applications.”

Not “complete Phase 1.”

Those are delivery milestones.

The outcome might be reducing order-to-cash time, increasing conversion, lowering cost to serve, reducing operational risk, improving forecast accuracy, or allowing a product to reach market faster.

The important point is that the metric cannot belong only to the business while IT owns a separate technical measure.

If one executive succeeds when the system launches and another succeeds only when the business benefit appears, their incentives diverge exactly when the difficult decisions begin.

The board should ask a simple question:

What number will move if this investment works, and which two executives own that number together?

If the answer is unclear, the partnership is unclear.

2. Do We Share the Capital Decision?

Technology portfolios are capital allocation portfolios, whether companies describe them that way or not.

Every rupee, dollar, pound, or euro committed to one technology initiative is capital unavailable for another priority.

Yet many companies still treat technology demand as a queue.

Business units submit requests. IT estimates effort. Projects are ranked. Budgets are negotiated.

The uncomfortable discussion is often missing: What are we choosing not to do?

That question changes behaviour.

Take the kind of situation I have seen many times in large enterprises. Five business units each present a project that is individually defensible. Each promises revenue, productivity, risk reduction, or customer improvement.

The problem appears only when you consider them together.

They depend on the same scarce people.

They require overlapping organisational changes.

They compete for management attention.

And their combined benefits assume the business can absorb several major changes simultaneously.

The portfolio may be financially funded while being operationally impossible.

A genuine technology partnership therefore requires business and technology leaders to allocate capital together.

Approval cannot mean, “The business wants it, IT must find a way.”

Approval means accepting the opportunity cost.

3. Do We Share the Trade-Offs?

This is where many supposed partnerships break down.

Everyone agrees on priorities until something has to give.

A launch date is fixed, so scope must change.

A budget is constrained, so some capability must wait.

A risk threshold cannot be compromised, so speed must be sacrificed.

A new strategic priority appears, so an existing initiative must lose resources.

Someone has to make that trade-off.

Too often IT is expected to absorb it invisibly.

The organisation says everything is critical, then asks technology leaders to reconcile contradictory expectations through heroic execution.

That is not partnership.

That is avoidance.

The most mature executive teams I have worked around make trade-offs visible. They do not ask whether every priority can be delivered. They ask which combination of priorities produces the highest enterprise value within real constraints.

This sounds obvious.

It is surprisingly rare.

The board can test this by asking:

When the next priority enters the portfolio, who decides what moves down?

If the answer is “IT will work it out,” there is no shared prioritisation.

There is only delegated pain.

4. Do We Share Accountability After Go-Live?

One of the most damaging habits in enterprise technology is treating implementation as the finish line.

A system goes live.

The programme team celebrates.

The steering committee winds down.

Attention moves to the next initiative.

But business value often begins after implementation, not before it.

Adoption must happen.

Processes must change.

Management behaviours may need to change.

Old systems or manual workarounds may need to disappear.

Benefits need to be measured.

Sometimes the original assumptions need to be challenged.

This is where shared accountability matters most.

Technology leaders should not be able to say, “We delivered what was requested.”

Business leaders should not be able to say, “The technology did not deliver the benefits.”

Both statements may be technically true and strategically useless.

If the promised business result does not appear, the executive team should investigate the outcome together.

Was the original business case wrong?

Did adoption fail?

Was the product badly designed?

Did market conditions change?

Did the organisation automate a poor process instead of changing it?

Was the investment simply a bad decision?

That is the accountability conversation boards need.

Collaboration Is Necessary, but It Is Not Enough

There is an obvious counter-argument.

Companies still need specialist functions. Technology requires expertise, governance, architecture, security, resilience, engineering discipline, and operational control.

Absolutely.

Removing the artificial divide between IT and the business does not mean removing professional accountability.

The CFO still needs financial expertise.

The CHRO still needs people expertise.

The general counsel still needs legal expertise.

But nobody argues that finance, people, or legal issues somehow sit outside the business.

Technology should be no different.

The CIO must remain accountable for technology integrity, just as the business executive remains accountable for commercial and operational judgement.

What should disappear is the gap in between, where the enterprise outcome belongs to everybody in principle and nobody in practice.

Boards Should Stop Asking Whether IT Is “Aligned”

“Are IT and the business aligned?” sounds like a sensible governance question.

It is usually too soft.

Alignment can mean meetings happened.

It can mean roadmaps were presented.

It can mean stakeholders agreed that the project was important.

None of those guarantees value.

Boards should ask harder questions:

Who owns the business outcome?

Who owns the capital at risk?

Who has authority to make trade-offs?

What will stop if this becomes more important?

What measurable benefit must appear after implementation?

And which executives remain accountable if it does not?

Those questions quickly reveal whether technology is genuinely embedded in the business or merely supplying it.

The CIO Should Not Aspire to Be a Better Supplier

This is ultimately why I think the “business partner” ambition is too modest.

A supplier needs a good relationship with its customer.

A business leader shares responsibility for the enterprise.

Those are different standards.

The modern CIO should certainly understand markets, customers, economics, operations, and strategy.

But not because doing so makes IT more responsive to the business.

Because technology leadership is now part of business leadership.

Likewise, business executives cannot outsource their understanding of technology to the CIO.

A CEO who treats technology as something the CIO owns is increasingly making the same mistake as a CEO who says the CFO owns economics.

Specialists provide expertise.

Leadership owns consequences.

Stop Partnering. Start Owning.

The phrase “IT-business partnership” has survived because the intention behind it is good.

It asks two groups to work together instead of throwing requirements, deadlines, and blame across an organisational boundary.

But that boundary is now the deeper problem.

The next step is not better partnership theatre.

It is shared ownership.

Shared outcomes.

Shared capital decisions.

Shared trade-offs.

Shared accountability when the promised value does not materialise.

That changes the conversation from:

“Is IT supporting the business?”

to:

“Are we making the right business decisions about technology?”

That is a much harder question.

It is also the one that matters.

What has worked in your organisation: stronger IT-business partnership, or removing the distinction altogether and creating shared accountability?

If this is the kind of technology conversation you want more of, subscribe to TechnologyTrends and add your perspective in the comments.

© Sanjay K Mohindroo 2025