'The Bad Data Ate My Homework' and Other IT Scapegoating

Loraine Lawson

No doubt, there are a lot of problems that can be blamed on bad data. I suspect it would be fair to say that there's a good percentage of problems we don't even know about that can be blamed on bad data and a lack of data integration, quality and governance.


Could the bank foreclosure fiasco be one of them? I find that hard to believe.


Utopia, an enterprise data lifecycle management consultancy, posted this piece about why Bank of America froze foreclosures last week. The post quotes a Bank of America press release that states, "Worries have developed which suggest that faulty data may be being used to decide the fate of houses, and may be causing some people to be evicted without merit."


The blurb about the data issues has been republished in several locations, but my favorite is this version, because you can read it right below the announcement that says "Bank of America Corporation (NYSE:BAC) has paused foreclosures on houses after reports that employees may have submitted false documents in order to speed up the process."


Technically, I suppose it could be both ways: Employees submitted false documents that created faulty data. But one of these versions strikes me as owning up to a problem while another seems to invite pity: "Woe is us. We're the victim of bad data."


Data-and by extension, the IT departments that manage it-are an easy scapegoat these days. Do a search and take a look at the range of quandaries blamed on bad data. Here, let me help.


Bad data might be the most ubiquitous excuse since "the dog ate my homework." But while most of us would laugh at the idea of blaming the dog for missing homework, when someone blames the data, we all nod our heads in sympathy, because we all know how troublesome computers are. And then the buck gets passed to IT.


I'm not saying there isn't bad data-obviously there is. One widely quoted, but by now ancient (circa 2005), statistic from The Data Warehouse Institute blames data quality problems associated with customer contact data alone as costing U.S. businesses more than $600 billion a year in postage, printing and staff overhead.


And it's difficult to measure its real impact. In a March blog post, Bill Hewett of Kalido raised this question, sharing a story from a business leader who estimated 20 percent of his company's customer data to be "bad" at any point in time. The executive considered it a cost of doing business.


But when you have "robosigners" processing legal documents without even reading them and lawyers outsourcing legal contracts-well, that's not bad data. It's unfair to IT at the least, bad business at best and negligence that could lead to another national financial crisis at worst.

Add Comment      Leave a comment on this blog post
Oct 22, 2010 11:13 AM Julian Schwarzenbach Julian Schwarzenbach  says:


A great post with an excellent title.

You touch on one of the areas that I find increasingly fascinating - that of data problems always being 'Someone Elses Problem' (SEP). You mention about IT perhaps being scapegoated (not an unusual activity), of 'robosigners' and extended contractual chains which will increase the risk that poor data will lead to poor decisions. Such problems are becoming increasingly prevalent in business today.

I think society (at least in the developed world) is reaching a point where the increasingly connected nature of everything using a smaller pool of suppliers will mean that technical innovation will become less important. The organisations in the future that will secure competitive advantage over their rivals will be those that are able to manage and understand their data better.

We have an interesting journey ahead of us.

Julian Schwarzenbach

Data Doctor at

Data and Process Advantage Ltd

Oct 27, 2010 11:15 AM Jill Wanless Jill Wanless  says:

I totally agree with you Loraine and your response Julian. Businesses need to start to really take responsibility for the processes that enable the creation of bad data and stop blaming everyone and everything else. IT may have designed it that way, but it was based on the business decision to do so, and more that likely it was so the project could be delivered quickly.

Somebody (like us) needs to stand up and explain this, which some times lands on deaf ears as most don't want to hear it.

Oct 29, 2010 3:12 AM Mobeen Aslam Mobeen Aslam  says:

Well thought with well presentation...

I also agree with you all, because process efficiency and data accuracy is responsibility of process ownwer, role of IT is help them out for planning and execution for peapole empowerment and improvement of processes and teachnology.  

Oct 31, 2010 7:56 AM m ellard m ellard  says:

Thank you Lorraine - What's that old saying:  "A poor workman blames his tools"?  Blaming the data just doesn't cut it - If you want to make something tasty, you don't start with tired ingredients; and, if you want good insights, you don't start with bad data.

There are some great rules to be found here that can help keep one from falling into bad-data traps:


Also, this white paper lays out the case for data quality: 


Nov 1, 2010 8:04 AM Sue Rayner Sue Rayner  says: in response to Jill Wanless

I note that while the business scapegoats the data, the IT department always scapegoats the business processes. If you want good data you have to concentrate on the data and put real effort into analysing what it means.

The main cause of bad data is the belief that good processes will magically create good data without any effort (from business or IT) to understand it.

Focusing on the business processes produces a lot of data, but there is no evidence that this approach creates good data. Too much data management effort goes into trying to retrofit whatever has been recorded instead of defining what needs to be captured.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.