What can we learn from TSB recent migration fiasco

What can we learn from TSB recent migration fiasco

During the past years, all of us have grown accustomed to online services as a daily tool to manage our households, relationships, and business. We expect it to be without failure, always available and to continuously improve.

TSB failure to its customers on this premise during the past week has highlighted to many of us the value of a properly planned and executed Migration and how badly things can go.

For the past 15 years, I spent most of my time in migration programs. These have been mostly successful but some less thus allowing me to gain a good understanding of the common mistakes being made. When talking to c-level executive these days, I find it necessary to first align many of the misconceptions that exist. I felt it is key to share few of our key lessons and factors leading to successful migrations thus avoiding a fiasco such as TSB.

Within our teams, we have put together what we refer to as the 10 "commandments” of migration which we use to guide our customers in this challenging journey.

 #1:      Set the expectations (Internal) – often we are all pushed for deadlines, yet key in migration is setting up the correct expectations internally first. To do so, we typically do preparation work with executives to align with a set of migration principles. These principals define the framework of the migration do’s and don’ts. These principles that are approved on executive/board level later allow the team to operate on execution level with the correct business framework. They are general and flexible, thus do not define low-level details for the teams but they do set a clear strategy of how the migration will be managed.

 

#2:      Do all you can do before – typically we advise our customers to conduct few mini projects prior to the program in order to simplify the work on the bulk migration. An inflated product catalog and customer distribution on a dispersed products portfolio are key failures during migration. As an example, assume we have a million customers, 80% of these customers will typically reside on about 15%-20% of our product portfolio (even less will drive actual revenue), thus we end up with about 20% of our customer base with many fragmented product offerings. These products typically carry service processes and business processes to fulfill them as well data management layers to support. A key preparation activity is to run in advance a rationalization of the product portfolio and migration of customers from the legacy defined products.

#3:      Get an early start – typically in transformation programs, the migration workstream is pushed to late stages as naturally, it is at the last phase. Migration is intensive, detailed and not a customer facing activity. Besides, working with tables of data for most of us is less glamorous than a new mobile app design. The earlier you start the more likely you are to get it right.  

#4:      Strategy first – yes, I know, it seems obvious, right – you’d be surprised. Too often we are brought in to assist failed projects, we often see that key strategic elements have not been properly set and this caused most of the failed activities down the road. You must assure that the migration part of the program is clarified for its priority and the strategy is clear and communicated. After all, the most wonderful applications have no value without customers data.

#5:      Junk in, junk out – align your business stakeholders, assure only needed data is taken and profile the new data sets by the target software requirements, regulations and needs of the business going forward. This is not an exercise of copy paste, get your data right.

#6:      You’ll get it wrong at first – I have yet to see a migration project that got it right on the first go. Test, test again, test more. Yet at some point its time to stop testing and start learning in the real environment (often all looks great in testing but tends to be less than ideal in live environments). Build and plan so it is possible to experiment with real users (subset, friendly) make small mistakes and quick so this can be fixed and scaled.

#7:      Simulate to perfection - following key failures some years ago, we have decided to implement a simulation strategy. Similar to a ballet company that rehearses each step to perfection, we have learned to copy this attitude and assure each person in the extended teams is aware of his/her part. This leads to a well-oiled machine that knows how to migrate customers’ data properly. 

#8:      An army like execution – after years of work, plans and teams who spent countless hours to prepare, it’s all down to execution. It is not the time for democracy, make sure your plans are to swiss clock precision and that execution is controlled centrally. We recommend to our customers to assure the “plan for the worst, hope for the best kind of approach”. We test our execution processes and people as it is a project of its own.

#9:      Not an IT show – at the end of the day technology is there to support business drivers. Get business stakeholders to actively participate and immerse themselves in the process. Typically, users will first time engage with the new systems post migration and so all relevant support teams need to be ready for the change. Assure you are prepared for the introduction of the systems from an operational perspective and teams know how to co-exist in both ecosystems.

#10:  Have legal, customer experience and communication teams ready - prepare statements and messages in the event that somethings go wrong, handling must be swift and without delay, there is a narrow window. Most organizations get this wrong! Customers will know today within few hours that something isn’t in order and will take it to social media and company support centers. Be ahead of the curve, if something is wrong, identify the impacted customers and communicate without delay, after all, you have it planned.

Recently I am asked how migration processes impact GDPR, how all this relates to GDPR? Well GDPR is mostly dealing with data management of customers. Many EU companies and other companies who serve EU customers are racing to meet May GDPR timelines. Often, companies will be required to consolidate many small and fragmented legacy systems into the leading CRM or data management systems used by the organization. Following an approach of clean up and consolidated migration, organizations will be able to achieve a quicker GDPR compliancy roadmap.

Full disclosure, the writer is an executive partner at GO-TE Consulting a company specializing in data migration and GDPR programs in Telcom and Banking.

I've done this probably 30 times in my career for banks, moving from old system to new system. It is not easy. There's not many options for rolling back with so many other system dependencies. Historical data needs to really be bridged rather than duplicated. Migration isn't straightforward from system to system. But strong testing, dress rehearsals and ownership by the business and technology is required.

Like
Reply
Clive Bowles

IT and Banking Consultant

7y

Perhaps an additional consideration to the excellent advice already provided, pick a tried & tested data migration tool like the one Fairmort provides rather than trying to re-invent the wheel.

To view or add a comment, sign in

More articles by Oz Waknin

Insights from the community

Others also viewed

Explore topics