This Thursday is Thanksgiving Day, which is a United States holiday with a long and varied history. The most consistent themes remain family and friends gathering together to share a large meal and express their gratitude.
This is the eighth entry in my ongoing series for expressing my gratitude to my readers for their truly commendable comments on my blog posts. Receiving comments is the most rewarding aspect of my blogging experience. Although I am truly grateful to all of my readers, I am most grateful to my commenting readers.
“Being a lover of both music and data, it struck all the right notes!
I think the analogy is a very good one—when I think about data as music, I think about a companies business intelligence architecture as being a bit like a very good concert hall, stage, and instruments. All very lovely to listen to music—but without the score itself (the data), there is nothing to play.
And while certainly a real live concert hall is fantastic for enjoying Bach, I’m enjoying some Bach right now on my laptop—and the MUSIC is really the key.
Companies very often focus on building fantastic concert halls (made with all the best and biggest data warehouse appliances, ETL servers, web servers, visualization tools, portals, etc.) but forget that the point was to make that decision—and base it on data from the real world. Focusing on the quality of your data, and on the decision at hand, can often let you make wonderful music—and if your budget or schedule doesn't allow for a concert hall, you might be able to get there regardless.”
“I used to get incredibly frustrated with the data denial aspect of our profession. Having delivered countless data quality assessments, I’ve never found an organization that did not have pockets of extremely poor data quality, but as you say, at the outset, no-one wants to believe this.
Like you, I’ve seen the natural defense mechanisms. Some managers do fear the fallout and I’ve even had quite senior directors bury our research and quickly cut any further activity when issues have been discovered, fortunately that was an isolated case.
In the majority of cases though I think that many senior figures are genuinely shocked when they see their data quality assessments for the first time. I think the big problem is that because they institutionalize so many scrap and rework processes and people that are common to every organization, the majority of issues are actually hidden.
This is one of the issues I have with the big shock announcements we often see in conference presentations (I’m as guilty as hell for these so call me a hypocrite) where one single error wipes millions off a share price or sends a space craft hurtling into Mars.
Most managers don’t experience this cataclysm, so it’s hard for them to relate to because it implies their data needs to be perfect, they believe that’s unattainable and lose interest.
Far better to use anecdotes like the one cited in this blog to demonstrate how simple improvements can change lives and the bottom line in a limited time span.”
“Yes, quality is in the eye of the beholder. Data quality metrics must be calculated within the context of a data consumer. This context is missing in most software tools on the market.
Another important metric is what I call the Materiality Metric.
In your example, 50% of customer data is inaccurate. It’d be helpful if we know which 50%. Are they the customers that generate the most revenue and profits, or are they dormant customers? Are they test records that were never purged from the system? We can calculate the materiality metric by aggregating a relevant business metric for those bad records.
For example, 85% of the year-to-date revenue is associated with those 50% bad customer records.
Now we know this is serious!”
“I am constantly amazed at the number of folks I meet who are paralyzed about advanced analytics, saying that ‘we have to fix/clean/integrate all our data before we can do that.’
They don’t know if the data would even be relevant, haven’t considered getting the data from an external source and haven't checked to see if the analytic techniques being considered could handle the bad or incomplete data automatically! Lots of techniques used in data mining were invented when data was hard to come by and very ‘dirty’ so they are actually pretty good at coping. Unless someone thinks about the decision you want to improve, and the analytics they will need to do so, I don’t see how they can say their data is too dirty, too inconsistent to be used.”
“Early in my career, I answered a typical job interview question ‘What are your strengths?’ with:
‘I can bring Business and IT together to deliver results.’
My interviewer wryly poo-poo’d my answer with ‘Business and IT work together well already,’ insinuating that such barriers may have existed in the past, but were now long gone. I didn’t get that particular job, but in the years since I have seen this barrier in action (I can attest that my interviewer was wrong).
What is required for Business Intelligence success is to have smart business people and smart IT people working together collaboratively. Too many times one side or the other says ‘that’s not my job’ and enormous potential is left unrealized.”
“It amazes me (ok, not really...it makes me cynical and want to rant...) how often Business and IT SAY they are collaborating, but it’s obvious they have varying views and perspectives on what collaboration is and what the expected outcomes should be. Business may think collaboration means working together for a solution, IT may think it means IT does the dirty work so Business doesn’t have to.
Either way, why don’t they just start the whole process by having a (honest and open) chat about expectations and that INCLUDES what collaboration means and how they will work together.
And hopefully, (here’s where I start to rant because OMG it’s Collaboration 101) that includes agreement not to use language such as BUSINESS and IT, but rather start to use language like WE.”
“Just a couple of days ago I had this conversation about the curse of IT in general:
When it works no-one notices or gives credit; it’s only when it’s broken we hear about it.
A typical example is government IT over here in the UK. Some projects have worked well; others have been spectacular failures. Guess which we hear about? We review failure mercilessly but sometimes forget to do the same with success so we can document and repeat the good stuff too!
I find the best case studies are the balanced ones that say: this is what we wanted to do, this is how we did it, these are the benefits. Plus this is what I’d do differently next time (lessons learned).
Maybe in those lessons learned we should also make a big effort to document the positive learnings and not just take these for granted. Yes these do come out in ‘best practices’ but again, best practices never get the profile of disaster stories...
I wonder if much of the gloom is self-fulfilling almost, and therefore quite unhealthy. So we say it’s difficult, the failure rate is high, etc. – commonly known as covering your butt. Then when something goes wrong you can point back to the low expectations you created in the first place.
But maybe, the fact we have low expectations means we don’t go in with the right attitude?
The self-defeating outcome is that many large organizations are fearful of getting to grips with their data problems. So lots of projects we should be doing to improve things are put on hold because of the perceived risk, disruption, cost – things then just get worse making the problem harder to resolve.
Data quality professionals surely don’t want to be seen as effectively undertakers to the doomed project, necessary yes, but not surrounded by the unmistakable smell of death that makes others uncomfortable.
Sure the nature of your work is often to focus on the broken, but quite apart from anything else, isn’t it always better to be cheerful?”
“They say that sport coaches never teach the negative, or to double the double negative, they never say ‘don’t do that.’ I read somewhere, maybe Daniel Siegel’s stuff, that when the human brain processes the statement ‘don’t do that’ it drops the ‘don’t,’ which leaves it thinking ‘do that.’
Data quality is a complex and multi-splendiforous area with many variables intermingled, but our task as Data Quality Evangelists would be more pleasant if we were helping people rise to the level of the positive expectations, rather than our being codependent in their sinking to the level of the negative expectation.”
DQ-Tip: “There is no such thing as data accuracy...” sparked an excellent debate between Graham Rhind and Peter Benson, who is the Project Leader of ISO 8000, which is the international standards for data quality. Their debate included the differences and interdependencies that exist between data and information, as well as between data quality and information quality.
Thanks for giving your comments
Thank you very much for giving your comments and sharing your perspectives with our collablogaunity.
This entry in the series highlighted commendable comments on OCDQ Blog posts published in August and September of 2010.
Since there have been so many commendable comments, please don’t be offended if one of your comments wasn’t featured.
Please keep on commenting and stay tuned for future entries in the series.