Every stalled bank transformation I have seen up close had the same autopsy. Deadlines slipped, then slipped again. The budget conversation turned tense. Somewhere along the way the programme stopped being a priority and became a problem to be managed. McKinsey found that more than half of digital banking transformations run past their initial timeline and budget, or fail outright, so the pattern is not unusual. What I want to argue is that it is also not mysterious.
In our experience across banking projects, the reasons deadlines burn are rarely discovered during delivery. They are built in before kickoff, in a handful of estimates that nobody stress-tested. Five underestimations come up again and again. A bank that catches them at the planning stage runs a different programme from the one that discovers them in month nine.
1. The timeline nobody asked the team about
The first underestimation is the most basic one. Management sets the delivery date by feel, without asking the people who will actually build the thing when it can realistically be done. The date then goes into the board deck, the deck creates the commitment, and from that point the plan defends itself. When the team finally sees the scope and says the honest number out loud, the honest number is treated as a negotiation position rather than information.
Nothing sophisticated is needed to avoid this. The estimate has to come from the delivery side before the date becomes public, and the gap between the two numbers has to be resolved by cutting scope or moving the date, never by pretending the gap isn't there. Programmes that skip this step spend their first year discovering it.
2. The readiness that exists only in the deck
The second underestimation sits on the client side, and I say that with sympathy, because it is almost invisible from inside. Banks tend to believe they already have everything a partner needs to start: the documentation, the process descriptions, the clear picture of how things should work in fine detail. Very often that is not true. The documentation describes the system as it was designed years ago, and the knowledge of how it actually behaves lives in the heads of a few people who are already overloaded. The "clear picture" turns out to be clear only at the level of slides, and dissolves the moment someone asks how a specific edge case should behave.
None of this is a reason not to start. It is a reason to plan discovery as real work with real time, instead of treating it as a formality before the real work begins. When readiness is assumed rather than verified, the missing detail doesn't disappear. It resurfaces mid-build, where it costs the most.
3. Change scoped as "digital only"
The third underestimation is about the shape of the change itself. Transformations get scoped as if they concern only the digital layer: new app, new interfaces, new journeys. In reality, almost every meaningful digital change requires changes at the level of business processes and, harder still, at the level of the people who own those business processes. If the process behind a journey stays as it was, the new interface just becomes a prettier way to reach the old bottleneck.
Oschadbank showed this clearly. The bank's first mobile app had existed for over a decade as a limited extension of branch systems, and customers kept going to branches for anything meaningful. What changed the trajectory was a decision about the operating model, redefining the app as a full primary channel and rebuilding the everyday actions around it, with the process owners involved. Once that structural decision was made, the results followed: the rating rose from 3.2 to 4.2 and more than 4 million customers became active mobile users. The detail is in the Oschadbank case study. The digital part was never the hard part. The hard part was that the change ran through the business.
4. Management involvement priced at zero
The fourth underestimation is how much of their own time the bank's leadership will need to put in. Plans assume the partner builds and management occasionally reviews. Then delivery starts, and answers to very simple questions take weeks. Not because anyone is negligent, but because nobody's calendar was ever adjusted to the fact that a transformation generates a constant stream of decisions that only the client can make.
A programme can absorb a slow answer once. When the answer latency is structural, it compounds: the team idles, then reshuffles work to stay busy, then the reshuffled work turns out to need the same missing answer. My practical rule is that the decision-making time of the client's management is a project resource, and it should be planned, with names and availability, exactly the way engineering capacity is.
5. The approval chain nobody mapped
The fifth underestimation is the one that produces rework, and rework is where budgets actually die. Teams assume that to approve a feature touching some business process, a tech lead and a product owner are enough. A banking digital product can have dozens of stakeholders: compliance, the credit committee, product owners, the technology team, operations, legal. A decision holds only when everyone whose process it touches has agreed to it. When a feature ships with half the approvals, the other half shows up after implementation, and the rebuilding starts.
We saw the compound version of this at one of the largest banks in Nigeria, an institution serving more than 30 million customers. For years, innovation there had run as a stream of standalone ideas, shipped without validation and without a fundamental view of how the platform should evolve. Fragility accumulated until teams were afraid to touch core functionality. Rebuilding the product foundations only worked because decision ownership was rebuilt with them, so that deep changes could be agreed once and then hold. The app rating moved from 3.4 to 4.7; the full story is in the mobile ecosystem case study. Mapping who must sign what, before the build, is unglamorous work. It is also the single cheapest insurance a transformation can buy.
The budget is the invoice for all five
Budget overrun is usually described as a cause of stalled transformations. In my experience it is the receipt. An unowned timeline, assumed readiness, change scoped too narrowly, unpriced management time and an unmapped approval chain each convert into extra months, and extra months convert into money. By the time the overrun is visible, the underestimations that produced it are six to twelve months in the past, which is why the budget conversation so often ends up litigating the wrong thing.
But budget is only the visible half of the invoice. The quieter cost starts the moment everyone involved feels control slipping through their fingers. People sense the programme is no longer fully steered, and quality is the first thing to give. Decisions get made to keep moving rather than to be right. Corners that nobody would have accepted at kickoff get accepted at month ten. What was scoped as a genuinely strong product ships as something that works, but carries the unmistakable feeling that it fell short somewhere. Not a failure. Just the quiet gap between what was promised and what arrived, which in banking is its own kind of damage: users feel it, the board senses it, and the team knows exactly where the compromises are buried.
The overrun also lands in an unforgiving climate. Accenture's Banking Top Trends 2026 estimates that around 70 percent of bank IT budgets already goes to maintaining existing systems, and in the UK, research among 150 banking innovation leaders puts core maintenance alone at roughly £3.3 billion for 2026. Change money competes with run money everywhere. A programme that needs more of it, without a defensible account of why, tends not to get it. That is the moment a transformation stops moving: still alive on paper, quietly deprioritised in practice. Where exactly those decisions get stuck inside the organisation is its own subject; we wrote about it in why bank digital programmes stall two levels above execution.
Five questions to ask before kickoff
Each underestimation has a cheap test, and all five can be run in a week, before any commitment hardens.
1. Did the delivery team produce the estimate, or receive it? If the date existed before the people who will build it saw the scope, you are starting with underestimation number one already active.
2. What evidence of readiness exists outside slide decks? Ask to see the actual documentation, the process maps, the named person who can answer edge-case questions. If the answer is "we'll pull it together as we go", plan discovery as a real phase and budget for what it will find.
3. Which business processes will this change, and who owns them? If the scope document lists screens and features but no process owners, the change has been scoped as digital-only, and the process side will surface later at a worse price.
4. Whose calendar has been cleared for decisions? Named people, with agreed response times. If management involvement has no owner and no SLA, simple questions will take weeks, and the plan silently assumes they will take hours.
5. For the three most important features, who has to approve them, end to end? Write the actual chain: compliance, credit committee, product, tech, operations. If nobody can write it, the first version of that map will be drawn by rework.
A bank that can answer all five has not eliminated risk, but it has moved the discovery of its hardest problems from month nine to week one, and that difference is usually the difference between a transformation that ships and one that stalls.
Frequently asked questions
Longer than the first plan says, and the gap is smallest when the estimate comes from the delivery team rather than the boardroom. The banks that sustain transformation treat it as a permanent operating rhythm rather than a project with an end date. Our longest client relationship, with PrivatBank, goes back to 2011 and spans more than 20 products serving over 24 million users. The work never "finished" because product evolution became part of how the bank makes decisions. A better question than "how long" is whether the governance is designed to outlive the initial roadmap.
The earliest one is answer latency: simple questions from the delivery team start taking weeks. Then decisions begin shipping with partial approvals, which shows up later as rework. The roadmap gets trimmed without an explicit trade-off discussion, and steering meetings shift from making decisions to reviewing status. Falling delivery velocity is a late symptom; by the time it is visible, the underestimations behind it have usually been active for months.
Only after checking where the stall actually lives. If timelines were set without the team, readiness was assumed, process owners were never in scope and approvals arrive after implementation, a new vendor inherits every one of those conditions. A vendor change helps when delivery is genuinely the weak link and the surrounding structure is sound. In our experience that combination is rare. Diagnose the underestimations first; the vendor is the most visible variable, and usually the least explanatory one.
The stall is set before the start, which means it can be unset there too
Bank digital transformations rarely fail loudly. They stall, and the stall is manufactured early: a timeline nobody validated, readiness nobody verified, change scoped a level too shallow, management time priced at zero, an approval chain left unmapped, and finally a budget that quietly absorbs the cost of all five. None of this requires better luck to avoid. It requires an honest week of pre-kickoff questions and the discipline to act on the answers.
If your programme is already somewhere in the uncomfortable middle, the same five questions work in reverse as a diagnosis. And if you want a partner whose first instinct is to structure those decisions rather than start building around them, that is precisely how we work. Or simply start a conversation.
Leonid Goriev is Co-founder of Alty, a digital product partner working with banks, fintechs, and regulated platforms across the UK and CEMEA.
Practical notes on fintech product design and banking UX, sent when we have something worth saying.
Further reading
