One of the cool things about the Internet is that you can constantly expand your knowledge base. I have already learned a great deal reading the posts on this forum. I had posted a few weeks ago on my own site about how writing books counts as my second IT education, and perhaps being a part of this community is my third. After two months of posting on this site, one thing to me is crystal clear:

I’m certainly not alone in my belief that many organizations don’t take data quality seriously–or at least as seriously as they should.

In this post, I’d like to focus on why leaders at many organizations merely pay lip service to data quality.

At some level, they know that DQ is important.

I’ve had many spirited discussions with both IT folks and line managers in my years of consulting. I have yet to encounter anyone who would admit that the integrity and quality of his/her organization’s data was not important.

In a way, this reminds me of some of my early career frustrations working in HR, before I turned to consulting. No one would admit that HR (the department or its overall) was, er, “less than strategic.” Unfortunately, their actions belied their comments.

Simon Says

It’s not enough to admit that DQ matters. Of course it does. Actions matter much more than words.

They realize that they are often powerless to effect standards and consistent DQ practices throughout the organization.

The bigger the organization, the more difficult it is for change agents and DQ proponents to put their ideas into action. Building consensus within a department is often difficult enough. Throw multiple departments and multiple countries into the equation and your job just got exponentially harder.

Simon Says

A DQ “maverick” may be just as likely to tick someone off as he is to effect actual change. Without support and commitment at the highest levels of the organization, it’s hard to buy into the “single bullet” theory of DQ. You need a DQ conspiracy or tipping point. Hopefully, this will spring from an epiphany, not a government audit or lost clients due to a horrible data in a CRM app.

Their systems’ architecture doesn’t permit meaningful DQ change.

I suppose that this is related to the previous point. If data is generated, stored, and retrieved from multiple systems without any type of MDM solution, then it’s really difficult to maintain the quality of an organization’s data.

At one large organization at which I worked, I saw more times than I could count the discrepancies among systems with respect to core employee information. The data was housed in something like ten different systems and imported into the theoretical data warehouse once every two months.

You could scream and yell about DQ (and I did, many times.) Trust me. I ruffled more than a few feathers.

Simon Says

DQ is a function of many things, not the least of which is systems’ architecture. By hook or by crook, fix that and then DQ change becomes a legitimate possibility.

It makes for good posturing.

Ah, the wonderful world of organizational politics. You have to love those that say the obvious, such as “DQ is important.”  Thanks, Sherlock. To me, the better position to take involves hard data (or at least approximations of the overall impacts to the business). Examples might include:

• incorrectly paid employees costs us approximately $X/year
• we mismatched invoices X% of the time last year
• we have to carry excess inventory because our sloppy item master has redundant codes

Do that and the decision makers will be more inclined to listen.

Simon Says

Resist the facile position of stating the obvious. Try to make the business case for DQ.

What do you think? Are there other reasons that people pay lip service to DQ?