Technology Is Rarely the Primary Cause of Failure
When digital transformation or integration projects struggle, the explanation is often framed in technical terms:
- The platform was inadequate
- The integration was complex
- The data was difficult to manage
While these factors matter, many failures stem from something less visible:
Unclear ownership of decisions and outcomes.
Without defined accountability, even well-designed technology can produce unstable results.
Where researchers have specifically separated technical causes of failure from organisational ones, the organisational ones come first. RAND Corporation interviewed 65 data scientists and engineers with at least five years' experience to establish why AI projects fail — a category where, by some estimates it cites, more than 80% of projects fail, twice the rate of IT projects that do not involve AI. The leading root cause it identified was not technical at all: stakeholders misunderstanding or miscommunicating the problem the project was meant to solve, so that what gets built is optimised for the wrong measure or does not fit the workflow it lands in. RAND's first recommendation follows directly from that — "misunderstandings and miscommunications about the intent and purpose of the project are the most common reasons for AI project failure" (RAND Corporation, The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed, August 2024).
Two caveats matter before that gets stretched too far. RAND studied AI projects, not ERP integrations, and it does not claim every cause is organisational — one of its five root causes is that the technology was applied to a problem too difficult for it to solve. The cost figures usually attached to this argument need similar care: PMI's Pulse of the Profession put the waste at an average of $97 million for every $1 billion invested in projects, but PMI attributes that to poor project performance in general, not to governance, and the figure comes from its 2017 report. Anyone quoting it as the cost of governance failure is adding that attribution themselves.
What the evidence does support is narrower and still useful. When failure causes are examined rather than assumed, the decisive ones sit above the technology — in whether the problem was understood, agreed, and owned by someone with the authority to settle it. That matches what we see in integration work: the projects that struggle are rarely the ones with the hardest technical requirements.
What "Integration Ownership" Actually Means
Integration ownership is not simply about assigning a project manager or technical lead.
It involves clear responsibility for:
- Architectural decisions
- Trade-offs between speed and stability
- Data governance
- Operational impact
- Long-term system behaviour
Ownership answers the question:
Who is accountable if this integration affects the business negatively?
Without a clear answer, responsibility becomes diffuse.
Why Ambiguity Creates Long-Term Risk
During implementation, unclear ownership may not appear problematic. Teams collaborate, progress is made, and milestones are achieved.
Issues arise later when:
- Unexpected behaviour emerges
- Business requirements change
- Data inconsistencies appear
- System performance degrades
Without clear accountability, resolution becomes slower because:
- No one has authority to make final decisions
- Root causes are disputed
- Fixes may conflict with other objectives
- Responsibility shifts between teams
This delays recovery and increases operational disruption.
ERP Integration Raises the Stakes
When integrations involve ERP systems, the consequences of ambiguity are magnified.
ERP typically governs:
- Inventory accuracy
- Pricing structures
- Customer records
- Order processing
- Financial reporting
Errors here affect core operations, not just digital channels.
Clear ownership ensures that decisions consider these wider impacts rather than local optimisation within a single system.
This is especially visible once marketplaces enter the picture — see Marketplaces and Wholesale Operations: Why Stability Comes Before Expansion for how ownership gaps compound once ERP has to stay synchronised with an external channel's own rules.
Ownership as a Governance Function
Integration success depends as much on governance as on engineering.
Governance defines:
- Decision rights
- Escalation paths
- Approval mechanisms
- Risk tolerance
- Change management processes
When governance is weak, technical teams may make decisions without full visibility into business implications, or business stakeholders may request changes without understanding system constraints.
Structured ownership bridges this gap.
Reducing Friction Through Accountability
Clear accountability simplifies collaboration.
Teams know:
- Who approves architectural changes
- Who prioritises requirements
- Who resolves conflicts
- Who communicates with stakeholders
This reduces friction because decisions do not stall in uncertainty.
It also accelerates problem resolution when issues occur.
The Relationship Between Ownership and Trust
Operational teams are more likely to trust systems when they know someone is responsible for their integrity.
Confidence increases when:
- Issues are addressed decisively
- Changes are coordinated
- Communication is consistent
- Responsibilities are transparent
Trust is particularly important in ERP-driven environments where data accuracy underpins daily operations.
Experienced buyers evaluating an integration partner tend to ask about exactly this — see ERP-Aware Buyers: Why Experienced Operators Ask Different Questions for the questions that surface whether ownership is actually clear before a contract is signed.
Avoiding the "Shared Responsibility" Trap
While collaboration is essential, diffused responsibility can be counterproductive.
When "everyone owns it," no one truly does.
Effective models typically designate:
- A single accountable owner for integration outcomes
- Supporting roles with defined responsibilities
- Clear boundaries between decision domains
This structure balances teamwork with accountability.
Why Ownership Outlasts Technology
Platforms and tools will evolve over time.
Governance structures and accountability models determine how effectively organisations adapt to those changes.
Strong ownership ensures continuity even as systems are replaced or expanded.
Weak ownership means each new project risks repeating the same coordination challenges.
Conclusion
Unclear ownership is one of the most significant risks in digital integration projects — particularly when ERP systems and core processes are involved.
Technology alone cannot compensate for ambiguous accountability.
Clear ownership provides governance, accelerates decision-making, reduces friction, and improves resilience when problems arise.
In complex operational environments, integration success depends not just on what systems do, but on who is responsible for their behaviour.
Integration Ownership: Common Questions
Is unclear ownership really a more common cause of failure than bad technology?
Where researchers have separated the two, the organisational causes come first. RAND Corporation interviewed 65 experienced data scientists and engineers about why AI projects fail, and the leading root cause was stakeholders misunderstanding or miscommunicating the problem to be solved — not the technology. RAND's own first recommendation is to make sure technical staff understand the purpose and domain context of the project. That study is about AI rather than ERP integration, and one of its five root causes is genuinely technical, so it is evidence for the pattern rather than proof about integration work specifically.
Is there a figure for what weak governance costs?
Not a clean one, and it is worth being sceptical of anyone who offers you one. The number usually quoted is PMI's Pulse of the Profession finding that organisations waste an average of $97 million for every $1 billion invested in projects — but PMI attributes that to poor project performance overall, not to governance specifically, and the figure comes from its 2017 report. Any breakdown of it by cause is the citing author's inference rather than PMI's finding.
What does clear ownership look like in practice for an ERP integration?
A single accountable owner for integration outcomes, supported by defined roles for decision-making, escalation and approval, so that when something needs resolving there is no ambiguity about who has the authority to resolve it. In practice the test is not the org chart but the escalation: when stock sync breaks on a Friday afternoon, does everyone know who decides whether to roll back?
Isn't shared responsibility across a team a good thing?
Collaboration is essential, but accountability and collaboration are not the same thing. When everyone shares responsibility for an outcome, in practice no single person is accountable for it. Effective models pair collaborative delivery with one clearly designated accountable owner — the collaboration is how the work gets done, the ownership is how decisions get settled.
If Brightpearl is your operational backbone, see how the Brightpearl integration hub keeps it the system of record while B2B, D2C and marketplace channels change around it.