Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

Data Quality is Not a Prosthesis, It’s in the Enterprise DNA

Why is it that so many enterprises, even those committed to Data Quality, fail to achieve it?

The major reason for this is that they implement all Data Governance and Data Quality activities in the form of expensive and cumbersome overhead departments and activities. This approach dooms Data Quality.

Data Quality cannot be treated as an expensive prosthetic; it must be made part of the DNA of the enterprise. Otherwise, it will fade and die – and will probably take the enterprise with it.

PROJECT NOT PROCESS

Twenty five years ago when I was working as an IT consultant for a large petrochemical company in Wales, the chief chemical engineer would often boast that he was so committed to quality that he spent every Friday working on it.

Sadly he, and many of his colleagues, did not see the irony of this statement.

Data Quality makes an ugly prosthesis

Data Quality: An Ugly Prosthesis

In a way it is understandable. In the early stages of introducing quality into an enterprise, people would spend most of their time doing business in the way it had always been done and some of their time trying to move to doing it in the way it ought to be done. That is, introducing Quality.

In the early stages of introducing Data Quality to an enterprise, if you are dedicating one day a week entirely to quality might be a good start. However, if you are still doing this twelve months later, then you are unlikely to achieve it. Worse still, if after the same period of time, you are now spending 100% of your time working on Data Quality, then you have definitely failed!

Data Quality is not something you work on. To be real and sustainable, it must be a natural by-product of everything else you do.

The introduction of Data Quality in any enterprise must be viewed, structured and run as a Project with a beginning and middle and, most importantly, an end.

Millstones Sink

If it is not, then one of two things will happen.

The first is, because the project had no end it will have morphed into an on-going overhead and millstone to be carried by all, everyone will have given up on Data Quality. They will have reverted back to getting by, as they had in the past, because it is easier for them personally. Data Quality will have failed.

The second is that the enterprise will have created large Data Governance and Data Quality departments that are fully staffed and funded. Again, Data Quality will have failed.

How can this be? Surely any enterprise that is willing to put in place and fund such structures is bound to succeed with Data Quality?

Paradoxically, no! By vesting the responsibility for Data Quality in such departments, enterprises are not only creating bureaucratic millstones, they are actually removing Data Quality from the only place in which it can be successfully achieved, namely in the core operations of the enterprise – its Business Functions.

Quality = BAU

The fact is that Data Quality should occur in an enterprise simply by doing “Business As Usual”. It ought to be achieved in the day-to-day activities of the enterprise without any extra effort at all. In fact it should take less effort. Successful Data Quality actually makes life easier for everybody.

Perpetual Projects Fail

Data Governance, Data Quality Departments and Data Stewarts are essential players in the project that is run to first introduce Data Quality thinking, structures and practices into an enterprise. However, if these players are serious about achieving sustained Data Quality, then there are two critical objectives that will be built into the project. The first is that the Project should have an end date no longer than 24 months from its start data. The second is that these departments and roles will make themselves redundant!

Well perhaps, not completely redundant. However, they will define a role for themselves that ensures that they play no day-to-day part in Data Quality. If the Data Quality Implementation Project that they ran has been successful then Data Quality will happen automatically.

If Data Quality is not happening automatically in the enterprise, then the Data Quality Implementation Project was a failure and, all of the people concerned, should depart the enterprise as they have shown that they do not know how to bring Data Quality about.

DQ Makes an Ugly Appendage

When an enterprise implements Data Quality in the form of overhead departments, it is an ugly appendage that will never achieve real Data Quality.

For Data Quality to be successful it must be implemented as if it were part of the DNA of the enterprise.

In any other form it is nothing but an ineffective prosthesis.

Tags:

One Response to “Data Quality is Not a Prosthesis, It’s in the Enterprise DNA”

  1. Richard Ordowich July 9, 2013 12:55 pm #

    As a data quality practitioner, I question the value and benefits of data quality. In many organizations as you describe, quality is something we talk about but don’t spend a lot of time doing. Not just data quality but product quality, service quality, business process quality, communications quality etc.

    If an organization has not established a quality culture, data quality is, as you state an appendage. I’m not convinced that you can introduce a quality culture starting with data. Data is too abstract, has no governing natural laws and is “fictional”. Its only when a data error occurs that there is any concern about data quality.

    That is not to say you shouldn’t be concerned about data quality but don’t set up elaborate bureaucracies with stewards and committees etc. and stay away from using the term data governance. It sounds bureaucratic. Call it Data Quality Management.

    Many data quality problems occur because of three factors:
    1. Lack of business process quality control
    2. Poor metadata (names, definitions, semantics, value domains).
    3. Duplication, ambiguity and inconsistency of data

    I would also add a fourth factor: “Data Illiteracy” but that’s a whole other train of thought.

    Until an organization is willing to address these factors, don’t embark on data a quality project. Just fix the data, which is what most data quality projects end up doing anyway.

Leave a Reply