Archive for August, 2008

Why Follow Data Quality (DQ) Best Practice? Why use Data Quality tools?

Thursday, August 14th, 2008

I am often asked by line of business managers and programme managers why the use of data quality tools, now increasingly considered best practice, is important: And particularly so when they are asked to fund investment in these platforms!

The heart of this problem is that many otherwise excellent data migration leads tend to talk in technical terms when it’s a simple business case that is required.   It is not necessary to explain the need in Data Quality terms at all, as the benefits can be explained purely in terms of risk management and planning:

Traditional Data Migration can be visualised in terms of a project plan, in which we would on-board the team, progress with setup, start moving small items of data around, begin gradually to integrate these into larger sets and then finally move to a fuller picture encompassing the whole starting data set and also the target.  However we notice when we look at this plan that any integration problems would only be realised a significant way into the project, when a lot of money has been spent and promises have been made on the size of the team, the budget and even the feasibility.

It’s tempting when budgeting to look at the data movement as an excercise unto itself, but if the data does not arrive, the system stays empty and an entire business change progamme may founder.  Workflows will have been created, hardware has been ordered, training has been undertaken, managers have been moved and backfilled, and other strategic business objectives have been put aside  – all for nought.   Worst still, if the data is flawed and the business trust to luck instead of calling a “no-go”, they may find themselves stranded on an unworkable platform, unable to operate processes effectively and in danger of damaging customer and investor confidence directly.

So that:

Data Migration is a critical dependency of wider change and implementaton programmes that has a tendency to generate long thin plans with a high liklihood of trouble towards their end-points.

As managers what are we going to do about that?   I don’t mean the Data Migration Lead, I mean you, the key sponsor with his/her career on the line.

With any other such problem you would seek to bring the problem area forwards in the timeline, work on it in parallel, investigate the extent of the risk and from there form an opinion sooner rather than later so that countermeasures can be deployed and mitigation put in place, even to the point of cancellation if teh endeavour appears too risky for the organisation to procede.   …This is Project management bread and butter.

This is what DQ Tools allow your Migration Lead – the means of performing that transformation of project time and risk; Snapping the problem elements away from the troublesome end section and bringing them forwards in the timeline, closer to programme initiation and before significant damage can occur.

Bringing The Risk Forwards in Time

The technical detail of how this works is far less important than the impact in risk, planning and certainty, allowing the project to forge ahead with confidence rather than bravado.