How to Build a Data Governance Organization

I’ve built a lot of data governance organizations.  I’ve also helped to reboot and restructure under-performing data governance organizations.  There are similarities in the way I structure them, but they’re always different.  Even in the same industry, they’re different.  Part of the reason behind that is that company structures and cultures vary and what works in one company doesn’t necessarily work in another company.  Putting in a data governance organization is a change and people get nervous around change.  However, you also have to be willing to stand your ground and not build a structure that is wrong just because you don’t want to face conflict.

There are different ways to structure a data governance organization.  I don't like people getting hung up on categories because they can waste time trying to figure out which category something goes into rather than focusing on what the need is, but some people like to categorize things.  For people who like categories, I think about several levels in the organization: executive, strategic, tactical, and operational.  Lines can sometimes get blurred, particularly in smaller organizations where some people play multiple roles.  If that happens, those people need to think hard when they're making a decision to determine if they're wearing their strategic metaphorical hat or their tactical one.  The categories typically used are:

• Executive – Oversight and guidance focused.  Data governance champion.  Sharing overall company direction.
• Strategic – Priority focused.  Setting data governance direction.
• Tactical – Solution focused.  Addressing regular issues.
• Operational – Support focused.  Keeping the infrastructure running.  Reporting issues.

1. Of all the levels, the executive one is the one that often gets missed.  As an executive, this isn't someone who's making day-to-day decisions about the data.  It's not even someone you're escalating issues to.  It's someone who's championing data governance within the company.  This is someone who is a respected leader in the company and can promote the value data governance is bringing.  Sometimes, people appoint someone to this role and they become a figurehead doing nothing.  If that's the case, why did you bother?  You might wind up with someone who doesn't see the value of data governance and lets the discipline die when they're trying to save money somewhere.  You don't want that person.  You need the right executive.
2. The strategic level consists of people involved in understanding the company's goals and how those goals need to be implemented through data governance.  They're not the ones doing everything, but they're the ones who know what needs to be done and are making sure people are working on the right initiatives with the right resources to do so.
3. The tactical level consists of the people involved in day-to-day activities.  They're close to the data and understand what it means.  They're involved in addressing regular issues with the data.
4. The operational level, like it sounds, is focused on regular operations.  Since these are the people who have hands-on experience with the data, some people get confused and think they are the decision makers.  No.  These people enable the decisions.  They might develop trusted relationships with people at the tactical or strategic levels, but they are very narrowly focused and we still need the higher levels to be the decision makers.

One role I typically build into data governance organizations is the role of an “Advisor”.  Advisors have specialized skills that are used as needed, such as legal, privacy, compliance, etc.  For instance, you need your Legal Advisor to provide feedback on legal issues, but otherwise, they don’t need to be involved in all decisions.  Frankly, if they were called on for all decisions, they would probably either be removing themselves from decisions they didn’t think mattered to them or they would just go with the group in making a decision.  Either way, you want the right people involved in the decisions and you don’t need to include people who could be better occupied doing something else.  This can also fall into a discussion of voting and non-voting governance members, which I'll discuss in a forthcoming article.

Another role I often use is "Support Team".  The Support Team consists of people who play important roles that you rely on, yet aren't the decision makers on data.  This is often where you find the IT people.  You need people like Data Architects, Data Modellers, and DBAs.  This is also where you'll find Trainers and Org Change Management Teams, if your company allows.  They need to be able to focus on their tasks, but they don't need to be in every data meeting.  Call on them when you need to.  You might call on them to provide data reports that can help the business people make a decision.

Some people put "Data Users" on their org chart.  If you do this, make sure you understand what you're doing with this group.  Essentially, everyone is a user of data, so having this group can easily grow out of control.  If you use it, there might be the expectation that these are the "key" users and they'll share information with other people on their teams.  Otherwise, you run the risk of having a box on your org chart that contains everyone in the company, and no one needs that.

The person running the organization, called something like a Data Governance Lead, needs to be a data person.  This person keeps things running like clockwork.  I’ve seen some companies put a non-data person in this role – perhaps an amazing Project Manager.  There might be some companies out there that have been successful with this, but I haven’t seen any yet.  A data person understands what is happening from the business side and the IT side and can bring it all together.  The data person understands what is happening, what needs to be done, how a problem can be solved, and is a champion of the effort.  Someone without those skills might focus on the organization being very tactical and think only of the tasks that need to be performed.  Also, a non-data person often gets carried away into thinking they understand and runs the risk of making some bad data decisions from not understanding the data implications.

When thinking about what you’re going to call things in your organization, don’t get hung up on fancy words.  Make it easy for people.  You can choose real English words!  Although some companies use "Council", I've found most prefer something like "Steering Committee".  I’ve also had better luck with groups called the “Working Group”.  As the “Working Group”, they always understood that there was work they needed to do and they weren’t figureheads.  “Steward” is another word I don’t always use.  People sometimes debate whether a “Steward” is someone who owns things or someone who does things.  Even "Owner" can be confusing because it's based on the context of what decisions someone owns.  Let’s just make things simple and not get people hung up trying to learn new vocabulary too.  Whatever you decide on, clearly document it in your charter with roles and responsibilities.

I worked with a company that was really struggling with the concept of a data governance organization.  They saw something that looked like an org chart and worried there would be concern that people were getting new managers.  After a lot of explanations that didn’t work, like explaining that it was a matrixed organization, we tried the simplest thing – we removed all lines from the org chart.  It was still structured like an org chart and had lots of boxes in what looked like an organized design, but there were no lines connecting one box to another.  That’s all they needed!  That solved the whole reporting problem for them.  From that time on, I have rarely created a data governance org chart with lines between boxes.  And companies don’t miss those lines!

Deciding who to involve in the data governance organization means understanding what needs to be governed and how the company is structured.  Look at the data domains that matter.  Look at the impacts each department or function has on the data domains, and how they're impacted.  Identify the heavy users of the data.  Focus on the business needs.  Dig into the company structure as a whole, not just the most vocal people.

When you think about what you’re governing, you might be developing domain groups under the same data governance umbrella.  For instance, if you wanted to govern customer data and product data, you might have some very different people involved in each domain.  There might be some similarities, such as both involving the same Legal Advisor, but knowledge of customer data is very different from knowledge of product data.  Not everyone knows both equally well.  In these cases, you can create a Customer Working Group and a separate Product Working Group.  Both groups can be coordinated by the same Data Governance Lead, but they can meet separately.  A customer person doesn’t have to sit through all the product discussions, and shouldn't have decision making responsibilities for something they're unfamiliar with.  Similarly, if it was a global company, you might have each country meeting separately and then only coming together at the higher leadership level.

Think about how you’re implementing data governance.  From software development, most people are familiar with the term “big bang”.  If you take a big bang approach, you’re implementing data governance all at once.  If not planned carefully enough, a big implementation often leads to a big failure.  To combat this, most companies start smaller.  Smaller might mean having less to govern or a smaller reach.  Having a smaller reach though needs to be carefully planned out.  For instance, a global company can often quite easily focus on a single country and then expand out to other countries in the future.  However, if you’re trying to focus smaller, you have to think about how that impacts what you’re not reaching.  Think about governing customer data.  If your company has 10 departments and you decide to only govern customer data in 2 of them, what does that mean to the data?  Chances are, there are so many overlaps that you can’t ignore the other 8 departments.  If you just focus on 2 departments, you're probably not involving everyone you need and are not making the best data decisions.  You're also building animosities by the 8 departments thinking that the company only values the 2.  Only governing the way select departments interact with the data probably doesn't accomplish much at all.

Even after doing this for years and plenty of published insights out there, I am still surprised when people approach data governance as an IT initiative.  IT is needed as an enabler of data governance to maintain the data infrastructure, help implement any needed tools, and help identify data issues, but data governance is a business initiative.  The business people have the knowledge of what the company wants to get out of the data, and therefore knowledge of the business rules.  They don't always know they're the ones with the knowledge and might think IT can read their minds.  They often need some good people to help get the information out of them in the context of governing the data, but they are the people who are benefiting from data governance the most.  Some companies might struggle to find the right people and staff the data governance organization solely with technical people, but they’re really doing themselves a disservice and should be taking more time to plan.  Knowledge of business concepts and business direction is not to be confused with knowledge of where the data resides and how good the quality is.

When you're developing your data governance organization, remember to actually talk to people!  If you create an organization on paper in isolation, all you've created is a picture with names in boxes.  You need to talk with people to determine who the right people are.  You need to get their buy-in that they're the right ones.  I often do a "roadshow" where I'm explaining to people what data governance is, what it will do for them, and if they're the right ones.  This always leads to discussions with additional people.  I never like to publish a data governance org chart without approval of everyone on the diagram.

I've talked through some broad concepts here that can help in building an effective data governance organization.  Everything can be talked about in more detail, and there are other articles out there that I've written that can help.  Building a data governance organization isn't rocket science, but it often does require assistance.  A lot of companies hire consultants to get them started and take them operational.  That can also often make it easier for employees to accept.  Change can be hard and it can sometimes be easier to accept coming from an independent party than a co-worker.