In 2018, the UK’s Trustee Savings Bank (TSB) experienced a massive IT migration failure that left nearly 2 million customers locked out of their accounts. The events were so catastrophic that by the beginning of 2020, TSB had abandoned the project altogether, outsourcing all its banking system operations to IBM.
Today, we’re looking at the TSB software failure to better understand what happened. Then, we’ll discuss how other organizations can avoid the same issues in their own software projects.
Contemplating litigation?
We have multiple software expert witnesses available for provision of reports, depositions, and testimonies.
The TSB Software Failure: What Happened?
Before we dive into what went wrong, let’s discuss how the project began.
Back in 1995, Britain’s Lloyds Bank merged with the Trustee Savings Bank to form Lloyds TSB. When the 2008 financial crisis hit, the UK government took a stake in the company, which technically qualified as state aid.
In response, Lloyds TSB was required to sell a large portion of its assets. A Spanish bank named Sabadell acquired a portion of Llyods TSB, and the entity was then called TSB.
For a while, TSB rented IT space on the original Lloyds Bank platform. However, it soon became obvious that this arrangement was both awkward and costly.
Sabadell laid plans to move TSB onto its platform, called Proteo. TSB’s tech firm SABIS took charge of the effort in 2015, tasked with creating a UK instance of the Proteo platform, called Proteo4UK.
Unfortunately, the data migration failed, and customers were locked out of their online accounts for weeks at a time. As a result, TSB lost around 330 million British pounds, along with 80,000 customers.
By 2020, the bank’s CEO had resigned, and IBM was brought in to right the incredible number of wrongs.
4 Lessons to Take Away From This Merger & Acquisition IT Failure
What can your organization learn from the TSB software failure? There are several important lessons to learn if you dig into the details. Here are the top points to remember.
1. Weigh the Risks of a Big Bang Implementation
When migrating to new enterprise software, you can choose to take one of several approaches. Two of the most common include big bang and phased.
As the name implies, a big bang implementation happens all at once. Users switch from the existing system to a new platform at a single point in time, and all offices go live simultaneously.
A phased approach, on the other hand, takes a slower, more deliberate pace. With this option, you establish a go-live date for each project phase, rather than going live on a single date across your entire enterprise.
TSB decided to not only take a big bang approach but to do so without considering other options. According to a report commissioned and published by TSB, the bank’s Board failed to discuss the risks associated with a big bang implementation. Additionally, no one consulted an external advisor for guidance.
As a result, the switch happened all at once, and the effects of the failure were immediately widespread. If TSB had taken a more gradual approach, the project team could have identified key pain points and system errors before go-live.
2. Understand the Importance of Conference Room Pilots
A successful project goes through several rounds of testing before it goes live. These events are necessary to ensure the technical components of the solution are functioning. They also reveal how the project will ultimately affect people and processes.
One testing best practice is conducting conference room pilots throughout the system design and implementation phases. This gives your employees a chance to get familiar with the software and allows you to identify inefficiencies in the design or processes that might need further improvement or standardization.
TSB admitted that while it did perform pilots, they weren’t carried out at a sufficient scale. Rather, they were done in small increments, known as “transition events.” These events were meant to mitigate risks associated with the Main Migration Event (MME), but they weren’t adequate to create a real-world pilot scenario.
3. Ensure Realistic Timelines
The original go-live date for the TSB project was November 2017. Sabadell set this date at the beginning, and TSB accepted the proposed timetable, citing that Sabadell had completed similar migrations onto the Proteo platform within this timeframe.
The only caveat? Those earlier integrations vastly differed from the TSB project. Chiefly, TSB required extensive customizations.
While the report shows that TSB acknowledged these differences, the Board didn’t fully understand the complexities of the Proteo4UK Platform. As a result, the project moved full steam ahead, even though there had been protections in place to ensure the system didn’t go live before it was ready.
As the project moved forward, it became clear that TSB didn’t plan for the issues and defects encountered during functional testing.
Further testing pushed the project into April 2018, which rushed non-functional testing and left the system riddled with errors.
4. Ensure Clear Communication and Project Transparency
After 18 months of delays, the TSB Board had the opportunity to ask Sabadell about the technical issues that had arisen. TSB could have inquired as to why Sabadell thought the platform would be migration-ready only four months behind schedule, when some workstreams were up to seven months behind schedule.
Instead of investigating the causes behind the delays, TSB went along with the updated timeline. As a result, the final platform was unstable.
Clear communication and strategic alignment should be prioritized at every stage of an enterprise software project. In this instance, we’re not talking about organizational change management but about communication regarding strategy and planning – every decision maker should be on the same page.
This ensures that nothing is left assumed or obscured. In the case of TSB, not speaking up was a major detriment.
Find Enterprise Software Success
As we’ve learned, planning and communication are critical at every stage. If there are gaps in this information flow, then errors get missed and software can go live before it’s ready.
Looking for support as you begin an ERP implementation, merger & acquisition integration, or another daunting initiative? Our ERP software consultants can help you develop a plan designed to avoid common failure points. Request a free consultation below.
