Implementing Data Governance – how to make it work!

I’m still having conversations with clients and colleagues about how best to embed good data governance into an organisation. Anyone who’s tried it knows that it’s difficult: it’s not (or shouldn’t be) just about compliance; it’s that we need to change embedded processes and the way people work – and we all know that habits are hard to break!

There are many things we can do to make and embed change, but I’ve pulled out 3 things that I continually lean on (and it makes a cool acronym too), and with a focus on data quality – since that’s usually a big driver in implementing Data Governance.

1. Focus

How many of us have been involved in programs that boil the ocean: “we’re going to be a Six Sigma organisation”, “we’re going to all stop using Excel”, “we’re going to become ISO compliant”.

That works at the start, but keeping that energy and momentum up is very hard – even if it’s backed by the C-suite.

I’ve had much more success where we attack smaller, but important areas with a “make and keep it better” focus (noting that we still need the “ra ra”, and the management backing):

• Focus on critical gaps that you’ve already identified: one or two key things that impact the whole organisation, e.g. agreeing average monthly revenue per customer, or number of reprocessed claims
• Focus on business outcomes: what can we now do if we understand the change in the agreed average monthly revenue, or the cost savings we get, by reducing the number of reprocessed claims?

At the start, you’re most likely doing proof of concept / proof of value projects, but you need to have a target state and some milestones in your overall program – to both keep you and the organisation on track, and to understand if you need to change tack as you’re working through what will likely be a 3-year program. NB: If you’re trying to get this done in less than 3 years, think again – embedding process and real change MUST become a new habit!

2. Empathy

Acknowledge that you’re going to be making people do things that they’ve not done before – and this will immediately surface the “why?”. There are a few things that people will be thinking of, that you need to prepare for:

Status Quo bias ????????????? We’ve been doing it this way for years: why is it suddenly wrong / what have “I” been doing wrong?

Increased workload??????? This is going to take ages to change / I knew how to do it before

Not again!??????????????????????? We tried this 2 years ago and it didn’t work

You need to apply empathy (and avoid sympathy) to this – that it’s not about them, that we’re in this together to make the change work (with the minimum of disruption), and that there are many factors backing this change that must be embedded.

3. Data

This should be natural (and, as Mister Data, I couldn’t not mention it). Use data before, during, and after your Data Governance projects and in line with your overall strategy and program of work.

Before:

Go and find those areas: the critical gaps, and some critical data elements (CDEs) – work out the historic and ongoing volume of records/entities that are being impacted by poor data quality. Lay down some $$ stats of the impact: effort to fix up data in usage/reporting, time for rework, cost of incorrect decisions (albeit harder). People may argue with your stats, but at least you’re starting the conversation, and getting them involved and interested. You now need to work out what you’re going to do in implementing governance – which means making a change in the process.

1.?????? The best way is ALWAYS to fix it at data capture time – make it easier to get right and harder to get wrong (and you get the most benefit doing it there). Calculate implementation and training cost here.

2.?????? Sometimes it’s going to be organisationally easier to add stewardship – and catch bad data before it spreads downstream. Calculate the cost of adding DQ checking rules and then the ongoing manual or semi-automatic stewardship costs here

3.?????? Sometimes (but please try and avoid it) you’ll have to implement a fix in the systems integration stage or the data repository. Calculate the cost of building and testing the fix and add some to ensure that the DQ fix stays accurate on business change (e.g. report and track the number records you’re fixing each run).

4.?????? You will also need, in many cases, to fix up historic data. Again, if you can fix it up in the source (without impacting audit etc.) do so. Calculate the cost of the one-off fix

You now have the cost of the data quality issue, and the cost to fix it – you should now be able to present a solid business case.

Repeat this for any and all data quality errors you’re finding – you’ll soon get very quick at estimating which ones are going to get through and which aren’t!

A good step here (when you know you’re on to a good thing) is to go and look for a data quality tool. If you’ve taken my advice and “shifted left” on fixing data at data capture time, then you’re looking for tools that can report on errors vs tools that fix. A couple I’ve used with good success are Great Expectations (or dbt’s Data Tests) and Ataccama. There are also a couple of easy ERD structures out there that you can populate into with your chosen ETL/ELT tool.

A good BI visualisation on this data can also quickly show how big and expensive the problem is, and help you track as you move through embedding the changes.

?

During:

“The best laid plans”: You’ve done the due diligence, you’ve fixed the data capture to make it a drop-down vs keyed free text, and trained people up. Your cost/benefit looks great!

One year down the line you’ve got weird results – on closer examination 90% of humans have picked the first entry in the drop-down list. Your completeness is at 100% but your accuracy is in the doldrums. Come back to focus, therefore:

1. Ensure the humans understand why the change has been made, and why it’s important to get it correct.
2. Add a “data observability” style rule, and make sure that the new content is making sense as the change is rolled out and embedded.

?

After:

You’ve spent the organisation’s money; you’ve supposedly made an improvement. You need to make sure you’ve done that and, almost as importantly, you need to demonstrate that to all the stakeholders: management, the people you put through the change, and then the wider organisation (since you’re going to hit them up soon).

Understand, also, that the fix you made this month will be respected for the next 12 months (at most). If you’ve done well, then this change is now embedded and is BAU. Use the “in the next 3 years we’ll save xxx” at the start - but understand that memories are short. You therefore need to actively look for the “next best fix”.

By focusing on a few key areas first, empathising with those involved, and using data-driven evidence to guide decisions, you can set the stage for a successful data governance program.

I do acknowledge that this is only skimming the surface of Data Governance (and is only one angle), but if you can apply these processes and keep your data quality action list well-FED, you will almost definitely be able to continue to be funded appropriately.

?