The technology was rarely the problem.
For twenty years, the largest enterprises in the world have poured budget into digital transformation programs — new platforms, new stacks, new operating models on paper. Most of these programs have not delivered. The rate is not a rounding error. Multiple published studies have arrived at similar orders of magnitude for the shortfall. Harvard Business Review, in a 2019 article by Behnam Tabrizi and colleagues, cited that roughly seventy percent of digital transformation initiatives do not reach their intended goals. McKinsey's own long-form research on organisational transformations reports that fewer than one-third of transformations succeed at both improving performance and sustaining the improvement. Different framings, different measurement bars, but the direction is consistent: the majority of transformation programs do not deliver their stated business objectives.
If the failure rate were about technology choices, it would have converged towards the platforms that "worked". It hasn't. The same firms failing on ERP in 2010 failed on cloud in 2015 and are failing on AI in 2025 — with different tools each time and the same essential outcome. We have written separately about the pattern for AI specifically in AI Readiness Is a Culture Problem, Not a Budget Problem.
The failure is not in the tech stack. It is in the org chart.
Fragmented ownership is the first constraint
In a large enterprise, a digital transformation program is almost always spanning multiple functions: technology, operations, finance, HR, at least two lines of business, sometimes procurement, sometimes legal. Each function has its own leadership, its own targets, its own budget cycle, its own reporting cadence.
At the executive layer, everyone signs the deck. Everyone agrees the transformation matters. The CEO speaks about it publicly. Board slides celebrate the ambition.
At the operating layer, no single person owns the outcome. The program has a sponsor — usually a senior executive whose real job is running the function they run — and a program lead who is often a hire brought in for the initiative. The sponsor doesn't control the operating budgets. The program lead doesn't control the reporting lines. The people who actually do the work continue reporting to the leaders they've always reported to, whose targets have not changed to reflect the transformation.
The result is predictable. Every function agrees to help. Every function protects its own operating priorities when the trade-off gets real. And the transformation slowly becomes a project that everyone endorses and no one is measured on.
Incentives point at old outcomes
Related but distinct: the compensation and career signals inside the enterprise almost never change to match the transformation's intent.
A regional sales leader whose bonus is based on quarterly regional revenue does not have a rational reason to divert her best account managers to help populate a new CRM taxonomy. A COO whose scorecard tracks last year's operational KPIs does not have a rational reason to accept the temporary throughput dip that comes with a workflow rebuild. A CTO measured on uptime does not have a rational reason to sponsor architectural work whose payoff is two years out.
None of these leaders are being cynical. They are responding to the incentive structure the enterprise puts in front of them. The transformation asks them to do something whose reward flows to somebody else's scorecard.
Published research on transformation outcomes consistently emphasises the role of aligned leadership and people mechanics — engagement, communication, ownership clarity — as differentiators between programs that succeed and programs that stall. McKinsey's 2021 study "Losing from day one" reports that fewer than one-third of transformations achieve both improved performance and sustained improvement over time. The pattern that follows is intuitive: when the compensation and career signals inside the enterprise continue to reward last year's outcomes while a program is asked to deliver next year's, the program tends to lose the trade-off.
Decision rights are not re-designed
An enterprise's ability to move at speed is largely a function of who is allowed to make what decisions and how quickly those decisions become binding.
Legacy operating models have decades of accumulated decision-rights baggage: procurement thresholds, architectural review boards, change advisory committees, contract-signing chains, vendor-onboarding gauntlets. Individually, most of these controls were created for good reasons. Collectively, they mean that even a modest transformation decision — say, deploying a new AI-assisted contact-centre workflow to one region — can require sign-off from eight or nine independent gatekeepers who each need to see the change on their calendar.
Transformation programs almost never redesign decision rights before starting. They inherit the existing decision architecture and then wonder why nothing is moving. The gatekeepers are not obstructing the transformation. They are doing exactly what they were structured to do.
Digital reengineering — as a discipline — starts by mapping the current decision-rights topology and either explicitly rewriting it for the transformation window or accepting the cadence it imposes. Firms that skip this step end up burning most of their program schedule waiting for approvals.
Reporting structures outlive transformation programs
Every digital transformation eventually collides with the reporting map.
An enterprise is a set of vertical reporting lines: functions, business units, geographies. A meaningful transformation is horizontal: it cuts across those verticals to redesign how work flows end-to-end. That misalignment is not incidental; it is structural.
Consider what an integrated customer journey requires: marketing to align lead qualification with sales' definition of a qualified opportunity; sales to align opportunity handoff with customer-success onboarding; customer success to align renewal signals with product's roadmap prioritisation; product to align feedback loops with data engineering; data engineering to align data quality with finance's revenue-recognition model. Every one of those alignments crosses a reporting line.
The traditional response is to declare a matrix — dotted reporting lines, program managers, cross-functional working groups. In practice, when a matrix and a vertical reporting line conflict, the vertical line tends to win, because the vertical line writes the review, sets the bonus, and controls the headcount. Matrix reports look busy. Matrix outcomes tend to move slowly.
For some transformations, this means restructuring part of the organisation around the flow of the outcome — not simply placing a matrix over the existing structure, but clarifying who owns what and where accountability sits. This can be politically difficult and may require sustained executive attention. But without structural alignment, the transformation remains dependent on coordination across reporting lines that were never designed to deliver it.
Technology layered over broken operating models fails predictably
Once these four constraints are visible — fragmented ownership, misaligned incentives, unchanged decision rights, unchanged reporting structures — a common failure pattern becomes clear.
The enterprise buys or builds a new technology capability that would in principle enable a new operating model: a cloud data platform, an integrated customer platform, an AI-assisted service capability, a modernised ERP. The rollout is technically successful — the tool works, integrations are stable, adoption training is delivered. Executive updates report green status.
Then nothing changes at the P&L level.
The tool sits on top of the old operating model, which absorbs it into existing workflows without redesigning them. Salespeople log into the new CRM to update the fields the old process required. Analysts use the new data platform to build the reports the old cadence needed. Customer service uses the new AI capability to draft responses that a supervisor edits back into the old tone. The technology is present. The operating model is unchanged.
At a certain point, the CFO notices that the promised productivity did not materialise. The vendor gets blamed. The tool gets called "immature". A new transformation is commissioned. The pattern repeats.
Replacing software does not fix structural problems. The structure has to be reengineered before the software can carry it.
Why digital reengineering is a different discipline
Digital transformation, as it has been practised for two decades, treats the operating model as a downstream artefact of technology selection. Pick the platform, run the change program, and the operating model will follow.
Digital reengineering inverts that sequence.
Reengineering starts with the operating model — decision rights, reporting structures, incentives, ownership — and asks what that model needs to look like if it were designed today to deliver the outcomes the business is trying to deliver. Only then does it work out which technology decisions serve that model. It treats software as a consequence of the operating decision, not the driver of it.
This is not new intellectual territory. Michael Hammer and James Champy laid out the case for business process reengineering in the early 1990s, in "Reengineering the Corporation". What has changed is that the toolset that operating models can use — cloud infrastructure, integrated data platforms, AI-assisted workflows, real-time analytics — is dramatically more powerful than it was thirty years ago. Reengineering with those tools produces operating models that were literally not possible before.
Jettifi operates as a Digital Reengineering firm because replacing technology without reengineering the system around it rarely changes the underlying business constraint. We start with the architecture of the enterprise — how decisions, operations, data and technology work together — before determining what needs to be rebuilt. You can read more about how we approach this on our About page.
What this changes for the leader running a program right now
Three practical implications.
First, ask the org-chart question before the platform question. Before the next platform decision, spend a week mapping who owns the outcome, whose incentives point at it, who has decision rights on it, and where the reporting line for it lives. If any of these has no clean answer, the platform decision is premature.
Second, treat operating-model change as a first-class deliverable of the program, not a downstream side-effect. Give it a sponsor, a scorecard, and an executive who is measured on it. Anything less is asking the program to change the org through wishful thinking.
Third, accept that reengineering is slower to start and dramatically faster to finish. A reengineering program spends a longer front-end on the operating model design and a much shorter back-end on the technology rollout — because the technology decisions are then serving a model that already knows what it needs to do. We work through the specific decisions this creates in The Reengineering Playbook.
The alternative is the same transformation cycle every enterprise has run for two decades. Different tools. Same outcome.
Reengineering isn't about tools. It's about making your organisation capable of absorbing change at the speed your market demands.
For a complete explanation of the methodology behind this perspective, see Digital Reengineering: A Practical Guide for Enterprise Leaders.
Sources
Behnam Tabrizi, Ed Lam, Kirk Girard, and Vernon Irvin — Digital Transformation Is Not About Technology, Harvard Business Review, March 2019.
McKinsey & Company — Losing from day one: Why even successful transformations fall short, December 2021.
Michael Hammer and James Champy — Reengineering the Corporation: A Manifesto for Business Revolution, HarperBusiness, 1993.