5 things your data governance officer must know

Data governance can feel like a daunting task, and it would be wrong to pretend there are complicated reasons why that’s not the case. It is the case. Data governance by definition is a complicated business. Getting a hold of your data governance demands the organizational skills of a librarian, the hawkish instincts of an accountant, the strategic nous of a general, and the business knowledge of a CEO. It’s a very particular set of skills that every data governance officer needs to get the job done – on top of which, there are 5 things your data governance office must know.

1. The destination of the data governance.

It would be almost magnificently pointless embarking on a data governance operation without both knowing and understanding the goal of the task. Data governance by definition is the task of bringing order and ease to an organization’s data stores. But order and ease are in themselves defined by the data goals of the company.

Before your data governance officer can begin to catalogue, tag, locate, define or assign access pathways to your data, they need to be clued up on the fundamental point of the exercise.

What are the benefits you intend your company to reap from the work of your data governance officer? What kinds of data do you have? Who needs access to what, when, why, and for how long? Is any of the data to be subject to local download, storage or copying, or will everybody with the correct permissions access the same data without it moving its location or duplicating the number of locations in which it’s held?

All these may sound like technical questions that the data governance officer by definition should decide for themselves. They’re really not – they should form part of the framework on which your expected results are built, and you should be able to tell your data governance office what they are, and what those expected results look like.

If that seems unreasonable, imagine you’re building a website. You employ a web designer to do the work of creating the structure of the site, to ensure pages link together, resources present themselves in the right way, and so on. You possibly also hire creatives to write engaging copy and provide eye-catching visuals and video resources to make your website stand out.

Unless you as a company or a manager give the website designer a wireframe, though – an understanding of what you need to happen and how you want your website to function and to look, the chances of them getting it “right” as you would like it are miniscule. You need to set the expectation, and make that expectation clearly understandable. The same is true of data governance officers and your data.

Define your data goals, and inform the data governance officer of permission levels, sensitivity levels of the data you hold, and all necessary information to build a data governance wireframe, so that the end result looks – and more importantly, functions – how you need it to.

And just to be clear – if you’re not certain what it’s important to let your data governance officer know about how you need the eventual result to work, tell them as much as possible. Extraneous information, they can ignore. A steer on data storage and access pathways, both they and you will be sorry they didn’t have.

2. The starting point.

It’s absolutely true that any data governance officer worth the name will fairly quickly be able to get their head around your current data management processes and strategy. But you need to go through it yourself, not only so that you understand it, but so that you can explain it to your data governance officer.

Why are you doing that?

There’s a process in the military, whereby briefings are given even to subject experts. The point of them is to ensure that “everybody knows the same ‘obvious.’” Things may be obvious to you. Things may be obvious to the data governance officer. The exercise of assessing the way you currently do things – and the exercise of explaining it to the person charged with delivering the new way you’re going to do things, means you both work from the same information – even if, with their greater expertise, they can point out holes in your assessment, and make you amend not only your understanding of what you do right now, but also, by definition, what your data governance officer needs to deliver for you.

You are almost guaranteed to find areas that are vague or ill-defined. That’s good – it means the process is working, and it’s information your data governance officer needs to know. Think about how and where you currently have data stored. Think about how it’s accessed, by whom, and how much control over the data location you have. Include information on how regularly your data is audited – and by whom, to what level of scrutiny.

What you’re aiming to achieve is a written “twin” of your current situation, which, alongside the data wireframe – essentially a written “twin” of the situation you’re aiming to achieve, give your data governance officer a Point A and a Point B, at least as you perceive them. Any areas of vagueness or confusion in your understanding of Point A will become clear in the writing of this understanding, and will be an element on which you can get them to focus, so that such vagueness does not survive into Point B – your future state of data governance.

3. The personnel.

There’s no sense in which providing a lit of important personnel should be an insult to your chosen data governance officer. What it should do is give them a clear idea of who will be using the data on a daily basis, and who will be in control of it. You should be able to give them details like the name and remit of the chief data officer (who usually, by definition, implements the data governance framework), as well as who technically “owns” the data, and who will be responsible for it day to day (usually known as a “data steward”).

4. The route map.

Usually, this is where the data governance officer will know more than you about the project. They should know, more or less based on the information you have provided them, how to move you from Point A to Point B. Make sure they explain the route they intend to take, and don’t be afraid to ask questions about why they’re making particular decisions.

Also, don’t be afraid to answer any questions they have. They will plan the route map – the method by which they’re going to establish your data governance – based on all the information you give them, and their own understanding of best practices. If they have questions, it’s likely because something in either your description of your starting point or your explanation of your desired destination doesn’t quite make sense. That’s especially common once they’ve taken a look at the data they’re actually dealing with. Answer any questions, including researching the answers if need be. The success of your data governance could depend on it.

5. How to monitor – and display – progress.

One of the biggest reasons why major projects of all kinds go awry is that the people commissioning the work and the people doing the work have different metrics for progress, completion, and sign-off.

Work with your data governance officer to get a clear definition of what progress will look like, when it will be delivered, and so on. Check in regularly – but not intrusively – to ensure that the project is not only on time and target, but that the governance is being performed as you had initially expected. That way, everyone in the process will “understand the same obvious” on progress and delivery, as well as on the nature of the task at hand.

If your data governance officer knows all these things, and you work with them openly, you should by definition get the data governance you want, with appropriate access, easy management, and ways of putting your data resources to use in ways that not only make you safe in terms of legislation but also help drive your business forward.