Monday, October 10, 2011

Dumb and Dumber. Or how to make sure your data migration problems get noticed.

Recently I received a bill from a company which went to great lengths to make sure I knew they had just replaced their billing system. Not only did their bill now look different (with fonts and colours that probably helped pay this year's private school fees for the children of some design studio director) but they also took the time to include their quarterly magazine (complete with an article on the new system) and a double sided full page insert explaining the layout of the new bill.

All good so far. Help the customers through the change, and all that! Glancing through the insert I noticed that loudly called out was a section which showed the amounts of prior bills and trends - last bill, this time last year, etc, and how this could be used to help customers monitor and control costs. Cool! Being a data guy I went straight to this section on my bill..... only to find nothing but zeros! Discussions with other customers in passing over the next few days told me that several lacked any historical data, some of them had historical data, although often for services that they didn't own and some lucky souls even had current period data for services that had long ago been terminated.

Now those of us that have been through a data migration or two know that they won't be without challenges and that mistakes will occur and some data issues may manifest. Calling these out is a good thing. Customers and users affected by the problem will likely be a lot more accommodating if they know about a problem in advance and are kept in the loop about progress toward rectification. But that's not what has happened here. Rather a feature which could have been a selling point may well have turned into a negative as it alerted customers to potential problems with their bills. At best, even if the data issues were nothing more than missing historical data a potential good news story was wasted and I bet that the company's call centre spent a lot of time fielding enquiries from concerned customers.

So how did this one slip through? Were the data problems a surprise to the company, a black swan that crashed into them after the system go-live, in which case the testing process has failed dismally. Or, were the data problems known but the system put into production anyway due to timelines which couldn't, or weren't allowed to, slip to the right? If this latter scenario was the case why was the extra promotional material sent out too? Surely, a short statement acknowledging the problems and talking about the anticipated fix times would have been more appropriate. Better still why not hold off on the release of the new paper bill layout until the issues had been sorted? This way no-one would have spotted a problem and few people would have been materially impacted.

What lessons can we take from this? The obvious ones we've seen before: Data migrations take time and they will strike unexpected problems - allow both time and money to deal with this when they occur. Plan data migration testing early, expect it to take numerous iterations and allow time for these. If there is not time during the go-live activity for comprehensive data migration testing then be sure to run a full dress rehearsal and test its outputs thoroughly. Perhaps not so obvious, is a very important lesson. Do not allow the data migration to become divorced from the rest of the project. Consider the impacts of data migration events and, when and if needed, take steps in the wider project to ensure that migration issues don't compound and lead to embarrassment, brand damage or unnecessary costs.

No comments:

Post a Comment