Turn to LinkedIn, attend an executive seminar, or consult an enterprise playbook, and you will find a near-unanimous consensus: digital transformations fail because of people. We are told that human resistance, lack of cultural alignment, or insufficient stakeholder buy-in are the primary drivers of IT project failure. The prescribed cure is always the same: double down on “Change Management.” Hire Prosci-certified consultants, establish elaborate governance frameworks, draft internal PR communications, and run endless workshops to ensure everyone is “ready for the journey.”
This is a comforting corporate lie.
It is a lie because it shifts the blame for catastrophic delivery failures onto end-users and organizational culture, while completely ignoring a much more brutal reality. Digital transformations do not fail because users refuse to adopt the software; they fail because the software delivered is architecturally broken, structurally unintegrated, or completely detached from operational reality.
No amount of corporate empathy or stakeholder alignment can rescue an enterprise platform that lacks foundational engineering integrity. The real battle of digital transformation isn’t won in a change management workshop; it is won in the trenches of technical stewardship, by leaders who possess the deep technical understanding required to plan realistic roadmaps, enforce conceptual integrity, and aggressively mitigate structural risk before the code hits production.
Change Management is inherently downstream of Architecture. Effective change management is a byproduct of excellent software design, without the latter, the former is a work of fiction.
Architecture defines what the system is and what it can legitimately do, change management prepares the business on how to use it (making training a by-product of QA, but that’s another post)
What the Data Actually Tells Us
The obsession with change management as a silver bullet flies in the face of decades of empirical software engineering research. When we look past the marketing material of change management consultancies, the structural root causes of project failure become glaringly obvious.
1. The Standish Group (CHAOS Reports)
For over three decades, the Standish Group has analyzed tens of thousands of global IT projects. Their data consistently reveals that the primary drivers of project failure are structural and technical, not behavioral. In their historical taxonomy of “Project Challenged Factors,” the top culprits are consistently identified as:
Incomplete and Flawed Requirements (12.3%)
Architectural Drift and Changing Specifications (11.8%)
Technology Incompetence and Lack of Technical Skill (7.0%)
When projects cross the threshold from “challenged” to “impaired” (cancelled entirely), it is almost always driven by an inability to translate business logic into working code, a mismatch between legacy systems and target architectures, or a fundamental lack of engineering capability.
2. The McKinsey Technical Debt Drag
Research from McKinsey & Company indicates that technical debt accounts for an astronomical tax on modern enterprises, consuming up to 20% to 40% of the value of an organization’s entire technology estate. Crucially, McKinsey notes that 71% of a business’s transformation impact depends directly on technology performance.
When an organization attempts to layer a modern digital front-end over brittle, undocumented legacy databases without an engineering-led migration and integration strategy, the resulting architectural drag halts progress entirely. The failure isn’t that employees don’t want to use the new system; it’s that the system’s underlying design cannot support the legitimate functions of the business.
The Legibility Trap: Managing What We Understand
If the data overwhelmingly points to engineering and architectural failure, why do organizations remain hyper-fixated on project governance and change management?
The answer lies in The Legibility Trap.
Typically, those holding the budgets offer different, often non-technical skillsets, generally financial, legal or general management; important roles in and of themselves, but missing the crucial technical lens through which to devise a digital transformation. They cannot read a relational data model, much in the same way I know little about corporate law. They do not understand why a tightly coupled microservices architecture creates a cascading failure across an estate. They do not know what an unindexed database query or an asynchronous race condition means for operational throughput.
Because the actual engineering is invisible and illegible to them, they naturally reframe the problem into something they know how to manage. A color-coded RAG status on a PMO spreadsheet, a stakeholder alignment matrix, or a post-it note workshop are legible. They fit neatly into a steering committee slide deck. It looks like progress because it can be counted, scheduled, and tracked.
In this environment, process compliance is valued higher than product outcome. An organization can spend years following a waterfall or rigid corporate agile framework to the letter, logging risks and holding change workshops, and still deliver absolutely nothing of value. The failure is then treated as an unpreventable tragedy or a vendor delivery issue, shielded by the fact that “the governance process was followed perfectly.”
Meanwhile, the engineering reality is completely unsteered. Without active Technical Stewardship at the helm, the target architecture undergoes massive drift as siloed development teams or external vendors make short-sighted, tactical compromises to hit arbitrary timeline milestones.
Case Study: An 11th-Hour Reality Check
This systemic failure of governance-over-engineering is not theoretical; it is actively playing out in boardrooms across the UK right now.
Take a recent, vivid example from an organisation I was engaged with. This organisation was approximately eight weeks away from an absolute go-live date for a new core system. This transformation initiative has been in development for many years.
For nearly a decade, this project has been wrapped in traditional corporate governance, steered by project managers, PMO leads, and change management specialists tracking milestones and validating stakeholder readiness. Yet, at the eleventh hour, a brutal technical assessment revealed a series of challenging engineering blind spots:
Zero Environment Baselines: The organization discovered they have no clear configuration or deployment audit across their three environments (Dev, UAT, and Pre-Prod). They cannot definitively state what version of code, schema, or configuration resides where, rendering years of user acceptance testing mathematically invalid.
No Data Migration Strategy: Despite being weeks away from discarding their legacy estate, there is no robust, tested ETL (Extract, Transform, Load) pipeline to migrate from source to destination in a repeatable, fault proof manner.
Catastrophic Query Performance: A deep dive into the application layer revealed an issue where the CRM takes upwards of 50 seconds to return a single customer record—tracked down to a heavily nested SQL search query generated blindly by an unoptimized application layer.
Critical Compliance Omissions: The system lacks a fundamentally secure, PCI-DSS compliant payment approach and PSP (Payment Service Provider) integration—a flaw that completely halts the legal ability to process commercial bookings.
Regardless of project and change management, the digital transformation lacked the fundamental technical foresight to plan and mitigate these risks, leading to a brittle live deployment and many months of post go-live clean up.
Because the project lacked Technical Stewardship. It had plenty of people asking “When will it be done?” but no one at the helm who knew the difference between a class and a function, let alone someone capable of reviewing an API contract, modeling a database schema, or challenging a software vendor’s architectural assumptions.
The database does not attend change management workshops. It does not care about user adoption frameworks. If the data structures do not map cleanly to the physical reality of a booking, and if the network layers cannot securely execute a payment transaction, the system will fail. No amount of internal PR can change manage a 50-second screen freeze or a missing data pipeline.
The Antidote: Engineering-Led Technical Stewardship
If organizations want to break the infinite loop of multi-year, multi-million-pound IT failures, they must abandon the delusion that technology is a commodity that can be managed entirely through generic project governance.
We must restore the role of the engineer-architect as the central steering force of digital transformation. This is what we define at Recursive Software as Technical Stewardship.
Technical Stewardship requires leaders who don’t just sit in ivory towers drawing abstract boxes and arrows, but who are actively embedded in the delivery trenches. A Technical Steward:
Enforces Conceptual Integrity: They ensure that the software being built actually matches the strategic data models and business capabilities required by the enterprise, ruthlessly refactoring or halting delivery when architectural drift occurs.
Translates Across Domains: They bridge the gap between executive intent and engineering reality, translating a CFO’s business case into concrete technical constraints and exposing hidden technical debt before it becomes a multi-million-pound liability.
Owns the Non-Functional Realities: They recognize that data migration, performance indexing, security compliance, and environment configuration are not post-implementation details, they are the foundation upon which the entire system stands.
Conclusion
It is time to retire the myth of the change management silver bullet. Human adoption is a necessary component of any business transition, but it is entirely downstream from engineering execution. If you build a structurally unsound system, your transformation will fail regardless of how many post-it notes you stick to a whiteboard.
If your digital transformation is lagging, over budget, or creeping toward a catastrophic deadline, stop hiring more project managers to color in spreadsheets. Put a Technical Steward at the helm, look ruthlessly at your data models, and start fixing the hull.
References & Further Reading
The Standish Group. The CHAOS Report. (An empirical study of over 50,000 software development projects detailing specific failure criteria).
McKinsey & Company. Tech Debt: Reclaiming Tech Equity to Accelerate Innovation. (Analysis of the financial and operational drag of legacy architectural accumulation on digital transformation velocity).
Consortium for Information & Software Quality (CISQ). The Cost of Poor Software Quality in the US: A Report. (Quantifying the trillions lost annually to operational failures and unmaintained codebase architecture).
