Operational Resilience is a key factor in ensuring your business can withstand unexpected events, which often happen outside of your control. 

Being ‘Operationally Resilient” means being able to respond effectively to unforeseen events, protecting your business from risks and allowing you to accelerate towards achieving your business goals. This in turn will passively mitigate the effects of any adverse events.

To highlight just how important this topic is to business leaders, operational teams, and regulators alike, we have considered the impact of a highly publicised, major change programme to separate TSB Bank plc (“TSB”) from Lloyds Banking Group in 2018. Whilst the scale of this change was unprecedented, the need for change, especially in the financial services sector, continues to grow. The need for organisations to be ‘resilient by design’, is therefore of critical importance.

The observations raised below reflect our summary view on the Final Notices issued by the Financial Conduct Authority (FCA) and the Prudential Regulatory Authority (PRA) on the TSB migration programme to separate from Lloyds Banking Group. Over a one-year period, the Programme triggered 225,000 complaints, and £32,000,000 in redress costs to customers who suffered detriment. In addition, the FCA and PRA fined TSB a total of £48,650,000 for operational risk management and governance failures, including management of outsourcing risks, relating to the bank’s IT upgrade programme.

Most recently, to further highlight its laser focus on personal accountability through the Senior Managers Regime (SMR), the PRA also personally fined the former CIO of TSB Bank plc. In this example it was directly related to the lack of supervision paid to the outsourcing arrangements.

If your organisation is undergoing change, why not see if you can augment some of your current efforts with the considerations below?


TSB Timeline of Events


In March 2015, TSB received a takeover bid from Banco de Sabadell, S.A. (‘Sabadell’), a Spanish bank known for acquiring banks in Spain and integrating them onto its IT banking platform (‘Proteo’). A key strategic aim of the proposed acquisition was a full migration of the Firm’s IT services onto the Proteo platform. Sabadell put together a timeline which aimed for migration to be achieved by the end of 2017.

TSB was the first major bank in the UK to undertake a Migration Programme of this scale and complexity, seeking to migrate customers off a third-party platform via a predominantly single migration event to a newly built platform (which was created largely from the existing Proteo (Spain) platform) with new datacentres, to be delivered and operated by an IT service provider with no experience of managing service delivery from UK subcontractors.

Achieving the migration would involve cooperation not only with SABIS and its external suppliers, but also with LBG, who owned the source platform from which the data would be migrated. The Proteo4UK Platform was an unproven version of the existing Proteo (Spain) platform and required significant customisation to meet TSB’s requirements. Migration off the LBG platform onto Proteo4UK was irreversible, creating risk if any major issues arose.

Between 2015 and 2018, TSB undertakes a major IT change program.


TSB Timeline of Events



Thematic Observations


Theme 1: Walk Before You Can Run

Many of the problems encountered within the project can be attributed to trying to do too much, in an unrealistic timescale. The road to missed deadlines and exceeded budgets is paved with good intentions. Careful and informed analysis of the balance between overplanning and under allocating resource is key to ensuring timelines and budgets are realistic and can be kept to.


1. Solutions Implemented Before Completed Designs

Observation 1: While this was done with the intention of actively mitigating delays already in place, this practice should only be taken if absolutely necessary and on a small scale.

Resilience Consideration: This approach causes direct and unmeasurable risk. You are potentially creating further future delays by having to repeat or undo work, exponentially increasing the risk potential. Gain confidence that what is being build is in line with expectations.


2. Did The Same Thing Expecting Different Results

Observation 2: It was recognised that the Migration Program was planned on an insufficiently ‘left-to-right’ basis and as delays were experienced, a re-plan was needed. Unfortunately, the re-plan was also planned on an insufficiently ‘left-to-right’ basis.

Resilience Consideration: While a difficult but courageous decision to make, when adjusting course due to delays and issues, the approach should be directly driven by the causes and impact of those delays and issues. Importantly these factors should be considered in light of the overall objectives e.g., what are the implications.


3. Not All Thematic Risks Managed at Program Level

Observation 3: A risk big enough to be described as thematic can be hard to grasp. It should be given the proper level of authority to manage it, but more importantly it should then be further broken down in to easier and more manageable risks.  This didn’t occur effectively.

Resilience Consideration: Thematic Risks should be directly tied to your high-level business objectives and be used to make informed decisions about how best to achieve those objectives. There should be proper oversight of these risks across the three lines of defence.


4. Complexity Was Identified but Never Solved For

Observation 4: While the Board were correct to highlight the complexities of the proposed migration and the significant reliance on outside parties, there was no subsequent scrutiny on how this would be solved and how it would be tracked.

Resilience Consideration: While it is an important first step, identifying the problem in front of you is just that, the first of many steps. Complexity identified should inform your subsequent solution and empower you to make informed decisions on the best course of action.



Theme 2: Not Passing the Sniff Test

While some of the issues encountered could be attributed to the unique nature and the scale of the project, some of the problems could have been potentially avoided through more stringent risk management, project oversight, and governance.


1. Unjustified Trust in Third and Fourth Parties 

Observation 5: While Third Parties can provide much needed benefits, they will naturally introduce risks which are difficult to spot. Remember that outsourcing responsibility does not outsource accountability.

Resilience Consideration: Engage third parties with a proven track record, wherever possible. Gain assurance over their capabilities throughout the lifecycle of your relationship with them. Define your baseline requirements which must be met for you to be confident in their delivery. Ultimately the outsourcing firm remains accountable, make sure you communicatee, communicate and communicate to ensure all parties are clear on expectations.


2. Risk Management Oversight Did Not Exercise Authority

Observation 6: Teams providing Risk Oversight were asked to conclude their work early, because the migration date had been set, and further risks would only cause further distraction.

Resilience Consideration: Those operating within independent risk functions should be empowered to bring material risks to the attention of leadership teams. Their activities shouldn’t be seen as ‘check box’ to fit around a change programme. It is important that leaders give adequate time to understanding the implications of risk on the targeted business outcomes. Ignoring risks will only increase their likelihood and impact of occurring.


3. Incorrect Focus on Savings Through Technical Delivery

Observation 7: More focus was given to the technical project (and associated savings) rather than considering the implications to customers e.g., customer outcomes or experience.

Resilience Consideration: While the migration was undertaken for a good reason, customer engagement was not prioritised in the decision-making process, resulting in unnecessary and unidentified risk to customers. Greater focus should be applied to both technical and business outcomes.


4. Testing Not Given Enough Credence

Observation 8: Testing costs time and money, and it’s not practical to test everything. Parallel testing was used to speed up the testing process by testing multiple elements at the same time. Testing wasn’t aligned to specific risks, making it unclear what is being tested and why. This was evident in the Programme.

Resilience Consideration: While it can be tempting to mitigate delays, parallel testing can introduce fixes which then affect other parts which have already been signed off as tested. In a major change programme, establish a risk-based testing approach that everyone understands and stands behind.



If you’d like to know more about this topic, why not have a chat with us today?

Get in touch

Also see...

Change Portfolio Governance: Is Your Change Portfolio Really 'Green'?

If you're a change leader with responsibility for change portfolio management, Head of Internal Audit (HOIA), Chief Risk...

Regulatory Oversight, PRA ‘Dear CEO’ Letters – IT Change and Outsourcing

If you're a Head of Internal Audit (HOIA), Chief Risk Officer (CRO), Board member (incl. Non-executive Director), Audit ...

DORA Explained & How to Ensure Compliance

On 27 December 2022, the Digital Operational Resilience ACT (DORA) was published in the Official Journal of the EU. The ...