A Christmas Rant - Who Needs Data Quality in Marketing?

A few days before Christmas my family received a Christmas card in the mail from the real estate agent who handled the sale of the house we bought about 18 months ago. It read:

"Dear Scott, Louise and family, hope you are enjoying the big house. Thanks again and warm regards...."

No doubt it was part of a campaign to have us keep the agent top of mind next time we choose to sell a house, but a nice touch nonetheless. Or at least it would have been had my wife's name been Louise!

What's more the "big house" reference was odd as we had down-sized when we bought this house in order to get a property closer to the city. Something the agent should have known only too well as it had come up in conversation on a number of occasions.

Whilst I found the use of the wrong name a little amusing and the reference to the size of the house didn't bother me, my wife was less than happy. It's a safe bet that when we do choose to sell this house this agent will indeed be top of mind - as someone we will definitely not be using.

For less emotive reasons, I'd actually arrived at the same conclusion as my wife. When I sell a house I want the agent acting for me to employ numerous tools to ensure the fastest sale for the best possible price. One of the tools I expect him to use is a database of potential purchasers which he or she has compiled and curated over time. Now, if the agent in question is unable to get basic details right (such as the name of a purchaser and the size of houses they have lived in) then what faith can I have that any of the other details he has will be accurate. Chances are that all he has is a list of names and a collections of facts which may or may not be right. the marketing campaign he'll conduct on my property may well be targeted incorrectly, either missing an obvious potential buyer or having me waste funds marketing to those who have no interest in my property.

So, he's lost a potential future client. So what? Does that really matter, he hasn't really lost any money, has he? Well, I think he has. If you consider the standard fee for an agent (where I live at least) is 4.25% of the sale price and my house might sell for around half a million dollars then he'll actually miss out on the chance of around $21,000. What's more, if my wife tells 10 of her friends that number balloons out to close to a quarter of a million dollars. Sure, not all of those would have been in the market to sell, nor might he have been one of their considerations for a listing agent, but the point is that there is indeed a cost to what at first glance seems like an almost irrelevant data quality issue.

You don't need to work in real estate to be subject to cost stemming from data quality problems. I'm sure that something of the same ilk could happen in many industries. So next time you're faced with what seems like a data quality issue too trivial to worry about just remember John* and his lost income.

* Name changed to protect the not so innocent.

Dead Men Pay No Bills

There should be more data quality horror stories out there. No, really there should. When we data quality practitioners struggle to get stakeholder buy-in for our initiatives it's good to have a few in the kit bag to pull and illustrate the problems poor quality data can have. So, to that end, let me share a recent experience.

Mid-afternoon late last week my phone buzzed with the arrival of a new text message. It came from a number I didn't recognise: "Steven, we refer to our demand for payment of last week sent to your address in Midway Point. If this amount is not paid by Wednesday at 5PM legal action will be started. Please contact us on xxxxxxxx and quote reference number xxxxxxxx to arrange payment." My first thought was wrong number or phishing attempt. Either way I wasn't going to action the request. Odd though - my Father is Steven and he had a Midway Point address. Odder still in that he died almost 5 years ago.

Curiosity got the better of me. A phone call to the provided number revealed that it was in fact a debt supposedly owed by my Father to a local electricity retailer. That bill had been dealt with years before when the lawyers were wrapping up Dad's affairs, why was a debt collection service chasing payment now and why / how on earth were they chasing me?

This is squarely in brand damage territory. Not the stuff of front page headlines, but certainly fodder for those trashy tabloid "current affairs" TV shows, and certainly capable of causing some degree of negative sentiment, brand avoidance and customer churn. Putting the commercial implications aside, it also has potential for emotional distress. Five years since Dad's passing gave me the space need to see the absurdity of the situation, but I suspect a more recent death would cause unnecessary upset for the person receiving the payment demand.

Looking from the outside in I can only make educated guesses at what is likely to have happened to get to this point. Here goes:

1. I know the company replaced their customer care and billing system between Dad's death and the payment demand. I assume there was a data migration exercise at the same time. Could it be that some part of the data associated with Dad's account wasn't migrated successfully, or even attempted to be migrated at all? Perhaps only the structured transactional data was migrated and the non-structured data attached to the account, such as notes advising of his death, wasn't migrated, or lost its association during migration.

2. There has been a concerted push from the major shareholder of the utility to recover debts recently. What if some form of data matching had been applied in order to find my mobile phone number (previously not associated with Dad's account) and use it as another communications channel to attempt to recover the debt. Dad and I share the same first initial and last name, we have at various times in the last forty odd years shared the same address and we were born in the same month of the year. Did we somehow become fuzzily matched as the same person? I'm all for finding ways to get value from your data in new ways, but it's got to be based on solid foundations - if the data quality is not understood, acknowledged and good enough then the insights gained may well be flawed.

Who knows what really happened - I'm guessing as to the chain of events that transpired. But I am sure of one thing - this is one bill that won't be paid.

So That's What IT Recruiters Are Good For!

The BI Market seems to be fairly hot right now, at least in Australia, if the number of calls I'm getting from headhunters and IT Recruiters is any sort of indicator. However an experience I had this week makes me wonder.

Right now I have a need to ramp up the number of BI folks in our company to handle some project demands. It's a short term gig for the time being so we directly approached a few service firms as well as posting in one or two LinkedIn groups. Two days later I received an email from an IT Recruiter offering me the chance to interview for a great BI position with a first class company there were working very closely with. The position description felt very familiar and no wonder, I'd written most of it only a few days earlier. It had been augmented a bit to give the impression that what was in reality a short term engagement with a slim chance of extension was instead just the initial piece of a long engagement. A hunch had me checking Australia's main jobs website. Sure enough, two more recruiters were also advertising jobs which were also obviously the roles I was trying to fill. Both had extra or erroneous information, I suspect to make their version of the job more attractive than the one being advertised by their competitors.

Recruitment "consultants" taking initiative and creating opportunities to make income for themselves and their companies is one thing, but it causes problems for those of us working in, or managing those working in, the BI arena. With multiple parties now advertising my two roles now seemed like eight, so when those two are filled it will seem as if many more roles have been quickly filled. I suspect this contributes to the general feeling that demand is high and might even be artificially forcing rates up. Worse still will it cause a scenario where this perception of great demand draws people from other IT areas to re-train in the BI field, potentially causing a future glut of supply?

So let's be generous and say that recruitment consultants generate a buzz for us and drive potential candidates our way, but those of us with our own Human Resource Departments could do that anyway. What else do recruiters bring to the table? In my experience the majority of those I've dealt with lack any depth of understanding - matching skills and expertise to roles is haphazard at best, and even basic screening of applicants seems limited to "if they can spell BI then they're qualified to get a second interview".

So, for me I struggle to see the value..... But then I had an experience that made me realize that recruitment consultants do serve a valuable purpose - they're here to make us laugh. I was approached by a recruiter interested in my data warehousing expertise and keen to learn if I had a forklift license and what my typing speed was. I suspect data warehousing may have been a new term for him! Another, during a preliminary chat when I was trying to find a candidate to fill a new data warehousing role, asked me if I felt rising real estate costs would make warehouse space more expensive and cause my firm to lift our rates.

So, guys, keep the laughs coming, but you'll excuse me if I pass on your other offerings!

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.

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.