Does your organisation have unsung data quality heroes?

More recently, I began to wonder if there are data quality heroes in organisations as well… You may know some of these heroes? Those who go the extra mile to make sure the report is ‘right’? Let me know if any of these sound familiar when you are talking to people close to the data:

• “That data is gathered sometimes but I would not use it”.
• “Yes, a project put in place that process, but the data can’t marry up with anything else.”
• “We had an issue a year ago, and the system was brought back, but the data never got fixed.”
• “I just always change these values to an average because it’s wrong.”
• “Be sure to exclude this set of data to get an accurate picture of what is really active.”
• “These values are different but actually mean the same thing, so I use my own reference list.”
• “Remember, there’s duplicates in that data that need to be removed first.”

These heroes are doing their best to keep the reports and insights coming, but in the end are somewhat hampering the implementation of sound data management practices such as metadata, data lifecycle management and data quality monitoring. It is difficult to make the case for these capabilities when everything is running ‘smoothly’.

So where do you start with data quality? And what are the considerations for a modern data quality capability? Here are a few to get started…

Maturity: Yes, there is a maturity curve for data quality! It starts with capturing issues as they are observed and reported, incorporating processes for risk assessment as well as fixes and remediation (including cross-functional issues – hint this needs shared data ownership sorted). At the mature end is proactively monitoring data across the information delivery chain and taking action to resolve issues (hint – deterioration in data quality is an incident).

AI: Does data need to be perfect for AI? Or should there be approaches to cater for poor data quality or irrelevant data? This could include scoping data, tagging and classifying data and also training algorithms so that routines are in place to handle unexpected scenarios (hint – use AI to test for different scenarios that may not have occurred in the past). Remember that for unstructured data, sound practices of content management and knowledge management,as well as disposing of information no longer needed are important, but also the recent organisations past will influence AI outcomes (hint – if the organisation recently had a significant event like a merger, acquisition, focus on risk and compliance after a breach, etc. this will skew results).

Data Variability: Another early career lesson is that anyone can build a model to optimise, but if there has not been any variability in the data to know what is the best treatment for a particular scenario, then there is money being left on the table. Incorporating a discipline of continuous test and learn, across different scenarios will provide a solid data set that will not deteriorate in usefulness in the future (hint – get the right primary optimisation measure to focus test scenarios).

Initial capture: Data is our representation of reality, and that reality is typically captured once and then updated, usually somewhat irregularly (hint – incorporate data quality monitoring rules trigger when updates are needed).Getting the initial capture correct is a golden opportunity to only collect what is needed and make sure cross-references are in place (hint – analyse quality assurance processes to see what can be incorporated as checks at capture).

Quality Dimensions: Rather than accept the first list of quality dimensions in a search result or what is already in place, look at what is really needed for your organisation, what is explainable in clear language to stakeholders as well as what is possible to measure. Look to remove dimensions not important and incorporate new ones (hint – test with key stakeholders and build a quick reference guide to make sure it is fit-for-purpose).

Data Ownership: Although data quality is often wrapped up into data governance, it is different. It makes sense to implement data governance first because data ownership is a key pre-requisite for data quality so that issues are owned and fixed where needed (hint – if it’s not fixed, is it really an issue, especially if the data is still being used?). Data quality needs a different skill set from data governance to be successful – including technical astuteness, risk management and design thinking.

In addition to data ownership, build relationships and help give agency to data heroes to raise data quality issues that may be limiting insights, agility and readiness for AI. Letting the heroes know they will be listened to and sharing optimism that things will be different this time, means quality issues can truly be resolved – creating lasting value across use cases now and in the future.