Data Quality and Chicken Little Syndrome
Jim Harris in Data Quality, Debates tagged Best of 2012, Business Benefits, Philosophy Monday, June 11, 2012 at 5:00PM “The sky is falling!” exclaimed Chicken Little after an acorn fell on his head, causing him to undertake a journey to tell the King that the world is coming to an end. So says the folk tale that became an allegory for people accused of being unreasonably afraid, or people trying to incite an unreasonable fear in those around them, sometimes referred to as Chicken Little Syndrome.
The sales pitches for data quality solutions often suffer from Chicken Little Syndrome, when vendors and consultants, instead of trying to sell the business benefits of data quality, focus too much on the negative aspects of not investing in data quality, and try scaring people into prioritizing data quality initiatives by exclaiming “your company is failing because your data quality is bad!”
The Chicken Littles of Data Quality use sound bites like “data quality problems cost businesses more than $600 billion a year!” or “poor data quality costs organizations 35% of their revenue!” However, the most common characteristic of these fear mongering estimates about the costs of poor data quality is that, upon closer examination, most of them either rely on anecdotal evidence, or hide behind the curtain of an allegedly proprietary case study, the details of which conveniently can’t be publicly disclosed.
Lacking a tangible estimate for the cost of poor data quality often complicates building the business case for data quality. Even though a data quality initiative has the long-term potential of reducing the costs, and mitigating the risks, associated with poor data quality, its initial costs are very tangible. For example, the short-term increased costs of a data quality initiative can include the purchase of data quality software, and the professional services needed for training and consulting to support installation, configuration, application development, testing, and production implementation. When considering these short-term costs, and especially when lacking a tangible estimate for the cost of poor data quality, many organizations understandably conclude that it’s less risky to gamble on not investing in a data quality initiative and hope things are just not as bad as Chicken Little claims.
“The sky isn’t falling on us.”
Furthermore, the reason that citing specific examples of poor data quality (e.g., IQTrainwrecks.com) also doesn’t work very well is not just because of the lack of a verifiable estimate for the associated business costs. Another significant contributing factor is that people naturally dismiss the possibility that something bad that happened to someone else could also happen to them.
So, when Chicken Little undertakes a journey to tell the CEO that the organization is coming to an end due to poor data quality, exclaiming that “the sky is falling!” while citing one of those data quality disaster stories that befell another organization, should we really be surprised when the CEO looks up, scratches their head, and declares that “the sky isn’t falling on us.”
Sometimes, denying the existence of data quality issues is a natural self-defense mechanism for the people responsible for the business processes and technology surrounding data since nobody wants to be blamed for causing, or failing to fix, data quality issues. Other times, people suffer from the illusion-of-quality effect caused by the dark side of data cleansing. In other words, they don’t believe that data quality issues occur very often because the data made available to end users in dashboards and reports often passes through many processes that cleanse or otherwise sanitize the data before it reaches them.
Can we stop Playing Chicken with Data Quality?
Most of the time, advocating for data quality feels like we are playing chicken with executive sponsors and business stakeholders, as if we were driving toward them at full speed on a collision course, armed with fear mongering and disaster stories, hoping that they swerve in the direction of approving a data quality initiative. But there has to be a better way to advocate for data quality other than constantly exclaiming that “the sky is falling!” (Don’t cry fowl — I realize that I just mixed my chicken metaphors.)
I welcome your suggestions (chicken-metaphor-based or otherwise) by inviting you to post a comment below.
Related Posts
Selling the Business Benefits of Data Quality
In Search of an Anecdotal Antidote
“Some is not a number and soon is not a time”
The Illusion-of-Quality Effect
Are you turning Ugly Data into Cute Information?
Perception Filters and Data Quality
The Data Quality of Dorian Gray
Data Quality and the Bystander Effect
Related OCDQ Radio Episodes
Clicking on the link will take you to the episode’s blog post:
- Data Driven — Guest Tom Redman (aka the “Data Doc”) discusses concepts from one of my favorite data quality books, which is his most recent book: Data Driven: Profiting from Your Most Important Business Asset.
- Organizing for Data Quality — Guest Tom Redman (aka the “Data Doc”) discusses how your organization should approach data quality, including his call to action for your role in the data revolution.
- The Johari Window of Data Quality — Guest Martin Doyle discusses helping people better understand their data and assess its business impacts, not just the negative impacts of bad data quality, but also the positive impacts of good data quality.
- Redefining Data Quality — Guest Peter Perera discusses his proposed redefinition of data quality, as well as his perspective on the relationship of data quality to master data management and data governance.
- The Blue Box of Information Quality — Guest Daragh O Brien on why Information Quality is bigger on the inside, using stories as an analytical tool and change management technique, and why we must never forget that “people are cool.”
- Studying Data Quality — Guest Gordon Hamilton discusses the key concepts from recommended data quality books, including those which he has implemented in his career as a data quality practitioner.
Reader Comments (2)
From the LinkedIn Group for the IAIDQ Professional Open Community, Andrew Dean commented:
“Ah - the old chestnut. The data quality business case. Specifically the financials - or lack of them!
It is simply a fact that a solid financial case to support a data quality (DQ) program is extremely difficult to make. In the absence of such a case vendors will naturally resort to Chicken Little tactics (nice example btw).
I have written a number of blogs around this area. I think what it all boils down to is that DQ will only be seen as a priority if it can be very clearly linked to a decline in business performance.
That's not to say that those of us in the data business should give up. We all believe in the benefits of clean data don't we? But I agree that the Chicken Little approach does not work and may even serve to damage the industry.
Organizations need to start thinking about data in the same way that they think about their staff, which I discussed in my latest blog post: Manage your data like your people.”
And Peter Benson commented:
“I agree that the Chicken Little approach has never worked, business is about identifying and exploiting opportunity.
Everyone agrees we are living in the information age and information is power so it really is not difficult to identify opportunities where better data or better use of data can generate revenue. I have just completed a new book, due out at the end of June under the title of "Managing Blind: A data quality and data governance vade mecum" and Chapter 1 is titled "Show me the money". If you are not able to identify a believable revenue stream nobody will be interested, and rightly so.”
And Bob Lambert commented:
“Great post and comments. Consistent with both commenters, it seems to me that to data professionals data quality is concrete and of interest in and of itself, while to business people the data quality topic is abstract, and data quality is of interest only in connection with something concrete. I try to advocate for data quality improvements in context of tangible (i.e., financial) results due to process improvements, better customer satisfaction, improved visibility into operations, etc.
I doubt that data quality in itself is possible to sell, Chicken Little or no, but the downstream results are another matter.”
And from the LinkedIn Group for Data Governance & Data Quality, Len Dubois commented:
“Jim, Another excellent article. Hope you don't mind if I expand on your allegory . . . in fact the sky isn't falling, it never has and never will. The sky, like data quality, is all around us.
I agree with you, it is rare when I run into someone who doesn't understand that poor data quality manifests itself within business process all the time. Data Quality, like many disciplines, requires subject matter experts who know how important it is to ensure that the context of data meets the business needs of any application.
Take it out of the context of technology for a moment; Insurance organizations write and manage policies, claims are made against those policies. Policies are then assessed a monetary value of risk. Multiply this by 500,000 policies and you have a small to mid-sized insurance company. Insurance executives don't say we certainly don't need technology to manage these policies. Technology therefore becomes a risk mitigation issue. Organizations equate how much risk they are willing to tolerate before they act.
In the same way, many executives say, "How much poor data am I willing to suffer, before I improve it, or in the case of the insurance company, "How much monetary value (read $$$ in loss reserve) am I willing to put aside because I don't know how many claims I have that involve head injuries?"
You said it well — telling business executives that the sky is falling is like asking them if they have heard about this new thing called "Mobile." As experts in the field of data quality, it isn't our role to tell them that data quality is important, i.e., that the sky is all around them, it is our role to provide for them a means to improve their business with better information.”
And Peter Galdies commented:
“Excellent thread, both spot on, and expanding a little further "our role to provide for them a means to improve their business with better information" often means helping evaluate and construct solid business cases that clearly demonstrate the real VALUE of quality data. Seeing the wood for the trees IS a business skill.”
And Gary Allemann commented:
“Any business case will be driven by one of three broad categories - cutting costs, reducing risk, or increasing value. In most cases it is easier to quantify the cost cutting or risk drivers, rather than the value creators.
For example, at one client we were discussing the impact of a long application process (many days) on new product sales. "But this is not a data quality problem," he replied. Well, no it may not be. But if they do not capture the application date and measure the process duration then it could be - the data is incomplete. So value is frequently harder to quantify - but certainly an important driver for data quality initiatives.”
And Robert Karel commented:
“Hi Jim, Great post as always and great discussion going here. I really appreciate the points that everyone has made recognizing that data quality (DQ) actually leads to value creation and is not purely an exercise in risk mitigation.
In my view, not only should we advise against the negative "the sky is falling" scare tactics of the DQ business cases of old, but really evangelize how high quality, trusted, secure data can really differentiate a business in terms of optimizing customer experiences, streamlining the supply chain, mitigating risk, controlling costs, optimizing spend, etc.
As you know, there's lots of work being done by many of us to provide frameworks, tools, and models to help DQ evangelists better prioritize and quantify the value of DQ and data governance efforts (I'm blogging more on that next week), but before we worry about building the financial case, we need to get better at promoting that DQ is not a bitter pill that must be swallowed, but a gourmet feast just waiting to be consumed.”
And Dr. Walid El Abed commented:
“Excellent discussion and comments. I would add to the discussion my 2 cents:
If we admit that the value resides in the business transaction which represents the ultimate rendezvous between the shareholder and the customer and also admit this ultimate rendezvous fully succeeds only if required information (data) meet requirements (rules). Each function of the enterprise becomes an intermediate rendezvous that prepares the ultimate rendezvous. Data quality becomes the enabler to accelerate the time to value and to assure a flawless execution of the ultimate transaction.
Which means that data quality is not about cost reduction or risk mitigation but it's about business value maximization and acceleration. Unfortunately the data people put data at the center of data quality initiatives which leads to consider data as a painful topic and it is very difficult to justify its cost. Data quality must always be contextualized by putting the business transaction at the center of data quality or any data initiative. Linking the data quality to the open and planned transactions will link the data to the only recognized value by the business and it's participation to the realization of the ultimate value becomes obvious and no business case would be required to unlock the value chain using data quality.”
Love the post! I am willing to confess that I have been guilty of Chicken Little Syndrome myself. Business cares for profit, which is both revenue and cost management. As you mentioned, the end-user reports "often passes through many processes that cleanse or otherwise sanitize the data", which I propose to call "data quality reconstructive surgery".
There, in my view, lies the real opportunity (i.e., avoid the issues by fixing the problem and hence reduce costs). If you tell your client: "Imagine the 3 days you currently spend in verifying and closing the gap in your financial report - gone!". The client will look at you and smile - thinking: quicker access to numbers and less man-hours. Am I wrong?