How to set up and run an effective Data Governance Committee

How to set up and run an effective Data Governance Committee

This article was originally published on the datazed.co.uk website and on LinkedIn in November 2022.

Data Governance Committees are one of the hardest elements of a data governance framework to get right.

If you've set one up, run one, or sat in one, do any of the following seem familiar?

• Key stakeholders don't show up.

• If they do show up, they're not engaged.

• The Data Team getting blamed for poor data quality

• IT making life difficult.

• The issue log gets longer and longer.

• There's no budget...

All painful.

All solvable!

Before we go in to the detail, let's refresh ourselves with some background into a data governance framework. What we need to cover is:

• What data you've got;

• What it means;

• Where it is; and

• Who to talk to about it

This last section is covered by what I call the Data Community.

The Data Community is made up of Data Leaders, Data Owners and Data Stewards which is discussed in more detail in this article.

The most senior data owners, together with other relevant stakeholders, make up your Data Committee.

This may be called a Data Committee, Board, Council, Steerco or anything else you like! Most likely the name will align with other decision making groups in the organisation.

However, whatever you call it, you really only get one opportunity for it to succeed, so let's consider what we need:

The first session will generally get the right stakeholders because you'll be able to promise great things.

If those stakeholders don't receive value for the time they invest into attending, then for the next meeting they may send a delegate.

The meeting after that, they'll send no one…

So your first rule should be that your data community needs to be pretty well established before forming the committee.

If you go too early and don't deliver then you've lost.

You need the key stakeholders showing up 

The people in the room must have the credibility, responsibility and authority to make decisions for the organisation.

If you have people who lack seniority (for example, they could be your most insightful data stewards) then you will find that the right issues are raised but no one can do anything about them. The issues sit there as pain points forever, which impacts on your risk RAG ratings and will likely come to haunt you on any internal audits or risk reviews that come your way.

If you go too senior, then the people in the room will be too far removed from the data pain points and your committee may even be overlapping with more senior forums such as the Operations Committee or Executive Committee.

One approach I have taken is to have the Operations Committee look at data issues and, where the committee is unable to provide the required focus on them, get them to set up a data committee which they can delegate. It may even have a big overlap in membership, but works because there is now a specific time allocated to data matters.

For significant items, the Data Committee can always escalate back up to the Operations Committee and beyond.

A key benefit of this approach is that the Data Committee gains buy in because it was the senior leadership who set it up, rather than the Data Team.

When the key stakeholders do show up, they need to be engaged 

Your committee members must feel that they are there to make relevant decisions. These decisions will come from your data quality log and we are looking for them to consider the risk and impact of these issues against the resource and cost required to resolve them.

The data team should be able to estimate both of those things, with the support of colleagues in the business, and it's perfectly ok for the data committee to challenge those findings because they are the senior leadership. What we are giving them is a sensible start point for consideration, rather than dumping a problem and a blank sheet onto them.

It's deeply important is to remember that your senior stakeholders are looking at the opportunity cost of action against any other project in the business, and not just data, so it may be a perfectly rational decision to not invest in a particular data issue and to use that money elsewhere.

This can be very frustrating to those of us who are passionate about data, but it's part of our learning curve to consider the business as a whole.

Too often data specialists will be moan and groan that the leadership are wrong, out of touch or even stupid (this is career limiting and not recommended!) because they don't see the data problem, but actually it's because they are looking at the business from a much broader angle.

We must give them decisions to make, then follow upon those decisions with actions.

The committee is not about the data team fixing data quality 

A common complaint of data governance and quality professionals is that too many of the agenda items the actions land on the data team.

This comes when the committee focuses on, for example, data quality dashboards and the view in the room is that it's the responsibility of the data team to make it better.

The result is that the reputation of the data team is made worse rather than better. This causes the data governance committee to be seen in a negative light and once again, we lose engagement.

Where data quality issues are identified, the data team must be supporting the business teams to resolve them. It's the business activities to get the data to the required standard

Align with the IT team  

It's hard to successfully manage the relationship between the data team and the IT team.

This could be because IT execute activities without engaging the data team sufficiently early; or it could be because the data team are carrying out activities which the IT team believe should be in their remit.

This is why the committee membership not only includes key business data owners; and representation from your risk, compliance and Information Security teams, but must also have representation from IT and from major change programmes.

The right people must be in the room when these issues are discussed.

Don't let the issue log grow and grow 

The issue log (see this article) should grow at first, as you engage with the business users of data and collect the issues that people have known about the years but never been able to resolve. This will gain you some goodwill as people realise that you are taking their concerns seriously.

I like to have an open chat with the business colleagues, and a question which I like to ask is

If I had a magic wand and could make one thing better, what would it be?

For other methods of engaging with colleagues and finding out the issues, try this article about elicitation techniques.

But this goodwill will soon be lost if the items sit on your data log and never get resolved. It's vital that you clock up some wins and you are able to close down some items, even if they are just the "low hanging fruit".

In fact, if an item remains on your log and is unresolved for a considerable time, that itself should be a reason to increase the risk rating, with a consequent need to escalate. The exception is if there is a proposed solution which is due for delivery at some known later point - then you can put the issue on hold.

If you are putting an issue on hold for that reason, then be careful. You still have to ensure that the proposed solution will solve the problem. Sometimes you may wait a year for an IT change or a new system to be delivered, only to discover that it didn't resolve the issue.

Now we're over a year further down the road and we aren't any better off!

Over time we should expect a regular cadence of data issues as old ones get resolved and new ones are raised. There should never be an expectation that the issue log will be clear. If that happens, then it's because no one is recording them!

Find budget. It probably won't be yours. 

It's unusual for the data team to have a specific budget to solve the data issues in the business. Generally the budget will come from the Change budget or that of the business team or unit concerned.

To get that budget allocated to solve the data problems, you need all the components discussed above to have:

• The right stakeholders in the room;

• Who are engaged and brought in in;

• Who are assessing and prioritising business data issues;

• Who are aligned with your colleagues in IT, Risk and Change; and

• A growing track record of delivery, solving the data problems of the business

And with those achievements, the budget will come.

Moreover, with each bit of problem solving, you get:

• Another success story;

• A new case study; and

• Enhanced advocacy for your data work from your colleagues and stakeholders

Let Datazed support your data governance initiatives and benefit from our experience so you can succeed.

Was this message forwarded to you, or are you reading it online? Click here to subscribe and get this newsletter sent directly to you. Unsubscribe instantly and at any time using the link in the footer.

Click here to see the archive of previous newsletters and articles.

Have a wonderful week,
Charles