Put Data Quality in Those Requirements, Already!

5 Min Read

Business Analysts look at all kinds of requirements.

1. Networking interface

2. System design

3. Database design

4. Business needs

And much more…

How often will a business analyst look at data quality requirements?

It is a missing. Period!

Rarely will you see a heading in your Business and System Requirements documentation for Data Quality. The business has such a hard time understanding what Data Quality actually means that they ignore the subject. This is not the fault of the business analyst, but often an oversight from the beginning of project conception. Quite often the reason for the oversight is the business’s inability to quantify the benefits of data quality and the actions needed to prevent bad data…

Business Analysts look at all kinds of requirements.

1. Networking interface

2. System design

3. Database design

4. Business needs

And much more…

How often will a business analyst look at data quality requirements?

It is a missing. Period!

Rarely will you see a heading in your Business and System Requirements documentation for Data Quality. The business has such a hard time understanding what Data Quality actually means that they ignore the subject. This is not the fault of the business analyst, but often an oversight from the beginning of project conception. Quite often the reason for the oversight is the business’s inability to quantify the benefits of data quality and the actions needed to prevent bad data.

I don’t want to harp on the business, but let’s face it, it is the rare mandate in any IT project to ensure data quality, or even to provide data quality action items. It is often left to the support analysts at the end of the day to step in and engage the business to address these issues. Unless the IT project has a data steward to engage, then it is very unlikely that data quality will become an important issue.

Not too long ago, I did a search on a well-known career search engine to find out how often data quality is seen as a requirement or function of the Business Analyst role. My results were disappointing. Only 19 positions with the term Business Analyst in the position name held the term “data quality” in its content. That translates into less than 5% of the postings that contained the term business analyst. Now I didn’t go and look for data integrity, or MDM. It is what it is, a search done out of curiosity with not too much in depth data mining… eh, I had kids to put to bed!

Out of curiosity, closer to the day, a free form search on “data quality” and “business analyst.” My results: 25% of business analyst type postings contained data quality in the body of their content.

Needless to say data quality is still a bit off the radar for many companies when it comes to defining the role of a business analyst.

With that said, the aspect of including data quality in the role of a business analyst is there, but to what degree remains relatively unanswered. So to those business analysts and business analysts wannabes… remember Data Quality in your requirements, it’s just good business.

Data Quality must be inseparable from the data. Good data quality at the requirements stage will positively impact:

1. Project success

2. Data Integrity

3. Efficient and effective support

4. Sound decision making

5. Reduce business costs from errors and corrective actions

6. Project longevity (something any good BA wants).

So if the business is not interested in Data Quality, make it your interest. It won’t hurt, and the business will love you for it!

Share This Article
Exit mobile version