In this post I want to outline a simple approach to help data migration project leaders get buy-in for data quality management. I see the project leader as the optimal resource for driving this requirement, but since many project leaders will have had little exposure to migration projects in the past I figured a little help may be in order.

Step 1: Define what you mean by data quality management

Obviously a great starting point is to come up with a simple definition so that when you’re invariably quizzed by programme sponsors (especially when you’re asking for extra cash) you don’t take endless hours rattling off buzzword after buzzword.

Here’s a definition you can try for size on your own project:

Data quality management during a data migration demands specialist skills and software to be executed in a controlled manner so that we can:

1. Understand precisely what issues our historic data will face on their journey to a completely new environment
2. Automatically fix as many defects as possible, freeing up much-needed resources to fix the defects that require manual intervention
3. Provide project sponsors with sufficient confidence that the quality and integrity of our data has not been negatively impacted during the migration

Step 2: Understand the fear of status quo thinking

Okay, you now have a good definition. Before we can work out the cost/benefit of data quality management we need to articulate exactly what “doing nothing” looks like. One of the things I like to do is recount assumptions from previous projects so you can clear the air with statements like:

• Our data was fine before so it will be fine in the target system
• We don’t have time; have you seen the go-live date?
• There are no skills or software available so we’ll have to ignore it
• Data quality means cleansing and we’ve already decided to do that in the target

What you’re doing here is creating a list of incorrect statements that many people probably believe to be true. The reasons people reject business cases are generally down to fear, not logic. By getting these assumptions aired you can then address them one by one. This way your sponsors can understand the context behind the decision to get specialist data quality software and skills on your project.

Step 3: Do some data quality mining

Get some data profiling carried out on the legacy data. Show the problems and what it will mean to the functionality in the target system. Explain how better data quality management will prevent these issues from happening.

Even if you don’t have software at this stage, you can generally get a vendor to carry out a pilot initiative for you to highlight some issues and even help you build a business case.

Step 4: Calculate the costs

The best way to pitch data quality is to focus on the cost of delay because the sponsor wants a slipped project. Work out the costs of a one-month overrun and explain how a data quality management capability will reduce that time deficit. Cite research (I can guide you on specific research papers, just ask in the comments) that illustrates how projects without data quality software can take considerably longer to complete. Work out the cost of a 5%, 10%, 20% delay.

Next, work out your cost of software and resources and then demonstrate how data quality management fits into the wider project, impacting practically every single activity. Link the benefits of data quality to the dangers of status quo thinking. You want to make it appear absurd to even contemplate eliminating data quality management from your project.

Step 5: Present interactively

I think the best way to present a dry topic like this is through a combination of stories and show-and-tell briefings. Have access to data profiling results, for example, so that management can see tangible issues. Walk through specific scenarios of how your data quality approach will tackle poor data and guarantee higher quality information and functions in the target system.

Don’t just rely on slideware; make the outcome tangible for all those present. Remember to go through the incorrect assumptions found in Step 2 and highlight how your approach tackles them individually. Be sure to create an open forum for discussion and do a round-robin of your sponsors to get their preconceptions aired and resolved.

Hope this has been of some help because far too many data migration projects are being kicked off with data quality as an afterthought. Whatever approach you take I do hope that you factor data quality into the very fabric of your project because when you get it right the process is far more enjoyable, less risky and a great deal cheaper overall.