This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Best practices for a data governance program that works: Read more in this section
- Prioritize communication and purpose for effective data governance
- Five best practices for data governance from experienced users
- With enough grassroots support, data governance programs can thrive
- Sallie Mae exec details data governance best practices
- Avoid these worst practices in enterprise data governance
Explore other sections in this guide:
More and more companies are recognizing that they’re accumulating ever-increasing amounts of data but not necessarily gaining business insights from it. The missing link is the transformation of data into information that is comprehensive, consistent, correct and current. That isn’t a problem technology can solve for you: The key step is establishing a data governance program to help your organization truly treat its data as a corporate asset by enforcing consistent definitions, rules, policies and procedures.
That’s the goal, at least. Although enterprise data governance efforts have been launched at many companies, the success rate of these initiatives hasn’t been encouraging. There’s a lot of advice available on data governance best practices that should be adopted. The following discusses the top “worst practices” and pitfalls that enterprises need to avoid. Consider it a roadmap of red flags to alert you that your governance program may be heading down the wrong path.
Buy-in but not commitment. IT often regards data governance sponsorship as business executives writing a check and putting people on a governance committee (see below). While that is in fact a great first step, the business needs to do more. People from the business side need to create the data definitions, business rules and key performance indicators (KPIs) for a data governance program; achieve agreement on them across an organization; enforce usage and compliance; and ensure that the definitions, rules and KPIs are updated on an ongoing basis as business needs evolve and change. The reality is that in the vast majority of cases, data governance tasks are merely tacked on to the already overloaded schedules of business managers instead of being made a priority, with other responsibilities correspondingly getting taken off their to-do lists. Without a real business-resource commitment, data governance will take a back seat to the daily firefight and will never be implemented effectively.
Ready, fire, aim. One thing most organizations have gotten right on the enterprise data governance efforts I’m familiar with is creating a governance steering committee and a separate governance working group. The steering committee should have business representatives from across the enterprise, and the working group typically is made up of the data stewards who do the real governance labor. What organizations often get wrong is the timing: They form these panels and assign people to them before they really understand the scope of the data governance program and the roles and responsibilities of the participants. A guaranteed way to stall a data governance initiative in its tracks and lead the business to lose interest is to prematurely organize the management framework and then realize you need a do-over.
Trying to solve world hunger or boil the ocean. A significant trap that many data governance efforts fall into is trying to solve all of an organization’s data problems in the initial phase of the project. Or companies start with their biggest data problems, issues that span the entire enterprise and are likely to be very political. It’s almost impossible to establish a data governance program while at the same time tackling data problems that have taken years to build up. This is a case in which you need to “think globally and act locally.” In other words, data problems need to be broken down into incremental deliverables. “Too big, too fast” is a sure recipe for disaster.
The Goldilocks syndrome. In the story of Goldilocks and the three bears, the little girl keeps encountering things that are either one extreme or another, which is precisely what happens on many data governance programs. Either the program is too high-level and substantive data issues are never really dealt with, or it attempts to create definitions and rules for every data field in every table in every application that an enterprise has – with the result being that the effort gets bogged down in minutiae. There needs to be a happy compromise between those two extremes that enables the data governance initiative to create real business value.
Committee overload. The good news about governance steering committees and working groups is that they get people representing various business units and departments involved in the governance process. The bad news is that they tend to get a lot of people involved in the process. Often, the more people on each committee, the more politics comes into play and the more watered-down governance responsibilities become. To be successful, try to limit the size of committees to between six and 12 people and make sure that committee members have the required decision-making authority.
Failure to implement. If the data definitions, business rules and KPIs are created but not used in any business processes, a data governance effort won’t produce any business value. The governance process needs to be a complete feedback loop in which data is defined, monitored, acted upon and changed when appropriate. Creating definitions and rules without implementing them is like getting blueprints drawn but never building a house. Similarly, ongoing communication about governance initiatives frequently doesn’t take place. That can result in business users going back to their old habits and the data governance program losing momentum.
Not dealing with change management. If enterprise data governance is to be successful, both business and IT processes need to be changed; however, the accompanying need for change management is seldom addressed. People and process issues, and the internal politics resulting from them, are challenges that need to be tackled.
Assuming that technology alone is the answer. This can be an issue within enterprises that buy master data management, data integration or data quality software – or a mix of the three – to support their data governance programs. The combination of vendor hype and high price tags often sets expectations that the software will do all the hard work and enable organizations to avoid the nasty people, process and political issues. Sorry – an enterprise may indeed find value in purchasing software, but it’s the internal interactions that make or break a governance effort.
Not building sustainable and ongoing processes. Even if the initial investment in time, money and people is adequate, many organizations don’t establish a budget, get resource commitments or design data governance processes with an eye toward sustaining the governance effort over the long haul.
Ignoring “data shadow systems.” A very common governance mistake is to focus on an enterprise’s transactional “systems of record” and business intelligence (BI) systems, assuming that all the important data can be found there. But often, key information is located in “data shadow systems” scattered throughout an organization. For example, the “real” BI reports and analytical findings used by business workers often end up in so-called spreadmarts within Excel. Ignore such data at your peril.
In general, it’s well understood that enterprise data governance needs to be a joint business and IT endeavor. What gets organizations in trouble is how they actually go about implementing governance programs. But if you stay away from the mistakes and missteps outlined above, you’ll be better positioned for governance success.
ABOUT THE AUTHOR
Rick Sherman is the founder of Athena IT Solutions, a Stow, Mass.-based firm that provides data warehouse and business intelligence consulting, training and vendor services. In addition to having more than 20 years of IT experience, Sherman writes on IT topics and is a frequent speaker at industry events. He blogs at The Data Doghouse and can be reached at firstname.lastname@example.org.