Data Quality communication

I have been reading with interest the current debates on who controls data quality – the IT group or the business group. Looks like the consenus is that both own a piece of it. Makes sense really.

From my experience working with our own internal data quality initiaves, the ones that fail had people in charge who didn’t listen to both sides. Spend all the money on a fancy interface, but don’t understand the data needed underneath and you have a Porsche body with a Focus engine! Likewise though, if you get all the data in the system, but make the interface too difficult for business users then nobody will use it.

Being from more of the IT side of things I understand the frustration they feel about users. If nobody was allowed to write anything into the system it would be perfect! Users can’t be trusted. It’s true, to an extent. The IT involvement is needed to help balance the business users need for information and the human nature of shortcuts and malice!

An interface that can be designed to be both easy for a user, but also limit free form text is good! How many ways can the country name US be spelt – take a look in any database with free form country field and you will soon discover! Using check boxes and multi-selection boxes can all be used to keep data quality in the system even with users adding content.

Of course, IT doesn’t always really understand what information is being stored in the system – just that the fields are not null, have consistant values and are complete. The business user needs to clearly specify what they want from a data quality project so that IT can figure out where the data is going to come from.

Problems can arise when the business user doesn’t understand that a legacy system just isn’t accessible – the joy of mainframe accounting systems!  The users think IT is being difficult or not team players when in fact it is just that IT has not clearly communicated to the business user why the data is not available.

Communication! An oft used term, flung around at other groups/managers/people, but never ourselves. We communicate perfectly, it’s the other people who need to get it! So, business users write your requirements in plain English so that IT can understand them. IT people need to use diagrams and simple words without acronyms to explain existing systems so that business users can understand.

Next week I will cover how we can use data quality to resolve the  Middle East conflict!


3 responses to “Data Quality communication

  1. I couldnt agree more that communication is imperative to the success of any project like you’ve mentioned. How though do we educated businesses to realise that departments such as IT and Marketing need to talk more and that both should be involved in these projects from the beginning. From my own experience i know just how different these departments are – both seem to have more important things to do than spend time with each other??

  2. That is where the DQ professional has to educate management so that any new data quality initiative consists of a team with members from both departments. Additionally, to ensure that both depts are paying attention, you need to make sure that the ultimate benefits for them are made clear. Marketing will get better, more accurate data. What benefit does IT get? Depends on the company – involvement might be enough for some, reduced user whining may be good for another!

  3. Fiona

    First off… welcome to the Information/Data Quality blogging community.

    Your post very neatly sums up the key challenge in Information Quality… communicating what the expectations are that need to be met. You also nicely touch on the “front-end fixation” that seems to afflict software projects.

    It is exactly these kind of challenges that the IAIDQ (International Association for Information & Data Quality) tries to help people understand and solve in their professional lives.

    I couldn’t agree more with you that an information/data quality team needs to be cross-functional with people from both IT and the Business side onboard working towards a clear and common goal. Far to often that is not the case and people wonder why the quality doesn’t improve.

    One key benefit that IT get from better quality data and a better understanding across the business and IT divide (of eis that they get fewer trivial support calls and a lot less “life is not like Star Trek” requirements into system releases. Also, they can avoid the inevitable blame game when the flashy front-end system falls over due to duff data in the processes.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s