You Didn't Buy a System. You Bought an Outcome. So Why Is Nobody Accountable for It?

Every year, organisations across Australia and beyond commit tens of millions of dollars to IT-enabled business transformation. They do so with genuine ambition: to reduce costs, improve customer experience, modernise operations, or unlock growth. The business case is approved. The System Integrator is selected. The contract is signed. And the journey begins.

Years later, many of those same organisations find themselves in a familiar and deeply frustrating position. The system is live. The SI has been paid. The project is technically closed. And yet the outcomes that justified the investment (the productivity gains, the process efficiencies, the culture shift, the return on capital) have not materialised. Or not fully. Or not sustainably.

This is not a technology failure. It is not, in most cases, a failure of the SI to deliver what they promised. It is something more structural, more systemic, and far more common than the industry acknowledges.

It is the consequence of managing contracts instead of outcomes.

The Structural Problem Nobody Wants to Name

When an organisation engages a System Integrator, they are entering a commercial relationship built around a specific, bounded set of deliverables. A configured ERP. A migrated dataset. A set of integrated systems. A number of training sessions delivered. These are the things that can be scoped, scheduled, priced, and contractually defined.

They are not, however, outcomes.

An outcome is a measurable improvement in business performance. It is "procurement cycle time reduced by 30 percent." It is "customer onboarding completed in two days instead of ten." It is "finance close process cut from twelve days to four." Outcomes live in the business. Deliverables live in the contract.

The gap between the two is where transformation projects fail.

The SI is commercially motivated, quite reasonably, to complete what they contracted to deliver. Their revenue is recognised when milestones are hit. Their relationship with the client is governed by the Statement of Work. When the scope is done, the engagement is done. The SI declares success, presents the go-live report, hands over the hypercare schedule, and begins transitioning off.

At that exact moment, the client is left holding something they did not fully anticipate: a system, not a transformation.

How the Money Gets Spent, and Where the Value Disappears

To understand the problem, it helps to follow the money through the lifecycle of a typical transformation programme.

In the business case and vendor selection phase, significant internal and consulting resources are consumed shaping the opportunity, building the ROI model, and running a procurement process. This is often where the first distortion occurs. The SI, eager to win the deal, will frequently play an active role in shaping or validating the business case. Benefits are framed optimistically. Risks are managed in the narrative. The client, understandably excited about the possibilities, does not always subject these assumptions to sufficiently independent scrutiny. The approved budget is often insufficient before a line of code has been written.

At contract signature, the structural flaw is locked in. The contract is written in the language of deliverables. Phase gates, milestone payments, acceptance criteria: all of these are defined in terms of what the SI will do, not what the business will achieve. There is no clause that says "payment is contingent on measurable adoption." There is no milestone called "productivity improvement evidenced." The client's legal and procurement teams, skilled at what they do, have negotiated hard on price and terms. They have not, and typically cannot, negotiate on outcome accountability, because the SI will not accept it, and because the metrics for measuring it have not been rigorously defined.

During implementation, the SI delivers. They really do. Talented consultants work long hours configuring systems, building interfaces, conducting workshops. The programme governance structure produces status reports. RAG ratings are mostly green. The steering committee receives updates on deliverables completed and milestones approaching. What it does not receive, systematically, consistently, or credibly, is an answer to the question: are we on track to realise the benefits we promised the board?

Meanwhile, Organisational Change Management, the discipline that determines whether people will actually use the system effectively, is typically under-resourced, poorly timed, and treated as a workstream rather than a strategic imperative. It starts too late. It is often the first thing cut when budgets come under pressure. And because it sits in the gap between what the SI is accountable for and what the business owns, it frequently falls through entirely.

Go-live arrives. The system is live. The SI has delivered. The contract is closed. The client's programme team, exhausted from two or three years of delivery pressure, disperses back to their day jobs or moves on to the next initiative. The benefits realisation plan, if one exists in sufficient detail, is handed to a business owner who was not part of the implementation and does not have the context, capacity, or mandate to drive it.

Six months later, adoption is lower than expected. Workarounds have proliferated. The process improvements the business case assumed are not happening, because the processes themselves were not redesigned deeply enough. The governance structures needed to sustain the change have not been established. The ROI is not being tracked. And nobody, not the SI, not the programme team, not the business, is accountable for the gap.

The Three Conversations That Reveal the Problem

In our experience working with organisations navigating these situations, three recurring conversations expose the dysfunction.

The first is the scope conversation. At some point during implementation, usually when the business starts to understand what the system actually does versus what they imagined it would do, a gap emerges. The response is a change request. The client is asked to pay more for something they believed was included, or to accept less than they expected. These negotiations are draining, corrosive to trust, and consume leadership attention that should be focused on the business transformation, not contract administration. They are also almost inevitable when the contract was written around deliverables rather than outcomes, because deliverables are always an imperfect proxy for what the business actually needs.

The second is the adoption conversation. Post go-live, the business discovers that training sessions delivered is not the same as capability built. That communication sent is not the same as change embraced. That a new system available is not the same as new ways of working embedded. The SI's OCM deliverables are technically complete. The business is not ready. And the question of who owns the gap is uncomfortable.

The third is the benefits conversation, or more precisely, the conversation that never happens. Benefits realisation is the most consistently neglected discipline in large transformation programmes. The business case contained assumptions. Those assumptions were never decomposed into measurable targets. Those targets were never assigned to specific owners. Those owners were never given the mandate, tools, or governance to drive realisation. When someone eventually asks "are we getting the return we projected?", the honest answer is usually: "we don't know, because we never built the mechanism to track it."

Why This Keeps Happening

It would be convenient to blame the SI. But the problem is structural, not personal. System Integrators are run by capable, well-intentioned professionals. They operate under commercial models that reward delivery of scope. They carry risk on their projects. They are not in the business of owning their clients' operational performance indefinitely.

The problem is that nobody else is either.

The client's programme team is focused on delivery. The business is focused on keeping the lights on during a complex change. The PMO is managing the plan. The steering committee is reviewing status updates. The CFO who approved the business case has moved on. And the question of whether the transformation will actually deliver its promised value sits in the space between all of these parties, unowned.

This is the SI Expectation Gap. It is not primarily a gap in technology. It is a gap in accountability. A gap between what was promised and what is being measured. Between what the contract covers and what the business needs. Between what the SI is responsible for and what the client expected them to deliver.

Closing it requires something that most transformation programmes do not currently have: an independent party whose singular purpose is to connect the investment to the outcome.

What Outcome Accountability Actually Looks Like

Closing the gap is not a matter of adding another workstream or hiring a bigger project management team. It requires a fundamentally different posture, one that begins before the contract is signed and continues after the SI has left.

It starts with an independent challenge of the business case. Not to undermine the investment thesis, but to pressure-test the assumptions, identify the risks that have been smoothed over, and ensure the benefits are decomposed into measurable, attributable targets before the contract is written.

It continues with outcome-oriented contract structuring. Helping clients define milestone criteria that go beyond deliverable completion, criteria that include evidence of adoption, process change, and early value signals, changes the commercial dynamic with the SI before the relationship even begins.

During delivery, it means maintaining a client-side leadership function that is distinct from programme delivery. Someone who attends the steering committee not to report on scope, but to challenge whether the trajectory of delivery is aligned to the trajectory of value. Someone who owns the relationship with the business, the people who will actually use the system, not just the relationship with the SI.

It means a live, maintained benefits realisation framework. Not a document produced at business case stage and filed away. A working mechanism that tracks leading indicators of value, flags early when assumptions are not holding, and gives the business the data it needs to intervene.

And it means staying after go-live. Not indefinitely, but through the period when adoption is consolidated, when the process improvements are being embedded, when the governance structures are being stood up. The period when most transformation programmes declare victory and walk away.

The Question Every Executive Should Ask

Before signing the next major transformation contract, every executive sponsor should be able to answer three questions.

Who, specifically, is accountable for realising the benefits in this business case? Not for delivering the system, but for the measurable improvement in business performance that justified the investment?

How will we know, six months after go-live, whether we are on track? What are the leading indicators? Who is tracking them? What happens if they are off course?

If the SI completes their contract and the outcomes have not been realised, what is our plan?

If those questions do not have clear answers, the programme has a structural accountability gap. The technology may be excellent. The SI may be talented. The team may work incredibly hard. And the organisation may still find itself, two years from now, in possession of a system rather than a transformation.

The investment has already been made. The question is whether anyone is positioned to realise it.

Closing the Gap

At Intuis Group, this is the work we do. We sit on the client side of the table, not as another layer of consulting overhead, but as the accountability function that transformation programmes consistently lack.

We challenge business cases before they are approved. We help structure vendor relationships so that outcome accountability is explicit, not assumed. We provide independent governance throughout delivery, not to duplicate the SI's programme management, but to maintain a relentless focus on whether the investment is on track to deliver its promised value. We own Organisational Change Management as a strategic imperative, not a workstream. And we stay through the critical post go-live period to ensure adoption is real, benefits are being tracked, and the business has the governance it needs to sustain the change.

The System Integrator Expectation Gap is not inevitable. It is the product of a structural accountability vacuum that has been allowed to persist because nobody has made it their business to fill it.

We have.

Intuis Group works with organisations undertaking significant IT-enabled business transformation. Our focus is outcome accountability: connecting the investment to the result, from business case to benefits realisation.


 

Previous
Previous

Your Payroll Problem is not a Payroll Problem

Next
Next

Service Delivery in an AI World…