You are on page 1of 2

© 2001 Giga Information Group

Copyright and Material Usage Guidelines

March 1, 2001

Organizational Structure for Data Quality

Lou Agosta
Contributing Analyst: Marc Cecere

A client inquiry

What organizational structure works best to support a data quality program?

The organization structure that works best to support a data quality program is the one you are using. The
point is that quality must be made a part of everyone’s job (not just a part of the job description). This means
an organization has to think about how data quality shows up in the job of the order-entry clerk, the
receptionist who answers the phone, the people who manage inventory, the staff who operate the production
line as well as the IT technical staff — the database administration, application developers and managers.

This answer violates expectations and guards against a facile misunderstanding for the matter is more
complicated than that. Good organizational design gives a firm the potential to optimize processes; however,
to make this happen leadership, culture and business processes are required that leverage the organization in
the direction of excellence. For example, if a firm targets being responsive to customers as a mark of quality,
then an IT shop organized around customer groups provides the potential. However, to realize that potential
an organization will also need planning, design, development and quality assurance processes that support
and further customer responsiveness. And, what that looks like will be the result of a certain amount of trial
and error. The organization must be flexible enough to sustain forward motion and direction, while keeping
the ship afloat. On the other hand, an organizational design can be an ever present barrier to meeting goals if
it is not aligned with the overall strategy. If a firm organizes around customer groups but really wants
efficiency, then it’s unlikely it will be able to overcome the nonoptimal structure.

Quality is a special kind of attribute that indicates the relations between other attributes and the environment.
Quality is not another physical property, such as red. It’s humorous to say, “I want to buy a blue Ford Taurus
and make it a quality one,” as if quality were some additional attribute alongside air conditioning or air bags.
This also implies a challenge in pricing a quality product, extra stereo speakers might cost $250, but
determining the price differential between a new car and a quality new car is fraught with semantic,
economic, marketing and customer service ambiguities. Note, however, that the language gives us a clue —
nobody wants to buy a new car that lacks quality. On the other hand, we do see “quality used cars”
advertised, since used cars are generally thought of as lacking quality, so adding the descriptor of “quality”
does add something to the underlying product, but it’s still not a color, rather it’s a commitment, warranty,
promise or prediction of future behavior. Thus, a firm can appoint a department that provides for defect
removal; however, this does not really provide for quality, it provides for recovery from error. The title of the
department should not be quality control, but rather damage control. Limiting damage is of course necessary,
but it only produces a level of quality to which everyone was entitled in the first place. Putting out the fire in
your kitchen is a matter of urgent necessity, but it does not ever create a quality kitchen.

Appointing a quality control steward is a trap and goes in the wrong direction if a firm believes this

IdeaByte ♦ Organizational Structure for Data Quality

© 2000 Giga Information Group
All rights reserved. Reproduction or redistribution in any form without the prior permission of Giga Information Group is expressly prohibited. This information
is provided on an “as is” basis and without express or implied warranties. Although this information is believed to be accurate at the time of publication, Giga
Information Group cannot and does not warrant the accuracy, completeness or suitability of this information or that the information is correct.
Organizational Structure for Data Quality ♦ Lou Agosta

individual will be responsible for quality. This individual may be a data quality champion or coach. It can be
useful to appoint a data quality steward who reports at a high level to a powerful executive who can be called
on to work on quality issues and resolve conflicts. However, the effort should be both top down and bottom
up. Quality is defined and implemented differently depending on what the individual task is. In a IT context,
the database administration (DBA) and data administrators (DA) have important roles to play in defining and
capturing the data, rules and metadata by which different business and computing systems interoperate.
Forming a cross-functional team or creating a function within a program office — analogous to the Year
2000 (Y2K) project — can also be useful in driving the issues and solutions to the surface.

Anecdotal evidence is available as firms report improved customer system, inventory control and faster
business results as a result of tracing defect resolution (including data defects) back to the root cause of the
problem. Most firms are reluctant to admit just how much money they were wasting due to defective data. By
implication, this was not previously the case. Probably the biggest data quality success story in the history is
lying right before our eyes, namely fixing the Y2K bug. The world was hanging by a thread due to a
defective two-digit date embedded in every software system on the planet, and as a result of spending billions
of dollars, nothing bad happened. The non-event was the result of real effort, and a tremendous success the
likes of which can be repeated for other data elements besides two-digit dates. How soon we forget.

For additional research regarding this topic, see:

•= Planning Assumption, IT Organizational Design: Part 1 — Choosing an Organizational Model , Marc
•= IdeaByte, Wide Range of Data Quality Metrics Is Good News, Lou Agosta

IdeaByte ♦ RIB-032001-00015 ♦

© 2000 Giga Information Group
Page 2 of 2