How Are You Creating a Pull for Data Quality in Your Organisation?
Industry Viewpoint In this article I want to reach out to members and readers to learn how they are engaging the organisation to get involved with data quality.
What techniques are you adopting to "pull" employees in your direction or are you relying on a "push" approach instead?
How Are You Creating a Pull for Data Quality in Your Organisation?
With any improvement initiative there are essentially two approaches to getting the workforce and management engaged.
One of the most common approaches is the "push" approach. We introduce new data quality procedures and stipulate that they must be adhered to as a part of our employment contract. If we are obtaining data from a 3rd party perhaps we can introduce some punitive measures. If the data does not come up to our required service level then a penalty will be liable or the contract terminated.
The opposite is obviously the "pull" method. This works on a reward strategy instead. Employees may gain something, either tangible or intangible, as a result of adopting new data quality processes.
Case Study A: The Push Approach
In a former organisation I was responsible for the technical management of a large data warehouse. Within the small development team we implemented some simple measures and made it a stipulation of employment that the measures be adopted. Training sessions were held and everyone was educated on what the process would be moving forward. Regular meetings were held to ensure that people were aware of their obligations.
A three month audit revealed that the standards had been ignored on many occasions. Several members of the team, whilst openly agreeing with the standards, had failed to understand the importance of the new processes and were degrading the data quality as a result. New contract staff were also found to be less than enthusiastic with the standards and even though they were compensated, began to deviate from the standards set down.
Cast Study B: The Pull Approach
In the very first organisation I worked our projects suffered from considerable data quality issues. It was simply taking far too long to create our information products. With a limited team of data analysts our only available resource were part-time data entry workers.
We came clean, explained the situation and invited the data entry team to suggest ideas and become a part of the solution. Numerous ideas began to flow and I promised a series of intensive training sessions for the data entry staff to give them a data quality education. The benefit for them would be marketable skills that they could use to advance a career in the organisation or indeed in the wider marketplace. The results were incredible and still shape my data quality approach to this day. Each individual worked tirelessly to educate themselves and improve the tough situation we had got our team into. Within six months the entire team were proficient in advanced data analysis and several went on to take senior data management and software development roles. Their efforts transformed the performance of the department and helped the business grow substantially.
The reason I quote these case studies is that it is all too common for management to fall back to the "push" approach. In my experience, this often has limited impact. As my "pull" case study shows, even with staff who are the lowest paid, part-time and relatively unskilled, incredible data quality gains can be made. Another important observation is that, in my experience, the pull approach tends to create longer-lasting gains.
How are you pulling employees in the direction of your data quality vision?
Are you forcing knowledge workers to adopt new standards and processes or are you demonstrating the value to them as individuals using a pull approach?
I welcome your views on how you are engaging and motivating the workforce (and management) to get behind your data quality initiatives
Please share your experiences in the comment section below.
Useful Resources
Building Your Internal Data Quality "Business"
WANTED: Data Quality Change Agents
8 Tips for Making Your Data Quality Resolutions Stick in 2010
How to set data quality goals any business can achieve
7 Essential Skills for Effective Data Quality Leaders
15 Tips for transforming knowledge-workers into a data quality task force
Reader Comments (10)
Good one Dylan!!!
In business people look at ‘What is in it for me?” – Factor, as the article rightly portrays a ‘PULL’ approach has made us win project stakeholders confidence. In fact the ‘PULL’ factor scale to different heights (across operational, tactical, strategic levels) as one tries to build a business case for a DQ assignment.
Though we make sure that there are stringent business rules embedded in the IT architecture to avoid poor data from entering the IT ecosystem, I do agree on the point that IT or business is all about ‘PEOPLE’ and making sure their understanding and cooperation is of the highest priority in any DQ assignment
Our ‘PULL’ strategy revolves around an ‘As Is’ – ‘To Be’ mapping, where we follow a road map approach de lining the current state of data, how it should ideally be, probable reasons for poor data quality, how has this gap occurred (scenario specific and not person specific), probable mitigation plans, communicate and create an awareness among the concerned stake holders. Following this we detail on the business benefit that the organization would reap and also how it would improve the operational efficiency (KPI) of the individual (who handle data entry/access points)
mdmanswers.com
Dylan, I add one more approach
Case Study C: The outsource approach. The businesses I work with are engineering data intensive with input from a high number of data suppliers. Outsourcing provides the flexiblity for data management, data cleansing and data governance to be management outside of the various ERP, Engineering & CMMS systems, resulting of accuracy of data quality at introduction of data into the business processes and systems. Management of the outsource data processing also permits that agility to respond to the needs of the business while meeting throughput / accuracy metrics and a faster adaptations of data cleansing process based on business needs. An example is the new requirement for automating the requirements of adding 5 new language translations for the PIM data was accomplished within 5 weeks, the automated tools were modify, test and a the new business processes were implemented.
@Satesh - thanks for your comments.
Really detailed response, thank you ever so much for sharing this progressive approach, a model for many to follow.
@Jackie - always appreciate you taking the time to share your views Jackie.
Very valid point, I think as we move to more cloud based approaches in particular then outsourcing will only increase, as you rightfully point out, many organisations have limited capacity for major improvements as they're already under the hammer to deliver existing services anyway.
Comments from Kevin Jackson on LinkedIn:
"So far, the pull (or push, depending how you look at it) has all come from regulatory requirements. In this case: Solvency II.
But this has been a catalyst to work towards improving overall Data Quality (as it has been pointed out that there are many other business benefits to be gained from high quality data). So the scope of the DQ work is above and beyond."
This is a great post, Dylan. I think this is a post that should be read by organizations looking to implement better data!
Although I'd like to say I've seen the "pull" method work, I haven't. I have seen the "push" method more often. On some occasions it worked, on others it failed.
Well done, Dylan!
Comments from Patrick Egan on LinkedIn:
I can say we are using both; firstly I’m not a huge fan of the phrase data quality it kind of has an audit/QA feel to it. I prefer data management, and really it’s the overall management of data including quality, glossary, classification, rights management, retention policy etc that we are managing. DQ is a huge part of this but it's not the full 360 view of the data.
We can identify different groups in our organization, believers, open minded (put prove it) and finally the naysayers.
The believers we have help us promote the initiatives, the open minded we work with and do proof of concepts, while the naysayers are usually pushed by regulatory compliance.
As my boss says at the end of the day we all do data management/quality as part of our day to day jobs we just don’t refer to it as that and don’t perform it in a standard formalized manner.
Comments from Michael Küsters on LinkedIn:
I have received a few wise words from one of my mentors regarding Data Quality which happen to hold true over all the years.
One of them is - " Sit there, prepare, wait for a disaster, then say 'Told you so, this is what you should have done!' "
Any amount of policies that you come up with will be dead meat, at best half-heartedly implemented unless people really understand what is at stake.
Be prepared with policies, metrics and controls for any kind of desaster that *could* be happening in your company and just wait.
The best thing that can happen to the Data Quality Agenda is that a senior or executive chair is shaking.
Then, come to them and explain exactly:
- how this could have been prevented,
- how you can clean up the mess now and
- how you will make sure that it never happens again.
You can be certain that you will have:
- Their full attention
- Their unconditional cooperation.
- Sufficient budget for your next move
Like this, you will succed. Let them pull the need from disaster. Don't push DQ onto them.
Cheers,
Michael
Comments from Sanjib Mallik on LinkedIn:
Only way I have been successful is to the define Data Quality goals in terms of business objectives laid out by Senior Management and to get their implied support to publish my metrics that way.
Example: Senior Leadership team decides that it is imperative to communicate to Customers over telephone and failing that over email. This objective now can be translated into Data Quality terms and metrics can be defined around completeness and accuracy of telephone and email data in the CRM and actions to improve these metrics over time.
Important here is to identify non-compliance or failure in business process where your metrics are not being supported and publish these on a monthly basis pointing to what that means to the initial company objective you are trying to support.
This works.
Comments from Sanjib Mallik on LinkedIn:
I would just add one thing to Michael's point.
In my situation, in past, I have used a typical consulting world instrument called a risk memo to inform all around me of the danger of not handling a data quality issues as soon as it is identified.
It comes handy when eventually disaster strikes and people and looking around to see where the failure was or is.
Comments from John Jennings on LinkedIn
A "push" approach is very difficult to implement unless you have a lot of political and formal clout in your organization.
I've generally used more of a "pull" approach. The challenge is to develop metrics that tie to business value, so there is a correlation between quality issues and its impact on the business.
The worst scenario, which I have had to live through a few times, is when the party responsible for the quality issues is not the same party that pays the price for the poor quality. That requires much more involvement from the business side to reconcile those issues.