The hidden cost of choosing the wrong implementation partner

Enterprise transformation does not usually fail in a single dramatic moment. It fails through a sequence of small, avoidable decisions that looked sensible at the time. A confident proposal is accepted without enough challenge. A partner is selected because they know the platform, not because they understand the business. A contract is shaped around activity rather than outcomes. The steering group assumes supplier governance will somehow emerge once the programme starts. By the time the warning signs become visible, the organisation has already committed its budget, reputation, operating capacity and political capital.

This is why implementation partner selection is one of the most important decisions in any transformation, and one of the easiest to underestimate. The software decision receives the attention, the demonstrations, the scoring matrices and the board scrutiny. The implementation decision is often treated as the necessary next step, as if the partner is simply the delivery mechanism for a technology choice already made. That is a dangerous assumption. The partner does not just configure the platform. They shape the delivery model, influence the business design, interpret requirements, manage trade-offs, control large parts of the delivery narrative and, in many cases, determine whether the organisation understands what it has actually committed to.

At Arqvera, we often say that most project pain is created before kickoff. The wrong partner decision is a good example. The damage rarely starts with bad intent. It starts with weak readiness, unclear outcomes, poor commercial framing, optimistic assumptions and a governance model that arrives too late. That is not a tooling gap. That is a transformation gap.

The partner decision is not a procurement event

A good procurement process can help, but partner selection is not merely procurement. It is a strategic risk decision. The organisation is not buying capacity alone. It is buying judgement, delivery behaviour, industry understanding, change sensitivity, commercial discipline and the ability to work honestly when the facts become inconvenient.

The market tends to describe implementation partners in reassuring language: proven methodology, global capability, sector expertise, accelerators, templates, certified consultants and deep platform knowledge. Some of that matters. None of it is sufficient. Large-scale transformations fail when generic capability is mistaken for specific fitness. The question is not whether the partner has done this type of implementation somewhere before. The question is whether they can help this organisation deliver this outcome under these constraints, with this leadership team, this data quality, this operating model, this culture and this appetite for change.

That distinction matters because the empirical record on major technology programmes remains uncomfortable. McKinsey and the University of Oxford’s analysis of more than 5,400 large IT projects found that, on average, large IT projects run 45% over budget, 7% over time and deliver 56% less value than predicted. The same research found that 17% of such projects perform so badly that they can threaten the existence of the company.  Gartner’s ERP research is similarly sobering, predicting that by 2027 more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, with as many as 25% failing catastrophically.

These numbers should not lead boards to conclude that major transformation is futile. They should lead boards to conclude that the front end matters far more than most organisations allow. By the time a programme is formally mobilised, many of the most important risk conditions have already been set.

How the wrong partner multiplies risk

The wrong implementation partner does not simply add delivery risk. It multiplies risk across the whole investment case. A weak partner can misunderstand the operating model, underestimate integration complexity, overstate the organisation’s readiness, underplay the adoption burden, misprice the work and create a programme structure that looks efficient on paper but collapses under real business pressure.

The most obvious cost is financial overrun, but that is rarely the whole story. The deeper cost is value erosion. Requirements become ambiguous, decisions become slower, change requests become routine, internal teams become overloaded, business confidence declines and the programme begins to optimise for survival rather than outcomes. The organisation may still go live, and the system may technically function, but the promised benefits quietly evaporate.

This is why partner selection must test behaviour, not just credentials. How does the partner respond to uncertainty? Do they challenge the business case or simply price it? Do they expose assumptions or absorb them into a delivery plan? Do they explain trade-offs clearly, or bury them in workstream language? Do they understand adoption, data and operating model change, or do they treat those as client-side problems? Do they tell the truth early, when it is still useful, or late, when it is mostly expensive?

A partner who cannot challenge you before contract signature is unlikely to challenge you effectively after it. By then, everyone has incentives to keep the machine moving.

The contract is part of the operating model

Many organisations treat the contract as a legal and commercial artefact, separate from the transformation itself. In reality, the contract becomes part of the programme’s operating model. It defines incentives, decision rights, escalation routes, acceptance criteria, change control, dependency ownership and the practical consequences of ambiguity.

A poorly framed contract creates a delivery environment in which both sides can be busy and technically compliant while value is leaking. The supplier can deliver outputs that satisfy contractual language but fail to create operational readiness. The client can approve milestones without having the internal capability to exploit what has been delivered. Both parties can point to process while the business case weakens.

The issue is not that fixed-price, time-and-materials or outcome-based contracts are inherently right or wrong. The issue is whether the commercial model reflects the nature of the work. Highly uncertain transformation cannot be governed as if every dependency is known. Equally, an open-ended commercial model without disciplined governance can become an expensive invitation to drift. The right contract creates clarity without pretending complexity does not exist.

This is where independent challenge earns its keep. Before the contract is signed, someone needs to ask the awkward questions that internal teams often avoid because momentum has already taken hold. Are the assumptions testable? Are the deliverables linked to business outcomes? Is the scope genuinely understood? Are client-side responsibilities explicit? Are data, process and adoption obligations clear? Is there a realistic mechanism for handling discovery without turning every surprise into a commercial argument?

That is not bureaucracy. It is risk management before the risk becomes structural.

The forensic lesson from public failures

Public disputes around failed implementations are useful not because they allow anyone to enjoy corporate misfortune, although the industry does occasionally pretend not to while reading every detail. They are useful because they show the pattern.

In September 2025, Zimmer Biomet filed a lawsuit in New York seeking at least $172 million from Deloitte Consulting in relation to an SAP S/4HANA programme, alleging fraud, breach of contract, negligent misrepresentation and deceptive trade practices. The claim followed operational disruption after go-live, with reporting from MassDevice noting allegations that Deloitte misrepresented its capabilities and failed to deliver the implementation successfully. The allegations remain legal claims, not findings of fact, but the case illustrates the type of exposure that can arise when major platform programmes break down publicly. 

Lidl’s abandoned SAP programme offers another well-known warning. After a seven-year effort, the retailer reportedly cancelled the programme having spent around €500 million and reverted to its old system. Consultancy.uk reported in 2018 that Lidl shelved the SAP introduction after the investment, making it one of the more prominent examples of ERP value destruction.

These cases differ in context, technology, governance and legal posture. They should not be reduced to simplistic morality tales about one platform, one supplier or one client. The more useful lesson is that large transformation failures are rarely just technical failures. They tend to involve a combination of overconfidence, weak alignment, unclear accountability, process misfit, poor readiness, commercial pressure and governance that becomes reactive too late.

Technology rarely fails in isolation. It fails inside a system of decisions.

The client-side capability problem

It is tempting to believe that selecting a strong partner compensates for weak internal capability. It does not. In fact, the more capable the partner, the more important it becomes for the client to know what it wants, how it makes decisions and who owns the business outcome.

A systems integrator can bring methodology, resources and platform expertise. It cannot outsource leadership alignment. It cannot manufacture clean data from years of underinvestment without trade-offs. It cannot create executive sponsorship where none exists. It cannot make the business own adoption if the organisation treats change as something delivered by a workstream. It cannot realise benefits after go-live if operational leaders were never made accountable for them.

This is the uncomfortable part of partner selection. The organisation must assess itself at the same time as it assesses the supplier. Weak buyers create weak delivery conditions. They issue vague requirements, delay decisions, change scope without recognising consequences, under-resource subject matter experts and then blame the partner for not delivering clarity that the business never created.

That does not excuse poor supplier performance. It does mean that partner selection should include a hard look at buyer readiness. Are we prepared to be a good client? Do we have the people, governance and decision discipline to match the ambition? Have we protected the right internal capacity, or are we pretending that already overloaded leaders can absorb a major transformation between meetings?

Confidence before commitment is not just about trusting the partner. It is about being honest about the organisation’s own ability to lead the work.

What good partner selection looks like

A better approach begins by separating sales performance from delivery confidence. The best presentation does not necessarily indicate the best delivery partner. Selection should test the team that will actually do the work, not only the senior people who appear during pursuit. It should examine relevant experience at the level of problem similarity, not logo similarity. It should include structured challenge around assumptions, implementation sequencing, integration risk, data readiness, business adoption and benefits ownership.

The process should also force explicit comparison between delivery approaches. Does the partner’s methodology fit the organisation’s maturity, or does it require a level of discipline the business does not possess? How will the partner manage scope discovery? What is their approach to design authority? How will they deal with unresolved process variation? How will they surface bad news? What evidence do they provide that they can work constructively with internal teams rather than simply around them?

References should be treated as evidence, not reassurance. Too many organisations ask polite reference questions and receive polite reference answers. The useful questions are sharper. Where did the partner struggle? What did they underestimate? How did they behave when the project became difficult? Were they transparent on cost and risk? Would you use the same team again? What client-side capability did they assume you had?

The commercial model should then be stress-tested against the delivery reality. Milestones, acceptance criteria and change control should encourage truthful reporting and value protection, not defensive behaviour. Governance should be in place before mobilisation, with clear escalation routes, decision rights, assurance points and independent review at the moments where optimism is most likely to outrun evidence.

This is the territory covered by Trust Arq, Arqvera’s project governance and delivery assurance framework. It is designed to help leaders de-risk major commitments before kickoff by aligning outcomes, partners, governance and delivery confidence. The purpose is not to slow decisions down. The purpose is to make the decision better before it becomes expensive to correct. 

Independent assurance is not a lack of trust

Some leaders worry that independent assurance sends the wrong signal to suppliers or internal teams. It can sound adversarial, as if assurance exists to catch people out. That is the wrong framing.

Good assurance improves trust because it makes the system more honest. It creates an agreed mechanism for testing assumptions, surfacing risk, checking readiness and making decisions with better evidence. It protects the sponsor from false confidence, the supplier from ambiguous expectations and the delivery team from inherited commitments that were never realistic.

Trust is a system. It is created through clarity, candour, consistency, care and continuity. In transformation, those qualities need to be designed into governance, not hoped for through goodwill. Good partners should welcome that discipline because it gives them a better chance of delivering successfully. Weak partners may find it uncomfortable. That is useful information.

The right time to introduce assurance is before the programme has fully mobilised, not after the first major escalation. Once delivery is under pressure, assurance can still help, but the economics are worse. Earlier intervention gives leaders more options: reshape scope, strengthen the contract, reset governance, improve buyer readiness, adjust sequencing or reconsider the partner decision before sunk cost takes over.

The decision leaders need to make

Implementation partner selection is one of those decisions where the cost of diligence feels visible and the cost of poor diligence stays hidden until later. That is why organisations rush it. The board wants progress, the sponsor wants momentum, the supplier wants closure and the internal team wants certainty. Everyone wants to get going.

But getting going is not the same as being ready.

The hidden cost of choosing the wrong implementation partner is not only the additional fees, the change requests or the delayed go-live. It is the erosion of confidence, the loss of operational focus, the credibility damage with users, the distraction for leadership and the value that disappears while everyone argues about whether the programme is technically on track.

Most transformation problems arrive disguised as technology problems. Partner failure is often one of them. Look beneath the surface and the real issue is usually clearer: the organisation committed before it had enough confidence in the outcome, the partner, the contract, the governance and itself.

Before signing the next major implementation agreement, leaders should ask one simple question: do we have evidence-based confidence, or are we buying reassurance?

The difference is expensive.

About Arqvera

Is an AI and technology transformation consultancy and advisory.

We help organisations shape business cases, projects, deliver excellence, and realise change and outcomes that stick. We support organisations before, during, and after projects with an end-to-end service where our domain specialization comes to life.

Before (Inception): We work with you to clearly define the idea, vision, strategy, and business case for change, as well as help select the right partners, and establish governance

During (Execution): We help deliver project and change objectives while keeping implementation under control through structured governance and assurance to realise intended outcomes.

After (Value Realisation): We ensure outcomes deliver measurable value and embed continuous improvement from successes and learnings.

Arqvera is led by industry veterans in the UK and USA with 100+ years of technology delivery intelligence across global consulting, digital transformation, and mission-critical projects and programmes.