Some data governance programs can’t gain momentum and cannot start delivering – it feels like you’re forever cutting bait. Getting out on the water to catch a fish – deliver data governance – seems to be an aspirational dream. A pragmatic, data issue-based approach can get your program off the dock and deliver business value.

These are ten anchors that hold a program back, along with pragmatic approaches to resolve them.

Anchor 1: Dunning-Kruger disorder

This is the biggest anchor holding back your program. You have well-meaning people running your data governance program, but they lack the knowledge to deliver. It’s not an official DSM-5 disorder, as the Dunning-Kruger effect is a cognitive bias in which people with limited competence in a particular domain overestimate their abilities.

If you don’t have people with the right training, skills, background, and experience, your program will spin. The team will celebrate ‘Success!’, but what did it really do for the business, and how long have they been spinning?

Pragmatic approach: Invest in training. Data governance, metadata management, data modeling, and data quality management are essential skills in a data governance team. Encourage Certified Data Management Professional (DAMA’s CDMP) designation — the DAMA Data Management Body of Knowledge (DAMA-DMBOK) reflects the real world where data governance facilitates business guidance to the other knowledge areas, and your data governance team needs that broad-based DMBOK understanding. When you consider the cost of training, compare it to the cost of ignorance.

Anchor 2: We can’t start without policies

Core data governance policies formalize common sense management of data assets, such as “We shall catalog and create metadata for our data,” “We shall identify one or more accountable data owners for our data,” and “Sharing our data is approved by the accountable data owners.”  In some organizations, policies are so important that internal audit teams monitor compliance. Policies are important in every organization, but can take time to write, review, and get approval.

Pragmatic approach: Avoid spending a lot of time on policies at the beginning. Rather, your first policies should be short and crisp with a plan for annual reviews — with data stewards. It allows policies to evolve in parallel with program delivery and after data-issue evidence is in hand — “We need to enhance Policy XYZ because {our evidence here}.” Paraphrasing W. Edwards Deming, without evidence, you’re just another person with an opinion.

Anchor 3: Delegating data governance to someone else

Business owns the data. IT departments manage hardware and software in the service of business priorities and push data through the software ecosystem. Compared to business teams, IT departments do not have the same sense of urgency regarding data issues and governance, but we often see IT departments delegated to leading data governance programs. Although data governance is in the service of business priorities, it’s not a core function for IT.

Pragmatic approach: Data governance should be a business-led initiative that prioritizes data issues for resolution by the IT department. The 2009 DAMA DMBOK mentions that “…the best data stewards are found, not made.” Start small by searching out the most senior executive on the business-side of the house who has known data issues and offer them a program that maximizes business value but minimizes their hands-on effort.

The data governance team and IT department do all the heavy lifting, such as meeting facilitation and writing definitions and data quality rules. First drafts of meeting minutes and metadata are passed to the business side for review and approval. With light-touch business involvement, the program will be the envy of other CxO and can evolve to a corporate program.

Anchor 4: We can’t begin without domain ownership

Seeking data domain ownership from business units and CxO executives without having hard, data-issue evidence will appear like an abstract request to them. There are obvious and high-level accountabilities with data — so why spend time documenting the obvious?

Pragmatic approach: Document and prioritize data issues for resolution. When synchronizing organizational opinion regarding issues with shared data assets, the true domain owner will stand up and not let others make decisions regarding their data — you now have CxO attention and engagement.

Anchor 5: We can’t find the right people for the data governance team

Without defined roles and job descriptions, desperate managers will hire someone, anyone, who has worked with data in one way or another. The hope is they will grow into the roles, and this sometimes happens. Progress can be slow and uneven, and we start to see the Dunning-Kruger effect.

Pragmatic approach: Define three roles with basic job descriptions, hire enthusiastic talent, acquire appropriate training, and let them backup each other. There are three core roles on a data governance team:

Anchor 6: We can’t start data governance without a metadata management solution

This is a true statement! Depending on the organization, I’ve seen it take four or more years to determine requirements, run the RFP, acquire, install, and train. Metadata management software can be a hard sell across the organization, and approval will only happen with solid ROI and that’s hard to pull off. In the meantime, MS Word, MS Excel, and maybe MS Access become your de facto metadata management solution.

Pragmatic approach: “Reuse before buy, buy before build” isn’t working for you right now. However, you have a trained Metadata Management Analyst who can build a simple but functional solution. Use free data modeling software to design the repository, use an existing database to host the tables, use a low-code application platform, either in-house or open source, for the CRUD presentation layer, and use MS Excel to deliver reports from the database. You have an interim solution and — bonus — it supports metadata ROI discussions with executive management around budget time.

Anchor 7: We can’t start without data personas

The data governance team thinks of business staff in terms of personas, such as Business Data Steward, Coordinating Data Steward, Executive Data Steward, and Subject Matter Expert. Business staff could care less about persona labels but do care about HR-based job titles and descriptions. Taking time to write persona descriptions has limited value.

Pragmatic approach: It’s been said that the best stewards are found, not appointed. They absolutely want to participate in a program that resolves their data issues. The data governance team can think of these enthusiasts with whatever persona label they want to use. If the analysis of data issues surfaces a root cause in job titles and descriptions, then work with HR as it’s discovered.

Anchor 8: We can’t start without business-side data literacy training

A business-focused data literacy program typically includes components like understanding basic data concepts, data visualization skills, data cleaning and manipulation techniques, statistical analysis methods, interpreting data insights, applying data to decision-making, and ethical data handling practices. All of these are job-specific skills that business teams need to have, but it’s their responsibility to train their people. None of these are critical path topics for business to participate in a data governance program.

Pragmatic approach: Analyzing the body of data issues may surface a root cause that can be resolved with specific training and/or a review of job titles and descriptions. Work with HR as they are discovered.

Anchor 9: It’s taking forever to write strategy documents

Boiling the ocean dry to put the right prose on paper for a data strategy, or a subordinate data governance strategy, doesn’t get fish in the boat. Often, the people writing the strategy have no knowledge of strategy and/or have limited knowledge of data management. Consequently, they can’t connect the dots between critical data challenges/opportunities, root causes, effects, and resolution.

Pragmatic approach: For both strategy documents, apply guidance from Rumelt’s “Good Strategy Bad Strategy: The Difference and Why It Matters”. Regarding your data strategy, it is essential but is not on the program’s critical path — you should write it in parallel with delivering data governance and from the perspective of the organization’s business plan and data-related pain points.

For example, the data issue statement “It takes forever to find data and its accountable owner,” is a clue that suggests metadata management is a significant challenge needing some strategic thinking and tactical solution. For your data governance strategy, write 10 pages around the strategy statement of “Implement Business-Led Data Governance” and the strategic goal of “Synchronize Organizational Opinion Regarding Shared Data Assets.” Keep it simple and straightforward.

Anchor 10: We’re still designing our data governance framework

A novice team will circle around the questions of “What Do We Do?” and “How Do We Do It?”. There may also be a number of proof-of-concept initiatives, hoping to see what sticks.

Pragmatic approach: Clone something that worked elsewhere and adapt it to your specific situation. The first component in your framework should be a Data Governance Program Operating Framework (DGPOF) that guides the business-as-usual activities of your data governance team. 

The second component is a Data Governance and Stewardship Framework (DGSF) showing how your business people synchronize organizational opinion regarding shared data assets. These committees and focus groups are supported by your Data Governance Facilitation Analyst.

Conclusion

There are many anchors that prevent the actual doing of data governance. The quest for perfection is the enemy of progress, and we’ve shared a pragmatic, data issue-based approach. It gets your program moving forward, checkpointing and fine tuning as you go along.

About the Author:

William (Bill) Carroll is a practitioner. At a director’s level in two international banks he delivered functioning data governance programs from scratch and has been consulting on this topic over the past eight years with Canadian federal and provincial government departments. With a career spanning 40+ years, Carroll has hands-on experience with 10 of 11 DAMA knowledge areas in 20+ organizations, in seven different industry verticals, in four countries and on two continents. He’s worked on 14 DW/BI projects, prepared designs for three MDM initiatives, worked as a Data Architect in multiple organizations, has DBA experience with four database products, written programs in six languages on four OS platforms, worked in a data center at the beginning of his career, and started writing programs in high school. He is the author of “Pragmatic Data Governance,” available from Technics Publications.