Data Quality Project Selection - A Missing Skill?
Data Governance In this post we present the different methods of selecting data quality projects.
The aim of this post is to open up a debate on whether project selection is a key skill currently lacking from the data quality profession.
Data Quality Project Selection - A Missing Skill?
There are essentially two ways to select a data quality project: bottom-up or top-down.
Historically, I'm guessing the bulk of most data quality projects have been bottom-up. The ideas and inspiration for launching a data quality initiative typically come from knowledge workers and managers who are failing to deliver operational processes or new projects etc.
In contrast, top-down project selection focuses on launching projects that are aligned to strategic priorities.
There are benefits and drawbacks of each approach.
Taking a top-down approach obviously helps you break out of the silo mentality and identify strategic opportunities that may generate more "bang-for-your-buck" when compared to more tactical, locally delivered projects.
The drawback of a top-down initiative is typically the heavy lifting required. Executive sponsorship, larger teams, data governance, greater complexity and ultimately, increased risk.
The bottom-up approach to project selection often focuses on eliminating delays and failures in other projects and programmes that are impacted by poor data quality. This can result in quick wins and a great deal of perceived value being generated, albeit at a local level.
The main drawback of a bottom-up approach is that they are often knee-jerk, tactical style projects that are reactionary in nature. Managers who are frustrated by constant delays and failures may justify tactical projects with often flimsy intelligence on the real value delivered.
As we try and move our organisation (and ourselves) up the data quality maturity curve there comes a greater need to shift our focus from bottom-up to top-down project selection. My gut feel is that this is where a lot of initiatives comes off the rails. A lot of the techniques involved in top-down project selection are alien to the average data quality project team. Typical approaches to top-down project selection may require deep financial analysis, observation of customer needs in high-value market segments, analysis of service profit chains etc. Many organisations of course have their own corporate policies for project selection at a strategic level.
Is there a skills gap in our profession here? We're talking a lot about tactics of delivery, those data quality techniques that get us over the finishing line but are we paying enough attention to those skills that get our projects over the starting line?
I'm not convinced we are but what do you think? Are we doing enough to educate the profession on how to select and justify projects that move up the value chain?
What are your views on this issue?.
Recommended reading
- Are You "Cookie-Cutting" Your Data Quality Strategy?
- How to Make Data Quality Improvements Stick: Expert Interview With Mark Eaton
- IQM-CMM: Information Quality Management Capability Maturity Model, interview with Author Sasa Baskarada
- How to set data quality goals any business can achieve
- Introduction to Guerilla Data Governance: An interview with Mike Meier
- How to create a data quality competency center: Expert interview with John Schmidt
Reader Comments (9)
As per usual, I am in total agreement. I've seen so many bottom-up decision on data quality and the reality is that those typically fall flat due to lack of commitment.
Thanks again for the cathartic affirmation!
William - thanks for the feedback, hoping to focus on some of the top-down techniques shortly so will be picking your brains on what has worked/failed in the past.
Thanks for dropping by.
William,
Can you unpack the "lack of commitment" statement? What I've seen is that the tactical team is very committed to the project's success, but cannot get cooperation or buy-in from other departments. This means that data quality efforts ultimately are far less effective. Is that what you mean by lack of commitment?
In general, I wonder if the skillset that is also missing is evangelizing data quality to the larger organization.
I prefer the bottom-up project approach, of course the project needs to be managed by the strongest of project managers with a identified escalation process. I like to understand the issues and full business processes, which when looking from the top-down, the reality tends to be an "mirage" which makes it extremely difficult to make adequate decisions.
Great feedback as ever Jackie, thank you.
One question, you wrote "...when looking from the top-down, the reality tends to be a mirage..."
Can you expand on that some more? Interested to learn about your own experiences in this area.
Thanks again.
I have participated in a number of meetings where higher level management of IT, Purchasing and Engineering were in attendance and their evaluation of the data integrity was that there is no issue. These groups are usually not directly responsible for uptime of equipment or responsible for equipment maintenance where a spare part on the shelf is required to maintain a piece of equipment. One of the challenges is to place a cost for indirect and direct cost of "bad" data in an manufacturing environment.
It has been my experience that a successful implementation of enterprise wide MDM requires experienced users and engaged management to determine the practical implications of data integrity issues. The business users experience the direct and indirect cost of stocking wrong parts in inventory, the cost (time, shipping and restocking fees) of sending back incorrectly order items, cost of time searching for parts in systems that are not set up accurately, the inability to identify functional equivalent items as a result of lacking detailed descriptions, duplicate setups, emergency purchases and shipping cost or the cost of a production line going down due to a part was not ordered because the supplier couldn't recognized the part number supplied by purchasing.
Great point Jackie, thanks for coming back on that one.
This is really the crux of so many issues in taking the organisation forward isn't it? The senior execs simply don't witness the day-to-day scrap and rework, instead they just class it as business as usual. I remember speaking to an operations head in a large Telco who said that it was inevitable for service problems due to data quality, it's the same in all businesses. With the kind of mentality plus the fact no-one is coming to them with hard costs it's little wonder we see so few success stories.
I think the key here is measurement, as you rightly point out. I think the point I was trying to make in the article ties into this, with measurement comes more appropriate project selection.
Thanks ever so much for adding that comment Jackie, great insight into the reality of MDM/data quality.
I agree with Jacqueline. It takes the folks in the weeds to validate the issues. It needs to be translated into business impact and ROI for it to be important to the executive team however. That is why companies providing data quality tools should incorporate statistics to help support data quality projects. Maybe you've already covered this in a previous entry but I've just stumbled upon your site. I'd be interested in hearing different ways at looking at ROI.
Susanne - thank you for dropping by and submitting your comment, appreciated.
It's a really valid point, I think all DQ tools currently lack the ability to link raw defects to financial costs, I've always had to create financial models and dashboards outside of the product.
There are countless interviews on Data Quality Pro which focus on ROI, happy hunting but if there is something specific you would like to see covered then please drop me a line: editor@dataqualitypro.com
Thanks again and welcome to the Data Quality Pro community.