Common Pitfalls When Getting Started With Data Governance

When we are working with clients to help mature their data capabilities, most agree that better data governance would help solve some of their data woes. At the same time, we find that data governance is rarely a priority and often falls by the wayside in favor of more pressing initiatives. It is a bit like flossing – easy to get motivated when you're at the dentist office but hard to maintain when you return home. 

Ultimately, this guidance is intended to help take a new data governance program from theory to a practice that delivers meaningful value or provide some learnings for those already started on their journey.

1. Developing your data governance strategy

Common pitfall

All too often data governance starts with a high-level strategy that is vague and difficult to action. Usually, this stems from data governance playing a secondary role to other data capabilities deemed more important such as a new data platform or deploying a new AI use case. The resulting data governance strategy may take the form of something like:

1. Stand up the data governance council
2. Write data policies
3. Define future activities based on the outcomes of 1 and 2

While a data governance council and data policies are both key parts of data governance, starting here can be a misguided approach for delivering impact and even lead to data governance getting derailed out of the gate. Typically, members of a data governance council are senior decision makers. These are not the folks responsible for developing a detailed data governance strategy that can be executed, so while these early meetings may lead to some interesting conversation, it is easy for a lack of action to follow. Likewise, while writing data policy at the onset sounds good in theory, it can lead to a lot of well-written documentation that is difficult to define next steps to implement. Combined, this can lead to a serious loss of momentum and data governance falling out of favor for more tangible activities. 

Recommended approach

When delivering a new capability, it may seem intuitive to focus on aligning to a business outcome. In our experience this often gets overlooked when it comes to data governance. It can be hard to tie data governance directly to a business outcome since the solution to achieving that outcome usually involves data governance plus data science, data engineering, etc. But that's OK. Data governance doesn't need to be a standalone solution to achieve a business outcome (although sometimes it is). What is important is that data governance is a key part of a solution that matters to the business. Examples here could be: 

1. Data organized by business context (e.g., data domains) with dedicated points of contact acting as institutional stewards for the data
2. A business glossary that supports the deployment of a new ERP system
3. A centralized data catalog that allows for consistency in understanding of important shared data assets and processes

Ultimately, we are recommending taking a business outcomes–driven approach (also known as a "use case–driven approach") to prioritizing the development of data governance capabilities. These data governance capabilities may encompass anything from new people requirements (e.g., adding responsibilities for data stewards) to new process requirements (e.g., writing a new data policy) to new technology requirements (e.g., building a data catalog in your data governance tool). This then forms the basis of your data governance strategy.  

We have already covered an accelerated approach to advancing data maturity in a separate article as well as getting started with data analytics use cases. Both are useful guides to learn more about getting started with this type of work.

2. Defining the role of a data steward

Common pitfall

Defining the data steward role at a high level may sound easy – often it describes someone like the "go-to expert" for a data domain who's responsible for ensuring adherence to data policies and standards, and has the authority to make decisions about the data. What is challenging is translating these responsibilities into clearly defined activities for the data stewards.  As a result, we usually see one of two different scenarios play out:

1. High-level description of role causes confusion and inaction: In some cases, an organization doesn't really know what the day-to-day of a data steward should look like, so the role's definition ends up being ambiguous. For new data stewards, this makes it hard to get started, especially if they are not guided by a strong data governance team.
2. Detailed responsibility list is overwhelming; scares away potential data stewards: We also see the exact opposite of #1, where an organization spends significant time defining every responsibility in detail. Since the role of data steward rarely comes with a pay raise or promotion, this can be intimidating for prospective data stewards. Why take on this new role that sounds like a lot of work?

Recommended approach

Our recommended approach focuses on spending less time working out the exact details of the data steward role and responsibility definition up front. Instead, we recommend focusing on identifying those individuals already acting as natural data stewards and empowering them to get started with the new data governance program. A high-level description of the data steward role is a great way to introduce the concept to leadership as well as prospective stewards to their new role – but it is most important to identify the right individuals to serve as data stewards. 

Once those individuals have been identified, we have found it highly valuable to invest time developing and executing a strong training/adoption program so stewards are given sufficient support as they transition into their new role. The structure of this program will vary based on the data maturity of the organization – for some prospective stewards it will be a natural transition, in fact, they may already be carrying out all the responsibilities of a data steward in an informal manner. For others, this may be a completely new concept and, therefore, require the data governance team to spend additional time helping them prepare for their new role. 

In terms of the specific responsibilities assigned to stewards, we recommend building them out incrementally and linking them directly to the data governance capabilities within a data domain (see #1 above). For example, start with the responsibility of maintaining a business glossary, then add ones around data quality, access, etc. It is also important to note that not all data stewards will be doing the same things. Some may be more technical in nature; others may be in the role because they have a stronger sense around how data impacts the business. This will lead to natural distinctions on who should be carrying out which responsibilities of data stewardship.  

3. Implementing a new data governance capability

Common pitfall

Lastly, implementing the new data governance capability is another area where we have seen companies struggle. To illustrate this pitfall, let's take an example. A client just got started with a new data governance tool (e.g., Collibra), and they are excited to start building out their first data governance capability – in this case, let's say it is a business glossary. The team starts identifying and collecting potential business terms from documentation and discussions. Very soon there is a long backlog of business terms to define and a need to adequately define them in a way that makes sense for their specific business context. Months go by as the data governance team works on definitions with data stewards and coordinators, continuing to refine the backlog. Finally, the new business glossary gets moved into production so the rest of the organization can use it. The only catch: the data governance team has been working on it for months before the rest of the organization sees anything. 

By taking this bottom-up, holistic approach to building a business glossary there is a significant risk of delaying the time-to-value an organization sees in the business glossary itself as well as building something that doesn't align to the needs of the business. Another risk is burnout from the data stewards and coordinators, especially if they do not see the business glossary generating business impact or worse, that they have invested time defining terms that aren't relevant. While this example is specific to a business glossary, it is easy to imagine a similar scenario playing out for implementing any type of catalog-related data governance capability. 

Recommended approach

Here our recommended approach can be summarized as "progress over perfection." By that we mean focus on building out the business glossary in bite-size chunks by prioritizing terms that will have the most value to the business. These may be simple terms that show up on frequently used reports and are therefore more likely to be useful to the broader organization or complex terms that hold different meanings in different areas of the organization (although these have the tradeoff of taking longer to define given the number of stakeholders usually involved). Again, this example could be extended to any type of data cataloging effort, whether it be focused on reports, data sets or something else.  

It is important that data governance does not appear as a black box to the rest of the organization. Data governance needs to be a business-led function and requires constant collaboration with business leaders to identify relevant problems that can be solved with data.  All data is important, but not all data is important right now. Ultimately, data governance must build momentum to show ongoing value.

Getting started with data governance at your organization

We hope these recommendations are helpful in getting started with or accelerating the growth of data governance maturity at your organization and, most importantly, avoiding some of the common missteps that we have seen at other organizations. For more information on how to implement data governance for your organization, request a workshop from one of our data governance experts.