5 Biggest mistakes in Data Governance Program Execution & how to avoid them

Those who followed my Data Governance 101 6-part series, ask me a multitude of scope questions about how to set up their data governance programs.

Several times, I get startling questions, sometimes naive, sometimes overthinking the application of various industry tools and methodologies.

Given the lack of quality practitioners in the industry (Financial Services, or otherwise), it is not surprising to hear those, I figured I will share some of my insights.

I won’t regurgitate the foundations from my past series, but rather I would focus on major program-level mistakes that are tough to “take back” if you happen to be leading one of these large programs or a stakeholder.

In this era where the tug of war is between data privacy and data monetization (product view), it is critical to underpin the data management activities with proper data governance.

From a nomenclature point of view, I would like to highlight the often misused and interchanged words, data management vs data governance. This is a decent summary.

What is data governance, anyway? It might actually be worth reading what other consortiums defined it as, a quick glossary here by Mr. Firican.

1. Control Framework — a.k.a. method to the madness

This the “how” of data governance, most large enterprises, stumble here and generally work out the differences 2nd or 3rd time.

The majority of the programs fail to sustain funding and trust because they have chosen a complete top-down model (“CDO driven”) or a complete bottom-up model (“Technology-driven”).

How to avoid this mistake?

Like many other enterprise capabilities, e.g., IT, Operations, Data capabilities should be supported top-down and executed bottom-up. CDO, Enterprise Data Architects, COO, should support policies, best practices, mandated tools, and a centralized support structure.

Each Line of Business teams or Geographically organized teams, should prioritize in an agile fashion, their data governance content (e.g., data quality, metadata) for their purposes leveraging the central tenants.

2. Scope

Any framework you pick, Any BoK (Book of Knowlege, you pick up for Data Governance), the best advice here is to apply common sense. Do not apply the methodology as-is.

Try to explain to yourself why you would personally spend 10 hours doing it? What would be the value to your customer, a regulator, and a business line (note, and, not or)?

There are 3 areas where the scope is managed ineffectively, if it all, it is even defined properly, on what areas to govern and write policies and procedures about.

Organizations under-invest in a good classification of their data “the business domain” and categorization “The taxonomy” of products, services, data associated with their daily business use.

Organizations over-invest without any clear requirements, on “most often-heard” parts of data governance control functions — Data Quality and Data Lineage.

Examples here are — Conduct a profiling and quality assessment of every single interface, data feed, element, that is stored in their Enterprise Data Warehouse. Create a data lineage program so complex, that it is cheaper to build the data interfaces than to manage/build data lineage of the data interfaces.

Whilst, if a regulator comes in and asks, where are all the customer PII data attributes are sitting and what are you doing with it? who owns it? How is its use controlled? People seldom have a comprehensive answer.

In my opinion, 80% of work done by large organizations in this space is a waste of time/effort/money.

How to avoid this mistake?

Like any other capability, deliver value in increments, understand policies, implement procedures, and have Technology build only what’s needed?

Approaches here are Critical Data Elements (CDEs), Business-driven Data Quality rule implementation, Level 0/1 lineage, and associated stewardship.

3. Operationalization

Another challenge, I often data governance teams’ run into is, how to operationalize data governance? EDM Council refers to this as an aspect of “Sustained funding”.

Data Quality programs are not “once and done” — You could get a data quality issue any time OR a new issue you never came across, when you change a market data vendor, for example. You could be delivering an incorrect report.

How to avoid this mistake?

Implement what I call, “Integrated Functional Model” of Data Governance into large organizations.

Integrate Data Governance principles into your Product lifecycle (like SDLC) and assign roles in your organization (Steward, Custodian) that manage procedural compliance in “Change Mode” and “Business As Usual (BAU) Mode”. From Architecture Review Boards to Operations Technology.

4. Measuring Progress

If you ask an average consumer, who has better data governance, Apple or Alphabet? I would assume the overwhelming response would be Apple.

But, would you be able to respond with similar confidence, the corporations you do business with or you are a customer of? Would you even know? It is becoming increasingly important to align data governance as a board mandate. You can read some background material here and here.

How to avoid this mistake?

Implement Data Governance KPIs at the central and line of business level and incorporate yearly OKRs to drive the KPIs.

5. Value Add

This is not at all done, in my experience, so there won’t be examples of mistakes I could point to, but, here is to avoid this mistake:

A proper fit-for-purpose data governance program, not only gets sustained business funding, it showcases the virtues of being empathetic to your customers and regulators, while also adding topline and bottom-line cushions to the balance sheet.

While the majority of traditional data governance activities are “risk mitigation” and a cost-center view (e.g., BCBS 239, GDPR, CCPA), it is an increasingly changing landscape on how certain value-added responsibilities could be assigned to the Data Governance function.

It is a practical evolution of data governance, as a matured capability, can provide insights into improving the product features, not only as enhancing experiences but also as completely data-driven products.

This maturity will come from data governance roles that are subject matter experts in the data they have custody of and can contribute to revenue like any other product owner.

In closing, I would call out that these 5 mistakes and techniques to avoid these mistakes will put your data governance program on track to success!