How can you include stakeholders in data cleaning for a visualization project?

Ideally stakeholders should be clearly identified. This may include those involved in data generation, data recording, data collection and data reporting. Usually at different levels and with varying roles/powers. After identifying that data generation stakeholders, it would appropriate to determine whether all validation rules for data collection, reporting had been applied throughout. Once the validation process is agreed upon, then designated data analysts from each stakeholders are give timeline to run their data in data collection databases to ensure validation is applied. After completing validation process data can be merged in a single database. Under this process validation rule will apply. Queries would be communicated back.

Involving stakeholders in data cleaning for a visualization project is crucial to ensure that the data used accurately reflects their needs and expectations. Set up regular feedback loops with stakeholders. This ensures that they are actively engaged in the data cleaning process and can provide feedback as issues are addressed also more importantly create data cleaning guidelines or a data cleaning plan with the input of stakeholders. This plan should specify how to handle outliers, missing data, and data discrepancies. The importance of documentation(e.g. profiling, guidelines, data dictionaries and meta data etc), feedback loops in addition to validation, quality checks, testing and collaboration standards cannot be over emphasized.

Determine the sources of data, and some of the key functional users of that system. It may make sense to make a data dictionary and define the functional stream of data on a row/field basis. They may provide domain context or expertise into the system, explain outliers in the data which may require feedback. For example, engaging with a stakeholder in sales, you may be able to receive feedback on certain historical transactions which are outliers. They may be able to guide you to the sales administrator or customer service point that may be able to review specific lines of sales orders to double check that scripts such as data acquisition or transformation are able to be checked through systems for accuracy and audit before visualisation

Data fields are determined in terms of its sensitivity and potential financial impact. Missing or incomplete data which has a financial impact during statutory reporting periods may requires an amount of cleansing or retrofit effort. If data transformation routines exist to handle bulk exceptions, they should be clearly documented & signed off by the functional area responsible. Quality scorecards can be developed on key areas affecting financial reporting. Example are vendor master records missing payment terms, or terms outside of company policy to be validated by finance. Consider the age of the records as well, where outside of the reporting period (say 5 years) & no financial impact, the master records can be flagged as inactive.

Sharing some of my experience here: What we study about data cleaning in theory and what is implemented in reality are very different. Be it a visualisation project or a model building project. Data cleaning strongly follows domain characteristics. The way we clean data for a automotive domain will be absolutely different from a healthcare domain. Hence understanding the nuances of a domain is super important. This can be achieved by including the stakeholders at each and every stage of the process. Not only will stakeholders clarify their expectations but they will also supply the DS team with process updates for example, a domain might not impute outliers using winsorization. They might employ entirely different tactics.

Changes to production systems, be it underlying data sources, or production reporting systems should have clear documentation to assist with audit and tracking changes which have been made. If a decision has been made in relation to data retention and reporting policy if should also be considered. Sharing the cleansing effort with the primary area responsible, for example a customer service team cleaning up legacy back orders which have been abandoned by the customer or no longer require fulfilment assists with ensuring that cleansing operations are known by the functional area responsible for them. If the data cleansing occurs en masse by IT or ERP teams, data snapshots before and after should be captured in case of unintended changes.

To include stakeholders in data cleaning for a visualization project, collaborate closely with them to define data quality metrics, validation rules, and a data cleaning plan. Encourage their active participation in identifying data anomalies and providing continuous feedback. This collaborative approach ensures that the data accurately reflects their needs and objectives, resulting in more effective and valuable visualizations for decision-making.

At the start of data cleaning projects, many business users can be overwhelmed by the amount of changes required to assist operational systems and reporting systems. However, socialising the impact to functional areas is important, as poorly maintained, and data which is of low quality can have an operational or customer impact. It also means that management teams could be making decisions based off incorrect, obsolete or skewed data, with financial implications. Early in my career, I had to clean up customer addresses for an Australian hire business. By correcting their physical addresses which weren't correct. There was an upside benefit they were able to perform asset recovery more accurately for insolvent customers.