Throughout this book, I promise to be transparent and direct about my experiences, and we’re going to start strong: governance programs fail because we have failed. We have failed to explain data governance in a way that makes sense to our business stakeholders. We have failed to deeply and intimately understand how our solutions will drive business success. In short, we have failed to explain in terms of business value. Conversely, the most successful data executives I have had the opportunity to work with have been successful because they deeply understand their company. They have spent the time to intimately understand the business, have crafted data solutions that enable business success and have successfully explained the benefits in terms of business results vs. data results.

As we go deep into these topics, I will not make assumptions about your experience implementing a successful data governance program. I will start with the basics by grounding you in definitions and the foundational capabilities and will build on how to launch a successful and impactful program, complete with the measures for success that will resonate with executive management and, ultimately, the board of directors for your organization. In the end, we will complete a case study to bring it all together. By the end of this book, you will have all you need to launch a program and deliver with excellence in your own organization. No longer will your organization be overwhelmed by data and underwhelmed by insight. We will change the narrative together.

In this chapter, we will ground ourselves in the basics of data governance and how it relates to adjacent capabilities. Then, we will define the components of a data governance program, why each component matters, and why we treat data governance as an enabler for business value. Subsequent chapters will dive deeper into the fundamental capabilities of a data governance program and how to implement them.

We will cover the following main topics:

• What is data governance?
• What’s driving the increasing need for data governance?
• A brief overview of the data governance components
• Data governance as a strategic enabler
• Building a business case for your company
• When and why to launch a data governance program

As I meet with data professionals across industries, it is abundantly clear that data governance is more important than ever. Executives are expecting more from data, but without the proper investment, it is harder than ever to respond at the speed of business.

So why is it increasingly difficult to respond to our executives at the pace of the business? There are a number of key factors, including the continuous rise in the following:

• Data volume: We have more data today than yesterday (everyday!). In fact, the amount of data doubles every two years. Yet, we cannot expect to double our efforts or double our staffing or technology spend.
• Regulation: The regulatory landscape is evolving, increasing expectations for how data is handled. In the United States, at the time of this writing, six states had signed privacy and data protection legislation into law. This increases the complexity of compliance for data handling.
• Expectations: Executives’ expectations are rising, but our use of data is not. In a recent Tableau survey, >80% of CEOs wanted their organizations to be data driven, but less than 35% percent of employees felt their data was used in decision making.
• User base: More individuals than ever are engaging in data, wanting it for their own use but needing to trust it. It puts our governance professionals in a position to add tremendous value by providing trusted, well-governed data to our organizations.

We have to become more innovative and more embedded, leveraging more technologies (e.g., automation and AI) than ever before. We talk about what that means for our customers. But what does it mean for us? If it’s difficult to answer key, basic business questions today, how do we expect to do it in two–three years with more data than ever? We must take this sense of urgency and build capabilities that will scale and last as our volume, complexity, expectations, and user base continue to grow at an unprecedented rate.

Before we dive in, it’s important that we ground ourselves in basic definitions. During my first role in data management, we made the mistake of assuming that our stakeholders around the organization were aligned on what data we were referring to when we were discussing a particular domain of data. After several months of having difficult conversations on scope (if a particular data element, report, or system were in scope), we realized that we needed to go back and ground all stakeholders in a few very simple questions.

Data governance is the formal orchestration of people, processes, and technology by which an organization brings together the right data at the right time with the right controls to enable the company to drive efficient and effective business results. This formal orchestration should control, protect, deliver, and further enhance the value of data and create equity for an organization. Data governance is active and is delivered through capabilities, including the following:

• Metadata management
• Data lineage
• Data quality
• Data architecture
• Mastering data
• Data operations

We will explore these core capabilities, among other methods, in detail in subsequent chapters. The capabilities that make up a successful data governance program are defined slightly differently in just about every organization. Therefore, it is important that we define them here for the purposes of this book. Feel free to use the vocabulary in this text within your organization or the common language of your business.

Important note

Take the time to build a quick reference guide that defines the most basic terms used around your data governance program (e.g., data, governance, metadata, and so on). Make it accessible to the whole organization as a quick reference guide. Add to it as needed.

Data versus information

I want to point out that there is a passion for the use of data versus information terminology among industry veterans. Some practitioners are firm in their beliefs that these terms are not the same and should not be used interchangeably. Others use them synonymously without much thought. In my humble opinion, either can be appropriate for your organization. The important point is to distinguish between the two so that your organization understands the definitions and how to use them appropriately in your organization. Personally, I do not believe either position is correct or incorrect. It is far more important that you meet your stakeholders where they are and that your organization agrees on the alignment you choose to use. For the purpose of this book, I will use the term “data” primarily, and I will be sure to be specific about what that means.

Use case – financial services company

In my very first data governance position, we launched a robust and multi-million dollar transformation to comply with a regulatory requirement around data management and regulatory reporting. About six months into the effort, we found we were really struggling to define what was “in” vs. “out” of the scope of the program. After several curricular and passionate conversations, we learned that we were not able to scope well because, ultimately, our stakeholders had differing views about what constituted “data” vs. “metrics.” We ended up building a full-blown methodology to ground the company and our regulators on how we thought about the reports so as to be in scope, built a full list of all reports, and documented whether each one either met the criteria or did not meet the criteria, and this was to be available for a credible challenge to anyone or any group interested. Instead of debating it theoretically, we documented the criteria with specificity and then clearly articulated the justification.

What I learned in this experience was two-fold: you cannot make assumptions regarding what people know or don’t know when scoping a data program, and that you must have grounding definitions that can be socialized, agreed to, and documented so that all involved could remain grounded.

I’ll ask us to do the same throughout this book. Please come back to these definitions as needed so we can be aligned.

What data governance is not

Too often, companies have a tendency to blame problems on the data and/or the data team. Data governance (team or program) is not the solution to every problem. Data, like air, is everywhere in an organization, and it truly takes the entire organization to manage it well. Similar to the quality of air when a fire breaks out, poor data moves through an organization like smoke moves from a fire. The strong management of data requires prevention, detection, and correction, and to manage data well requires the entire company to be on board. A single data team cannot unilaterally solve every data problem. It will take the involvement and action of the organization at large to drive change and manage data effectively.

Secondly, data will never be perfect. If you or your executive team is expecting perfection from data governance, I would urge you to adjust your expectations. To ensure we align on what the appropriate expectations and objectives of a successful data governance program are, we must define success. To do that, we must start with the objective of data governance.

The objective of data governance – create business value

To put it simply, companies exist to increase value for stakeholders. When it comes to data, there is one very important objective of data to increase equity for stakeholders. Managing data effectively is one of the ways companies can increase value for their organization.

Figure 1.1 – A simple value equation

An asset is something of economic value that is owned by an organization. A liability is an obligation (either current or future) that decreases the overall value of the organization. Thus, when assets minus liabilities result in a positive value, the organization has an increase in value (i.e., has created equity), whereas when assets minus liabilities results in a negative value, the organization has a decrease in value (i.e., has reduced equity).

The same mindset can be applied to data. Data can impact equity in a number of ways. Equity can be created through addressing and minimizing operational risks by sustaining regulatory compliance, avoiding fines and penalties, and increasing or creating revenue. I break this concept down into two key subcomponents to manage data governance more specifically. These two subcomponents (assets and liabilities) are directly influenced by my formal training as an accountant and IT auditor, and this tends to resonate well with management when they translate data solutions into measurable value (ideally, monetary value, but may also consider the time value of employees).

Important note

Data is an asset when it creates value for the organization.

A few examples include:

• Curated datasets that are used for multiple purposes
• Customer health scoring
• An authorized provisioning point
• A data model used for predictive modeling

Important note

Data is a liability when it creates risk for the organization. Data can be both of these things but cannot be either (for example, a data solution may create value and reduce risk).

A few examples include:

• Non-cataloged data
• Data that has not been classified and, therefore, not appropriately secured
• Data leaks/breached data

Ideally, organizations should manage the liability of data while maximizing data as a strategic asset, such that data equity is created. Depending on your business and the maturity of your data governance practices, either asset management or liability management may be a bigger priority.

Data governance should create data equity by increasing the value of data as an asset and minimizing data liabilities. I encourage you to come back to this framing as you apply the principles in this book to your own organization. As you pitch data solutions, consider this:

How is this solution increasing the value of my data (increasing the asset) and/or decreasing the liability?

Both are of value. The momentum created by delivery should translate directly to an increase in data equity over time.

An example of a data asset might be a curated dataset that is reliable because it has clear ownership, is of high quality, and can be leveraged for multiple business purposes organization-wide. An example of a data liability might be as simple as an organization not knowing what data it has, where it lives, or what to do with it. This carries a risk to the company from a security perspective, but also, the lack of accountability means that individuals may be using the data inappropriately for decisions that it is not fit for, increasing the company’s risk of making a decision that it shouldn’t be based on data that were never intended to be used for that particular purpose.

The measurement of the value of an asset is unique to each organization, but in short, being able to tie back the impact to the organization is a good guiding principle. The following are a few example questions to consider as you attempt to value the data asset:

• Does this asset enable additional revenue? How much?
• Does this asset save time? Can you calculate the hours saved by an hourly rate for an individual to calculate the person-hours saved?
• Does this asset improve customer satisfaction? Can this satisfaction be translated or calculated into value for the organization in terms of additional spending or increased customer retention?

Figure 1.2 – Data assets, liabilities, and equity formula

Data assets may provide value across these components, and value should be calculated accordingly. The most important part of this valuation exercise is not the calculation itself; rather, it is the alignment and agreement with the business. Once you have calculated the value, it is important to go to the business and ask for their feedback. Do they agree with your assessment? If yes, then you have a fully vetted value for your data asset. If not, work with the business to iterate on your data asset valuation until you reach an agreement. If you skip this important step (vetting the value), data teams often are seen to be overselling their value to the organization. This immediately undermines your credibility in the organization. Agreeing on the value of the business supports a strong business relationship and provides credibility of past success when seeking future investment into data solutions.

The measure of the liability portion of the equation is of equal importance. Like data assets, the measurement of the liability carried by an organization’s data will vary based on your organization.

Important note

It is not as simple as more data equals more liability.

Rather, the less the data is managed, the higher the liability. When data is unmanaged, the risk to the organization is higher.

A great example is security risk. When an organization does not understand where data is, it cannot effectively or adequately protect it. This comes at a high risk (liability) to the organization and could result in a data leak or, worse, a data breach. Here are a few questions to consider when calculating your organization’s data liability:

• Do data liabilities increase the risk to the organization? How much? Are there fines or regulatory penalties we could be subjected to as a result of this liability?
• Does liability drive inefficiencies in our business? Can you calculate the hours incurred by an hourly rate for an individual to calculate the person-hours impacted due to the inefficiency (for example, a manual process vs. an automated one)?
• Does this liability impact customer satisfaction? Can this satisfaction be translated or calculated into a decrease in value for the organization in terms of additional spending or decreased customer attrition?

Once you have assessed your data asset value and data liability value, you can apply this to calculate data equity. The idea is to increase the equity over time. This initial calculation can serve as your baseline by which to calculate progress over time. Organizations also may like to leverage a data maturity model to measure progress; however, these models can be interpreted widely in an organization and do not take into account the business value associated with data solutions. Instead, they focus on the development of data capabilities, which do not always translate well for executive management. I prefer to focus on business value rather than an organization vs. a maturity model.

We will not dive into data monetization efforts in this book. The economics of the monetization of data is expertly described in Doug Laney’s book, Infonomics, and I would highly recommend his book to anyone looking to dive into the monetization of data further.

Now that we have classified data solutions into assets and liabilities and defined how to calculate value, let’s dive into the components in further detail. I prefer to group the components of data governance into building blocks. The reason I prefer this approach and have leveraged this framing in several companies is because it allows the organization to directly tie each building block to specific and straightforward outcomes. The first building block, policy and standards, is relatively basic and can be designed with a small team. This is a great place to get started in developing a data governance program.

Policy and standards

The purpose of this building block is to define data ownership and the structures needed to design accountability to manage your organization’s data as an asset. This building block will ensure effective, sustainable, and standardized data governance on which the company can depend. This building block is a prerequisite for future building blocks because it defines what is required to drive effective data governance and who needs to be involved. Additionally, the components of this building block can be created in a simplified way and can be expanded as the company matures in its data journey.

An easy place to start is to draft a simple and straightforward data governance policy. The purpose of a data governance policy is to tell the company what they need to do, why, and who is accountable.

The objectives of a strong data policy include the following:

• Establishing a single policy and set of standards for data management
• Establish the capabilities and data assets that are in scope for the policy and, in turn, for the office of the Chief Data and Analytics Officer
• Define the accountability and responsibilities for the implementation of the policy and the operationalization of data management capabilities
• Set minimum standards for data management, specifically for governance, quality, and meta- and master data management
• Define the procedures and usage requirements for tools to drive the consistent and robust adoption of minimum standards in a consistent manner
• Enable flexibility where appropriate to allow for ease of implementation where possible
• Define what is out of the scope of the policy

As with any policy, it is important to identify the owner of the data governance policy, who will be accountable for managing the policy by refreshing it at least annually, updating the content, and evangelizing it to the company. It is also the owner’s responsibility to ensure buy-in from key stakeholders across the company. Ideally, this owner would be a chief data officer, head of data governance, or similar role. If your company does not have a data leader in the role yet, another option would be a chief information officer, chief information security officer, chief privacy officer, or even a general council.

A policy does not need to be lengthy to be effective. Ideally, the policy would set forth the basics and would be supported by more specific and topically focused data standards. This approach often allows the policy to go through a more formalized corporate governance approval process while allowing for slightly easier updates to the data standards as your organization matures. I recommend implementing a data standard for each of the core capabilities addressed in Part 2 of this book, plus any specific to your business requires additional guidance for data stakeholders. Remember, the policy sets forth the minimum expectations for the company.

To get started in developing your data governance policy, a suggested data governance policy outline may contain the following:

1. Purpose and scope statement (for example, to transform how the company utilizes data by creating additional revenue streams and simultaneously reducing data risk)
2. The owner (for example, a Chief Data Officer)
3. Reviewers/contributors and titles (for example, Head of IT, COO, and data stewards)
4. Sign-off/approval (For example, CEO, CFO, and so on)
5. Data governance requirements
6. Roles and responsibilities for implementation
7. Feedback loops for improvements and/or additions
8. Measures of success
9. Compliance/audit expectations and frequency
10. Glossary of terms

Data governance policy example

The following is an example of an enterprise data governance policy:

Owner: Chief Data & Analytics Officer

Last Approval: 12/31/2023

Policy Leader: Head of Data Governance

Contributors:

• Head of Information Technology/CIO
• Head of Human Resources/CHRO
• Head of Marketing/CMO
• Head of Sales/CRO
• Product/Business Unit Leaders
• Product/Business Unit Data Stewards

Purpose and scope

This data management policy applies to all data held or processed by the company, which may include customer data, transactional data, financial information, regulatory and risk reporting, and any other data related to the business of the company. This data may be first-party data, derived data, or data acquired from another company (third-party data). The outcomes of this policy are the following:

• Reduce risk
• Unlock revenue opportunities
• Drive operational efficiencies

Introduction

The company is responsible for ensuring all data is accurate, complete, secure, and accessible only to those who require access to fulfill their job responsibilities. This policy sets for the requirements for the enterprise to deliver on the outcomes established above.

Data governance

Data governance establishes the requirements and standards for all corporate data deemed “in scope” of this policy in the aforementioned policy and scoping section. The purpose of the data governance capabilities established within this policy are to drive enhanced transparency and accountability for our company’s data and to drive improved consistency, control, and oversight for how data is managed, stored, and used going forward.

Roles and responsibilities

1. Enterprise Data Committee: An Enterprise Data Committee will be established, chaired by the Chief Data & Analytics Officer, to provide an oversight and prioritization body to manage data and analytics initiatives and issue remediation enterprise-wide. A Data Domain Executive will be required to sit on this committee to ensure appropriate prioritization across all data domains.
2. The Chief Information Officer will partner with the Chief Data & Analytics Officer to ensure technical requirements and systems are provided in support of the data and analytical needs of the organization, both for the Office of the Chief Data & Analytics Officer, but also for all functional data domains enterprise-wide.
3. A Data Domain Executive will be established for each functional area to ensure the appropriate focus, funding, and resourcing is established and maintained to manage data in accordance with both this policy and the needs of the business.
4. Data Stewards will be assigned by each Data Domain Executive to ensure the day-to-day execution of data requirements is completed in accordance with policy and the needs of the business. Data Stewards will also be required to work with the Office of the Chief Data & Analytics Officer to ensure that transparency of progress and ongoing operational effectiveness is maintained for leadership, regulators, and across domains.

Requirements

This section provides the minimum expectations for compliance.

Data Governance

Each data domain will develop a plan to drive compliance with this policy to operationalize the requirements within their data domain. The Data Domain Executive will ensure appropriate prioritization, whereas the Data Stewards will execute the plan on behalf of the Data Domain Executive. Additionally, Technical Data Stewards will support the delivery of all technical requirements to ensure compliance with this policy and the broader needs of the business. The minimum requirements are the following:

1. Identify all data assets and systems
2. Identify all data and technical data stewards for each asset and system
3. Assign each asset and system to the appropriate data domain
4. Develop a plan to meet the requirements for each asset and system and maintain compliance going forward

Data Cataloging

The purpose of data cataloging is to centrally manage and publish business and technical metadata across the organization to enable accelerated discovery of the data available across the organization in a clear, transparent manner. As data cataloging is implemented, the Chief Data & Analytics Office will evaluate metadata to determine the best source of truth for a given data asset and identify opportunities to reduce proliferation and redundancy across the company. This will further simplify our data ecosystem over time and reduce the costs of duplicate data handling/management and storage. The minimum requirements to be published in the Enterprise Data Catalog are the following:

1. Description of the data asset/system
2. Technical metadata
3. Description of schemas and tables
4. Identification of critical data elements (CDEs)
5. Business definitions for CDEs
6. Data classification for all data elements within the asset/system in accordance with the company data classification policy

Data Quality

The purpose of data quality is to ensure the data is fit for use. The following requirements have been set forth with the aim to centrally develop data quality rules, provide profiling resources and tooling, and monitor data hygiene to ensure the data can be trusted for analytical and business use and identify issues requiring disclosure and/or remediation. The minimum requirements are the following:

1. Define the data quality rules for each CDE and enter this into the enterprise data quality tool
2. Enable CDEs for data quality monitoring
3. Provide data quality dashboards to transparently report on current quality levels
4. Identify data quality issues and create plans to address material data quality issues

Policy Management

• Feedback Loops: Feedback about the policy and/or questions about policy implementation should be directed to the Policy Leader defined above.
• Measures of Success: A robust Enterprise data governance scorecard will be established for each data domain and at the corporate level. Periodic reporting of the progress of complying with this policy will be reported to the Office of the Chief Data & Analytics Officer and to the Enterprise Data Committee. Further measures of success may be required.
• Compliance/Audit: Internal audits, external audits, and regulatory bodies may audit this policy for compliance on a regular basis. All requests for audit should be disclosed to the Office of the Chief Data & Analytics Officer so that requests can be co-ordinated and driven through the Enterprise Data Committee.
• Frequency: This policy will be reviewed, updated, and re-approved at least annually.

Now that we’ve reviewed what makes up a great policy, let’s pivot into the key roles and responsibilities for a data governance program.

Roles and responsibilities

Any data governance expert will tell you that people are the key to a successful data governance program. People are responsible for caring for the data and ensuring its accuracy, that it is fit for use, and how to improve it to make it better. This concept is called data stewardship. Data stewardship requires collaboration to drive success. The executive identified for each data domain appoints a data steward to drive day-to-day activities for the data domain.

The key responsibilities of data stewards include the following:

• Serve as the single point of leadership for their data domain
• Ensure the data domain executive is kept informed on key activities
• Ensure the funding necessary for adequate data management is secured and allocated properly to data management activities
• Collect data requirements for the data domain and execute the data management requirements across the data domain

The key responsibilities of the office of the Chief Data and Analytics Officer include the following:

• Define data policy, publish the policy, and review for updates at least annually
• Lead data domain executives and data stewards through requirements, ensuring a comprehensive understanding
• Provide data tooling to drive the enterprise-wide enablement of data management
• Streamline, to the extent possible, compliance with the policy
• Report regularly to the executive team and, when required, to regulators and the board of directors

Important note

One of the hardest parts of data governance is gaining the collaboration required to drive the outcomes the organization needs to leverage its data for results.

In every company I have worked in, the intention was almost always good: the people wanted to collaborate. Data governance experts wanted to collaborate to drive success; however, competing priorities, a lack of a clear vision, and difficulty measuring the impact of a data governance program often led to data stewardship being deprioritized. Ultimately, organizations that drive successful data governance initiatives recognize the importance of good data governance and that it is more than just understanding records, fields, and tables. They recognize that it is more than just building another data warehouse. They recognize that people are the center of success and that identifying the individuals responsible and accountable for strong data is the cornerstone of any data governance program.

For data to be good, stewards must be good. Good stewards take accountability for their data’s quality, access, and overall management. The best data stewards I have worked with ensure the buy-in of the business users is achieved in every step of the governance process because the goal of data governance is not just clean data; it’s enabling the users of the data to confidently and easily use data in pursuit of their business objectives.

Let’s compare two examples to illustrate this:

• Example 1: A business user, person A, needs data X to report to a regulator. In a well-governed data environment, person A goes to the enterprise data catalog, where person A can search for data X. Person A finds the metric they need to report to the regulator, but they have a few questions. In the catalog, person B is identified as the data steward. Person A can reach out to person B to ask questions and learn more about data X to confirm it is the appropriate metric to share with the regulator.
• Example 2: Here is a company with little to no data governance. A business User, person A, needs to get data X for the regulator, but does not know where to start. There is no catalog for the data, so they ask the person they think might know about the data, person C. Person C suggests person A calls person D. Person A calls person D, and so on. Days or even months go by, and person A does not feel confident they have the right information for the regulator but provides the best information they know of. Ultimately, the regulator does not have confidence in the data because person A does not have confidence in the data.

Often, aligning data stewards in an organization is easier said than done. One of the easiest approaches to getting started is to begin at the executive level. I refer to these individuals as data domain executives. These are the individuals who are ultimately accountable for the data their division of the organization is accountable for. An example would be a Chief People Officer (CPO) being assigned the data domain executive for human resources data. This would make the CHRO ultimately accountable for human resources data. The CPO would delegate the day-to-day activities to their data steward, who would be responsible for ensuring human resources data is managed according to data governance policy and standards.

As a part of your data governance program, one of the first activities should be to identify the data domain executive for the organization. In my experience, defining the logical types of data into data domains and assigning a data domain executive is the best place to start. Upon defining the data domains and data domain executive, you will have the executives responsible for the data of the entire organization named. These individuals should make up your sponsors, and should you choose to start an enterprise data committee or council, they should become your voting members:

Figure 1.3 – Identification of data domain executives and data/technical data stewards

Depending on the size of your organization, you may have a third key role in the business side of data management. For larger organizations, you may consider establishing a more senior-level person to be a data domain manager. This person would have the role of the data steward, as described in the preceding section, and would likely have a 1:M relationship with data stewards who either report to them or have a dotted-line relationship with the business. In one organization I worked for, we had a data domain manager for the division of the organization, and for each sub-group, a data steward was defined. It looked like this:

Figure 1.4 – Example of data domain appointments

Governance forums

An enterprise data committee is an effective way to align an organization around a data strategy and a data governance program, and it serves as a prioritization and escalation body. Each data domain executive who participates in the committee should assign a data steward to drive activities within their data domain. Often, organizations establish sub-groups (e.g., human resources data councils or human resources data working groups) to carry out the implementation and ongoing governance of the respective domain. This allows data governance activities to be implemented more deeply within the organization. The Chief Data Officer (or equivalent) should chair this committee and be responsible and accountable for managing the agenda, cadence, and facilitation, as well as reporting progress upward in the organization to the C-suite and the board of directors.

Figure 1.5 – Example of how various data governance forums work together

Important note

If you notice that the enterprise data committee is delegated below the data domain executive, you may have a problem. Having someone delegate once may not be of concern (e.g., for vacation); however, if you start to see a pattern, either by a particular domain or across the board, it is a signal that your committee is not providing value. Quickly reach out to the data domain executive and seek to understand what is driving the delegation. Simply ask, “I noticed that you have delegated the last few EDC meetings to someone on your team. Is there anything I can do to make the meeting more engaging for you? Your perspective is critical for the whole committee, and I want to make sure it’s a valuable use of your time.”

There are other key roles that may play a part in your data governance program, including BU stakeholders (often users of data) and the information technology team. We will dig deeper into the metadata chapter in Part 2, but for now, I also included the IT application owner in the preceding diagram (see IT). In any program, an IT application owner plays a key role in the success of a data governance program. The IT application owner is the individual responsible for the technical implementation of any data governance requirements set forth by the enterprise data governance policy and by the data domain executive or their delegate. We will get deeper into operating models in Chapter 3.

Reporting on governance progress

Ideally, as implementation progresses, the enterprise data committee should receive ongoing reporting to demonstrate improvements in data governance. One way to report this information is through the use of an enterprise data governance scorecard (EDG Scorecard). The EDG Scorecard should provide a transparent status of how well the company is doing in implementing data governance capabilities and how well this remains implemented post-implementation. Ultimately, the EDG Scorecard should communicate to its users how the company is doing in terms of making data easier to find, understand, and, ultimately, trust.

Before trying to design and implement the EDG Scorecard for the entire company, I recommend selecting one data domain to pilot this process. I prefer to start with a data domain that has at least slightly more mature data governance practices than other domains. One data domain that tends to be a bit more mature in most organizations is finance and/or regulatory reporting. By piloting a data domain, the other data domain executives, who make up the enterprise data committee, get a sense of what an EDG Scorecard looks like and how they should be implementing it for their respective data domain.

Sample implementation metrics

Metrics should be defined to measure the implementation of the data management policy as well as the operational effectiveness of capabilities on an ongoing basis. To measure the implementation of the policy across domains, each domain should measure progress and report that progress to the office of the chief data & analytics officer on a regular basis (bi-weekly, monthly, or quarterly, based on your organizational expectations).

Examples for the office of the Chief Data and Analytics Officer include the following:

• The total number of data domains (this becomes the denominator for the following metrics)
• The number of domains with an identified/confirmed data domain executive
• The number of domains with identified/confirmed data stewards(s)
• The number of domains with systems of record identified
• The number of domains with systems of record assigned to system owners
• The number of domains with critical data elements identified for each system of record
• The number of domains with data quality rules written and executed for each system of record
• The number of domains with business glossaries established for each system of record
• The number of domains with data dictionaries established for each system of record
• The number of domains with reference data adopted for each system of record

Use case

A large multinational company has seven business units and four corporate functions. A chief data & analytics office was established to advance the use of data, analytics, and AI. As a part of the office’s first-year strategy, the CDAO organized a team focused on data management maturity. With this focus, the head of enterprise data governance was tasked with the formal development of a data policy and a scorecard to track the implementation thereof.

The head of enterprise data governance developed an enterprise data policy to establish expectations for the organization and defined the key roles and responsibilities to drive compliance with the policy. The team identified 12 data domains: one for each of the seven business units, one for financial data, one for risk data, one for marketing data, one for employee/HR data, and one for master and reference data, which is owned by the CDAO.

To track the implementation progress across the 12 domains identified, the following scorecard was developed for the office of the chief data & analytics officer. This report is updated bi-weekly and reported to the executive team, the data domain executives, and the data stewards, and it is reviewed in the enterprise data committee meetings on a monthly basis.

Figure 1.6 – Example of a data governance scorecard for the chief data and analytics office

Examples of the data domains/data stewards include the following:

• The total number of system of records assigned to the data domain (this becomes the denominator for the following metrics)
• The number of system of records with critical data elements identified
• The number of system of records with data quality rules written and executed
• The number of system of records with business glossaries established
• The number of system of records with data dictionaries established
• The number of system of records with reference data adopted

Each data domain should track its own respective metrics and submit the report to the office of the Chief Data and Analytics Officer on a bi-weekly basis.

Figure 1.7 – Example of a data governance scorecard for a data domain

Related teams and capabilities needed for success

No data team will function alone. To be successful in implementation, partnership is the most valuable skill at your disposal. There are a series of key functions that you will need to build strong and sustainable relationships with. First, the business functions. You must build trust with each business function you support. This begins and ends with deep listening. Deep listening requires you to listen with the sole purpose of learning. You are listening to learn not to respond. Your business function leaders will provide you with their needs. It is your job to listen and be able to take their needs back to your data team to inform and build out the data strategy. Trust will be earned as you deliver against their needs. Initially, hearing them out, regardless of their past experiences with data, is the most important place to start.

Information technology

Your company’s information technology team (IT team), led by a chief information officer (CIO), will likely support your success by delivering the infrastructure (at minimum) to support your team’s data solutions. The relationship you build with your CIO and their key leaders is critical to your success. I’ve found the quality of the relationship between CDO and CIO to be one of the most powerful indicators of a CDO’s success. In cases where the CDO and CIO have a high-functioning and trusting relationship, I have witnessed success for both leaders. In cases where the relationship is not high-functioning or, at worst, competitive, the success of both leaders is hindered.

Information security

Additionally, with the rise and formalization of the role of the CISO and the increasing threat landscape across all industries, the importance of the CISO has never been higher. One of the core tenants of the liability side of the data equity equation is the protection of your company’s data. This shows up in data security, of course, but also spans and tightly connects with technical metadata management. In short, you cannot protect data if you don’t know where it is. Technical metadata is a critical enabler that supports an understanding of what data you have, where it is stored, where it moves, how to classify it, and then what controls are needed to properly protect and secure it. We will cover more about this topic in Chapters 6 and 7. As a data leader, this capability will enable the success of your CISO, and therefore, I suggest you engage early and often with them throughout your data governance implementation.

Chief financial officer

As you work through building relationships and, ultimately, building out a stakeholder list, I encourage you to think of both business functions and corporate functions. Your stakeholders should include the CIO and CISO, as mentioned in the preceding section, as well as the CFO, head of privacy, general council, human resources, and operations, in addition to business functions. If you work in the technology field, product and engineering leaders are critical, whereas in financial services, groups such as risk management and regulators may be relevant. The point is to look at the company at large, including all the stewards and users of data, and identify the key leaders you need to work with to partner effectively. Most data leaders who do not succeed in their role fail because they fail to build relationships and/or fail to build trust through value creation.

Human resources

Your human resources leader will be a key stakeholder and strategic partner in helping you design your organization and develop a hiring, training, and retention strategy for talent management.

Privacy and legal

Privacy and legal teams will be key drivers for many of the capabilities your team will enable. For example, while the legal team should define data retention standards and the privacy team should define the types of information classification (private or company confidential, for example), it is your team’s responsibility to implement the capabilities to discover, inventory, and auto-classify the data in accordance with these policies. Regulations such as GDPR or CCPA drive much of this work across industries, but other industries have special considerations, such as BCBS 239 or HIPPA. Be sure to work with your legal and privacy teams to find the right relations to follow.

Additionally, be mindful that emerging state regulations are coming quickly. At the time of this writing, the State of Iowa was the most recent state in the US to release a privacy law. It will go into effect January 2025.

As you are starting to formulate your vision for the future, it is important you take into account all the input you receive from the stakeholders you interact with. As we work toward building your business case, building a coalition of support, and building a team throughout the next few chapters, it is important to note that no two companies will have a consistent message or vision for success. You will need to address each opportunity with fresh eyes. Despite having led data transformations in three Fortune 500 companies, each data strategy I have had the opportunity to lead has required a unique perspective. Companies are on their own journey to excellence, and even the most established firms have work to do to improve their data governance capabilities. You must assess each situation from this perspective, or you will risk applying the wrong strategy to the situation before you start.

Who to meet with

As you prepare to customize your vision for the company, build your list of stakeholders thoughtfully, as introduced in the preceding section:

1. What are the business divisions?
2. Who leads each division? Do they have a chief of staff or chief operating officer you should meet with also?
3. What corporate functions do the stakeholders have? Who leads each one?
4. How does funding get disbursed in an organization? Seek to understand the process and who influences the release of funds.

All of the individuals you list out in response to the preceding questions become key individuals to meet as you prepare your vision, your business case, and begin to socialize your vision. Many of these individuals may become data domain executives in the future.

Figure 1.8 – Example alignment of domain model with corporate organizational chart

Important note

CDAO, CPO, CMO, and so on will also have domain managers, data stewards, and technical stewards aligned with them.

During your first interaction, simply listen to what their business priorities are. This is not the time for a solution. You are gathering facts and opinions from them so that you can use that as input to your future vision. Take copious notes. Before ending the meeting, ask for a follow-up in 4–6 weeks, where you will bring forward the mission, vision, and objectives for your team from their input and feedback.

Important note

In your organization, your data domain executives should be no more than your CEO-1 or CEO-2. No matter how large your organization is (50 or 500,000), if your data domain executive is too far from the top of the organization, your program will dilute. You must create a value proposition that clearly defines why the senior leaders must drive this body of work together. If it is pushed too far down in your organization, you will risk losing the prioritization, funding, and focus of your C-suite. Ideally, the individuals reporting to the CEO would be your data domain executives. In larger organizations (i.e., 50,000 or more employees), a CEO minus two may be appropriate.

Crafting a powerful why statement

A powerful vision statement is not exclusively for the chief data & analytics office but for the data and analytics capabilities of the company as a whole. When drafting the vision statement, be clear and concise about your aspirations and goals for the future use of data and analytics for the company. Consider the following:

1. What is it you aspire to do?
2. Who will help you achieve it?
3. How will you know when you’ve arrived?

A powerful vision statement should be clear, concise, and easy to understand and communicate. It should be to the point, and jargon should not be used (no “data speak”). The statement should be focused on the future, inspirational, and aspirational, bringing all stakeholders together to work towards this imagined future together. Make it easy, short, and memorable. It should be able to be committed to memory easily. While being future-focused, it should be achievable and in alignment with the company’s values.

Important note

Let’s consider an example. Perhaps you are the new Chief Data and Analytics Officer at a leading insurance company. You might craft a vision statement such as:

Insights are embedded in the flow of business with highly trusted, relevant, and curated data at the speed of our need to proactively wow our customers with delightful and meaningful moments that matter. We trust our data, and our customers trust us.

Customizing the message

As you craft your vision statement, bring it with you to your one-on-one meetings with the leaders you identified and met with. Share it with them individually, and ask for their feedback:

• Does it make sense for the company’s strategic direction?
• Is it visionary?
• Will it inspire your team members and drive meaningful focus to the future?
• Is it meaningful for your needs?
• What would you change?

Listen and incorporate feedback as you review with these individuals. The degree to which you remain open-minded and take into account their input will directly impact their buy-in. This does not mean you must incorporate each iota of input, but you should consider it thoughtfully and loop back with each individual, thanking them for their support and explaining what you changed, what you didn’t, and why. It is critical to close the loop with any changes you did not make, carefully explaining why they didn’t make the cut. This transparency will build trust with your stakeholders, which you can build upon over time.

After you have revised and have finalized your vision statement, it is time to bring it forward for final approval. I suggest you incorporate an approval in your enterprise data committee meeting to further establish that the vision is not just that of the chief data & analytics office, but of the entire company. By involving the company in this exercise, you are setting a precedent that data is part of everyone’s responsibility, although the CD&AO is ultimately accountable.

Before you can dive into building out the data governance business case, you must understand the business outcomes the company is driving. In order to draft data objectives, you need to first understand the entire company strategy. If you don’t have it already, request a copy of the company strategy. Ask questions to understand it fully. Then, work with your data domain executives to understand both their priorities and how their business unit or corporate function is delivering upon the company strategy. What outcomes are they required to achieve to create the value the company requires? Ultimately, the definition of these outcomes will support the wider company strategy and lead to business outcomes that are highly relevant and critical to the success of your organization.

The point is that you must define a path that clearly demonstrates how data and analytics will power your company and not slow it down. Often, when individuals hear the word “governance,” they equate it to bureaucracy, friction, and slowing down progress. You must show how what you and your team will do will add value and enable the business and to do so without a negative impact on progress. It’s critical that you define a mission and clear objectives that demonstrate this point clearly.

The mission of the chief data and analytics office

The purpose of the chief data and analytics office is to drive the business outcomes needed with data and analytics solutions. It is not to sit on the side of business; rather, it is to achieve the organizational outcomes by serving this with the business. It is an accelerant to results. Success is determined by business outcomes, and thus, the chief data & analytics office must define its mission as such. Start by defining what your team is to do in business. It may contain guiding principles such as the following:

• Inspire enterprise thinking
• Deliver business outcomes powered by insights
• Define and implement the delivery model for common data and analytic solutions
• Curate solutions that embed insights when and where the business needs it
• Ensure business is executed with governance by design, which is embedded in the processes
• Drive operational efficiencies through automation
• Create revenue streams or speed revenue generation cycles
• Reduce risk and remediate compliance issues

Ultimately, you and your team should craft a powerful mission statement that encompasses the full suite of your service to and with the company. Think about the question, What is our intention?

Important note

Let’s consider a couple of example mission statements:

• Empower the company with timely, trustworthy, and relevant insights to drive revenue to USD 1B and beyond.
• The chief data and analytics office will unlock revenue, drive efficiency, and reduce regulatory compliance risk for Bank XYZ.

The mission of the data governance program

Once you have defined the mission of the chief data & analytics office, you must next define the mission of your data governance program. Your data governance program will need to take into consideration what problems you need to solve for your company and how you intend to solve them. This program should be an enabler and collaborator in solving problems for the company in a way that serves their broad interests. It can be as simple as the following:

We do X for Y by doing A, B, and C.

“We deliver enterprise-wide data governance capabilities for all corporate functions by enabling governance by design in our platforms, powering data management solutions, and delivering trusted, curated data solutions when it matters.”

Determine the projects, programs, and budgets needed to enable the enterprise activities required for delivery against the company data and analytics strategy. As we go through Part 2 of this book and dive deeper into each data governance capability, think about where you are with your company. Do these capabilities exist? To what degree? What gaps are you seeing? These gaps become your programs, projects, and deliverables. I suggest you come back to this section as we baseline your organization in Chapter 4.

As you are meeting with the stakeholders you identified in the preceding sections and iterating on feedback regarding your vision statement, it is a perfect time to ask your stakeholders about what is working well, what could be improved, their priorities for the coming year(s), and some of the burning challenges their team is facing. I’ve often found that asking key leaders across a company open-ended questions and deeply listening to their experiences is fruitful when it comes to identifying opportunities to help drive value for them from data governance.

For example, if a stakeholder tells you that they are having a difficult time in the board of directors meetings because the CEO is always questioning their data, you may have an opportunity to help them. Spending time unpacking the reporting process, the metrics on the reports, the definition of the metrics, how they are calculated, where they are sourced from, and the quality of the underlying data itself may expose that there are problems with the reporting going to the board. Conversely, this exercise may prove the data is accurate, and now the stakeholder is armed with strong backing from you, the leader of the data organization, to attest to the accuracy of the reporting. Often, the data is guilty until proven otherwise. It is your great privilege to support your stakeholder in providing reliable and highly trusted data to deliver their results to the board. Treat the experience accordingly.

No matter what your stakeholders tell you, the importance of these conversations is to listen. Very rarely are stakeholders going to tell you that they need better governance, or they need stronger technical metadata, or for a team to come in and profile their data more frequently. They are not going to speak to you in these data terms. What they will say is no one trusts the reporting, or I can’t get what I need when I need it. They are giving you the symptoms. It’s your job to identify the root cause to diagnose the problem and fix the underlying issue: data governance.

As you are executing these deep-listening sessions and learning about the challenges your colleagues are facing, start to identify common themes. It’s helpful to keep detailed and organized notes that you can easily refer back to, but that also can begin to group like problems together. Pulling on the preceding example, perhaps you hear from a number of stakeholders that there is inconsistency in reporting where the results sound similar, but the numbers are actually different. The executive team is now calling the data and the leader into question. You now know one of the components of your data governance business case is going to be centered around key metric alignment for the executive team. You will need strong metadata capabilities (Chapter 6) and data quality (Chapter 8) to help you, along with strong reporting and/or data analysts to help drive this alignment. Most importantly, you need to bring people together and drive consistency.

As you are preparing to write your business case, your listening sessions will produce themes, and you will center your delivery around the strategic implementation of capabilities and iterative delivery (sometimes referred to as quick wins) to show progress throughout the delivery. As you build your business case, be sure to highlight what your building blocks will be (that is, the components in Part 2 of this book) and the iterative delivery you will enact to drive impact along the strategic journey. As you iteratively deliver for your data domain executive in alignment with the themes you’ve identified, you will turn challenges into wins, naysayers into advocates, and you will become the trusted advisor the company needs to deliver excellent data governance for the company at large.

As you start to build out the business case, which you will do iteratively as we work through this book, there is some good news: you have already made progress. The preceding items are key components of your business case. You will need to include the following:

• Your company’s strategic vision and objectives
• Your team’s mission statement
• Your data governance program mission statement
• Your powerful objectives

From here, you can start to frame out the programs you’ll need to launch for your business case. At this point, you won’t know what most of them are; however, you may have already begun to identify thematic issues or problems through your stakeholder listening sessions. Perhaps you already know your company does not have a data catalog or a way to measure data quality with transparency. You can start to plot out the capabilities you will need to deliver as “Programs.”

I prefer to use a memo format to define a business case. The six-page memo is a strong format for delivering depth of content without losing your audience. Some companies pitch by using slides. You will need to determine which format is best for your company’s culture. No matter how you decide to pitch, writing a memo is a good exercise to ensure your thoughts are solid going into the business case process. Ultimately, how well you write your business case will determine your degree of buy-in from stakeholders and your degree of funding. An example template for a business case may look something like the following:

Figure 1.9 – Business case template

I suggest you put together this framing now, and as we go through the remainder of the book, fill in the business case for what you need for your company. As you gather information from meetings with your stakeholders, make notes and start to build your business case over time.

The fact that you have picked up this book and are working through it is a huge step on your journey. Continue to read, chapter by chapter, and execute the steps as we go. You can move as quickly or slowly as you need to in order to go at the pace you need at your respective company. Use this as a reference, a guide, and most importantly, the framework for how to deliver strong data governance at scale. Before we move into the next phases, it’s important to discuss a final constraint: when and when not to launch your program.

While a data governance program could be launched at any time, successful programs tend to precisely time their launch aligned with other adjacent business programs and ensure the impact is very clearly defined for the executive team, not just in the individual program, but as a suite of transformations. If management does not have a strong need, is not fully bought in, or is too distracted (for example, in the middle of a large merger or acquisition), you will not have a successful program launch. Said another way, timing matters.

Take the time you need to understand your business, the challenges, politics, and the other key strategic transformational programs in flight or about to launch. Align with your peers on any business functions and operations to ensure you have buy-in. Then, plan your launch. If you do not get this timing right, you will need to restart your program, and in my experience, that is a very difficult process, usually requiring a new leader.

Why you should launch now

There are a handful of reasons that lead to an organization’s investment in data governance. There’s no perfect time, but there are some common reasons:

• Regulatory: There are a number of regulatory reasons that may drive your company to implement a data governance program. In financial services, for example, large global systemically important banks (known as GSIBs) were required to comply with BCBS 239, which drove an earlier focus on data governance for risk reporting.
• Crisis: Data breaches are another common driver for data governance programs. This is especially true when companies do not have a good handle on where all their data is, how it’s classified, and/or are not confident they have properly secured it (you can’t secure what you don’t know about).
• Executive request: The C-suite has come to understand that they need more from data, and they are willing to fund a transformation to enable you to deliver against their needs.
• Business request: There is a critical and visible business need that is well-defined and funded.
• Experimental: The company wants to explore data capabilities and has set aside a funding pool to support experimentation in this space. You have the remit to use this funding to demonstrate the power of the possible.

Why you might want to wait

Finally, the willingness of executive management to celebrate quick, iterative wins that align around a long-term roadmap with adequate funding is critical. The program is not going to be successful overnight, and you must align with the fact that a long-term, sustainable, and data-centric culture requires iterative and ongoing investment and support. Ultimately, if the company does not understand what it wants and/or is not prepared to fund appropriately, you should not proceed in launching a wide-scale transformation to establish strong data governance. Here are some warning signs to watch for:

• Executive Request: The C-suite has come to understand they need more from data, but they do not understand what it will take to transform and get what you need to be a success
• Business Request: The business has a critical need, but they do not have it well defined, and there is no funding set aside for delivery
• Experimental: The company wants to explore capabilities but is unaware of what it will take to drive results
• Undefined: The company wants to establish a data and analytics function but does not follow through with forming a complete function

The company cannot ever finish the job of data transformation. It is like exercise. Just like you can’t get in shape for one race and then claim you have become in shape for life and go back to sitting on the couch and expect to maintain the results. Take the time to secure support and funding for the program upfront. Your success and the company’s success depend on it.

How to build your delivery timeline

Once you have built the framing for your business case and you have decided what capabilities you need, you should come up with some options for a timeline and funding. I find it’s best to put forward three options for management so you can have a healthy discussion about what to do, how fast to do it, and how much the company is willing to spend to deliver.

Option #1 – Your preferred timeline

Start to build your optimal timeline. If what you need to deliver is up to you, and you can obtain adequate funding to do the work at a pace you feel is appropriate, what is that timeline? When will you release new capabilities? What will the company be able to do at each release?

Option #2 – Fast and expensive

Build an option that delivers more rapidly but likely has an increase in resourcing (the funding, headcount, or consultants’ involvement). This option gives a faster time to value but comes with the balance of an increase in costs.

Option #3 – Slow and cheaper

Finally, build an option that takes longer but will cost less. In my experience, this is often the option that is thrown out right away by executives. Once they decide to move forward with data, they want to see results. Having this option on the table demonstrates that you were thoughtful and considered all options, and although they are not your preference, you considered the expectations of others.

You may also find that a combination of the options is created out of these review discussions. Be open minded. If management is putting forth their time and energy to review these options with you, this is a good sign. Listen to their feedback and be willing to come back with alternatives. Ultimately, you are aiming to receive support and funding; the more flexible you can be, the more likely you are to gain support.

You now have all the framing and background you need to build your data governance program and start to put your business case together. As we explore the next several chapters, we will go deeper into each topical area, which will give you the detail needed to design a powerful data governance program that delivers excellent results for your organization.

Beginning a journey to establish data governance transformation in your organization doesn’t have to be difficult. It can take time, and requires support, but you can establish a strong data governance function for your organization. There are a few key steps that you should focus on as you embark on this journey, starting with identifying a data governance leader to own and sponsor data governance for your company, which will establish authority over the data governance function. You will also need to define what data governance means in the context of your company, through publishing a data governance policy (and standards, if needed). By carrying forward that policy implementation through establishing clear owners (e.g., data domain executives), establishing appropriate councils and committees, and writing a strong business case.

As you proceed through the chapters of this book, I will walk you through how to drive data governance into the ethos of your company, first, by establishing a coalition of advocates. In Chapter 2, I will begin by explaining why a coalition matters, how to assess possible supporters, and how to gather broad support.

• https://www.forbes.com/sites/bernardmarr/2018/05/21/how-much-data-do-we-create-every-day-the-mind-blowing-stats-everyone-should-read/?sh=302772a160ba
• https://medium.com/callforcode/the-amount-of-data-in-the-world-doubles-every-two-years-3c0be9263eb1