Less is More: Creating your First Data Quality MVP

Can we use startup principles for Data Quality? Have you found it difficult to deliver a full-blown data quality initiative?

Did it take forever to get backing and grass-roots support? Perhaps it’s time to roll back your “grand plan” and take a “less is more” stance with a Data Quality MVP.

So what’s a “Data Quality MVP” you ask?

Introducing the Data Quality Minimum Viable Product Project (MVP)

The term MVP has been common in startup companies for quite some time now. Startup companies are adopting a minimalist approach to building their product in a bid to get it into the market quickly, delivering value, gaining feedback, learning and creating the impetus and directions for the next release.

Wikipedia explanation:

“The [MVP] is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.”

Less is more for “data quality startups”

So, much of what startups are trying to achieve with highly focused product launches resonates to what we need to achieve in those early days of our data quality projects too.

The big mistake many companies make is creating long, complex projects with a lack of experience or over-reliance on untested 3rd parties.

Opting for a Data Quality MVP is a credible alternative with a focus on Plan, Deliver, Learn, Adapt could be a simpler way forward.

Just like a product our data quality project consists of features and benefits, stakeholders and users, market needs and bottom line results delivered. It therefore makes sense to “test the product” out first to see if we have the right skills, approach, support and so on.

Links to Agile Methodologies

In my recent Agile MDM interview with Craig Cox  (of Agile Solutions Ltd) we learned of how Craig’s team prefers short sprints where they deliver time-boxed value very quickly, learning and adapting as they go. The same rules apply for data quality initiatives obviously so what are some of the key components of a Data Quality MVP?

Problem Focus: You need to concentrate on one issue that is of concern to sponsors. Yes, improving data quality can have widespread benefits but by sticking to one problem you solidify the team with one goal.

Data Focus: Because we’re not just having a “general look at data quality” but are applying a business driven, highly focused attitude, we can immediately narrow our data scope. I’ve found that being ruthless with data scoping you can shave weeks off delivering value in your first initiative.

Smaller Team: By going “hyper-niche” with the problem you’re trying to tackle you automatically reduce the size of the team and engagement with the business community required. The more silos and applications you need to investigate, the bigger the team, processes, orientation and delays you’ll receive.

Faster Results: The focus has to be on results even if you’ve not been asked to create a business case. You need to be able to demonstrate tangible value early in the life cycle and if you can’t then it raises questions over project selection so you can stop, adapt and move on to another problem without burning weeks of effort. I’ve seen teams bogged down for months trying to crack a problem that no-one really cares about and delivers limited value.

The key benefit to taking this MVP approach is that your speed of learning dramatically increases. As you come out of the project lifecycle faster, you can then share what you’ve learned, adapt your business processes and quickly move on to the next initiative.

What do you think? Does an MVP make sense? Should we be creating larger visions and programs of work instead? Welcome your views below.