Thursday, October 27, 2011

Dumb, Dumber and Dumberer: Or how to make sure your data migration problems really hurt.

A little while ago I blogged / ranted about the importance of keeping the data migration activity close to the main project and not allowing it to drift away into its own little world. I used an example of a company that services me which had been through a recent data migration process and how choices it made with regard to communications with customers had apparently been made without regard for data migration issues, with the end result being data quality issues which might otherwise have gone unnoticed being made very obvious to the customer. If you like you can read the original piece here: Dumb and Dumber, or how to make sure your data migration problems get noticed.


Fast forward three weeks and I received my next quarterly bill from the company. No folks, that wasn't a typo - the bill for the next quarter arrived only three weeks after last quarter's bill. A quick glance at the bill confirmed that the data migration problems hadn't been resolved. That's OK, it had only been three weeks after all! But, amazingly, I got the same extra communications and marketing collateral I'd received last time that had inadvertently drawn attention to the data migration and data quality problems. Ok, I can understand how a lack of an holistic approach to the new billing system rollout could have resulted in this happening last time, but surely the flood of calls they must have got to their call centre after the last bill cycle must have alerted something that something was amiss. Do these people need a sledgehammer to drive the point home? Or, more likely, is it symptomatic of how bad the isolation of data migration activities are - a problem for IT to  own and solve. (Watch this space for a blog post on that issue as well!)

So, what's to be learned here? The key [new] takeaway for me is that data migration activities don't end at the conclusion of the go-live weekend. Having the data loaded into the new system is only one milestone on the journey. Someone needs to continually monitor the quality of data  and assess if it continues to be fit for purpose in its new home. This should include monitoring indicators from around the organisation that might provide clues that there are data issues afoot. And, in today's world where social media abounds, this monitoring really should extended outside the organisational boundaries as well. Chances are the marketing department already has some sort of monitoring of social media, so connect in with these folks and work out from there.

As a footnote (and perhaps not connected to the data migration) the company had also failed to reconcile my payment of the last bill against my account and so included a demand to pay this prior amount immediately. However they were nice enough to point out that if I was having trouble paying my bill they have options to help.  I'm contemplating if I should send them a reply along the lines of "Thanks for your offer. All good here, but are you experiencing difficultly migrating your data? Please contact us for a confidential discussion on how we may help you. Information architects have Data Migration Policies and can arrange suitable remediation plans for immature organisations."

But it's not all bad, at least they provided an example of how brands and reputations can be damaged as a result of poor data migration (and related) decisions. That's material for another blog post. You can read it here: Selling the Data Migration Strategy.

No comments:

Post a Comment