   |
By Sjoerd de Wijn, Randal van Vliet and Pei-Hsuan van Sloten-Lo |
The Unfortunate Fate of Strategic Transformation
Few projects carry as much risk as a large-scale transformation. A core banking replacement, a post-merger integration, a regulatory remediation programme or a move to cloud-native architecture will typically run three to five years, cost (hundreds of) millions, and touch most of the key functions of the organisation.
The track record is not encouraging.
McKinsey, BCG and Bain consistently find that 60% to 90% of these programmes miss their original objectives. They slip, blow their budgets, ship a watered-down scope, or get quietly shelved when the sponsoring executive moves on. Financial services have no special exemption from this pattern; if anything, heavy legacy estates, intense regulatory scrutiny and consensus-driven cultures make matters worse.
The transformation track record
|
88% of business transformations fail to achieve their original ambitions |
70% of digital transformation initiatives fail to meet their objectives |
|
75% of digital transformations fail to generate returns exceeding the original investment |
2 in 3 senior leaders experience at least one underperforming major transformation within five years |
Sobering as they are, the figures argue for treating programme risk with the same seriousness financial institutions already apply to credit, market and operational risk. In the work we do across Dutch banks, insurers and payment firms, the same handful of under-managed risks turn up repeatedly. Caught early, they are manageable.
The Main Risks in Strategic Transformation
Across the transformations we have supported, five categories of risk repeatedly emerge as the main threats to delivery. Other risks exist, but these are the ones most likely to derail a programme when nobody is actively managing them. They also reinforce each other. A resourcing gap tends to push scope decisions in the wrong direction; the resulting scope changes squeeze the budget; budget pressure exposes which dependencies were never properly secured; and the consequences eventually land on already-busy governance bodies. Managing them one at a time rarely works.
Five risks that derail strategic transformation
| 1 |
Resource & Skills Availability Shortage of the right people, with the right expertise, at the right time. |
| 2 |
Missed Scoping Processes, applications or obligations not identified within the defined scope. |
| 3 |
Budget Constraints Structural underfunding, or mid-programme budget reductions. |
| 4 |
Dependency on Other Projects Unresolved dependencies on other concurrent programmes or upstream deliverables. |
| 5 |
Governance & Decision Making Slow, fragmented or unclear decision-making structures. |
The risks reinforce each other
|
1. Resources Resourcing gap |
2. Scope Wrong scope calls |
3. Budget Budget squeezed |
4. Dependencies Gaps exposed |
5. Governance Overloaded bodies |
The rest of this paper takes each risk in turn and sets out what we have found works in practice. The mitigations described draw on our project work in the Dutch market, including programme rescue and PMO assignments for major banks and insurers.
1.
Resource and Skills Availability
Specialist talent in financial services is scarce, and the scarcity is structural rather than cyclical. A modern transformation needs three kinds of expertise that rarely live in one person: domain knowledge, regulatory literacy and technical depth. The few people who hold all three are also the ones the rest of the bank cannot easily do without. They get pulled into quarter-end reporting, audit responses, incident investigations and the steady drip of small change that keeps the institution operating. Even when formally allocated to the programme, they are rarely fully available in practice. FiSer observed this directly in a Basel IV implementation programme at a large Dutch bank, where delivery depended on scarce expertise across Risk, Finance, IT, Data Management and business teams. The programme required specialists who understood Basel IV methodology, RWA calculation logic, collateral treatment, segmentation, use of external ratings, reporting templates and supervisory expectations, while the same people also had to support BAU regulatory and operational work.
Resource risk at a glance
|
3 kinds of expertise needed (domain, regulatory, technical) that rarely live in one person |
3–6 months normal lead time to source a missing specialist skill |
1 person key person risk: one absence can halt progress |
Three patterns show up most often:
Key person risk. A single individual whose absence halts progress. Their knowledge of a legacy system, an undocumented process or a regulatory interpretation is irreplaceable on a short timeline.
Capacity constraints. Not enough headcount to deliver programme work alongside ongoing BAU obligations. The numbers on paper look fine, but the real availability does not.
In the Basel IV case, the issue was not simply that the bank needed more people. The same experts were needed across multiple workstreams at once, including collateral eligibility, collateral management, segmentation, external ratings, reporting, testing, issue resolution and governance updates. At the same time, these people still had BAU responsibilities, including regulatory reporting, internal reviews, data quality work and operational activities. Without strict prioritisation, Basel IV tasks could easily be delayed by daily business demands. These are capacity constraints: the programme cannot run effectively because there is not enough available workforce with the right expertise.
Skill gaps. Specialist expertise that cannot be sourced internally at short notice. Lead times of three to six months are normal, and a skill gap identified late in design almost always pushes go-live.
Basel IV also created specific knowledge gaps. Teams needed to understand revised risk-weighted asset calculations, the new standardised approaches, the output floor, limitations on internal models, collateral treatment, segmentation rules and the use of external ratings. Some teams understood their own business area, but not the full Basel IV impact across data, calculation, reporting and governance. This created a risk that issues were identified too late, or that remediation actions were technically correct but not aligned across the full reporting chain.
What works in practice
Work on this risk has to start before the programme formally begins. That means mapping the roles that are genuinely critical to delivery (often not the most expensive roles), getting written resource commitments from line management rather than verbal assurances, and pre-arranging contingency through a vetted contractor pipeline and structured knowledge transfer. The aim is simple: fewer single points of failure once delivery is in flight.
In a Solvency II PIM rescue we ran for a major Dutch insurer, previous attempts to implement the Partial Internal Model had been declared unsuccessful and the programme was carrying open findings from regulators and internal audit. We restructured the team around an experienced Programme Manager focused on change management, together with a Business Alignment role tasked specifically with the early identification and escalation of issues across business units. With the right people in the right roles, the programme eventually closed out the findings that had defeated previous attempts.
2.
Missed Scoping
Most financial institutions run application estates that no single person fully understands. Decades of organic growth, acquisitions, divestments and regulatory retrofits have left thousands of applications in place, many of which predate the current management team. Shadow IT proliferates in the business. The result is that costly scope adjustments mid-programme are the rule, not the exception, and they tend to arrive at the worst possible moment: after the business case has been approved and the steering committee has moved on to delivery metrics.
Shadow IT and legacy systems. Undocumented tools, end-user computing and ageing systems that surface only mid-programme, when integration or decommissioning cannot be avoided any longer.
Scope creep. Uncontrolled additions beyond the agreed boundary. Contingency and schedule are consumed quietly, one "while we’re at it" request at a time, without formal impact assessment or approval.
Late compliance requirements. Regulatory obligations identified after the design is locked. Each retrofit adds cost and rework, and in regulated environments creates direct supervisory risk if a deadline cannot be met.
What works in practice
What truly makes the difference is investing in a genuine discovery phase before the scope is locked in. Review each in-scope business process with the operational team and identify any tools, applications, or data sources they use that are not currently captured on the list. Inventory the end-user computing (spreadsheets, Access databases, personal scripts) against a clear risk taxonomy. Catalogue the lot in a programme-owned register. Anything not catalogued by a defined deadline is explicitly excluded from the business case, and that exclusion is communicated openly. Bring Compliance, Legal, Financial Crime and Operational Risk into the conversation from day one, not as late reviewers. Treat regulatory horizon scanning as an ongoing activity rather than a one-off task.
A genuine discovery phase, before scope is locked
|
1. Review each in-scope process with the operational team |
2. Inventory end-user computing against a risk taxonomy |
3. Catalogue everything in a programme-owned register |
4. Exclude what is not catalogued by the deadline |
5. Involve Compliance, Legal, FinCrime and OpRisk from day one |
A documentation programme we ran for a major Dutch insurance client showed how much hidden scope a serious discovery effort can surface. The brief was to set up a maintainable documentation framework for a new execution organisation built on a greenfield IT landscape. By close, the team had produced more than 400 pages describing systems, processes and (non-)key controls. Many of the details had never been written down before and would otherwise have remained inside the heads of a few individuals.
What serious discovery surfaces
|
400+ pages describing systems, processes and (non-)key controls |
Greenfield IT landscape for a new execution organisation |
3.
Budget Constraints
Transformation budgets in financial services routinely underestimate the full cost of change. The visible items (software licenses, integrator fees, internal labour) are usually modelled well enough. The invisible items are what break business cases. Parallel-run periods between legacy and target systems, end-user training at scale, process redesign, data cleansing, regulatory archive retention, legacy decommissioning, and the multi-year operational uplift of running a more sophisticated target platform are all routinely omitted or under-scoped at submission.
The result is a structural funding gap that forces increasingly painful trade-offs as delivery progresses. Contingency goes first, then scope, then quality, then timeline. Each trade-off looks rational at the time; together, they erode the business case, and this happens before any external shock arrives. A regulatory fine elsewhere in the bank, a worsening macro environment or a change in strategic priority can then drop a top-down cut onto a programme already running on fumes.
How a business case erodes
|
1. Contingency goes first |
2. Scope is cut next |
3. Quality is compromised |
4. Timeline finally slips |
Underestimated project costs. Business cases that ignore parallel-run, training, data cleansing or decommissioning. Decommissioning is the most reliably underestimated item; retiring a legacy core or trading system tends to require a multi-year tail of archive access and regulatory query response that rarely appears in the initial submission.
Unplanned resource costs. When an internal team cannot deliver, the default response is to engage external help at premium rates. A modest substitution of two or three contractor roles over twelve months can consume several hundred thousand euros that was never budgeted.
Mid-programme cuts. Funding reductions driven by deteriorating market conditions, competing priorities or a change of senior sponsorship. Programmes that have not planned for this scenario get rescoped under pressure, usually badly.
What works in practice
Model the total cost of transformation across all phases, including parallel-run, training (with refresher cycles), data migration, hyper-care, decommissioning, and the sustained operational cost of the target state. Have the numbers reviewed independently, ideally by someone with no stake in the programme proceeding. Hold a resource contingency of at least 15% of direct labour cost with clear triggers and authority for accessing it. Stress-test against a 20% budget reduction, and agree a written de-scope hierarchy before the pressure arrives, so the answer to "what goes first?" is already in the governance pack when a cut lands.
Budget safeguards that work
|
15% minimum resource contingency of direct labour cost |
20% budget reduction to stress-test the programme against |
1 written de-scope hierarchy agreed before pressure arrives |
The previously mentioned Basel IV programme at a large Dutch bank is a concrete example of this budget pressure. The implementation was run as a 1.5-year time-boxed strategic change initiative with a fixed 1 January 2025 go-live deadline. Basel IV created cost pressure through higher capital requirements, data and IT infrastructure upgrades, and additional compliance expenditures. In practice, the programme required investment in RWA calculation changes, data sourcing, model and reporting adjustments, control updates, testing, governance routines and senior management reporting. The fixed deadline also meant that delays could not simply be absorbed by extending the timeline, making external delivery support and strict PMO discipline necessary to keep the programme moving. This shows how budget risk in regulatory transformation is not only about the initial budget estimate, but also about the cost of mobilising scarce expertise, closing gaps quickly and maintaining delivery control under supervisory pressure.
4.
Dependency on Other Projects
Major financial institutions do not run one strategic programme at a time. A tier-1 bank will typically have several major programmes live in parallel: core banking modernisation, cloud migration, AML uplift, regulatory reporting and ESG build-outs are all common. Each of them draws on the same scarce resources: the enterprise data platform team, the identity and access management team, the cloud platform, the core vendor’s on-site specialists, and a handful of senior architects whose attention is effectively load-balanced across the portfolio.
Inter-programme dependencies are under-estimated and under-governed. They sit across multiple sponsors, no single programme owns them, and they fail in ways that surface somewhere other than where they originated. A delayed API delivery from an infrastructure programme will turn up as a timeline problem in a consuming programme that had no visibility of the original risk.
Shared resource conflicts. Multiple programmes competing for the same specialists. The best-sponsored programme wins, often without formal arbitration, and the others quietly slip rather than escalate.
Blocked deliverables. Outputs held hostage to another team’s late API or platform delivery, with no contractual obligation or workable escalation mechanism in place.
Data migration delays. Upstream data quality issues may block everything downstream. Every week of delay cascades into training, testing and cutover for every consuming system.
What works in practice
Maintain a live portfolio-level dependency register, owned by the transformation office or portfolio PMO, with named owners on both supplying and consuming sides of every dependency, agreed delivery dates and a defined escalation path. Resource conflicts go to a portfolio steering body with the authority to make trade-offs between programmes, not merely observe them. Define data readiness as a formal go / no-go criterion with measurable thresholds and rehearse migrations at realistic volumes before cutover. Where dependencies sit with external vendors, insist on contractually binding delivery dates rather than best-efforts language.
For one Dutch insurer, a Strategic Asset Allocation study required by the regulator following an envisaged merger could only be delivered by getting 1st and 2nd line business units and Group to co-operate across organisational boundaries. The programme delivered on time and on budget. The multi-year balance sheet projection it produced has since been used in a three-year investment plan, generating more than €30 million in additional annual capital generation. The harder work was up front: agreeing roles, baselining the deliverables and setting up a PMO that could resolve cross-unit dependencies before they hit the critical path.
Strategic Asset Allocation study: the result
|
€30m+ additional annual capital generation |
On time and on budget |
3-year investment plan built on the balance sheet projection |
A separate Partial Internal Model oversight engagement for another Dutch insurer made a similar point. The business units and Group had each been managing their own internal models for market risk. The value of the engagement came from finally giving the various activities a centralised view, with a standardised reporting cadence and aligned planning.
5.
Governance and Decision Making
Financial institutions combine mandatory regulatory approval chains with consensus-driven cultures. The correct process and the expedient one are often in tension. A single technical architecture decision in a large bank may need review by several committees (an Architecture Review Board, a Technology Risk Committee, a Data Governance Forum, a Change Advisory Board and a programme Steering Committee), each on its own cadence. Layered on top are the three lines of defense model, divisional governance, and the informal pre-meetings needed to avoid surprises at the formal bodies.
One decision, five committees
Each body runs on its own cadence. A design decision can block a Scrum team for eight to twelve weeks.
Decision latency erodes velocity. A design decision blocking a Scrum team for eight to twelve weeks while it works through the governance stack is not unusual. During those weeks the team either builds around the gap (creating technical debt and rework later) or sits idle and burns budget. Neither outcome shows up clearly in status reporting; the decision is simply "in progress with governance" for week after week, with no single body accountable for resolving it.
Slow decision making. Approval chains across multiple committees extend timelines. A single architectural decision can traverse four committees over ten weeks; no individual decision-maker intended this outcome, but it emerges from the system.
Conflicting priorities. Retail versus wholesale, front office versus operations, revenue-generating versus risk-management functions hold different views on what a transformation should prioritise. Without a way to arbitrate, the same disputes keep reopening previously closed decisions.
Unclear ownership. No named accountable owner for key decisions. Responsibility diffuses, everyone is consulted, and nobody decides.
What works in practice
Define a tiered decision-rights framework that maps decision types to the lowest governance level at which they can safely be taken, with maximum response timelines at each tier and automatic escalation when those times are breached. Where possible, consolidate overlapping committees; a single well-attended Programme Board is usually more effective than five specialised ones. Mandate a RACI with one named Accountable owner per decision domain (not a committee, not a shared role), ratified by the executive sponsor. Resolve cross-unit conflicts at steering level using a small set of pre-agreed priority principles: regulatory commitments take precedence over commercial ones, customer-harm prevention takes precedence over cost optimisation, and audited process integrity takes precedence over delivery speed. Quote them explicitly when trade-offs are made, so the rationale is consistent rather than re-litigated at every forum.
Pre-agreed priority principles
| Regulatory commitments | takes precedence over | Commercial ones |
| Customer-harm prevention | takes precedence over | Cost optimisation |
| Audited process integrity | takes precedence over | Delivery speed |
Most of our project rescue work in the Dutch market eventually comes back to governance. In an Asset & Liability Management change programme at a major Dutch bank, we pulled all the change initiatives under a single central programme management organisation, set up a Project Board with weekly status, a bi-weekly Steering Committee, and formal change controls. Delivery teams shifted to an Agile way of working with daily stand-ups. That structural change is what produced a roughly 50% improvement in compliance status across a €50 million multi-year change initiative.
ALM change programme: the result
|
~50% improvement in compliance status |
€50m multi-year change initiative |
Weekly Project Board, bi-weekly Steering Committee |
The Solvency II PIM rescue followed the same pattern of governance simplification: an experienced Programme Manager focused on change management, a Business Alignment role for early issue identification, and a small number of clearly accountable decision bodies. A separate engagement for another Dutch insurer on Solvency II Ratio Estimation governance produced faster and higher-quality reporting once a clear process overview and tightened project structure (weekly updates to the project management team, monthly updates to the Steering Committee) were in place. Getting governance right is rarely the most glamorous part of a programme, and it is almost always what determines whether it lands.
FiSer’s Approach
Implementing complex strategic programmes requires a structured approach to ensure timely delivery. At FiSer, we believe delivery assurance should be built into a programme from the start, not checked at the end. As an independent firm focusing on financial services, we combine subject-specific expertise with disciplined programme and project management, supporting our clients from strategy design to implementation.
In this publication, we summarised five programme risks that commonly appeared in strategic transformation programmes. To us, they are a connected system rather than separate problems, and we have developed corresponding approaches that have been proved to be effective. Learning from our experiences of rescuing programmes that lost their way, we also know how to identify and address the early warning signs.
Our mission is to be the assurance of delivery for our clients. If you are planning a transformation, or are already in the middle of one, we would be glad to discuss how we can help.
About the authors
 |
Working Student, FiSer Consulting |
 |
Banking Practice Lead, FiSer Consulting |
 |
Senior Banking Consultant, FiSer Consulting |
