Many consultancies have shown that 70% of companies fail at digital transformation - this isn't pessimism, it is industry consensus. McKinsey, BCG and Gartner have all reached the same conclusion.
What is less well known - or less discussed - is why. In my view the answer isn't "they chose the wrong technology", nor "the budget wasn't big enough". The real causes are mostly organisational and process-related, and frankly predictable - at least once you have seen enough of them. (What I mean is that the problem lies in how the project is defined and scoped: the project simply sets a goal that isn't realistic or doesn't match the actual objectives. More on that below.)
I have spent 25 years on the IT and business sides of financial services companies - as CIO at an insurer, as head of development and data warehousing at an insurance group, and as a board member at a leasing company. From that time I have brought five patterns that come up again and again - and every one of them could have been prevented.
Reason 1: The transformation starts as a technology project - not a business change
This is the most common and most expensive mistake. Everyone has seen it: "This is an IT project, so IT should own it and deliver it."
At a large insurer, a digitalisation project was led by the IT department. The goal: to digitalise a claims settlement process. The technical solution was excellent: a modern workflow system, integrated document management and a mobile-friendly interface. The project closed on time and on budget.
Six months later the claims process was essentially as slow as before. Why? Because the business logic of the process hadn't changed - they had simply digitalised the existing, poor process. The paper claim form was replaced by a digital one, but the underlying approval levels, parallel checks and siloed ways of working all remained. (The old paper-based steps were simply mapped across - the project essentially created "electronic paper".)
Digitalisation is not mirroring a process in digital tools. It has to mean rethinking the process and building a new model - and business and IT have to work on it together from the start.
From financial services experience: most digitalisation projects fail where IT "receives" the task from the business and builds what it is asked for - without anyone asking: how do we actually want to do this in the future? (You could say this no longer happens, that everyone knows and understands it by now. Unfortunately not. It is still a live problem.)
Reason 2: Nobody owns the business requirement - or doesn't commit enough resources to it
This is closely related to the first reason, but the mechanism is slightly different.
The project sponsor is (usually) in senior management. The developers are in the IT department. Somewhere in between - empty - is the place where the business analyst should sit: someone who understands what the business wants and can translate it into what IT can build. (I don't necessarily mean a specific business analyst here, but the business team that pulls together the project's scope and content.)
One of the most common failure patterns in financial services projects: the specification is written by an internal project manager or an external consultant who knows the methodology but doesn't deeply know the insurance process or the bank's application architecture and processes. The result: a document everyone signs off, but which eight different developers interpret into eight different pieces of code. (It isn't deep or thorough enough, or it simply contains factual errors.)
According to BCG research, one of the most dominant causes of digital transformation failure is a lack of collaboration between IT and the business - and this is especially true in financial services, where products and processes are complex to begin with. 55% of banks say the limitations of existing systems are the biggest obstacle (article in Hungarian) - but behind the systems are business processes that nobody understands deeply enough to digitalise. (This doesn't mean an expert who really understands the business process takes no part at all - but perhaps not with enough time or depth, or the finished specification simply doesn't go back through their hands before development starts.) The reasons can be that it is urgent and they "don't have time", or simply that the specification is always running late and development starts before business validation.
Reason 3: The legacy system is the elephant in the room - and nobody talks about it
Every large financial institution has one or more systems that have been running for decades, that nobody dares touch, and around which every other system has been built. At an insurer it is usually the core insurance system. At a bank, core banking. At a leasing company, the contract management system.
The digitalisation project usually builds integration layers, APIs and a new interface "around" it. That isn't necessarily bad - but if the legacy system's logic dictates the business processes, digitalisation actually digitalises the legacy system's limitations rather than the business need.
I have seen this up close. At an insurer, during development of a new digital customer service app, it turned out that the core insurance system couldn't return policy status in real time because it worked with batch processing. The developers found a workaround: they built a cache layer. The customer sees "real-time" data that is actually refreshed every four hours. That isn't digital transformation. It is a compromise you can live with, but it doesn't achieve the business goal (real-time data). This is just one example and there are probably better ones, but the point is that there is an element in the process that has to change before the status quo can genuinely change.
The lesson: the state and limitations of the legacy system (or any system) must be mapped at the very start of the digitalisation project, presented clearly, and the project continued with that knowledge - not discovered in the middle of development when there is no way back, leaving you with yet another closed project that doesn't fully satisfy the business or achieve its original goal.
Reason 4: Change management comes afterwards - if at all
Digital transformation is not just an IT project but organisational change, with IT as its tool.
In theory everyone knows this. In practice, 90% of the project timeline goes on technology, and not even 10% is left for organisational preparation and user training. Before go-live, a "training" and a "communication" checkbox are added to the project plan - and that's it. Users are then suddenly confronted with a new interface and a new process.
In financial services this is especially critical, because the processes involved are usually compliance-sensitive. Staff don't resist the new system out of "laziness" - they resist because the new process breaks the control points they are used to, and they are accountable if something goes wrong. If nobody manages this tension in advance, the resistance surfaces after go-live - by which time the project has been booked as "closed".
Reason 5: The project's definition of success is technical, not business
"The system went live." "The project closed on time." "We came in at 95% of budget."
These are IT - or at least technical - success metrics. They are not business success metrics.
Business success metrics look like this: "Credit decision lead time fell from X days to Y days." "The customer satisfaction index rose by N points." "The number of manual administrative steps fell by Z%, so 7% fewer administrative resources are needed."
If the measurement points and success criteria aren't defined at the start of the project, at the end everyone can book as a success something that wasn't actually achieved. This isn't deliberate deception - it is the natural consequence of unclear goals.
Over 25 years I have learned that the one question to ask at the very start of a project is: "how will we know it worked?" - and the answer has to be a business metric, not a technical one. (This connects to the first point: what we want to achieve - the goal - must be defined at the very start.)
What does work
To be fair: surveys put the success rate at 30%, and the 30% that succeed usually do these things differently.
The owner of the business requirement is identified - usually an experienced BA or internal product owner who deeply understands both the process and the IT constraints. (This key person's time is allocated to the project as needed.) The system architecture is mapped before architecture decisions are made. Success KPIs are defined in business terms at the start of the project. Change management runs in parallel with technical development, not after it.
None of this is rocket science. Yet in 70% of cases one or more of these elements is missing.
What this means at FrontX
On FrontX digitalisation projects, the business analyst is not "optional" - they are mandatory. Not because it is "best practice", but because experience tells us that without one, the project is likely to end up in the 70%.
Before every digitalisation project, we map the legacy systems, clarify the business requirement and define the success criteria - before a single line of code is written. This doesn't slow the project down - it is what allows it to actually be completed.
We insist on being able to work with the key business stakeholders and on agreeing how much resource we need from each role.
If you are planning a digitalisation project in a financial services environment, we are happy to discuss the first steps: frontx.hu/en/company/contact
Frequently asked questions
Why does digital transformation fail in financial services companies? Industry data suggest that 70% of companies fail at digital transformation. The most common causes: the transformation is treated as a technology project rather than a business change, nobody owns the business requirement, legacy system limitations aren't mapped in advance, change management is neglected, and success metrics remain technical rather than business-focused.
Why is digital transformation especially hard at insurers and banks? In financial services, three factors make it particularly difficult: complex, decades-old legacy systems around which the entire infrastructure is built; strict regulatory and compliance requirements that limit room for manoeuvre; and the domain-specific complexity of the processes - digitalising an insurance product or banking process requires deep knowledge of the sector. 55% of banks consider the limitations of their existing core systems the biggest obstacle.
What is the difference between digitalisation and digital transformation? Digitalisation converts a process or document into digital form - for example, a digital form instead of a paper claim form. Digital transformation goes deeper: rethinking and reshaping the business process with the help of digital tools. The most common mistake is digitalising an existing, poor process - which is digitalisation, not transformation.
When should a business analyst be brought into a digitalisation project? At the very start - not when development begins. The business analyst's job is to uncover the real need, identify the limitations of legacy systems and define success criteria in business terms. If the BA only joins when the specification is being written, the project's strategic decisions have already been made, and the BA is left managing the consequences.
How can the success of digital transformation be measured? With business metrics, not technical ones: has the process lead time fallen, has customer satisfaction risen, have manual steps decreased, has the error rate improved? If success is defined as "it went live" or "it closed on time", it was an IT project, not a transformation.
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services. LinkedIn profile
