As a new contributor to the data quality blog site, I wanted to start by introducing myself and highlighting the types of topics I plan to discuss on a semi-frequent basis. I am a Principal Consultant with Informatica Professional Services and have spent the past 6 years in the data quality space in a variety of sales and post sales roles. During this time I have seen the data quality market continue to evolve and mature. Thus, I would like to use this column to reflect on the types of use cases I have seen and continue to see when meeting with organization’s faced with data quality problems. I hope these posts can start an active dialogue, regardless if your company is trying to tackle their first data quality initiative or looking to build out a formal center of excellence around data quality.

To start, I wanted to pose a common question I am often asked by clients and prospects – how do I build a business case for data quality? Although an organization may think (or even know) there is a problem, the need to justify the cost around procuring a data quality solution often exists. This justification requirements often comes from the idea that data quality issues aren’t necessarily a core business issue (how wrong this is!) or something that can be handled through manual intervention (this is true – if you have unlimited time and money, but even then your results will be limited). Thus, the following points are meant to help start an organization down the path to building the internal business case through a Data Quality Audit. Note – if you have access to Informatica’s Velocity Methodology, I go into these steps in further detail in the best practice document, “Developing the Data Quality Business Case.”
1. Identify a test source – A manageable, yet representative, sample set of data should be evaluated. This can be a cross-section of an enterprise data set or data from a specific department that a potential data quality issue is expected to be found.

2. Identify issues – Any anticipated issues with the data should be identified prior to conducting the Audit, in order to ensure the known use cases are investigated.

3. Define scope – The scope of the Audit should be defined in order to ensure that a business case can be made for a data quality initiative within weeks, not months. The project should be seen as a pilot in order to validate the anticipated ROI if an enterprise initiative is pursued. Just as the scope should be well defined, commitments should be agreed upon prior to starting the project that the required resources (such as the data steward, IT representative, business user) will be available as needed during the duration of the project in order to ensure the activities such as data and business rule review remain on schedule.

4. Highlight resulting issues – Upon the conclusion of the Audit, the issues uncovered during the project should be summarized and presented to key stakeholders in a workshop setting. During the workshop, the results should be highlighted, as well as any anticipated impact to the business if a data quality initiative is not enacted within the organization.

5. Build knowledge – As previously stated, the intent of the Audit is to quantify the anticipated ROI within an organization if a data quality strategy is implemented. In addition, the knowledge about the data, the business rules and the potential strategy that can be leveraged throughout the entire organization should be captured.

The intent of these five steps is to ensure the initial business case can be quantified in a relatively short period of time without a significant investment being incurred by the organization. In addition, the information gathered during the activity will be the starting point for the actual data quality initiative.

In future posts I will discuss where to go after you have quantified the problem. You now have the knowledge and tools available, but how do you start attacking the 800-pound data quality gorilla in the room?

Until next time…