Data Quality: Quo Vadimus?
Jim Harris in Blogs, Data Quality, Debates tagged Best of 2012, Business Benefits, Data Governance, Henrik Liliendahl Sørensen, Philosophy, ROI Sunday, February 26, 2012 at 12:00PM Over the past week, an excellent meme has been making its way around the data quality blogosphere. It all started, as many of the best data quality blogging memes do, with a post written by Henrik Liliendahl Sørensen.
In Turning a Blind Eye to Data Quality, Henrik blogged about how, as data quality practitioners, we are often amazed by the inconvenient truth that our organizations are capable of growing as a successful business even despite the fact that they often turn a blind eye to data quality by ignoring data quality issues and not following the data quality best practices that we advocate.
“The evidence about how poor data quality is costing enterprises huge sums of money has been out there for a long time,” Henrik explained. “But business successes are made over and over again despite bad data. There may be casualties, but the business goals are met anyway. So, poor data quality is just something that makes the fight harder, not impossible.”
As data quality practitioners, we often don’t effectively sell the business benefits of data quality, but instead we often only talk about the negative aspects of not investing in data quality, which, as Henrik explained, is usually why business leaders turn a blind eye to data quality challenges. Henrik concluded with the recommendation that when we are talking with business leaders, we need to focus on “smaller, but tangible, wins where data quality improvement and business efficiency goes hand in hand.”
Is Data Quality a Journey or a Destination?
Henrik’s blog post received excellent comments, which included a debate about whether data quality is a journey or a destination.
Garry Ure responded with his blog post Destination Unknown, in which he explained how “historically the quest for data quality was likened to a journey to convey the concept that you need to continue to work in order to maintain quality.” But Garry also noted that sometimes when an organization does successfully ingrain data quality practices into day-to-day business operations, it can make it seem like data quality is a destination that the organization has finally reached.
Garry concluded data quality is “just one destination of many on a long and somewhat recursive journey. I think the point is that there is no final destination, instead the journey becomes smoother, quicker, and more pleasant for those traveling.”
Bryan Larkin responded to Garry with the blog post Data Quality: Destinations Known, in which Bryan explained, “data quality should be a series of destinations where short journeys occur on the way to those destinations. The reason is simple. If we make it about one big destination or one big journey, we are not aligning our efforts with business goals.”
In order to do this, Bryan recommends that “we must identify specific projects that have tangible business benefits (directly to the bottom line — at least to begin with) that are quickly realized. This means we are looking at less of a smooth journey and more of a sprint to a destination — to tackle a specific problem and show results in a short amount of time. Most likely we’ll have a series of these sprints to destinations with little time to enjoy the journey.”
“While comprehensive data quality initiatives,” Bryan concluded, “are things we as practitioners want to see — in fact we build our world view around such — most enterprises (not all, mind you) are less interested in big initiatives and more interested in finite, specific, short projects that show results. If we can get a series of these lined up, we can think of them more in terms of an overall comprehensive plan if we like — even a journey. But most functional business staff will think of them in terms of the specific projects that affect them.”
The Latin phrase Quo Vadimus? translates into English as “Where are we going?” When I ponder where data quality is going, and whether data quality is a journey or a destination, I am reminded of the words of T.S. Eliot:
“We must not cease from exploration and the end of all our exploring will be to arrive where we began and to know the place for the first time.”
We must not cease from exploring new ways to continuously improve our data quality and continuously put into practice our data governance principles, policies, and procedures, and the end of all our exploring will be to arrive where we began and to know, perhaps for the first time, the value of high-quality data to our enterprise’s continuing journey toward business success.
Related Posts
Selling the Business Benefits of Data Quality
Data Quality is not an Act, it is a Habit
Data Quality Practices—Activate!
Hyperactive Data Quality (Second Edition)
What going to the dentist taught me about data quality
Reader Comments (3)
From the LinkedIn Group for Data Governance & Data Quality, Paul Erb commented:
“Definitely a journey. In the Collins sense, quality is a flywheel. Because the world will keep throwing risks and changes at you, the attitude and organization and culture needed for data quality have to be continuously maintained and altered.
Ergo, journey.
At a previous group, the project-and-portfolio-trained C-level lead asked, "When are we done?" The disappointing answer was "never."
But maturity models are useful tools to get the flywheel spinning, so it CAN feel like a destination compared to the effort it takes to overcome the early inertia.”
And John Owens commented:
“It really depends on what you mean by Data Quality.
If you mean the need for each activity in an enterprise to create quality data as a matter of course in doing business day-to-day, then it is neither a journey nor a destination, it is an integrated part of the vessel called Enterprise, just as a keel is an integrated part of a ship. Without it the ship is not a viable vessel.
On the other hand, if by Data Quality you mean:
(A) The huge industry that has grown up and whose whole reason for existence is to create expensive software to find and rectify data errors?
Or
(B) The army of consultants who go around leading Data Quality projects that advocate the use of this software and who tell enterprises that data quality is a journey, not a destination, but 'fear not we will always be with you'?
If you do mean either of these then it is, sadly, a journey.
Bad data is like a hole in a vessel. If you have a hole in a ship that lets in water, what do you do? Mend the hole or invest in a bailing bucket business? Data Quality is currently a very lucrative bailing bucket business and the enterprises who are its victims will have journeys, sometimes short, sometimes long, always rough, but all leading to the same destination - sunk!”
And I responded:
Thanks for your comments, Paul and John.
@Paul — I like the flywheel analogy, and I agree that data quality is a never-ending journey. Excellent point about levels in maturity models feeling like destinations in and of themselves, especially to the early efforts where it is necessary to overcome the inertia of not beginning the journey, but, of course, an organization can also move backwards in a maturity model if they do not embrace a continuous improvement mindset. I have previously blogged about sustaining data quality inertia (The Second Law of Data Quality) as well as overcoming the inertial resistance to change (Retrograde Organizational Motion) at the beginning of data quality and data governance efforts.
@John — I agree with your concerns about the potential conflicts of interest inherent in the data quality industry (which I blogged out in my post Data Quality Industry: Problem Solvers or Enablers?), but I do not think your ship metaphor holds water (sorry, I couldn’t resist that pun) because although ships are definitely not structurally sound without a keel, as Henrik’s post pointed out and my professional experience can attest, enterprises can most definitely, and rather successfully, both set sail and remain seaworthy without data quality (and no matter how you want to define data quality).
As I explained in my blog post There is No Such Thing as a Root Cause, if bad data was the root cause of bad business performance, then every organization would never be profitable. Furthermore, just as the Titanic proved that there is no such thing as an unsinkable ship, there is also no such thing as a final destination in any aspect of our constantly changing business world, which is why data quality, just like every other aspect of doing business, requires the continuous improvement mindset of a never-ending journey.
And Paul Erb responded:
“What I like about John's piece is that he is distinguishing good from great, amateur from professional.
The great businesses understand that data is not just an input, but also a product of the way they operate; but also they understand (pro vs amateur athlete metaphor) the value of coaching and conditioning, and it is appropriate to hire trainers to do that so that they can attend to whatever specialty they do best.
There are plenty of amateurs in every business operating with bad data.”
And Garry Ure responded:
“Great discussion. What gets an organization really confused is when they undertake a DQ initiative as part of a bigger project (regulatory, systems development, migration etc.). Due to the fact that the project is planned with an end date and that there are different DQ activities required at different stages, it is hard for people to grasp that certain activities also need to continue into BAU. It usually leaves project managers scratching their heads.”
And I responded:
@Paul — Although I agree that data is not just an input, but also a product of the way businesses operate, I have always been uncomfortable with the data/information product analogy because products are the final result of a manufacturing process, whereas data/information gets continually reused and repurposed as it travels through the organization.
David Loshin recently blogged about Data Governance and Quality: Data Reuse vs. Data Repurposing and the different impacts they can have on data quality requirements and data governance policies.
So, calling someone an amateur/professional practitioner or assessing their data as having bad/good quality are going to be varying attributes observed at different points along data’s journey throughout the organization.
@Garry — Yes, projects and even program phases have end dates, which is necessary for determining deadlines for deliverables. The notion of automatically extending a project or program phase task beyond its end date runs contrary to most planning practices. Perhaps we need to get people to view data quality and data governance tasks as service contracts that automatically renew, which you automatically keep paying for unless the contract is canceled.
In the United States, most mobile phone carrier plans function that way, so just as many of us couldn’t imagine not having a mobile phone after a particular date, perhaps we can convince people that they similarly couldn’t imagine not having to continue working on data quality and data governance tasks?
And John Owens responded:
“Data Reuse and Data Repurposing are false concepts that ought to be banned from use. They represent a manufactured, imaginary and totally unnecessary level of complexity regarding data usage in a enterprise.
To think that to use data to market to a set of customers in the morning is one use and then to use the same data to market to another set of customers in the afternoon is another use, is quite wrong - its actually ludicrous! This data is simply being used to support one Business Function, namely to "Deliver Marketing Content to a Customer Segment". This is the same function, no matter how many times it is performed, regardless of the number of customers or segments.
The term 'Repurposing' is also misleading. It is suggesting that that 'Customer' was first introduced into the enterprise for one purpose only and that every other use made of it is a 'repurposing'! Again quite wrong.
This fragmented view of data usage has arisen because so many (far too many) DQ practitioners approach the business and data with a narrow systems centric view of the world. They see only physical data structures and are blind to the logical!
Process modeling was introduced to overcome the 'department silo' mentality that prevented people in different parts of the enterprise realizing that what they all did was in essence the same thing - just done in a different place.
Now we have DQ bringing fragmentation to enterprises with its system silo goggles. While some of what they might be talking about could be said to constitute 'systems' or 'database' reuse or repurposing, it definitely does NOT constitute data reuse or repurposing. These uses and purposes are exactly why the data is held in the enterprise in the first place - to support the Business Functions of the enterprise.”
And Andy Bury responded:
“Agree that proposing that "using data to market to a set of customers in the morning is one use and then to use the same data to market to another set of customers in the afternoon is another use", would be wrong.
However, that same customer data could be used by Logistics to deliver equipment to customers, by the Service organization to dispatch maintenance engineers to fix faulty equipment, by Invoicing to dispatch invoices, and by Credit Collection to send the bailiffs round.
Different processes, different quality purposes, different quality requirements.”
From the LinkedIn Group for the IAIDQ Professional Open Community, Richard Jarvis commented:
“Great post Jim! I missed Henrik's initial post, and it made great food for thought.
I agree with everything you've said, but there's a much uglier truth about data quality that should also be discussed - the business benefit of NOT having a data quality program.
The unfortunate reality is that in a tight market, the last thing many decision makers want to be made public (internally or externally), is the truth. In a company with DQ principles ingrained in day to day processes, and reporting handled independently, it becomes much harder to hide or "reinterpret" your falling market share. Without these principles though, you'll probably be able to pick your version of the truth from a stack of half a dozen, then spend your strategy meeting discussing which one is right instead of what you're going to do about it.
What we're talking about here is the difference between a politician - who will smile at the camera and proudly announce 0.1% growth was a fantastic result given x, y and z factors - and a statistician who will endeavor to describe reality with minimal personal bias. And the larger the organization, the more internal politics plays a part.
I believe a lot of the reluctance in investing in DQ initiatives could be traced back to this fear of being held truly accountable, regardless of it being in the best interests of the organization. To build a data quality-centric culture, the change must be driven from the CEO down if it's to succeed.”
And I responded:
Thanks for your excellent comment, Richard.
Yes, one of the biggest obstacles is that many executives are so biased against believing that poor data quality is prevalent within their organization that, instead of a continuous improvement mindset, the organization adopts a continuous blissful ignorance mindset. Which is exactly why these organizations are so often seemingly blindsided by data quality disasters.
In my blog post Data and Process Transparency, I explained that the downside of transparency is that it can reveal how bad things are, but without this awareness, improvement is not possible. But, like you said, organizational politics, and especially the fear of being held truly accountable often obfuscates data and process transparency.
However, as I wrote in my blog post “Some is not a number and soon is not a time”, organizations have to admit that some business decisions are mistakes being made based on poor quality data.
Although perfect data quality is impossible, data quality driven by a continuous improvement mindset is becoming a matter of corporate survival in today’s highly competitive and rapidly evolving world.
Best Regards,
Jim
The question 'Is Data Quality a Journey or a Destination?' suggests that it is one or the other. (Sounds like the subjective and objective question.) I agree with another comment that data quality is neither...or, I suppose, it could be both (the journey is the destination and the destination is the journey. They are one and the same.)
The quality of data (or anything for that matter) is something we experience. Quality only radiates when someone is in the act of experiencing the data, and usually only when it is someone that matters.
This radiation decays over time, ranging from seconds or less to years or more. The only problem with viewing data quality as radiation is that radiation can be measured by an instrument. There is no such instrument to measure data quality. We tend to confuse data qualities (which can be measured) and data quality (which cannot.)
In the words of someone whose name I cannot recall: "Quality is not job one. Being totally %@^#&$*% amazing is job one."
The only thing I disagree with here is that being amazing is characterized as a "job." Data quality is not something we "do" to data. It’s not a business initiative or project or job. It’s not a discipline.
We need to distinguish between the pursuit (journey) of being amazing and actually being amazing (destination - but certainly not a final one). To be amazing requires someone to be amazed. We want data to be continuously amazing...to someone that matters, i.e., someone who uses and values the data a whole lot for an end that makes a material difference.
Come to think of it, the only prerequisite for data quality is being alive because that is the only way to experience it. If you come across some data and have an amazed reaction to it and can make a difference using it, you cannot help but experience great data quality.
So if you are amazing people all the time with your data, then you are doing your data quality job very well.