The First Law of Data Quality explained the importance of understanding your Data Usage, which is essential to the proper preparation required before launching your data quality initiative.
The Second Law of Data Quality explained the need for maintaining your Data Quality Inertia, which means a successful data quality initiative requires a program—and not a one-time project.
The Third Law of Data Quality
“Data quality is everyone's responsibility.”
Data quality is neither a business issue nor a technical issue—because it is both.
Data quality initiatives require the collaborative effort of business and technical stakeholders working together. A true collaboration is built on accepting shared ownership of the challenge as well as shared responsibility for its success—or failure.
Blamestorming
What happens when data quality is not viewed as a shared enterprise-wide responsibility and an incident occurs when poor quality information undermined a critical business decision?
In most organizations, the answer is a good old-fashioned blamestorming session.
Yes, blamestorming can feel very cathartic.
Sometimes, it seems like nothing brings a group closer together than when they are pointing their collective finger at another group, or at an individual stupid enough not to attend the blamestorming session—and sometimes the designated scapegoat is accidentally on purpose not invited to the meeting.
However, these sessions don’t help the organization move forward, don't help minimize the likelihood of similar incidents recurring in the near future, and don't foster any true sense of teamwork (except among those on Team Not Our Fault).
Redefining CYA
Many data quality issues are caused by a lack of data ownership and an absence of clear guidelines indicating who is responsible for ensuring that data is of sufficient quality to meet the daily business needs of the enterprise.
However, establishing data ownership and defining data quality standards and guidelines is not about predetermining who to blame if something goes wrong.
Blamestorming is all about the traditional definition of CYA. Forget that definition. Your organization needs to redefine CYA as Collaboration Yields Accountability.
Business stakeholders usually own the data because they are more closely aligned with its meaning and daily use within a business context.
Technical stakeholders usually own the data quality processes because they are more closely aligned with the daily management of the enterprise architecture.
However, everyone—regardless of their primary role or job function—must accept their personal responsibility in both preventing data quality issues and responding appropriately to mitigate the associated business risks when issues do occur.
Collaboration yields accountability for collective ownership of the current data quality issues as well as collective responsibility for resolving them.
It's NOT a cliché
Assuming that it is someone else's responsibility is a fundamental root case for your organization's data quality problems.
The need for collaboration among all business and technical stakeholders is so obvious that it has become a cliché.
Clichés are universal truths that have become universally ignored.
Data quality is everyone's responsibility.
It's NOT a cliché. It's NOT a slogan. It IS the law.
More specifically, it's The Third Law of Data Quality.
13 Comments
Good post, Jim.
I agree with you but have met many I'm not sure that everyone on the business side is as, er, "progressive" as we are. I can think of dozens of people I've encountered who'd cringe at the very implication that they "own" the data. As soon as I would mention data, I could almost see their "IT antennae" go up.
Thanks for your comment, Phil.
Good point. Even without discussing data quality in relation to it, the very concept of data ownership can make many throughout the enterprise say either "IT" or simply "Not it!"
Again, I fear the underlying issue is that most people equate ownership with the label "designated scapegoat."
"Team Not It" and "Team Not Our Fault" can sometimes seem like the only two tribes in an organization's version of Survivor.
However, no immunity idols are available for either data quality or data ownership.
Best Regards,
Jim
Great point well made Jim.
This rears its head so often on data migration projects in particular. An SI will throw the defects back at the business who, often incredulously, are horrified that they should have to get their hands dirty! Blamestorming soon follows.
Sweeping generalisation of course but no surprise that the only migrations I've seen succeed are where both business and technical teams work out the data quality issues together.
Of course a data migration is just a lens which focuses attention for a short time on a particular segment of corporate data but it really highlights the need for a broader alliance.
There has been a lot of debate about DQ ownership in this recent thread too: http://www.dataqualitypro.com/data-quality-expert-forum/post/951315
@Dylan - I know, the humanity! You mean we have to do the work now?
The only migrations I’ve seen succeed are where both business and technical teams work out the data quality issues together.
Very true. I've seen so many fail precisely because of the lack of the New CYA.
As an aside, is it possible that we're going to get through this entire post/comment string sans an 18th century philosopher quote?
@Phil - It sounds like when the IT antennae go up when "data ownership" is mentioned seems to indicate that the organization in question has yet to identify it as an organizational asset. But I'm preaching to the choir again.
The redefinition of CYA should be a keystone in no only the data quality process, but the governance of the organizations data.
Great stuff Jim.
Great post Jim,
This is for Phil.
18th century Irish philosopher Edmund Burke once said "All that is necessary for the triumph of evil is that good men do nothing." And that can not be more true in the world of data quality. We need to find those good me (or women) and make data quality their responsibility, and overcome the evil that is bad data!
Thanks for your comments everyone. As always, your feedback is greatly appreciated!
@Dylan - Yes, it never ceases to amaze me how befuddled people are about what really should be one of the simplest aspects of a data quality initiative - collaboration. I have also seen the blamestorming sessions target the technology, as if the root cause of the data quality issues was simply that “the wrong software” was purchased. So they switch vendors and surprise, surprise - the new software doesn't work either! :-)
@Rob - Yes, I agree that a fundamental problem is that the organization doesn't view its data as a corporate asset. IT is often assigned “data ownership” in these cases as if managing the database architecture was exactly the same as understanding the business context of the data loaded into the database. By that logic, since you drive inside of a car, then your mechanic should be able to perform surgery on you.
@Charles - Excellent 18th century philosopher quote! To complete Phil's day, I'll add a science fiction reference from Jedi Master Yoda:
“Poor data quality is the path to the dark side.
Poor data quality leads to bad business decisions.
Bad business decisions leads to lost revenue.
Lost revenue leads to suffering.”
May the Quality be with your Data . . .
I love CYA and Team "not our fault"!! I completely agree with you on the fact that business and technology issues are one-in-the-same. As I have said a few times before, I believe we need to drive these efforts and frame DQ in the business context appropriately for it ever to be adopted by "the business". I agree with Phil in his assessment about business' lack of "progressive" attitude. I just don't think they see it (dq) in it's true light (yet?).
Excellent point, William.
Failure to frame data quality issues in a business context is the leading reason for data quality not being adopted by business stakeholders.
It's like not phrasing your answer in the form of a question on Jeopardy.
:-)
Best Regards,
Jim
Jim, love the series.
I am wondering... how do you approach the collective group to accept "Collaboration"? Reason I ask, I have learned that when there is a mention of "data quality" or "data (insert adjective here)" the biz and analysts all put down their pens, cross their arms, and roll their eyes... saying: "great, another technical discussion on data quality... "
Like some industries, the biz leverages the data, they consume it... not produce it... like retail or distribution. (yes they do produce data, but most of it is consumed or acted on).
My comment is more of a question (to anyone), how do you turn the corner to explain that the initiative is an Asset. Information, which includes the data, is a key asset.... so that we can conduct your newly defined CYA :) (how do you get them to buy in).
keep it up, and thanks.
Nice post Jim.
The bad news is that the business is actively trying to figure out how to circumvent application data quality rules. Faced with ominous backlogs of IT enhancements, the business often searches out any text based screen fields with no audits. Address 2 makes an excellent candidate. The business then develops a XML like language to cram multiple new fields into the assimilated Address 2 field.
The symptoms here are data quality issues. At a previous client, Social Security Number had ten different meanings based on organization and sales channel. The problem, however, is overworked and/or understaffed IT organizations. I've yet to convince a CIO yet that these two problems related.
Garnie,
Thanks for your excellent comment/question. There is no way that I could provide a concise response.
Both Thomas Redman
and Tony Fisher have written excellent books about viewing data as corporate asset.
I will try to write more about this topic in future blog posts on this community.
Best Regards,
Jim
Thanks for your comment, Walter.
You make an excellent point. There is definitely a connection between overworked and/or understaffed IT groups and data quality issues.
As you rightly point out, this doesn't mean that data quality is a technical issue. The business groups are often left with immediate needs that they are forced to invent creative workarounds for when IT is not available to provide assistance. Necessity is the mother of invention - and not only good inventions.
And I agree that a C-level executive is absolutely necessary to facilitate the necessary collaboration - and I also agree that it is rarely easy to convince them of the depth and breadth of the problem.
Best Regards,
Jim