Are data governance projects doomed? According to the searchDataManagement.com article "Data governance requires checks and balances, Gartner says," a recent Gartner study predicts that "by 2008, less than 10% of organizations will succeed in their first attempts at data governance."
Less than 10%? Doesn't that seem surprising, given that business conditions are receptive to data governance because of competitive pressures, the desire for financial transparency and regulatory compliance with Sarbanes-Oxley and HIPAA? And those attempting to implement data governance read white papers and hire outside experts to help them.
But when we dig a little deeper, that 10% success rate doesn't seem so surprising, especially to those of us who have spent time in the data management trenches.
We know that data governance, like data quality, is not accomplished by listening to PowerPoint presentations or reading high-level white papers. It comes from continuous and vigilant hard work.
The key reasons for Gartner to predict this low success rate of data governance projects are "cultural barriers and a lack of senior-level sponsorship." I agree with those reasons, but there are other significant barriers. A few that I've observed in my discussions with clients are:
- Underestimating the amount of work involved. Even if you have high-level commitment, organization structures and processes, you still have to get someone to actually do the work. Who determines the data fields and business algorithms (data transformations) that need to be defined and documented? Who prioritizes the list? Who meets with all interested parties and gets agreement on the definitions? Who makes the business decisions when there is the inevitable disagreement? Who documents it all? Who implements these definitions in the applications, databases, reports and BI tools? This is a lot of ongoing work. Often the right people are not assigned to the tasks, they are not given the proper authority, they don't have the time, or not enough people are assigned.
- Long on structure and policies, short on action. It's easy to get bogged down by meetings and process discussions before any hands-on work takes place. This is a complex undertaking and the tendency is to try to "get it right" before you get into the nitty-gritty work. This approach generally can lead to "analysis paralysis" or creates complicated procedures, paperwork and bureaucracy that inhibit hands-on efforts.
- Lack of business commitment. High-level business sponsorship is a start, but the business people in the trenches have to be committed to not only initiate the data governance project but also live it on a day-to-day basis.
- Not understanding that business definitions vary. Too many times people try to settle on a single definition of a business term for an entire enterprise and wonder why they fail. The classic example is sales. From a simplistic viewpoint there should only be one definition of sales. But in a typical enterprise each business group has its own perspective -- and there are different points in the supply chain that have their own definitions. Manufacturing may consider off-the-dock as sales, logistics may include inter-company transfers, while others will not. Marketing may look at list price, sales may apply discounts (depending on their commission plans) and finance may apply returns and allowances. Which definition is right? It depends. Data governance should establish the common definition for sales (or whatever you want to call each variant) for each appropriate business situation. Then when people discuss sales they can select the appropriate definition for each business context. One size does not fit all, but common definitions for a business context can be established.
- Too much too soon. You cannot go from not having any data governance program to having an enterprise-wide implementation overnight. You need to start with a project plan that identifies priorities, tasks, resources and responsibilities. I have seen many cases where a list of all the tables and columns in the data warehouse or enterprise application were printed out and handed to the newly appointed data stewards. The expectation was that all the data stewards had to do was return to their cubicles and type the definitions of these items into documents. Data governance requires discovery, definition and documentation phases with a lot of discussions, interviews and meetings. Business and IT have to achieve a common and holistic understanding of what data is used and how it is used to make business decisions. Business people representing different functions and processes need to agree on the data definitions and business transformations used to support business decisions. This is a time-consuming and people-intensive process. If you short-circuit this process it is unlikely the definitions will be accepted or used by the business. Grandiose plans should be matched with realistic expectations.
These are just a few of the things that can trip up a data governance project. What others have you observed?
About the author
Rick Sherman has more than 18 years of business intelligence and data warehousing experience, having worked on more than 50 implementations as an independent consultant and as a director/practice leader at a Big Five accounting firm. He founded Athena IT Solutions, a Stow, Mass.-based business intelligence consulting firm. Send Rick an email.
